ATs are wrong then. Most <img>s are not semantically images and it makes no sense to call them out as images — they should just be replaced by their textual alternatives.

I've added role=img as the default for <img> elements with no alt="" at all, though, since those are more or less by definition specifically images.


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: Partially Accepted
Change Description: see diff given below
Rationale: see above

(In reply to comment #1)
> ATs are wrong then. Most <img>s are not semantically images and it makes no
> sense to call them out as images — they should just be replaced by their
> textual alternatives.
> 
> I've added role=img as the default for <img> elements with no alt="" at all,
> though, since those are more or less by definition specifically images.
> 
> 
> 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: Partially Accepted
> Change Description: see diff given below
> Rationale: see above

> ATs are wrong then. Most <img>s are not semantically images and it makes no
> sense to call them out as images — they should just be replaced by their
> textual alternatives.

"Most <img>s are not semantically images and it makes no sense to call them out as images"

please provide data to back up this statement.

For example, are the millions of photos on flickr semantically images?

Removing the HTML <img> role mapping to img in accessibility APIs is wrong as it will deny users of AT the opportunity to identify, copy, save images if they want.

Steve was was faster than me in reopening this bug. Hereby follows my justification for reopening:

NOTE 1:  you want <img> to default to no role. OK. Could make sense.
NOTE 2: it seems like your thinking goes like this:

  a) you draw a line between "key part of the content" and "role=img".
  b) you draw line between @alt="<empty>" and "not key part"
  c) you draw a link between "semantically images" and role="img" - not sure that is smart.

NOTE 3: HTML5 describes what should happen when @alt is not set:

]] 
if the src attribute is set and the alt attribute is not"
The image might be a key part of the content, and there is no textual equivalent of the image available.

In a conforming document, the absence of the alt attribute indicates that the image is a key part of the content but that a textual replacement for the image was not available when the image was generated.

    [ snip ]

If the image has a title attribute whose value is not the empty string, then the value of that attribute is the caption information; abort these steps.

If the image is the child of a figure element that has a child figcaption element, then the contents of the first such figcaption element are the caption information; abort these steps.
[[


CONCLUSIVE REMARKS:
==============

(1) Regarding a no-alt <img> inside a <figure> with a <figcaption>: 

    (PS: I suppose what you have in mind, is when such an <img>, apart from <figcaption>, is the only child of <figure>, right?!?)

 If the ficaption of the figure element is used to caption an <img> with no-alt, then it seems counterproductive to say that such an <img> should default to role="img". Setting the role of an <img> to role="img", without at the same time pointing - via aria-labelledby - to a something that can serve as caption, will cause the AT to present the <img> as if it doesn't have any caption. Also, should the author set the @role of the <figure> to role="img", then there would suddenly be another element with role="img" inside the <figure role="img"> element.

The only role that it would make sense for a no-alt <img> to default to when used inside a <figure> with a <figcaption>, would be "presentation". Ironically, this bug thus is related  Laura's request that it should be valid to drop the @alt as long as the <img> has role="presentation" - bug 9214.

(2) Regarding <img> with no-alt, used *outside* a <figure> with a <figcaption>:

(2a) This usecase differs from the <figure> with <figcaption> usecase in that defaulting the <img> to role="presentation" would make it completely disappar from the AT user's attention.

But still,  for similar reasons as when used inside a <figure> with <figcaption>, it does not seem to make sense to default such an <img> to role="img", simply because setting the role of an element to "img" means that the user agent will only consider  elements that are pointed to via @aria-labelledby as captitions for the image. It is not possible to point to the @title via aria-labelledby and @title is not automatically considered a label whenever an element is given role="img". (It is of course possible that I misread ARIA 1.0 or that ARIA could change would happens when an element gets role="img" ...)

(2b) I agree that it could make sense to use the @title of such an image as replacement for the lacking @alt. However, effectively, this would mean treating the @title attribute a variant the @aria-label="*" attribute.   But exactly therefore do I also believe that it should be considered an error to use @title on an <img> without @alt: if someone applies aria-label="*" to an <img>, then the proper thing would be to tell the author to use @alt instead. Likewise, when someone uses @title instead of @alt, the propoer thing would be to tell authors to use @alt  instead.

(2c) The way you now have specified things to work, we have the strange situation that, as long as the <img> has no @alt, then it has role="img". The purpose of @role is to help AT users, but there seems to be little help to gain from such a thing. Likewise, if the authors adds a non-empty @title, then it also remains role="img". But if  the author adds an @alt or turns the @title attribute into an @alt attribute, then the <img> is suddenly not considered an role="img" element anymore.

3) The issues described in 1) and 2) means that it becomes quite difficult for the author to keep track of whenever the <img> defaults to role="img", and also difficult for the author to know what consequences  role="img" is meant to have.

(In reply to comment #3)

> CONCLUSIVE REMARKS:
> ==============

> (1) Regarding a no-alt <img> inside a <figure> with a <figcaption>: 

> Also, should the author set the @role of the <figure> to role="img",
> then there would suddenly be another element with role="img" inside the <figure
> role="img"> element.

I was wrong, here: Adding role="img" to <figure> would automatically make its children presentational.
(See: http://www.w3.org/TR/wai-aria/complete#childrenArePresentational )

> The only role that it would make sense for a no-alt <img> to default to when
> used inside a <figure> with a <figcaption>, would be "presentation".
> Ironically, this bug thus is related  Laura's request that it should be valid
> to drop the @alt as long as the <img> has role="presentation" - bug 9214.

I take back the above as well: it makes sense to treat such an <img> as role="img". 

 What doesn't make sense, however, is to treat such an <img> as an role="img" element, by default, whereas an <img> with a proper @alt is not, by default, an role="img" element.

PS: Ian, we do not discuss role="image", but role="img": Something which semanticaly isn't an image, could still semantically be an "img" ...

I am completely at a loss as to what this bug is about now.

I didn't notice when I filed it, but the original request in this bug is pretty clearly a dupe of bug 10481. Oops! Leif, it seems like you may have touched on other issues in your comment, which might be covered by other ones of your bugs. I'm going to mark this a duplicate, and you can cover the related issues in your other bugs, ok?

*** This bug has been marked as a duplicate of bug 10481 ***

The bug-triage sub-team doesn't think this bug is task force priority, since marked as duplicate.