[Bug 10482] Specify how @usemap affects role (of <img> and <object>)

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10482

--- Comment #6 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-01-22 04:31:48 UTC ---
Here is the suggested title and text for the Issue Tracker.

TITLE: A comprehensive, semantic image map specification

TEXT:  

Image maps have a complex structure which UAs and AT understand differently. At
the same time HTML5 adds ARIA, which also have no particular model for how
image maps works.  This requires as fine grained understandig and specification
of image maps.

The complex structure is caused by the fact that elements outside an <img>
affects the image - thus conceptually, the <area>s are inside (or "around" -
like anormal anchor elment) the <img> even if the container <map> element is
outside the image map. (On the other side, image maps for object@usmap can be
placed _inside_ the <object>.)

Examples of UA/AT differences:
- at least one UA (Opera) seems  treat <area> elements of the <map> element as
the content of the  img@usemap element, causing that the @alt of the img@usemap
element is ignored.
- another (VoiceOver) seems to treat image maps quite differently on OSX 10.6
compared to 10.5, and it is not  easy to conclude if there is progress 10.6 
- some AT (Jaws) seems to treat stray <area> elements as links, even outside
<map>
- some AT treat the <area> as a links if they have @role="link", but VoiceOver
seems not to 

HTML5 issues:
- <area> isn't listed amongst the interactive elements, while
img@usemap/object@usemap are listed as interactive elements. E.g. <area> has
role="link" but still isn't considered interactive (because, I assume, it
"interactivates" the image and not itself.)

HTML4 issue
The editor's solution to Bug 10518 says that authors may place both <area> and
<a> in the same <map>, for better maintainance. But HTML4 (see HTML4 section
13.6 Image maps) then has rules which says that UAs then should ignore either
the <area>s or the <a>s. (Yes, this is linked to the fact that <a> in HTML4 can
take the @coords and @shape attributes. However, in my experience, some AT
(VoiceOver, it could seem) may still work that way.)  And, as for instance text
based browsers do handle the <area> elements, and we don't want them - or any
other UA/AT - to get a double set of links. 

Other things:
- there is no method in ARIA for pointing from the img@usemap element to the
<map> element. And this perhaps have implications of what one should *not* do.
E.g. to point from the img@usemap element to the <map> element with
aria-labelledby might not be a good idea, for instance, unless the purpose is
to make the AT not treat the image map as an image map
- can the image of img@usemap be presentational? I.e. can it have an empty @alt
? And does this affect how AT treat the area elements.

This issue  is not about "fixing ARIA", but about establishing a image map
model which, eventually, lets ARIA implement image maps. (In that regard, I
also mentioned image maps in this comment to on the ARIA 1.0 spec
http://lists.w3.org/Archives/Public/public-pfwg-comments/2011JanMar/0001 )

The purpose of this issue is to bring a clear specification of image maps with
a clear understanding of how ARIA fits in.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Saturday, 22 January 2011 04:31:50 UTC