SVG1.1 accessibility support is limited in browsers and screen readers. Things are set to improve with SVG2, but ARIA can be used now to improve the accessibility of simple SVG.
SVG accessibility
SVG includes two elements for providing short and long text descriptions: The title and desc elements.
<body>
...
<svg xmlns=https://www.w3.org/2000/svg>
<title>Circle</title>
<desc>Large red circle with a black border</desc>
<circle cy="60" r="55" stroke="black" stroke-width="2" fill="red" />
</svg>
…...
</body>
Browser support for SVG accessibility
Note: Thanks to Adobe for commissioning the research and for permission to share the data!
In the browser’s accessibility API, the title and desc elements should map to the accessible name and accessible description respectively. The browser’s accessibility API should also expose the role of the SVG, so screen readers can correctly identify it.
Testing across recent browsers indicates that the title and desc elements, and the role of the SVG element, are not represented consistently in browser accessibility APIs.
| Expected result | IE10 (Windows) | FF25 (Windows) | Chrome 30 (Windows) | Chrome 30 (Mac/iOS) | Safari 6 (Mac/iOS) | Chrome 30 (Android) |
|---|---|---|---|---|---|---|
title = accessible name |
Yes | No (is accessible description) | No | No | No | N/A |
desc = accessible description |
Yes | No (is accessible name) | No | No | No | N/A |
| SVG role = graphic/diagram | Yes (graphic) | Yes (diagram) | No | No | No | N/A |
Internet Explorer 10+ (on Windows) is the only browser to correctly expose both the title and desc elements and the SVG role through its accessibility API. Firefox 25 (on Windows) is close, but it computes the accessible name and accessible description the wrong way around. The computation issue has been resolved but is not yet available.
Screen reader support for SVG accessibility
Screen reader support is largely dependent on the information exposed through the browser’s accessibility API. The fact that information is available through the accessibility API doesn’t mean that a screen reader automatically recognises it though.
The desired behaviour is that the screen reader can navigate to the SVG image, identify it as an image, and that the accessible name and accessible description are announced.
| Expected result | IE10 (Windows) | FF25 (Windows) | Chrome 30 (Windows) | Chrome 30 (Mac/iOS) | Safari 6 (Mac/iOS) | Chrome 30 (Android) |
|---|---|---|---|---|---|---|
| Jaws 15 | Yes | No | No | N/A | N/A | N/A |
| NVDA 2013.2 on Windows | Partial | No | No | N/A | N/A | N/A |
| VoiceOver on OSX | N/A | N/A | N/A | No | No | N/A |
| VoiceOver on iOS | N/A | N/A | N/A | No | No | N/A |
| TalkBack on Android | N/A | N/A | N/A | N/A | N/A | No |
Jaws 15 and Internet Explorer 10 is the best combination at present, although nested SVG images are not well supported. NVDA and Internet Explorer present the role, title and desc, but support is erratic with multiple images announced and repetition of the title and desc. In all other browser/screen reader combinations the SVG is ignored.
ARIA enhanced SVG accessibility
It is possible to enhance the information exposed through the browser accessibility APIs with a handful of ARIA attributes. Specifically role and aria-labelledby.
<body>
...
<svg xmlns=https://www.w3.org/2000/svg role="img" aria-labelledby="title desc">
<title id="title">Circle</title>
<desc id="desc">Large red circle with a black border</desc>
<circle role="presentation" cy="60" r="55" stroke="black" stroke-width="2"
fill="red" />
</svg>
…
</body>
Putting role="img" on the svg element ensures it is identified as a graphic. Using aria-labelledby referencing the id values of the title and desc elements provides the accessible name and accessible description. The aria-describedby attribute is not used in this case, due to support issues and the practical outcome is the same, i.e. When a screen reader user encounters the SVG image, the accessible name is announced followed by the accessible description.
The presentation role is applied to the circle element. This removes its role of graphic. Although this might seem unintuitive, the img role needs to be applied to the SVG element instead, as it makes support across screen readers more robust.
SVG ‘image’ represented as multiple images
The presence of multiple images may be announced by a screen reader because each child element of an SVG element, <path> for example, is represented as an image in the accessibility tree. For example the SVG version of the HTML5 logo is represented as a container image with 10 nested images:
As noted above, by using role=presentation on the child elements of the svg element, the role of the nested graphics can be hidden.
It’s also worth mentioning that if the SVG contained the text element, the role of presentation wouldn’t need to be applied to it. The the text element is represented as just that – text.
Browser support for ARIA enhanced SVG
Enhancing the SVG with ARIA dramatically changes the information that is available through browser accessibility APIs.
| Expected result | IE10 (Windows) | FF25 (Windows) | Chrome 30 (Windows) | Chrome 30 (Mac/iOS) | Safari 6 (Mac/iOS) | Chrome 30 (Android) |
|---|---|---|---|---|---|---|
title + desc/aria-labelledby = accessible name |
Yes | Yes | Yes | Yes | Yes | Yes |
svg role = graphic/image |
Yes (graphic) | Yes (graphic) | Yes (graphic) | Yes (image) | Yes (image) | Yes (image) |
Screen reader support for ARIA enhanced SVG
The addition of ARIA also improves the level of support provided by screen readers.
| Expected result | IE10 (Windows) | FF25 (Windows) | Chrome 30 (Windows) | Chrome 30 (Mac/iOS) | Safari 6 (Mac/iOS) | Chrome 30 (Android) |
|---|---|---|---|---|---|---|
| Jaws 15 on Windows | Yes | Yes | Yes | N/A | N/A | N/A |
| NVDA 2013.2 on Windows | Yes | Yes | Yes | N/A | N/A | N/A |
| VoiceOver on OSX | N/A | N/A | N/A | Yes | Yes | N/A |
| VoiceOver on iOS | N/A | N/A | N/A | Yes | Yes | N/A |
| TalkBack on Android | N/A | N/A | N/A | N/A | N/A | Yes |
In most cases screen reader support is now available. The notable exception is Jaws in Firefox or Chrome. Jaws support for Chrome is based on its Firefox scripts, so given this and the availability of the correct information from the browser, it appears to be a bug in Jaws.
These techniques take a small step towards more accessible SVG1.1. With Rich Schwerdtfeger and IBM leading the effort to introduce ARIA and tabindex support in SVG2.0, the outlook for SVG accessibility support is even better.
Thanks again to Adobe for commissioning the original research, and Steve Faulkner for doing all the hard work!
Comments
The YUI chart library uses live regions to make their SVG-based charts interactive. I’ve seen this pattern starting to expand to other applications.
https://yuilibrary.com/yui/docs/charts/