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 21579 - Empty @alt should not imply role="presentation" if the <img> has @usemap
Summary: Empty @alt should not imply role="presentation" if the <img> has @usemap
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: steve faulkner
QA Contact: HTML WG Bugzilla archive list
URL: http://www.w3.org/TR/html5/dom.html#s...
Whiteboard:
Keywords: a11y, a11y_text-alt, CR
Depends on:
Blocks:
 
Reported: 2013-04-04 13:46 UTC by Leif Halvard Silli
Modified: 2014-01-23 17:40 UTC (History)
7 users (show)

See Also:


Attachments

Description Leif Halvard Silli 2013-04-04 13:46:29 UTC
See comment number 10 in bug 21565

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21565#c10

If empty @alt on @usemap were to imply role="presentation", then the entire image map would have to stop working. This follows from ARIA’s requirement that elements that are "linked" should be altogether disabled if one disables the "main" elment. (E.g. if you do <table role="presentation">, then all the childrene elements will be disabled as well)

Looking in Safari + VoiceOver, there is thus a difference between doing

1) <img role="presentation" usemap="#map" alt="alt" src="src" />

on one side, and on the other side only use empty alt:

2) <img usemap="#map" alt="" src="src" />

In the first case, the entire image map stops working, while in the other case, the image map works just fine. (Also, in Safari + VoiceOver, the alt of the img in the image map seems to not be presented to the user - only the alt of the area elements are presented.)

I think we can take for granted that there are many image maps around where there is an empty @alt, and where the author have not intended that this would make the image map stop working in AT.

Further more, adding role="presentation" on an anchor element does as well not remove its interactivity. And given that image maps are links, to the extent that HTML5 requires the CSS img:link{} selector work for images that are image maps, it does not make sense to say that empty alt should remove the image map <img> elements from the accessibility tree.
Comment 1 Leif Halvard Silli 2013-04-04 13:48:26 UTC
(In reply to comment #0)

Sorry, here, I did not mean 'disabled':

>(E.g. if you do <table role="presentation">, then all the childrene elements will be disabled as well)

I meant that the would inherit the presentation role from the 'linked' main element, the <table> element.
Comment 2 steve faulkner 2013-05-28 09:13:31 UTC
(In reply to comment #0)
> See comment number 10 in bug 21565
> 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21565#c10
> 
> If empty @alt on @usemap were to imply role="presentation", then the entire
> image map would have to stop working. This follows from ARIA’s requirement
> that elements that are "linked" should be altogether disabled if one
> disables the "main" elment. (E.g. if you do <table role="presentation">,
> then all the childrene elements will be disabled as well)
> 
> Looking in Safari + VoiceOver, there is thus a difference between doing
> 
> 1) <img role="presentation" usemap="#map" alt="alt" src="src" />
> 
> on one side, and on the other side only use empty alt:
> 
> 2) <img usemap="#map" alt="" src="src" />
> 
> In the first case, the entire image map stops working, while in the other
> case, the image map works just fine. (Also, in Safari + VoiceOver, the alt
> of the img in the image map seems to not be presented to the user - only the
> alt of the area elements are presented.)
> 
> I think we can take for granted that there are many image maps around where
> there is an empty @alt, and where the author have not intended that this
> would make the image map stop working in AT.
> 
> Further more, adding role="presentation" on an anchor element does as well
> not remove its interactivity. And given that image maps are links, to the
> extent that HTML5 requires the CSS img:link{} selector work for images that
> are image maps, it does not make sense to say that empty alt should remove
> the image map <img> elements from the accessibility tree.

