This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(This bug depens on bug 10481 - default @role for img elements should be "img") Question: Should the presence of @usemap change the default role of img elements? Assumption: My assumption is that presence of @usemap shoud not affect the @role of an img element. Background: Opera and Webkit fails to render the @alt whenever an img element has the @usemap attribute. That is: Unlike for IMG elements without the @usemap attribute, blocking access to the @src URL, does not lead these browsers to display the alt text instead.) Also, at least in Webkit's case, the role changes from its default (role="img") to something else which again causes VoiceOver to not read the @alt attribute. (If one adds role="img" to it, _then_ Webkit will read the @alt attribute.) In contrast, Firefox and IE will display the @alt text I don't know what they do with the ARIA @role. Sub-question, depening of the solving of the primary question: Even if @usemap would change the @role of an IMG element, should such a thing impact on the presentation of the @alt attribute?
One of my observations was incorrect: Webkit does _not_ display @alt text any differently when the @usemap is present compared to what it does when it _is_ present. (Thus: Only Opera fails to do so.) The observation that VoiceOver+Webkit needs role="img" in order to read the @alt _remains_ correct. In my view, the image map usecase shows that an element can have role="img" and still be interactive.
Please use the mailing list for discussion, and only file bugs once you have a concrete request. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: Invalid use of bug system.
The bug-triage sub-team doesn't consider this to be task force priority as the issue is in good hands being followed by Lief and has already the aria keyword.
(In reply to comment #2) Some interactive elements are only interactive when they have a certain attribute: audio@controls, img@usemap, input@type="<not-hidden>", menu@type="toolbar", object@usemap, video@controles When they are interactive, HTML5 often gives them a role (or removes the role): * <audio>: @controls make them interactive, but there is no useful role, so role is unchanged * <input>: type="hidden " makes it un-interactive and also sets its role to no role (other @type values affects input's role to positively ) * <menu>: @type="toolbar" changes the role to role="toolbar" * <video>: same as <audio> Similarily one could have assumed that the role of <img> and <object> would change when they become interactive. In that regard: The ARIA tables says that <area> has role="link". But <area> is, nevertheless, *not* listed amongst the interactive elements. Why is that? An element with link role that isn't an interactive element sounds odd. We can put it like this: When object/img is an image map, is it then the <area> element that carries the link role(s)? or is it object/img? Or is it none of them - perhaps it is the particular area of the image which the <area> element designates that carries the link role(s)? We can also put it like this: can an image that acts as an image map - the img@usemap - be considered presentational? Note that when e.g. the anchor element is given the role="presentation", then - to ARIA supporting AT -it stops acting as a link. Thus, one should therefore assume that if we have <img role=presentation usemap=#m >, then the image stops acting as an image map. (Meaning what? That the area links stop working in the AT??? Or would AT handle the <area> elements regardless?) In that regard, since alt="<empty>" causes the role to be set to presentation, then this would make the image map stop working/be ignored, for AT. Meaning that if there are no parallell anhor links, the AT would not get any links.
In the section about the #the-area-element, you say: ]] and with the alternative text of the image, but without the image itself, [[ http://dev.w3.org/html5/spec/the-map-element.html#the-area-element Because I assume that you would not have spoken about "the alternative text" if you had considered that the @alt attribute could be empty or absent, it does definitely not sound as if you have in mind an image that is presentational.
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.
See <http://www.w3.org/html/wg/tracker/issues/157>.
Your use of the bug tracker is, again, inappropriate. Please read the decision policy.