This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Spec currently says that <img> elements with a non-empty @alt, has 'no role' as the default role. However, it is common for user agents to treat the role of such img elements as as having role="img". A default to role="img" is also in line with the A11Y TF proposal: http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html
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: Rejected Change Description: no spec change Rationale: For most images, role=img is unsuitable, because the <img> doesn't represent an image, but something else (e.g. text as part of a link).
(In reply to comment #1) > 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: Rejected > Change Description: no spec change > Rationale: For most images, role=img is unsuitable, because the <img> doesn't > represent an image, but something else (e.g. text as part of a link). 2 questions: 1. Can you provide data to back that up? 2. does this mean that a user agent that maps an <img> to a role="img" by default is non conforming?
1. No formal data, no, but if you browse the Web you'll quickly see that most images are either presentational (alt=""), or logos, or text in buttons or links, etc. Very few are actually interesting. Even on pages where you'd think there were interesting images, they're in the minority -- e.g. a Flickr page has on the order of 20 images only one of which is really an image from the user's perspective. 2. Yes. It would also have a poor user experience.
I doublechecked the data for a Flickr page and the photo page I tested has 35 <img> tags. All images 2500 pixels in size and larger were thumbnails or other content stuff (maps and the real photos).. perhaps the role should be applied based on photo size? That seemed flawed, as well. Opt-in for the role=img is certainly a bummer, but I think it's fair to say the role=img semantics wouldn't be accurate for most <img> elements.
(In reply to comment #4) > I doublechecked the data for a Flickr page and the photo page I tested has 35 > <img> tags. > All images 2500 pixels in size and larger were thumbnails or other content > stuff (maps and the real photos).. perhaps the role should be applied based on > photo size? That seemed flawed, as well. > Opt-in for the role=img is certainly a bummer, but I think it's fair to say the > role=img semantics wouldn't be accurate for most <img> elements. We all know that table/td/tr are widely abused and so why not prohibit user agents from providing the mappings for these elements to accessibility APIs? Assistive technology (screen readers) generally offer a range of preferences to users on how they want the UI presented to them aurally. By not providing the role information via an accessibility API users are being denied the choice. image role information provides necessary context to the text alternative for vision impaired users (not just blind).
This is mind-boggling: an image is not an image because most people use it as either a background image, a mood image, an image of a logo, or an image of text? That's still an image. In your opinion, what would be the correct role for a logo or an image with alternative text? Please, let's move on to more pressing issues and let's not waste time discussing the obvious: the default role of an image is image, what else?
I'm puzzled by what it means for <img> to have no role by default instead of img role, in terms of browser implementation. I would expect the effect of role=img to cause the element it is applied to (and its contents as a unit) to be treated like an <img> element - that is to say, in the appropriate contexts and depending on user configuration, a screen reader might replace it entirely with its text equivalent, might combine it as a unit with a link where it is the sole contents, or might flag it as an image. In the case of images that are not an <img> element, this would involve a form of text equivalent other than alt, e.g. specified by aria-labeledby, but in WebKit's accessibility code, those are presented to AT in the exact same way. In brief, from the implementation perspective, I think it is factually true that an <img> with missing or non-empty alt will be treated the same as if it had role=img. (<img> with empty alt is exceptional and treated the same as role=presentation, of course). In fact, as far as I can tell from our accessibility code, <img> and role=img are treated exactly the same except in what constitutes valid sources of text equivalents. Given all this, I am not sure what it means to say <img> does not have img as a default role. Is WebKit buggy? Should we be somehow treating <img> with no explicitly specified role differently from <img role=img>?
(In reply to comment #7) > I'm puzzled by what it means for <img> to have no role by default instead of > img role, in terms of browser implementation. I would expect the effect of > role=img to cause the element it is applied to (and its contents as a unit) to > be treated like an <img> element - that is to say, in the appropriate contexts > and depending on user configuration, a screen reader might replace it entirely > with its text equivalent, might combine it as a unit with a link where it is > the sole contents, or might flag it as an image. In the case of images that are > not an <img> element, this would involve a form of text equivalent other than > alt, e.g. specified by aria-labeledby, but in WebKit's accessibility code, > those are presented to AT in the exact same way. > In brief, from the implementation perspective, I think it is factually true > that an <img> with missing or non-empty alt will be treated the same as if it > had role=img. (<img> with empty alt is exceptional and treated the same as > role=presentation, of course). In fact, as far as I can tell from our > accessibility code, <img> and role=img are treated exactly the same except in > what constitutes valid sources of text equivalents. > Given all this, I am not sure what it means to say <img> does not have img as a > default role. Is WebKit buggy? Should we be somehow treating <img> with no > explicitly specified role differently from <img role=img>? I think you will find that EVERY user agent that maps html elements to accessibility APIs, maps the <img> element to an image/graphic role in MSAA, IA2, ATK, UIA etc, but it appears that the editor is saying that these will all be non conforming implementaions in HTML5
The default role for images, should be role="img". If the "image" element is not meant to represent images, then these other roles should be defined better in HTML 5. I agree with Martin - this discussion is daft.
Sorry but most, some, a few web statistics on how alt text is used does not cut it. When you encounter alt text on an image it needs to be handled properly. The fact is that if you have an img in web content it maps to a role of img or graphic in the accessibility API. A screen reader user may need to know that there is a graphic on the page. Also, if it were just the alt text that were passed along to the screen reader then they would want to be able to navigate the text in the virtual buffer - which they would not do and makes no sense to do for images. If the AT decides, when it has not alt text to toss it from the UI the user sees then fine. The default role needs to be img.
(In reply to comment #3) Ian, In bug 10478 [1] you argue in favor of keeping the defaul trole for <table> in sync with ARIA, even if ARIA might be incorrect. Why don't you apply hte same logic to <img>? http://www.w3.org/TR/wai-aria/complete#img ]] Related Concepts: DTB imggroup HTML img [[ http://www.w3.org/TR/wai-aria/complete#grid ]] Base Concept: HTML table [[ [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10478#c3
OK, folks, let's not pile on. It's not necessary to add comments to this bug unless you have new useful info to add.
What differences will there be in an AT user's experience when encountering <img role=note> as opposed to when encountering a <img role=img>?
>------- Comment #13 From Ian 'Hixie' Hickson 2010-09-09 09:54:41 ------- >What differences will there be in an AT user's experience when encountering ><img role=note> as opposed to when encountering a <img role=img>? Currently, the AT will probably ignore it (as with any user agent that encounters a role it doesn't understand), or it may trigger heuristic evaluation depending on content. But I guess, current implementations aren't the point right? As we are trying to improve the markup language and future UA implementations. Hence many peoples support for this bug, as it seems like a no-brainer. FWIW, the image role=note etc is an interesting idea, but that should be an expansion on the default which should really be that the default role of <IMG> should be "img", unless any other annotation is explicitly provided by the author.
*** Bug 10485 has been marked as a duplicate of this bug. ***
Forwarding blocks relationship from duplicate
(In reply to comment #13) > What differences will there be in an AT user's experience when encountering > <img role=note> as opposed to when encountering a <img role=img>? Testing in VoiceOver on Mac OS X 10.5: A role="note" element is expected to have text or element children. Thus if you have <p role="note">Foo</p>, then VoiceOVer reads "Foo". Wheras for an <img role="note" alt="Foo">, then there are no text or element children, and thus VoiceOver just stops reading. Whereas if you have <img alt="Foo."> or <img role="img" alt="Foo.">, then "Foo" is read.
(In reply to comment #17) > (In reply to comment #13) > > What differences will there be in an AT user's experience when encountering > > <img role=note> as opposed to when encountering a <img role=img>? > > Testing in VoiceOver on Mac OS X 10.5: > > A role="note" element is expected to have text or element children. Thus if you have <p role="note">Foo</p>, then VoiceOVer reads "Foo". Note that if you had <p role="teapot">Foo</p>, the UA would probably read out "Foo", unless the role is recognised by the UA it will just read out the contents of the containing element. > Wheras for an <img role="note" alt="Foo">, then there are no text or element > children, and thus VoiceOver just stops reading. Ok, that is to be expected. > Whereas if you have <img alt="Foo."> or <img role="img" alt="Foo.">, then >"Foo" is read. That is also to be expected, in HTML4, img==img. The point is that this default is no longer defined the same way in HTML 5. It makes sense to me that the role is defined in a similar way, for backwards compatibility etc and that the element has the capability to take explicit annotations at the authors discretion. The implementation can be modified by UA/AT vendor.
(In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #13) > > A role="note" element is expected to have text or element children. Thus if you have <p role="note">Foo</p>, then VoiceOVer reads "Foo". > > Note that if you had <p role="teapot">Foo</p>, the UA would probably read out > "Foo", unless the role is recognised by the UA it will just read out the > contents of the containing element. > > > Wheras for an <img role="note" alt="Foo">, then there are no text or element > > children, and thus VoiceOver just stops reading. > > Ok, that is to be expected. In case of <p role="img">Foo</p>, then the "Foo" is *not* read, since an role="img" element is not expected to have children. Whereas in case of <p id="bar" role="img" aria-labeledby="bar" >Foo!</p> then the content of th <p> is read, since @aria-labelledby point to the <p>. I don't know ... but I think VoiceOver has one of the best ARIA implementations out there. At elast better than the latest release of Jaws. (But Jaws has much beter *native* support for HTML.) > > Whereas if you have <img alt="Foo."> or <img role="img" alt="Foo.">, then >"Foo" is read. > > That is also to be expected, in HTML4, img==img. > > The point is that this default is no longer defined the same way in HTML 5. I simply answered Ian's question. Presumably, he asked because he is willing to listen to the arguments. Thus "no longer" is a bit early to say.
testing with JAWS 11.0.1467 on Windows 7 Home Premium <p role="note">Foo</p> JAWS reads: "note landmark foo" <p><img role="note" alt="Foo"></p> JAWS reads: "note landmark graphic foo" <p><img alt="Foo."></p> JAWS reads: "graphic foo" <p><img role="img" alt="Foo."></p> JAWS reads: "graphic foo"
testing with JAWS 11.0.1467 on Windows 7 Home Premium <p role="teapot">Foo</p> JAWS reads: "foo" (does not identify as landmark or by landmark type)
(In reply to comment #1) > 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: Rejected > Change Description: no spec change > Rationale: For most images, role=img is unsuitable, because the <img> doesn't > represent an image, but something else (e.g. text as part of a link). You are countermanding your own semantics. The first sentence for the img element states: An img element represents an image. Now you're saying that img doesn't represent an image. Your reasoning is confusing, your application of semantics, flawed. Either an img is an image, in which case it is an image to every user agent, regardless of author intent. Or it is not, in which case, it is not an image to every user agent. You can't have it both ways.
Removing TrackerRequest keyword since this bug is still open and is awaiting re-resolution from the Editor based on the new info provided. (I assume it was added in error.)
(In reply to comment #22) > (In reply to comment #1) > > Rationale: For most images, role=img is unsuitable, because the <img> doesn't > > represent an image, but something else (e.g. text as part of a link). > > You are countermanding your own semantics. The first sentence for the img > element states: > > An img element represents an image. Regarding "represents": Several other places in the spec, the word 'represents' has a link to a paragraph with a definition of 'represents': [*] ]] In the absence of style-layer rules to the contrary (e.g. author style sheets), user agents are expected to render an element so that it conveys to the user the meaning that the element represents, as described by this specification. [[ [*] http://dev.w3.org/html5/spec/rendering#represents And in a recent bug (that I unfortunately was unable to relocate, despite searching for it a lot ...), Ian explained to Maciej that CSS can used to used to adjust the semantics stylistically. While ARIA can be used to futher adjust the semantics, for AT users. HTML even has some features of its own for adjusting the semantics for AT users: an empty @alt means that an <img> is not represented as an image to AT users. > Either an img is an image, in which case it is an image to every user agent, > regardless of author intent. Or it is not, in which case, it is not an image to > every user agent. Even if the title of this bug is 'default role of <img> should be "img"', the bug is only about <img> elements which do not have an empty @alt attribute. With that qualification, I believe that you do indeed point at an inconsistency in Ian's line of argumentation inside this bug report: Whenever there isn't something AT specific (such as an empty @alt) which modifies the the semantics of the <img> element, then an <img> represents an image, and thus its role should be "img".
(In reply to comment #24) > (In reply to comment #22) > > (In reply to comment #1) > > > Rationale: For most images, role=img is unsuitable, because the <img> doesn't > > > represent an image, but something else (e.g. text as part of a link). > > > > You are countermanding your own semantics. The first sentence for the img > > element states: > > > > An img element represents an image. > Regarding "represents": Several other places in the spec, the word 'represents' > has a link to a paragraph with a definition of 'represents': [*] > ]] > In the absence of style-layer rules to the contrary (e.g. author style sheets), > user agents are expected to render an element so that it conveys to the user > the meaning that the element represents, as described by this specification. > [[ > [*] http://dev.w3.org/html5/spec/rendering#represents > And in a recent bug (that I unfortunately was unable to relocate, despite > searching for it a lot ...), Ian explained to Maciej that CSS can used to used > to adjust the semantics stylistically. While ARIA can be used to futher adjust > the semantics, for AT users. HTML even has some features of its own for > adjusting the semantics for AT users: an empty @alt means that an <img> is not > represented as an image to AT users. > > Either an img is an image, in which case it is an image to every user agent, > > regardless of author intent. Or it is not, in which case, it is not an image to > > every user agent. > Even if the title of this bug is 'default role of <img> should be "img"', the > bug is only about <img> elements which do not have an empty @alt attribute. > With that qualification, I believe that you do indeed point at an inconsistency > in Ian's line of argumentation inside this bug report: Whenever there isn't > something AT specific (such as an empty @alt) which modifies the the semantics > of the <img> element, then an <img> represents an image, and thus its role > should be "img". leif wrote: >an empty @alt means that an <img> is not represented as an image to AT users. currently that is not strictly true, an <img> is still mapped to accessibility APIs as an image, AT use the alt="" as flag to indicate the image should not be announced to users. In HTML5 alt="" is mapped to role="presentation" so AT will no longer be able to provide a choice to users as to whether they get an indication that an image is present or not.
(In reply to comment #25) > (In reply to comment #24) > > (In reply to comment #22) > > > (In reply to comment #1) > > > > Rationale: For most images, role=img is unsuitable, because the <img> doesn't > > > > represent an image, but something else (e.g. text as part of a link). > leif wrote: > >an empty @alt means that an <img> is not represented as an image to AT users. > > currently that is not strictly true, an <img> is still mapped to accessibility > APIs as an image, AT use the alt="" as flag to indicate the image should not be > announced to users. > > In HTML5 alt="" is mapped to role="presentation" so AT will no longer be able > to provide a choice to users as to whether they get an indication that an image > is present or not. So <img alt="" src="*"> as currently implemented maps to role="img", except that isn't (by default) announced?
(In reply to comment #26) > (In reply to comment #25) > > (In reply to comment #24) > > > (In reply to comment #22) > > > > (In reply to comment #1) > > > > > Rationale: For most images, role=img is unsuitable, because the <img> doesn't > > > > > represent an image, but something else (e.g. text as part of a link). > > leif wrote: > > >an empty @alt means that an <img> is not represented as an image to AT users. > > > > currently that is not strictly true, an <img> is still mapped to accessibility > > APIs as an image, AT use the alt="" as flag to indicate the image should not be > > announced to users. > > > > In HTML5 alt="" is mapped to role="presentation" so AT will no longer be able > > to provide a choice to users as to whether they get an indication that an image > > is present or not. > So <img alt="" src="*"> as currently implemented maps to role="img", except > that isn't (by default) announced? in firefox and IE yes on windows . its not possible to check on the other browsers as they don't expose the accessibility API information well. In safari 5 on Mac OSX <img alt=""> is not exposed as an image.
(In reply to comment #25) > In HTML5 alt="" is mapped to role="presentation" so AT will no longer be able > to provide a choice to users as to whether they get an indication that an image > is present or not. Taking away an option for the user, is one side of it, indeed. Is e.g. JAWS really going to do that? If they aren't, then role=_img_ on an <img> with empty @alt will work differently in JAWS compared with AT which _does_ map alt="" to role="presentation". See below. (In reply to comment #27) > (In reply to comment #26) > > So <img alt="" src="*"> as currently implemented maps to role="img", except > > that isn't (by default) announced? > > in firefox and IE yes on windows . its not possible to check on the other > browsers as they don't expose the accessibility API information well. > > In safari 5 on Mac OSX <img alt=""> is not exposed as an image. I believe that it is simple to test this, without a11y API info. Simply: 1. Insert an <img> with an empty alt="" and set it to role="img" into a page. (In other words <img src="*" role="img" alt="">.) 2. Check whether the role="img" causes the AT to announce the <img> to the user, despite the empty @alt. In Safari 5 with VoiceOver, the above <img> is announced to the user. Not so in Jaws with IE. (Unless, of course, aria-labelledby="*" points to a label. which again means - VOILA - that it is incorrect to have role="presentation" as strong semantics for an <img> with empty alt=""! I'll open separate bug.) It seems to me that it is quite important to clarify whether VoiceOver or JAWS is correct w.r.t. exposing an <img> with empty alt="" and role="img". (That said, the opposite isn't true: setting <img alt="Foo" role="presentation" > does not make the AT read the @alt text.) PS: Doesn't this bug depend on bug 10666?
(In reply to comment #28) > (In reply to comment #25) > > In HTML5 alt="" is mapped to role="presentation" so AT will no longer be able > > to provide a choice to users as to whether they get an indication that an image > > is present or not. > Taking away an option for the user, is one side of it, indeed. Is e.g. JAWS > really going to do that? If they aren't, then role=_img_ on an <img> with empty > @alt will work differently in JAWS compared with AT which _does_ map alt="" to > role="presentation". See below. > (In reply to comment #27) > > (In reply to comment #26) > > > So <img alt="" src="*"> as currently implemented maps to role="img", except > > > that isn't (by default) announced? > > > > in firefox and IE yes on windows . its not possible to check on the other > > browsers as they don't expose the accessibility API information well. > > > > In safari 5 on Mac OSX <img alt=""> is not exposed as an image. > I believe that it is simple to test this, without a11y API info. Simply: > 1. Insert an <img> with an empty alt="" and set it to role="img" into a page. > (In other words <img src="*" role="img" alt="">.) > 2. Check whether the role="img" causes the AT to announce the <img> to the > user, > despite the empty @alt. > In Safari 5 with VoiceOver, the above <img> is announced to the user. Not so in > Jaws with IE. (Unless, of course, aria-labelledby="*" points to a label. which > again means - VOILA - that it is incorrect to have role="presentation" as > strong semantics for an <img> with empty alt=""! I'll open separate bug.) It > seems to me that it is quite important to clarify whether VoiceOver or JAWS is > correct w.r.t. exposing an <img> with empty alt="" and role="img". > (That said, the opposite isn't true: setting <img alt="Foo" role="presentation" > > does not make the AT read the @alt text.) > PS: Doesn't this bug depend on bug 10666? it does, I have added it to bug 10066. my understanding is that voiceover (for example) relies solely on information provided through the Mac accessibility API and does not use the HTML DOM, while windows screen readers use both.
(In reply to comment #29) > (In reply to comment #28) > > (In reply to comment #25) > my understanding is that voiceover (for example) relies solely on information > provided through the Mac accessibility API and does not use the HTML DOM, while > windows screen readers use both. The Jaws behavour perhaps implies that Jaws maps @role="img" to <img> rather than mapping <img> to @role="img". And if that is so, then Jaws - in a wider perspective - seems compatible with Ian's current definition of <img> as having no default role. It is simply up to the AT to treat it as an image, regardless of role="img" ... Does Jaws announce the image/label, if the @alt is empty, with no @role attribute but thre is aria-labelledby is present? You said that JAWS sees alt="" as a flag, so I suppose it doesn't. Example: <img aria-labelledby="label-element-somewhere-on-the-page" src="img.gif" alt="" /> But then, what if you configure JAWS to not treat alt="" as a flag, will it _then_ present the label?
(In reply to comment #30) > (In reply to comment #29) > > (In reply to comment #28) > > > (In reply to comment #25) > > my understanding is that voiceover (for example) relies solely on information > > provided through the Mac accessibility API and does not use the HTML DOM, while > > windows screen readers use both. > The Jaws behavour perhaps implies that Jaws maps @role="img" to <img> rather > than mapping <img> to @role="img". And if that is so, then Jaws - in a wider > perspective - seems compatible with Ian's current definition of <img> as having > no default role. It is simply up to the AT to treat it as an image, regardless > of role="img" ... > Does Jaws announce the image/label, if the @alt is empty, with no @role > attribute but thre is aria-labelledby is present? You said that JAWS sees > alt="" as a flag, so I suppose it doesn't. > Example: <img aria-labelledby="label-element-somewhere-on-the-page" > src="img.gif" alt="" /> > But then, what if you configure JAWS to not treat alt="" as a flag, will it > _then_ present the label? Hi leif, i don't understand how you come to the conclusion that "The Jaws behavour perhaps implies that Jaws maps @role="img" to <img> rather > than mapping <img> to @role="img". " In MSAA at least if an <img> has an alt="" its role is graphic and its name="" <img> has no alt its role is graphic and its name=none[false] <img> has an alt="text" its role is graphic and its name="text" so MSAA provides a differentiation between them
testing with JAWS 11.0.1467 on Windows 7 Home Premium and FF 3.6.9 <img alt="" src=""> JAWS said: "graphic 21" (note: "21" was also listed in the list of graphics) <img alt="" src="*"> JAWS said: "graphic" but did not list this graphic in the list of graphics although i could navigate to it using the "G" command to navigate all graphics in the web document in the order in which they appear in the document source) <img role="img" src="" alt=""> JAWS said: "graphic 27" (note: "27" was also listed in the list of graphics)
(In reply to comment #32) testing with JAWS 11.0.1467 on Windows 7 Home Premium and FF 3.6.9 <p role="img">This is a test.</p> JAWS said: "This is a test" (NOTE: JAWS did not report the string as a graphic, nor could i navigate to it using the "G" command to navigate by graphic, nor did JAWS indicate that the element contained a landmark) from previous tests, i don't think that JAWS currently recognizes role="img" as a landmark, else it would have spoken the above example as "landmark graphic This is a test." or "landmark image This is a test."
(In reply to comment #33) > JAWS said: "This is a test" (NOTE: JAWS did not report the string as a graphic, You must add aria-labelledby="id" as well. Jaws+Firefox works then, for me. If there is no @aria-labelledby or @aria-describedby, then AT SHOULD, according to ARIA 1.0, treat the element as textually empty. E.g. try this code (though Jaws+Firefox don't seem to support aria-hidden): <div role="img" aria-labelledby="a b" ></div> <p>Dummy text that should be presented <em>after</em> the image labels have been presented.</p> <p id="a" aria-hidden="true">Foo foo fo.</p> <p id="b" aria-hidden="true" >Bar bar bar.</p>
(In reply to comment #31) > (In reply to comment #30) > i don't understand how you come to the conclusion that > > "The Jaws behavour perhaps implies that Jaws maps @role="img" to <img> rather > > than mapping <img> to @role="img". " > > In MSAA at least if an > <img> has an alt="" its role is graphic and its name="" > <img> has no alt its role is graphic and its name=none[false] > <img> has an alt="text" its role is graphic and its name="text" > > so MSAA provides a differentiation between them The difference I am looking for is difference between <img role=img src=* alt=* > and <img src=* alt=* >. Can you repeat the test above, and say if adding role="img" makes any difference? This bug is about default ARIA role for img. Default for whom? For authors or for user agents? And in what sense? If <img> has role="img" by default - from user agents' persepective, then I suppose that authors should be able to - literally - write this (where the point is that I omitted role="img"): <img aria-labelledby="labelElement" src="foo" alt="" > <span id="labelElement">Lorem ipsum</span> And, as a result, the ARIA and HTML5 supporting user agent or AT include "Lorem ipsum" as the label for the image. However, as a matter of fact, one has to add role="img" too, or else today's AT doesn't consider the value of the aria-labelledby attribute. <img role="img" aria-labelledby="labelElement" src="foo" alt="Dolor bla bla." > <span id="labelElement">Lorem ipsum</span> You had an exchange with Tab, where he claimed that AT/user agents: [*] "must implement ARIA mapping and they must respect the defaults listed in the table". Is he right? I am puzzled about what this means. Does it not sound as if he thinks that one, when HTML5 has gained better support, should be able to skip adding role="img"? That's a question that isn't clear to me. But I think he can't be right. Because user agents are not required to support ARIA, are they? So I think the default mappings only apply _if_ the AT/UA supports ARIA. But even then, the question needs to be answered: do I, for an <img> - in HTML5 compatible ARIA supporting UA/AT - need to insert role="img" in order to use @aria-labelledby? [*] http://lists.w3.org/Archives/Public/public-html/2010Sep/0101.html Back to your question: The reason why I said that Jaws maps role="img" to <img> rather than mapping <img> to role="img" was because I observed that if the <img> has an empty @alt and no non-empty aria-labelledby/-describedby attribute, then Jaws doesn't announce the graphic. So Jaws doesn't treat an <img> with role="img" any different from what it currently treat an <img> without role="img". (The reason for this might be that Jaws already has its own methods for discerning between when an <img> with an empty @alt should be announced - it is, if I understood you correctly, a user choice.) This is different from VoiceOver, where adding role="img" means that the image is announced - this is an example of mapping <img> to role="img". But strictly speaking, there are no user agents, today, where an <img> "maps" to role="img", if "maps" is meant to imply that the author does not have to use role="img" in order to "trigger" ARIA in the AT. HTML5 already requires user agents to represent <img> elements as images ... Looking at ARIA 1.0, then it doesn't make it a requirement that an element with role="img" has alternative text. Instead it says (the emphasizes are mine): [*] "An img _can_ contain captions and descriptive text, a" And that: [*] "In order for elements with a role of img be perceivable, authors _SHOULD_ provide alternative text " [*] http://www.w3.org/TR/wai-aria/complete#img The HTML5 debate has largely taken as premise that only an <img> which actually _has_ alternative text, should be considered to have role="img". However, as my quotes above shows, there is no support in ARIA 1.0 for that conclusion. I will also point out that ARIA says that role="img" has "Children Presentational: True". Which means: [*] ]] The DOM descendants are presentational. User agents SHOULD NOT expose tdescendants of this element through the platform accessibility API. If user agents do not hide the descendant nodes, some information may be read twice. [[ [*] http://www.w3.org/TR/wai-aria/complete#childrenArePresentational I'm not sure what happens to direct text node children - <element role="img">TextNode</element>. But anyway, it should not be necessary, per se, to set an <img> with empty alt, to role="presentational". There is at least no requirement in ARIA 1.0 that an <img> with alt="" has to be presentational. So, the more I read ARIA 1.0, then more does role="img" seem to be modeled after how the <img> element works.
(In reply to comment #35) > user agents are not required to support ARIA, are they? I think conforming HTML5 user agents are required to expose ARIA semantics to platform accessibility APIs, where possible. The editor's draft says: "User agents are required to implement ARIA semantics on all HTML elements, as defined in the ARIA specifications". It references the ARIA User Agent Implementation Guide, which specifies that: "Where supported by the platform Accessibility API, WAI-ARIA semantics MUST be exposed through the standard mechanisms of the desktop accessibility API." http://www.w3.org/WAI.new/PF/aria-implementation/#mapping_general > do I, for an <img> - in HTML5 compatible ARIA supporting UA/AT - need to > insert role="img" in order to use @aria-labelledby? No, just as you don't need to use "role='textbox'" to apply "aria-required" to an text "input". But, per the current draft, you do need to specify role="img" to images with a non-empty "alt" if you want them exposed as images to platform accessibility APIs.
(In reply to comment #36) > But, per the current draft, you do need to specify role="img" to images with a > non-empty "alt" if you want them exposed as images to platform accessibility > APIs. I cannot find this in the spec. Can you point out where this is specified?
(In reply to comment #37) > (In reply to comment #36) > > > But, per the current draft, you do need to specify role="img" to images with a > > non-empty "alt" if you want them exposed as images to platform accessibility > > APIs. > > I cannot find this in the spec. Can you point out where this is specified? I guess it's specified by omission, in that no default role is specified for "img" with non-empty "alt", and given the editor closed this bug as WONTFIX, I guess that's a correct interpretation. The spec could be clearer on this point, for example by including "img" with non-empty "alt" in the list of "elements in HTML [that] have no default role and no restrictions on what roles can be applied to those elements".
(In reply to comment #38) > > I guess it's specified by omission, in that no default role is specified for > "img" with non-empty "alt", and given the editor closed this bug as WONTFIX, I > guess that's a correct interpretation. The spec could be clearer on this point, > for example by including "img" with non-empty "alt" in the list of "elements in > HTML [that] have no default role and no restrictions on what roles can be > applied to those elements". With all due respect Ben, the reason why this is comment #39 in an open bug is in part because many people feel that it's an INCORRECT interpretation (guess) by the editor, as many of the comments have documented.
(In reply to comment #38) > (In reply to comment #37) > > (In reply to comment #36) > > > > > But, per the current draft, you do need to specify role="img" to images with a > > > non-empty "alt" if you want them exposed as images to platform accessibility > > > APIs. > > > > I cannot find this in the spec. Can you point out where this is specified? > I guess it's specified by omission, in that no default role is specified for > "img" with non-empty "alt", and given the editor closed this bug as WONTFIX, I > guess that's a correct interpretation. The spec could be clearer on this point, > for example by including "img" with non-empty "alt" in the list of "elements in > HTML [that] have no default role and no restrictions on what roles can be > applied to those elements". the spec says: "User agents are required to implement ARIA semantics on all HTML elements, as defined in the ARIA specifications. The implicit ARIA semantics defined below must be recognized by implementations." Unless its explicitly stated the user agents must not map <img alt="some text"> to a graphic role in an accessibility API they can can continue to do so and be conforming to the spec. I am not disagreeing that the editor intent or desire is to forbid user agents from mapping an <img alt="some text"> to a graphic role in platform accessibility APIs, but unless it is specified, it is not correct to say that user agents need to do it, it is not up to anybody to try to divine what the editor has specified by omission.
(In reply to comment #39) > I am not disagreeing that the editor intent or desire is to forbid user agents > from mapping an <img alt="some text"> to a graphic role in platform > accessibility APIs, but unless it is specified, it is not correct to say that > user agents need to do it, it is not up to anybody to try to divine what the > editor has specified by omission. Reading any text involves opinions about intent, but that's a theoretical quibble: in this case, I think it *is* specified, even if the specification could be clearer. The spec says: "User agents may apply different defaults than those described in this section in order to expose the semantics of HTML elements in a manner more fine-grained than possible with the above definitions." It doesn't say that user agents can apply different defaults using the existing ARIA roles. Clearly, it's possible to express the image-ness of an "img" using an implied ARIA role of "img", so I don't think the spec gives licence to UAs to present "img" with "alt" with an implied role of "img". I think a UA seeking to claim conformance might be able to work around this with a bit of rules lawyering, but I don't think we should rely on that if discarding the information that such elements represent images is unsafe. I'm sympathetic to Ian's concern to avoiding cluttering speech/text/braille renderings with irrelevant information, but I agree with you (comment #5) that discarding the information that "img" is an image is unsafe and I agree with Shelley (comment #22) that it's inconsistent with how "img" itself is now defined.
(In reply to comment #41) > > I'm sympathetic to Ian's concern to avoiding cluttering speech/text/braille > renderings with irrelevant information, Which poses a larger questions: is this a solution in search of a problem? Has this ever been reported as a problem? > but I agree with you (comment #5) that > discarding the information that "img" is an image is unsafe and I agree with > Shelley (comment #22) that it's inconsistent with how "img" itself is now > defined. +1
(In reply to comment #31) > In MSAA at least if an > <img> has an alt="" its role is graphic and its name="" > <img> has no alt its role is graphic and its name=none[false] > <img> has an alt="text" its role is graphic and its name="text" > > so MSAA provides a differentiation between them Here are the results from WebKit, according to Accessibility Inspector in Mac OS X 10.5: <img> has alt="<the empty string>" its role=AXWebarea, its AXRoleDescription=HTML content <img> has no alt its role=AXimage, its AXRoleDescription=Image <img> has alt="<space or text>" its role=AXimage, AXRoleDescription=Image So Webkit looks consequently at the @alt: if the @alt contains if only space character, then the <img> is considered an image. But if the content is the empty string, then the users doesn't get any info whatsoever about the presence of the iamge - it is conflated with the page. Steve, when you said alt="text", did you include alt="<space>" ?
(In reply to comment #43) > (In reply to comment #31) > So Webkit looks consequently at the @alt: if the @alt contains if only space > character, then the <img> is considered an image. Forgot to say: as long @alt's content is not the empty string, then aria-labelledby will just work, even if you don't declare role="img".
(In reply to comment #41) > The spec says: "User agents may apply different defaults than those described > in this section in order to expose the semantics of HTML elements in a manner > more fine-grained than possible with the above definitions." It doesn't say > that user agents can apply different defaults using the existing ARIA roles. NO default for <img alt="sometext"> is defined, so how does a lack of definition mean that user agents must not map <img alt="sometext" as an image? Anyway, this is not getting us anywhere, the editor needs to clarify it and resolve this bug in some way. If his intent to not allow user agents to must not map <img alt="sometext"> as an image. Then he should declare this unambiguously in the spec.
(In reply to comment #45) > Anyway, this is not getting us anywhere, the editor needs to clarify it and > resolve this bug in some way. If his intent to not allow user agents to must > not map <img alt="sometext"> as an image. Then he should declare this > unambiguously in the spec. That would indeed be good, but that's not really that this bug is about. This bug assumes my reading of the spec and requests (I think pragmatically) that "img" be assigned a default role of "img". Clarifying what user agents should do for elements not listed in the ARIA section really belongs in some other bug. "img" is not the only element to which this applies. Other elements include: "html", "head", "body", elements that occur inside "head", and most curiously "i".
(In reply to comment #46) > Clarifying what user agents should do for elements not listed in the ARIA > section really belongs in some other bug. Filed as: Bug #1063. http://www.w3.org/Bugs/Public/show_bug.cgi?id=10603
(In reply to comment #42) > > I'm sympathetic to Ian's concern to avoiding cluttering speech/text/braille > > renderings with irrelevant information, > > Which poses a larger questions: is this a solution in search of a problem? I don't think so. In my experience, screen reader users (for example) often mention "clutter" generally in webpages as a problem. Here's a few examples from public mailing lists: * http://www.mail-archive.com/jaws-users-list@jaws-users.com/msg18188.html * http://www.mail-archive.com/jaws-users-list@jaws-users.com/msg27293.html * http://www.mail-archive.com/blindhandyman@yahoogroups.com/msg13088.html ("graphics laden web sites") All things being equal, reduction of clutter is good. > Has this ever been reported as a problem? End-users seem highly unlikely to articulate concerns in terms of how elements are mapped to accessibility APIs, but JAWS's announcing of "graphic" sometimes comes up as a user annoyance, e.g.: * http://www.freelists.org/post/jfw/graphic [2006] * http://www.freelists.org/post/jfw/graphics (and thread) [2010] As a user, I personally think it's highly suboptimal if to consume a webpage I need to view UI images (e.g. icons) or even be notified of their existence. More generally, I think it's a real failure that a purportedly media independent, user-formattable markup language requires this. So it would be great if we could work out a way to discard such irrelevant information. But I suspect it's not safe to do this in the blanket manner suggested by Hixie, even though some implementations apparently do this (e.g. Safari+VoiceOver). Maybe there's some heuristics we could come up with (e.g. images that are links, buttons, headings versus content images), or maybe not. If not, I guess we need wider and better implementations of CSS3 Replaced Content (http://www.w3.org/TR/css3-content/) that expose the replaced text to accessibility APIs so that authors stop having to use "img" for safe-ish text replacement.
The purpose of role="presentation" is to negate an implicit role. Thus, if it is supposed to make sense that alt=<the empty string> is treateed as a synonym for role="presentation", then <img> *must* have an implicit role as well. If <img> can't have an implicit role, then it is meaningless to say that alt="<the empty string>" negates the <img>s implicit role: ]] presentation (role) An element whose implicit native role semantics will not be mapped to the accessibility API. [[ [*] http://www.w3.org/WAI.new/PF/aria/complete#presentation We must hover clarify the effect of role="presentation" on <img>s with a non-empty @alt: It is seems possible to read ARIA as saying that role="presentation" should not cause the _alt text_ to become inaccessible for AT users. It should only cause the <img> to loose its image role. See bug 10614 against ARIA. That said: AT doesn't announce "image" for all img elements with role="img". And as Steven has said [*], they aren't required to do so either: [*] http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0337 For example, for a link containing nothing but the image [*], then VoiceOver doesn't announce anything but the link and the @alt text - that the link is an image, is not announced. [*] http://dev.w3.org/html5/spec/embedded-content-1#a-link-or-button-containing-nothing-but-the-image It is, however, not clear to me whether the question of making known to the user that the image it is an image, should be completely left over to the AT, such as in the case with a link with an image. Or if role="presentation" should/may be used as a tool for making sure that that user isn't disturbed with such role information. Clearly, HTML5 could possibly open the door for more "microformats" to be defined where the image-ness is not announced. E.g. if a <header> elemen contains nothing but an <img>, then it is probably a logo image, and it shouldn't be necessary to announce that it is an image. Provided that it is correct that role="presentation" should not make the @alt text inaccessible to AT users, then some guidelines somewhere, for when it is acceptable to give an <img> role="presentation" would be useful. Of course, alt="<the-emtpy-string>" is obvious. But also, images which only contain characters - e.g. when the image is a text and the @alt just contains that text - seem like a candiate for when role="presentation" is a SHOULD. Such a thing seems consistent with ARIA, which says: ]] The intended use is when an element is used to change the look of the page but does not have all the functional, interactive, or structural relevance implied by the element type [[ [*] http://www.w3.org/WAI.new/PF/aria/complete#presentation
(In reply to comment #49) > The purpose of role="presentation" is to negate an implicit role. > Thus, if it is supposed to make sense that alt=<the empty string> is treateed > as a synonym for role="presentation", then <img> *must* have an implicit role > as well. If <img> can't have an implicit role, then it is meaningless to say > that alt="<the empty string>" negates the <img>s implicit role: > ]] presentation (role) > An element whose implicit native role semantics will not be mapped to the > accessibility API. [[ > [*] http://www.w3.org/WAI.new/PF/aria/complete#presentation > We must hover clarify the effect of role="presentation" on <img>s with a > non-empty @alt: It is seems possible to read ARIA as saying that > role="presentation" should not cause the _alt text_ to become inaccessible for > AT users. It should only cause the <img> to loose its image role. See bug 10614 > against ARIA. > That said: AT doesn't announce "image" for all img elements with role="img". > And as Steven has said [*], they aren't required to do so either: > [*] http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0337 > For example, for a link containing nothing but the image [*], then VoiceOver > doesn't announce anything but the link and the @alt text - that the link is an > image, is not announced. > [*] > http://dev.w3.org/html5/spec/embedded-content-1#a-link-or-button-containing-nothing-but-the-image > It is, however, not clear to me whether the question of making known to the > user that the image it is an image, should be completely left over to the AT, > such as in the case with a link with an image. Or if role="presentation" > should/may be used as a tool for making sure that that user isn't disturbed > with such role information. Clearly, HTML5 could possibly open the door for > more "microformats" to be defined where the image-ness is not announced. E.g. > if a <header> elemen contains nothing but an <img>, then it is probably a logo > image, and it shouldn't be necessary to announce that it is an image. > Provided that it is correct that role="presentation" should not make the @alt > text inaccessible to AT users, then some guidelines somewhere, for when it is > acceptable to give an <img> role="presentation" would be useful. Of course, > alt="<the-emtpy-string>" is obvious. But also, images which only contain > characters - e.g. when the image is a text and the @alt just contains that text > - seem like a candiate for when role="presentation" is a SHOULD. Such a thing > seems consistent with ARIA, which says: > ]] The intended use is when an element is used to change the look of the page > but does not have all the functional, interactive, or structural relevance > implied by the element type [[ > [*] http://www.w3.org/WAI.new/PF/aria/complete#presentation i asked a question about use of role="presentaion" on <img> on the wai-xtech list last month: http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/0014.html
(In reply to comment #41) > (In reply to comment #39) >I'm sympathetic to Ian's concern to avoiding cluttering speech/text/braille >renderings with irrelevant information... ben, the sorting, selecting and suppression of repeated text/items that fulfill an identical purpose is something that should be left to the user's assistive technology -- most ATs have mechanisms for filtering out repeated text, redundant hyperlinks, etc. it is best for the author to do ALL she can do to provide contextual and meaningful information about the objects in her document -- as someone totally dependent on speech-output, i find that a bit of redundancy is a small price to pay to ensure that the content is accessible not only to those who own the "latest and greatest" (and most expensive) screen readers, but to those who have no choice but to soldier on with older versions of AT, a significant factor given the economic realities that face persons with disabilities -- one of MY primary backwards-compatibility issues... FWIIW, to me, the logical default role for IMG is role="img" -- i believe that any IMG without a role should be treated as if role="img"
This bug is out of control. I have no idea what I'm even supposed to respond to anymore. If there is something that needs changing, please file a simple bug with a clear and succinct statement of the problem, without going on for pages and pages about how I'm misunderstanding the spec or discussing the finer points of ARIA's definitions, which all be happening on a mailing list.
Adding tracker request to this bug, the default role of <img> should be img. It is mapped as such in every browser and no browser vendors have indicated they will change this.
added to HTML WG Issue http://www.w3.org/html/wg/tracker/issues/129
(In reply to comment #53) > Adding tracker request to this bug, the default role of <img> should be img. It > is mapped as such in every browser and no browser vendors have indicated they > will change this. <img> has been mapped to the MSAA role 'graphic' in IE since the the 1990s, and is the same in Firefox. AT products rely on this. There is not a compelling case here for breaking backward compatibility.
The bug-triage sub-team considers this bug to be task force priority but it's currently linked to ISSUE-129 and handled by Steve Faulkner and the aria mapping sub-team.
spec has said for some time that img has img role: http://dev.w3.org/html5/spec/wai-aria.html#sec-strong-native-semantics so closing resolved