Should an img with no src be mapped to role=img?

[dd8]

Should the following (non-conforming) img element without src and without alt map to role=img

<img/>

Chrome: nothing rendered on screen, but exposed as role=img
Firefox: nothing rendered on screen, but exposed as role=img
Safari: nothing rendered on screen, not in accessibility tree

The HTML standard and html-aam seem to be at odds here::

• html-aam maps all img elements without alt to role=img (even if they have no src)
• the HTML spec says an img with no alt and no src represents nothing (i.e. has no semantics)

The HTML spec says:

If the src attribute is not set and either the alt attribute is set to the empty string or the alt attribute is not set at all
The element represents nothing.

https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element

The HTML spec defines "represents nothing" as meaning the element has no semantics.

This came up in the ACT Rules face-to-face meeting. Usually an img with no accessible name would be a SC 1.1.1 failure, but this looks hard to justify for <img/> since there's no non-text content because there's no src.

Does it make sense to add an element without content, and that's never rendered, to the accessibility tree?

[jnurthen]

personally I agree with the webkit behaviour but until the mappings are fixed it seems reasonable to flag as an error in conformance checkers.
To guide priorities how often does this kind of thing happen in the real world?

[dd8]

It's less than 1% of pages for <img> with no src.

The same problem happens (with identical browser/AT results) where src is an empty string:

<img src=''>

This is much more common (around 3-4% of pages) because it's easy to generate from templates like the following:

<img src='{{imgURL}}'> <!-- Handlebars.js / Mustache template -->
<IMG src='{$imgURL}'/> <!-- XSL template -->

[scottaohara]

After discussion with the wg, seems we should treat this case as an implicit role=none