aria-label on svg image element

pkra commented 1 year ago

Product

axe Extension

Product Version

axe DevTools for Firefox, 4.49.0

Latest Version

[X] I have tested the issue with the latest version of the product

Issue Description

Expectation

An aria-label attribute on an svg image element should not trigger an error.

Actual

axe dev tools reports a error (of level "serious") with the message: "aria-label attribute cannot be used on a image with no valid role attribute."

How to Reproduce

<!DOCTYPE html>
<html lang="en" >
<head>
    <meta charset="UTF-8">
    <title>axe svg image aria-label</title>
</head>
<body>
  <h1>Image test</h1>
<svg>
  <image width=100px height=100px aria-label="hello"></image>
</svg>
</body>
</html>

Additional context

From a quick test, chromium and webkit appear to follow the svg-aam and expose svg image elements correctly with role img and image respectively when an aria-label is present.

While Firefox seems to expose the image element with a strange role of "nothing", the label seems to be exposed -- orca, jaws and narrator voice it even if NVDA fails. (For completeness, Narrator fails to voice the label on Chrome.)

pkra commented 1 year ago

While writing up a firefox bug report, I noticed that I had overlooked https://w3c.github.io/svg-aam/#include_elements. So having no aria-label is fine as per spec -- but an aria-label is specifically mentioned as one way to include an image element in the accessibility tree.

I corrected my original post on that detail.

straker commented 1 year ago

I apologize for the delayed response, we've been super busy prepping for the 4.7 release. I plan on taking a deeper look at this next week.

pkra commented 1 year ago

Thanks so much for the update, @straker!

straker commented 1 year ago

Alright, here's some notes on what I found:

VO / Safari - doesn't see the svg using next/prev line. Reads the aria-label when putting tabindex on the svg (role is read as "group")
JAWS / Chrome - reads the aria-label using next/prev line. Reads the aria-label when putting tabindex on the svg (role is read as "graphic")
NVDA / Firefox - doesn't see the svg using next/prev line. Reads as "blank" when putting tabindex on the svg

(for context, an img element is read in all 3 when using next/prev line)

So it would seem that support of aria-label on the svg image element isn't widely supported. Reading over the svg-aam section you linked, I think what it's saying is that the svg element itself needs the aria-label to include the svg in the accessibility tree. This makes sense as the previous exception talks about a direct title or desc element, which only apply to an svg element.

pkra commented 1 year ago

Thanks for digging deeper.

I think it would be good to separate the issue of AT behavior from validation. I'm primarily concerned with getting something flagged as a validation error which, I believe, is incorrect. As I pointed out, browsers expose it correctly and nu validator also has no issues with it. In my practical situation (of complex, explorable SVGs), it also works very well with AT in practice (e.g., when the <image> element itself gets focus).

Reading over the svg-aam section you linked, I think what it's saying is that the svg element itself needs the aria-label to include the svg in the accessibility tree.

I have to disagree. The spec says (with my bold):

SVG user agents MUST provide an accessible object in the accessibility tree for rendered SVG elements that meet any of the following criteria, unless they are excluded from the accessibility tree per the rules in ...

The list of criteria mentions "a non-empty (after trimming whitespace) aria-label".

While I understand that the phrase "SVG Elements" is somewhat ambiguous, this section of the spec talks specifically about all elements in the SVG spec, not just the svg element.

I'm happy to ask for clarification on the svg-aam issue tracker but I think older discussions like https://github.com/w3c/svg-aam/issues/1 (and the graphics-aria spec) support my interpretation.

FWIW, I also don't think it's correct to say that title only applies to the svg element; they are valid in other elements from the svg spec as well - see https://w3c.github.io/graphics-aria/#role_other for many examples.

WilcoFiers commented 1 year ago

From what I can tell, and what Steve has said markup like this will cause accessibility problems for screen reader users. That tells me axe-core isn't wrong in failing this. It can definitely do a better job of explaining the problem. Instead of reporting aria-label as not allowed it should say it's not sufficiently supported.

pkra commented 1 year ago

Thanks @WilcoFiers. I don't know what precisely was tested so it's difficult to respond - my minimal example was primarily about validation, not an actual live example.

I suspect expectations are tricky. As I wrote, in my experience, labels on image tags work quite well across AT. But then I've only ever needed/seen them in complex SVGs with details to explore (e.g., a chart or infographic with some parts needing raster graphics, explorable by tabindex or by JS).

Maybe ARIA-AT could be of use here. I think I might just file an issue on svg-aam so it comes up on the ARIA WG's agenda.

In any case, thank you both again for taking the time to respond.

dequelabs / axe-core