SVG image role should align with HTML on missing versus empty alt

[cookiecrook]

In SVG-AAM section on Including Elements says unlabeled images should note be exposed and use the generic/none role, but implementations disagree. I think the implementation behavior is correct (currently returning the image role), and the spec should change to match...

A few reasons:

1. Some screen reader users will want to know that an image is there, even if it is not labelled.
2. Many AT users have some vision so forcing these to be excluded from the accessibility tree penalizes AT users who aren't fully blind. (No navigation stop for a sighted SR user, for example.)
3. Machine vision is getting very good, and several tools (including VoiceOver and maybe others) can describe a lot of images despite them missing a label. But if the image weren't exposed to the tree at all, that may be more challenging.

[pkra]

Somewhat related: I had filed #25 a while back because aXe complained about image elements even when they have an aria-label.

[jcsteh]

implementations disagree. I think the implementation behavior is correct (currently returning the image role)

Firefox currently implements this per the spec; i.e. it only exposes labelled images.

On one hand, it seems inconsistent to expose unlabelled HTML img but not unlabelled SVG image. On the other hand, why are image elements special in contrast to other SVG elements? We explicitly don't expose rect, circle, line, path, etc. if they're unlabelled. Do we want that to change as well? Some of the same arguments could apply here: low vision users, etc.

[jcsteh]

It looks like Chrome also implements this per the spec, at least according to the WPT dashboard.

[cookiecrook]

Yes, I agree that Firefox and Chrome are implemented to spec, but I think the spec is wrong here, and should match the precedence set in HTML for unlabeled images.

Given that SVG-AAM is not being maintained at the moment, we can move the specific test into a speculative directory or something to pull it out of the Interop 2024 Focus Area while the spec issue is being resolved.

[jcsteh]

FWIW, I don't have an objection to this change, but as per my above comment, I think there should: a) be a good explanation documented here for why image is different to shapes (rect, circle, etc.) with respect to them being exposed when unlabelled; or b) be an equivalent change to shapes to expose them when unlabelled. b) doesn't seem ideal - it'd result in a whole bunch of unlabelled stuff - but I'm also finding it difficult to justify why image is different enough in the context of SVG to warrant different behaviour to shapes.

[cookiecrook]

a good explanation documented here for why image is different to shapes (rect, circle, etc.) with respect to them being exposed when unlabelled

Quick answer: Unless you have a fully transparent or solid color image, there is always more information embedded in the pixel data of an image than in the vector data of an SVG shape. The spec requiring the engine to not expose them actively requires the engine suppress data from a blind user that sighted users will receive. There could be a similar shorthand to mark as decorative (Like HTML's alt=""), but without that de facto pattern, they should be passed through to the platform APIs.

[cookiecrook]

There could be a similar shorthand to mark as decorative

Tentative WPT tests use an empty <title> element inside the <image> element.