Should SVG with no accessible children have role=img?

[AmeliaBR]

See discussion: w3c/html-aam#43
(This came up on Twitter and I couldn't find the issue because it was on HTML-AAM instead of SVG-AAM.)

Summary of issue:
Currently, the SVG element is mapped to the graphics-document ARIA role.

Most uses of inline SVG on the web are for simple icons, where the "document" nature of the SVG tree isn't relevant — there are no interactive or named child nodes. It may be better for end users if these simple SVGs are just treated as regular images.

Next steps:
I'd like some feedback from implementers if they see any problem with having an element's role depend on it's child tree. If it seems feasible to include that check, then I agree that using the img role for this case, and reserving the graphics-document role for cases where there is accessible child content.

PS, probably best to keep all the discussion in the same place: on the HTML-AAM issue for now, until a decision is made.

[LJWatson]

On the face of it this seems like a good idea to me.

[cookiecrook]

Also w3c/html-aam#290

[joanmarie]

I'm working on Chromium's SVG-AAM implementation. I think we should make this mapping change.

[joanmarie]

As the (unexpected-to-me) notification above indicates: The implementation in Chromium to expose SVG with no accessible children as role=img is done.

[jcsteh]

As I understand it from my own testing, Chromium (at least on Windows) currently exposes all svgs as role image.

I see problems with this if the svg mutates to contain accessible children (and there's no reason that can't happen). Consider this:

data:text/html,<svg id="svg"><title>title</title></svg><script>setTimeout(() => svg.innerHTML += '<rect aria-label="rect"></rect>', 1000);</script>

The svg initially contains no accessible children, but after a second, it mutates to contain an accessible child. If we have different role mappings for svg here, the role has to change. This is a challenge for some platforms at least, particularly with roles as different as image and document.

To deal with that, should the browser recreate the whole subtree? This would require the browser to check the parent every time an accessible is added/removed from an svg subtree to see whether it needs to be recreated. There's probably no perf issue there, but it will definitely require special case code with regard to tree management, so we need to be sure this is really what we want.