Ambiguous whether <img alt=""> should negate the tree inclusion of accessible SVG content

[cookiecrook]

There are a number of WebKit bug reports related to SVG, and one of the recurring themes is differences of opinion of what should happen when accessible SVG content is linked in the context of an otherwise presentational <img> element. For example:

<img src="foo.svg" alt="">

<svg>
    <title>An accessible title</title>
    <circle cx="50" cy="50" r="50">
        <title>Some accessible content.</title>
    </circle>
</svg>

Some argue that alt="" should override the accessible contents of the image, effectively making the SVG behave as if it had aria-hidden="true" applied. From the authoring perspective, that's an easy solution, but ignores the fact that authors (and more often, inclusion contexts like a CMS) get accessibility wrong. From a user perspective, it's undesirable that a simple authoring mistake might make otherwise accessible content now inaccessible.

I think there are two relevant spec sections, linked below. However, my initial read is that neither of them covers the case mentioned, and so there is probably some ambiguity.

1. SVG Accessibility API Mappings: 5.1.1 Excluding Elements from the Accessibility Tree does not mentioned how the presentational role of accessible SVG content is treated when referenced from an HTML img element with alt="".
2. HTML Accessibility API Mappings: 5.10.1 img Element Accessible Name Computation appears to assume that no images can have accessible content.

If there is not other spec section covering this, I'd propose that one (HTML-AAM) or both (HTML-AAM and SVG-AAG) of the mapping documents be updated to address the ambiguity. I think HTML may be a slightly better location, because the concept of images with embedded accessible content is not exclusive to SVG... HTML could address this more generally as something "linked image files with accessible content, including but not limited to SVG."

[cookiecrook]

My personal opinion is that there should be several different conflict resolutions. Listing a few here, starting with the first example above:

1. Ambiguous conflict: alt="" with accessible contents. Expose the contents because they are accessible in the file and rendered to sighted users. <img alt=""> equates to role="none" so sub-tree contents should be exposed as they would be on <div role="none">. If the author really wants to hide this content, force them to use a more unambiguous method (see below) to hide otherwise accessible image contents.

   <img src="foo.svg" alt=""> <!-- alt="" may be accidentally applied (e.g. by the CMS) so ignore when the linked image content contains its own accessibility information -->
   <svg>
   <title>An accessible title</title>
   <circle cx="50" cy="50" r="50">
       <title>Some accessible content.</title>
   </circle>
   </svg>

2. Unambiguously hidden at <img> inclusion: aria-hidden="true" with accessible contents. Do not expose the contents because the author is using a documented method to explicitly hide all sub-tree contents.

   <img src="foo.svg" alt="" aria-hidden="true"> <!-- all subtree content hidden, even though it's in a different document root -->

3. Unambiguously hidden in the linked content.

   
   <img src="foo.svg" alt=""> <!-- ambiguous until linked contents reveal no accessible content -->
   <svg aria-hidden="true"> <!-- unambiguously hidden in the SVG -->
   <title>An accessible title</title>
   <circle cx="50" cy="50" r="50">
       <title>Some accessible content.</title>
   </circle>
   </svg>

[AmeliaBR]

WebKit is unique in exposing any accessible content from a document linked via <img>. The specs assume that the image is always treated as an atomic element (no children), so it is understandable that no specs have further guidelines. Specifically, the <img> element maps to the img role, which means that any children are presentational. An <iframe role="img" src="graphic.svg"> would not expose the linked document as child content, so per spec, an <img src="graphic.svg"> shouldn't either.

However, if you do allow that an <img> can theoretically have child content from the linked document (like an <iframe> does), then you're right that the HTML-AAM mappings for <img> with empty alt is problematic, since by switching the role to presentation, the child content would be exposed: <iframe role="presentation" src="graphic.svg"> is supposed to be expose the contents of the SVG graphic as if it was inline.

I'm not going to get into the debate about whether <img> should behave like <iframe> and expose the linked document, or not. There are arguments on both sides & I don't think WebKit seems likely to change their behavior.

To me, the most important part, is that the alt attribute continues to have it's intended effect. If a non-empty alt is provided on the image, that must be exposed as an accessible name, whether it's the only name of the image or the name of a group. If an empty alt is provided, that indicates that the entire image is presentational / hidden.

For clarity, the section on the mapping for <img> with empty alt should probably explicitly say that it (including the linked document) is not exposed at all, or that it behaves the same as aria-hidden="true".

[cookiecrook]

WebKit is unique in exposing any accessible content from a document linked via <img>.

I think the only reason other browsers don't expose SVG accessibility is just because they haven't gotten around to it yet.

The specs assume that the image is always treated as an atomic element (no children), so it is understandable that no specs have further guidelines. Specifically, the <img> element maps to the img role, which means that any children are presentational. An <iframe role="img" src="graphic.svg"> would not expose the linked document as child content, so per spec, an <img src="graphic.svg"> shouldn't either.

