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 10481 - Default role of <IMG> should be "img"
Summary: Default role of <IMG> should be "img"
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P1 normal
Target Milestone: LC
Assignee: Leif Halvard Silli
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11ytf, aria, TrackerIssue
: 10485 (view as bug list)
Depends on: 10444 10614
Blocks: 10066 10482
  Show dependency treegraph
 
Reported: 2010-08-28 19:57 UTC by Leif Halvard Silli
Modified: 2012-11-29 12:36 UTC (History)
19 users (show)

See Also:


Attachments

Description Leif Halvard Silli 2010-08-28 19:57:40 UTC
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
Comment 1 Ian 'Hixie' Hickson 2010-09-08 08:35:38 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: 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).
Comment 2 steve faulkner 2010-09-08 08:59:18 UTC
(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?
Comment 3 Ian 'Hixie' Hickson 2010-09-08 09:08:12 UTC
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.
Comment 4 Paul Irish 2010-09-08 09:55:38 UTC
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.
Comment 5 steve faulkner 2010-09-08 10:15:42 UTC
(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).
Comment 6 Martin Kliehm 2010-09-08 10:22:42 UTC
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?
Comment 7 Maciej Stachowiak 2010-09-08 10:31:59 UTC
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>?
Comment 8 steve faulkner 2010-09-08 10:40:10 UTC
(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
Comment 9 Joshue O Connor 2010-09-08 11:53:23 UTC
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.
Comment 10 Rich Schwerdtfeger 2010-09-08 12:56:16 UTC
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.
Comment 11 Leif Halvard Silli 2010-09-08 14:01:03 UTC
(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
Comment 12 Maciej Stachowiak 2010-09-08 18:51:20 UTC
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.
Comment 13 Ian 'Hixie' Hickson 2010-09-09 09:54:41 UTC
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 14 Joshue O Connor 2010-09-09 10:00:13 UTC
>------- 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.
Comment 15 Maciej Stachowiak 2010-09-09 10:12:47 UTC
*** Bug 10485 has been marked as a duplicate of this bug. ***
Comment 16 Maciej Stachowiak 2010-09-09 10:13:29 UTC
Forwarding blocks relationship from duplicate
Comment 17 Leif Halvard Silli 2010-09-09 10:50:30 UTC
(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.
Comment 18 Joshue O Connor 2010-09-09 11:21:25 UTC
(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.
Comment 19 Leif Halvard Silli 2010-09-09 11:34:24 UTC
(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.
Comment 20 Gregory J. Rosmaita 2010-09-09 13:23:13 UTC
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"
Comment 21 Gregory J. Rosmaita 2010-09-09 13:25:33 UTC
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)
Comment 22 Shelley Powers 2010-09-09 14:31:32 UTC
(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.
Comment 23 Maciej Stachowiak 2010-09-09 16:42:48 UTC
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.)
Comment 24 Leif Halvard Silli 2010-09-09 17:56:39 UTC
(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".
Comment 25 steve faulkner 2010-09-10 09:15:51 UTC
(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.
Comment 26 Leif Halvard Silli 2010-09-10 12:27:04 UTC
(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?
Comment 27 steve faulkner 2010-09-10 12:52:40 UTC
(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.
Comment 28 Leif Halvard Silli 2010-09-10 14:48:39 UTC
(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?
Comment 29 steve faulkner 2010-09-10 14:54:59 UTC
(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.
Comment 30 Leif Halvard Silli 2010-09-10 17:09:39 UTC
(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?
Comment 31 steve faulkner 2010-09-10 18:28:26 UTC
(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
Comment 32 Gregory J. Rosmaita 2010-09-10 20:58:06 UTC
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)
Comment 33 Gregory J. Rosmaita 2010-09-10 21:03:25 UTC
(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."
Comment 34 Leif Halvard Silli 2010-09-10 23:38:31 UTC
(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>
Comment 35 Leif Halvard Silli 2010-09-11 13:49:11 UTC
(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.
Comment 36 Benjamin Hawkes-Lewis 2010-09-11 16:17:21 UTC
(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.
Comment 37 steve faulkner 2010-09-11 18:52:25 UTC
(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?
Comment 38 Benjamin Hawkes-Lewis 2010-09-11 19:01:13 UTC
(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".
Comment 39 John Foliot 2010-09-11 19:17:14 UTC
(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.
Comment 40 steve faulkner 2010-09-11 19:19:16 UTC
(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.
Comment 41 Benjamin Hawkes-Lewis 2010-09-11 19:55:24 UTC
(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.
Comment 42 John Foliot 2010-09-11 20:18:40 UTC
(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
Comment 43 Leif Halvard Silli 2010-09-11 21:29:04 UTC
(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>" ?
Comment 44 Leif Halvard Silli 2010-09-11 21:33:28 UTC
(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".
Comment 45 steve faulkner 2010-09-11 21:59:53 UTC
(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.
Comment 46 Benjamin Hawkes-Lewis 2010-09-11 22:40:59 UTC
(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".
Comment 47 Benjamin Hawkes-Lewis 2010-09-11 23:00:37 UTC
(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
Comment 48 Benjamin Hawkes-Lewis 2010-09-11 23:54:44 UTC
(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.
Comment 49 Leif Halvard Silli 2010-09-13 02:47:39 UTC
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
Comment 50 steve faulkner 2010-09-13 09:18:34 UTC
(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
Comment 51 Gregory J. Rosmaita 2010-09-14 14:50:56 UTC
(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"
Comment 52 Ian 'Hixie' Hickson 2010-09-27 22:26:43 UTC
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.
Comment 53 steve faulkner 2010-09-27 22:52:13 UTC
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.
Comment 54 steve faulkner 2010-10-12 09:06:56 UTC
added to HTML WG Issue http://www.w3.org/html/wg/tracker/issues/129
Comment 55 Cynthia Shelly 2010-10-13 20:46:01 UTC
(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.
Comment 56 Marco Ranon 2011-01-11 17:57:35 UTC
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.
Comment 57 steve faulkner 2012-11-29 12:36:54 UTC
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