ISSUE-157: A comprehensive, semantic image map specification

image-map-spec

A comprehensive, semantic image map specification

State:
CLOSED
Product:
pre-LC1 HTML 5 spec
Raised by:
Julian Reschke
Opened on:
2011-01-22
Description:
Raised on behalf of Leif Halvard Silli, see also <http://www.w3.org/Bugs/Public/show_bug.cgi?id=10482>.

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.
Related Actions Items:
No related actions
Related emails:
  1. {minutes} HTML WG telecon 2011-03-03: Issues, Decisions, Task Force Reports, and Other Business (from Paul.Cotton@microsoft.com on 2011-03-04)
  2. RE: {minutes} HTML WG telecon 2011-03-03: Issues, Decisions, Task Force Reports, and Other Business (from adrianba@microsoft.com on 2011-03-03)
  3. {agenda} HTML WG telecon 2011-03-03: Issues, Decisions, Task Force Reports, and Other Business (from rubys@intertwingly.net on 2011-03-02)
  4. {minutes} HTML WG telecon 2011-02-24: Action items and Issues (from Paul.Cotton@microsoft.com on 2011-02-24)
  5. Re: ISSUE-157 image-map-spec: Chairs Solicit Proposals (from rubys@intertwingly.net on 2011-02-24)
  6. {agenda} HTML WG telecon 2011-02-24: Action items and Issues (from Paul.Cotton@microsoft.com on 2011-02-23)
  7. {minutes} HTML WG telecon 2011-02-17: Issues, handling of features, task force reports (from Paul.Cotton@microsoft.com on 2011-02-20)
  8. {agenda} HTML WG telecon 2011-02-17: Issues, handling of features, task force reports (from mjs@apple.com on 2011-02-17)
  9. Re: request to re-open issue 133 due to submission of a change prposal. (from faulkner.steve@gmail.com on 2011-02-01)
  10. {minutes} HTML WG Telecon 2010-01-27: status of actions, new issues, closing items, new calls, charter status (from Paul.Cotton@microsoft.com on 2011-01-27)
  11. RE: Handling of non-escalated pre-Last Call bugs (from Paul.Cotton@microsoft.com on 2011-01-27)
  12. Re: Handling of non-escalated pre-Last Call bugs (from xn--mlform-iua@xn--mlform-iua.no on 2011-01-27)
  13. {agenda} HTML WG Telecon 2010-01-27: status of actions, new issues, closing items, new calls, charter status (from Paul.Cotton@microsoft.com on 2011-01-26)
  14. ISSUE-157 image-map-spec: Chairs Solicit Proposals (from rubys@intertwingly.net on 2011-01-22)
  15. HTML-ISSUE-157 (image-map-spec): A comprehensive, semantic image map specification [HTML 5 spec] (from sysbot+tracker@w3.org on 2011-01-22)

Related notes:

reverting to RAISED until a change proposal is produced

Sam Ruby, 14 Feb 2011, 15:17:27

Closed without prejudice: http://lists.w3.org/Archives/Public/public-html/2011Feb/0398.html

Sam Ruby, 24 Feb 2011, 13:03:17

Display change log ATOM feed


Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>, Chairs, Michael[tm] Smith <mike@w3.org>, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: 157.html,v 1.1 2019/10/11 08:02:24 carcone Exp $