[html4all] [longdesc]:hover {cursor:context-menu}

[Leif Halvard Silli]

Laura, 

    About the idea I presented in public-html about changing the cursor 
when hovering about an image with @longdesc, then iCab basically has 
this style rule:
	img[longdesc]{cursor:context-menu;} 

    In bug 258960 from september 2004, iCab's solution was also 
proposed for Mozilla/Firefox. [2] That bug even contains context-menu 
icon examples, similar to those iCab uses. [1] The bug got a WONTFIX 
with the justification that Windows does not use a particular context 
menu icon on hovers. Which could be a reason to introduce another 
cursor icon - for example an (i) icon? Or - perhaps the things looks 
different on Windows today? But is it really Windows related at all?

	Since I use iCab, I can tell about my experience the context-menu 
parser. The thing is: I did not understand - before opening the  
attachment in the bug [1] - that iCab does in fact show a context-menu 
icon. [1]  I had, till now, interpreted the square inside iCab icon as 
a "document icon" rather than the menu it is supposed to mimic. 
(Because, after, all, I know that longdesc is supposed to lead me to a 
document...)

	I find that a context menu exists all the time - control-clicking 
almost anywhere on mac, one gets a context-menu. As such an icon only 
for the purpose of informing that there is a context-menu, is almost 
without purpose. (Even in Windows, I find that images always get a rich 
and long context menu.)  So perhaps there *is* reason to look at 
another icon? *Or* perhaps there is reason to explain in CSS3 - or 
wherever - that there is no reason to pay too much *attention* to the 
very name "context-menu" - the point is that it is to attract attention 
to the context-menu?

Are there any issues with using [longdesc]{cursor:context-menu;} today? 
Could a pointer icon with an (i) icon be used instead?

	The Mozilla bug (as well as Mozillas' longdesc bug [1]) btw had a link 
to the UAAG10 Technical guidelines NOTE, [2]  which has this 
interesting text about presentation of a long description (that is: the 
long description document):

]]
3. Allow the user to configure how the user agent renders a long
   description (e.g., longdesc in HTML 4 [HTML4]). Some 
   possibilities include:
    1. Render the long description in a separate view.
    2. Render the long description in place of the associated
       element.
    3. Do not render the long description, but allow the user to
       query whether an element has an associated long description
       (e.g., with a context-sensitive menu) and provide access to
       it.
    4. Use an icon (with a text equivalent) to indicate the 
       presence of a long description.
    5. Use an audio cue to indicate the presence of a long 
       description when the user navigates to the element.
[[

How does these 1 + 5 points from 2002 match reality in 2011? Well:

 0) The first idea is that users should be allowed to configure
    some options for how to present @longdesc. Point 1 to 5 are 
    meant to list some options on the table. Clearly, I would say,
    it must have been meant that there should be a default. E.g.
    if you are blind, then and audio cue is what you want .... 
    Though, as we can see, this text also considers that the 
    description could be automatically rendered - at least that is
    the impression I get from reading 1), 2) and 3) together.
    Reality: UAs don't really offer many fixed configurations.
    (Only the general user CSS and user Javascript adaptation
    is available.)

 1) Most/All UAs render the description in a separate view/window,
    so this matches reality.
 2) To let the long description render instead of the image, is
    an interesting thing which I don't think any UA support.
    This is, sort of, comparable to ARIA-describedby in the sense
    that it leads to immediate presentation. John's javascript
    solution comes pretty close, though that solution should may
    be rather be seen as a variant of 1) as the user must activate
    the long description text with a click.
 3) Basically this point suggests having a context menu, which we
    know is the common solution = a reality match.
 4) Using an icon (or text equivalent) to indicate longdesc link -
    the only implementation is the one in iCab, which displays a
    different cursor when there is a longdesc. This shows that the 
    thought of letting everyone see the that there is a longdesc,
    is old. Supports both the cursor idea and the ::marker idea.
 5) Audio cue is used by most screenreaders. Reality match.

It is notable that focus navigation is not mentioned.

PS: Laura, You should perhaps a link to the UAAG Techniques in your 
research? And may be the Mozilla bugs too.

[1] 
http://lists.w3.org/Archives/Public/public-html/2011Apr/att-0134/icab-longdesc-implementation
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=258960
[3] https://bug258960.bugzilla.mozilla.org/attachment.cgi?id=169071
[4] http://www.w3.org/TR/UAAG10-TECHS/guidelines#long-descriptions
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1996#c29
[6] http://www.w3.org/TR/UAAG20/
-- 
leif halvard silli