Using ARIA to enhance SVG accessibility

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=http://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.

SVG title and desc element mapping in browsers
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.

SVG title and desc support in screen readers
Expected result IE10 (Windows) FF25 (Windows) Chrome 30 (Windows) Chrome 30 (Mac/iOS) Safari 6 (Mac/iOS) Chrome 30 (Android)
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=http://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:

output from accessibility object inspector.

Accessibility tree representation of the SVG version of the HTML5 logo.

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.

ARIA enhanced SVG title and desc support in browsers>
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.

ARIA enhanced SVG title and desc support in 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!

About Léonie Watson

Léonie is Senior Accessibility Engineer at The Paciello Group. She joined the team in 2013, after more than a decade at Nomensa. Léonie is a member of the W3C HTML Working Group and HTML Accessibility Task Force. She is Chair of the British Computer Association of the Blind, and co-author of BS8878 Web Accessibility Code of Practice. Léonie also writes for .Net magazine, and talks at conferences about accessible technology.
This entry was posted in General. Bookmark the permalink.

3 Responses to Using ARIA to enhance SVG accessibility

  1. Pingback: Bruce Lawson’s personal site  : Reading List

  2. Ted Drake says:

    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.
    http://yuilibrary.com/yui/docs/charts/

  3. Pingback: Tweet Parade (no. 51 Dec 2013) - Best Articles of Last Week | gonzoblog