This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27787 - Sequential Navigation Focus Order for Image Maps
Summary: Sequential Navigation Focus Order for Image Maps
Status: RESOLVED MOVED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML a11y Task Force (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: This bug has no owner yet - up for the taking
URL:
Whiteboard:
Keywords: a11y_focus
Depends on:
Blocks:
 
Reported: 2015-01-08 18:27 UTC by Rodney Rehm
Modified: 2016-04-28 15:58 UTC (History)
7 users (show)

See Also:


Attachments

Description Rodney Rehm 2015-01-08 18:27:03 UTC
"User agents may also allow individual area elements representing hyperlinks to be selected and activated (e.g. using a keyboard)."

Every major user agent (Gecko, Trident, WebKit, Blink) adds <area> elements to the document's sequential navigation focus order. But because the specification does not explain *how* that should happen, they disagree on the order.

In Blink and WebKit the <area> elements are added to the sequence in DOM order. In Gecko and Trident <area> themselves are inserted into the sequence in place of the <img usemap=""> actually using the map containing the <area> elements.

So in Blink and WebKit the image maps are accessible, just not in place of the image, but wherever they appear in the document. The <map> element might be placed right after <body>, but the <img usemap> may be used in a modal <dialog> element. There is no way to Tab through the image's map. (using the <dialog> here is just an extreme example to make a point.)


"Because a map element (and its area elements) can be associated with multiple img and object elements, it is possible for an area element to correspond to multiple focusable areas of the document."

In Trident those multiple references to the same map cause the the associated <area> elements to occur multiple times in the document's sequential navigation focus order. In Gecko this should happen, but is masked by a bug. In Blink and WebKit the <area> elements are only tabbed through once.


Can we get the Trident behavior added to the specification?
Comment 1 Charles McCathieNevile 2015-01-09 11:30:58 UTC
Will run this past the accessibility task force, but it seems to make sense that the relationship between a label and a form control is roughly the same as an image and an image map, with the proviso that area elements are not rendered by default - so as if a label applied to a form button that was not, itself, going to be rendered…
Comment 2 LĂ©onie Watson 2016-04-28 15:58:01 UTC
Moved to HTML on Github:
https://github.com/w3c/html/issues/297