Can you provide a concise description of the chnages you think need to be made?
Comment 3 Leif Halvard Silli 2013-05-28 13:12:22 UTC
(In reply to comment #2)

> Can you provide a concise description of the chnages you think need to be
> made?

Concise change proposals:

   (1) Make it an authoring error for img elements with the usemap attribute set to leave the @alt attribute empty.

   (2) Say that Aria-hidden="true" on on an img element with the usemap attribute set, should disable the entire image map (including aria links). (Currently, in VoiceOver on OSX 10.7, setting @hidden on the img element, disables the image map, whereas setting aria-hidden="true", does not disable it. (Note that the very <map> element should not be disabled - as it could be used by another <img> element - it is the very <img> with usemap that should be disabled.

   NOTE: Current thinking is (I believe) that role="presenation" is not supposed to impact interactive elements/content. So my proposals regarding role=presentation are nullfied. However the thinking I applied to role="presentation" is still valid if aria-hidden="true" is set for the img element.

Justification:

   This bug is much older than from April 2013 ... Thinking it through today, this is how I see it:

   An analogy to what an img@usemap with an empty @alt represents, 
   would be an img link where the alt is empty: 

   <a href=foo><img src="abc" alt="" /></a>

   In an image link, if the <img> element has empty alt, then the
   img *does* have presentaton role. However, it is an authoring
   error to have empty alt inside an image link, when the image is
   the link’s sole content.

   Now, an img element with the usemap attribute set, is a bit tricky to analyse: It *is* an interactive element. And, w.r.t. CSS, then its borders *are* supposed to become green if you do  img:link{border:green solid 3px;}. (Last check, only some browsers implemented it.) However, from ARIA’s point of view, an <img> with usemap, does not have link role - the link role is instead linked (sic) to the area elements.

   Since I filed this bug, I believe there has been some clarification with regard to whether role="presentation" should have an effect on interactive content. Namely, I think that role="presentation" on interactive content, is not supposed to have any effect on interactive elements. However, it still stands that if you e.g. add @hidden to the <img>, the entire image map should be disabled. And thus, it follows that the same should happen if you add aria-hidden="true" to the <img>.
Comment 4 Leif Halvard Silli 2013-05-28 13:13:46 UTC
(In reply to comment #3)

>    (2) Say that Aria-hidden="true" on on an img element with the usemap
> attribute set, should disable the entire image map (including aria links).
> (Currently, in VoiceOver on OSX 10.7, setting @hidden on the img element,
> disables the image map, whereas setting aria-hidden="true", does not disable
> it. (Note that the very <map> element should not be disabled - as it could
> be used by another <img> element - it is the very <img> with usemap that
> should be disabled.

The above is probably clumpsy said. The point is that it should be possible to reuse the map for another image map.
Comment 5 steve faulkner 2013-12-08 10:42:20 UTC
(In reply to Leif Halvard Silli from comment #3)
> (In reply to comment #2)
> 
> > Can you provide a concise description of the chnages you think need to be
> > made?
> 
> Concise change proposals:
> 
>    (1) Make it an authoring error for img elements with the usemap attribute
> set to leave the @alt attribute empty.
> 
>    (2) Say that Aria-hidden="true" on on an img element with the usemap
> attribute set, should disable the entire image map (including aria links).
> (Currently, in VoiceOver on OSX 10.7, setting @hidden on the img element,
> disables the image map, whereas setting aria-hidden="true", does not disable
> it. (Note that the very <map> element should not be disabled - as it could
> be used by another <img> element - it is the very <img> with usemap that
> should be disabled.
> 
>    NOTE: Current thinking is (I believe) that role="presenation" is not
> supposed to impact interactive elements/content. So my proposals regarding
> role=presentation are nullfied. However the thinking I applied to
> role="presentation" is still valid if aria-hidden="true" is set for the img
> element.
> 
> Justification:
> 
>    This bug is much older than from April 2013 ... Thinking it through
> today, this is how I see it:
> 
>    An analogy to what an img@usemap with an empty @alt represents, 
>    would be an img link where the alt is empty: 
> 
>    <a href=foo><img src="abc" alt="" /></a>
> 
>    In an image link, if the <img> element has empty alt, then the
>    img *does* have presentaton role. However, it is an authoring
>    error to have empty alt inside an image link, when the image is
>    the link’s sole content.
> 
>    Now, an img element with the usemap attribute set, is a bit tricky to
> analyse: It *is* an interactive element. And, w.r.t. CSS, then its borders
> *are* supposed to become green if you do  img:link{border:green solid 3px;}.
> (Last check, only some browsers implemented it.) However, from ARIA’s point
> of view, an <img> with usemap, does not have link role - the link role is
> instead linked (sic) to the area elements.
> 
>    Since I filed this bug, I believe there has been some clarification with
> regard to whether role="presentation" should have an effect on interactive
> content. Namely, I think that role="presentation" on interactive content, is
> not supposed to have any effect on interactive elements. However, it still
> stands that if you e.g. add @hidden to the <img>, the entire image map
> should be disabled. And thus, it follows that the same should happen if you
> add aria-hidden="true" to the <img>.

Hi Leif, 

>    (1) Make it an authoring error for img elements with the usemap attribute
> set to leave the @alt attribute empty.

sounds reasonable, will do

>    (2) Say that Aria-hidden="true" on on an img element with the usemap
> attribute set, should disable the entire image map (including aria links).
> (Currently, in VoiceOver on OSX 10.7, setting @hidden on the img element,
> disables the image map, whereas setting aria-hidden="true", does not disable
> it. (Note that the very <map> element should not be disabled - as it could
> be used by another <img> element - it is the very <img> with usemap that
> should be disabled.
> 

this sounds like this is an implementation issue, setting aria-hidden on an <img> should remove the img from the acc tree, so the image map should not be represented in the acc tree (for the for the aria-hidden <img>. will look into it, but suspect the HTML spec is not the place for this to be specified.
Comment 6 github bugzilla bot 2013-12-09 11:04:39 UTC
Commit pushed to master at https://github.com/w3c/html

https://github.com/w3c/html/commit/2963592fe3736e3d0e4b5a0c4413931cb1c144d7
add advice on image maps

see bug 21579
Comment 7 github bugzilla bot 2013-12-24 13:47:17 UTC
Commit pushed to master at https://github.com/w3c/html

https://github.com/w3c/html/commit/7fbdbb11ae4e188c90b69961b7f1a9046c27b45b
updated image alt example after feedback

see bug 21579
Comment 8 github bugzilla bot 2014-01-16 15:11:50 UTC
Commits pushed to CR at https://github.com/w3c/html

https://github.com/w3c/html/commit/2963592fe3736e3d0e4b5a0c4413931cb1c144d7
add advice on image maps

https://github.com/w3c/html/commit/7fbdbb11ae4e188c90b69961b7f1a9046c27b45b
updated image alt example after feedback
Comment 9 steve faulkner 2014-01-23 17:40:39 UTC
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: Accepted
Change Description: refer to commit https://github.com/w3c/html/commit/a68049c2740788ec7ab12a6c036d51d0b9e42d0f
Rationale: The element was missing.if the image is being used as an image map then it should not be removed from the accessibility tree - alt="" = role presentation which is meant to remove it from the accessibility tree, so have modified this case so that the presence of a usemap in combo with alt="" does not override the img role.