IMO, that's clearly an oversight/error in the spec, but I'm open to conflicting opinions if there's a case for it.

However, if you do allow that an <img> can theoretically have child content from the linked document (like an <iframe> does), then you're right that the HTML-AAM mappings for <img> with empty alt is problematic, since by switching the role to presentation, the child content would be exposed: <iframe role="presentation" src="graphic.svg"> is supposed to be expose the contents of the SVG graphic as if it was inline.

I'm not going to get into the debate about whether <img> should behave like <iframe> and expose the linked document, or not. There are arguments on both sides & I don't think WebKit seems likely to change their behavior.

To me, the most important part, is that the alt attribute continues to have it's intended effect. If a non-empty alt is provided on the image, that must be exposed as an accessible name, whether it's the only name of the image or the name of a group. If an empty alt is provided, that indicates that the entire image is presentational / hidden.

For leaf node images, I'd agree. For linked accessible content, like some SVGs (a few accessible SVG examples) I don't agree that alt="" is explicit enough to negate all accessible contents.

If you'll forgive the tangent, many CMS tools include lang="en" on the document regardless of the content language. Initially this caused VoiceOver on iOS to force an English TTS voice, regardless if the system could auto-detect the human language. Some pages in Chinese were spoken as "Chinese ideograph". WebKit made the choice to ignore the HTML lang attribute if lang="en" defined on a document container like html or body. This change was in conflict with the spec, but resulted in fewer false negatives, and therefore a more accessible Web.

I think the linked accessible SVG is another case where the heuristics are more nuanced than "trust the author." A significant percentage of web browser code and spec language is intended to fix problems when authors do things the wrong way. I hope we all agree that authors sometimes use alt="" incorrectly.

For clarity, the section on the mapping for <img> with empty alt should probably explicitly say that it (including the linked document) is not exposed at all, or that it behaves the same as aria-hidden="true".

I don't agree with this. I suspect it will result in a worse behavior in more cases for users of assistive technology. Priority of constituencies indicates we should prioritize the needs of users over the needs of authors... In this case, the cost to a user (potentially making content inaccessible accidentally) is worse than the cost to the author (minor inconvenience to hide the content more explicitly), so we should err on the side of the user.

[stevefaulkner]

@cookiecrook use of alt="" on an img element is a longstanding and widely understood indication that AT can ignore the image. I am not understanding why we should break this convention in this case? there is always the possibility that an image marked as alt="" contains useful information.

[AmeliaBR]

I hope we all agree that authors sometimes use alt="" incorrectly. there is always the possibility that an image marked as alt="" contains useful information.

And for this reason, I've actually argued before that maybe the spec should ease up on the expectation that empty alt means completely hidden content. But if so, that should be discussed in general, for all images (e.g., so that the undescribed image could be exposed with a prompt to use an image recognition service to generate a description).

There shouldn't be one behavior for raster images and another for SVG. HTML Authors often use SVG files without editing or examining the code, and extracting text from that file may be no more helpful than using the file name.

[scottaohara]

I'm finding that if referencing an SVG with accessible content via an image element that no browser allows for the traversal of the svg conent, including Safari.

This meets the expectation I've always had for svgs rendered via the img element, going along with the fact you can't style subtree elements of an SVG when rendered with the img element. Styling / making that subtree content accessible/interactive was always achievable by rendering via an <svg> element in the page.

FWIW, if browsers were to change their behavior and treat <img src=whatever.svg> the same way as if an author had used an <svg> <!-- whatever content --> </svg>, then I think we should pick this topic back up. But based on the fact that all browser don't actually expose the subtrees of SVGs when rendered with the image element, I don't think there's a change to make here (yet?)

closing for now. can reopen in the future if things do in fact change.

[cookiecrook]

Reopening.

if browsers were to change their behavior and treat [img-linked SVG contents] the same way as [inline SVG contents]

The reason Safari/VO doesn't is in part because of an artifact that AXImage had always been considered a leaf node. At the time that the SVG accessibility was added in WebKit, we agreed to avoid adding the functionality to <img src="*.svg"> until there was group consensus on this and other related topics. img-linked SVG doesn't have to be a leaf node (and I don't think it should be in many cases) but no rendering engine developer wants to risk interop problems until we generally agree on how this should behave.

I think Chromium, Gecko, and WebKit would all agree to change if we agreed on the specific circumstances that would result in the accessible SVG contents being exposed to the containing HTML document.

[cookiecrook]

Here's an example of interactive SVG content that IMO would be useful to have as a cross-referenced external image rather than inline markup. https://cookiecrook.com/longdesc/svg/

[scottaohara]

thanks for the additional info and reopening, @cookiecrook

it does sound like an actual discussion around this needs to happen then. i think that'd be a good idea.