SVG offers great promise for accessibility, since it is a structured, logical, scalable format for images, can carry rich descriptive metadata, and presents text as text (including custom embedded fonts), not as mere raster graphics. Ideas can be expressed iconographically, which can aid those with cognitive challenges. But like any graphical format, it can also present challenges to users with various forms of disability, especially if not authored well. User Agents can also degrade the user experience if they do not properly implement the accessibility features of the language.
This document describes various considerations for properly authoring an SVG document, such that it will be more usable not only by those with a disability, but by users in general. It also describes conformance requirements on User Agent implementations that serve a particular need for accessibility. For a complete understanding of how the roles of author and user agent combine to create a rich, accessible experience for all users, authors and implementors should read this entire document.
UAs should not underestimate the importance of SVG Fonts. This is not merely a "nice to have" stylistic feature; given the strong demonstrated desire of designers to control the look of their fonts, this becomes a necessity for accessibility. In the absence of rich stylable fonts, authors will fall back on images as fonts, which decreases the semantic value of the Web: text rendered as a raster image is not readable, searchable, selectable, or indexable.
(should this be in a Best Practices authoring guide, with mixed content so that Accessibility nuggets are thrown into normal authoring practices?)
If it is necessary, you should provide descriptive fallbacks and multiple input options. For example, for selecting a province or state, you may have a clickable map of the country. For some users, such as those who cannot read well or who have cognitive disabilities, this may be ideal; for others, such as visually impaired users or those with limited mobility, this may be difficult, uncomfortable, or even impossible to use, in which case you should provide an alternative input such as a dropdown or text input
The necessity of accessibility for each instance of each Intent below can be assessed on the following scale:
Note that you might have a control (normally a critical consideration) that has very little impact on the user experience (for instance, it might change the visual style of the page); this might be downgraded to merely 'important' or even 'unnecessary'. The author should assess the impact each use of SVG has on the various types of users.
There are several intents for which authors might use SVG content. The intent of the content dictates the amount and type of accessibility issues that an author should address.
[note: for each intent, discuss considerations for each user group needed]
SVG is merely used to enhance visual appearance of page, with little or no informative content. These may be static or animated, and may even contain script. This includes uses that convey stylistic impressions, but have no specific substance (for example, a black background may connote somberness, or a animation of bright shapes may convey frivolity).
No particular accessibility concerns need to be addressed for purely decorative content. In some cases, adding metadata to decorative content may even "clutter" the accessible view.
Typical instances might include:
Vision: for textual data, common sense practices like high contrast and designing so the font can be increased (or is large by default) are good for low vision. For those who will be using text-to-speech UAs, the key to making text accessible is to structure the text in the document such that it makes sense in context and in order. Do not split words merely in order to position them; use SVG's native positioning to achieve this. Do not present text in an order contrary to reading order to achieve a visual effect; use positioning or 'use' elements to simulate this.
Cognitive disabilties: Use clear descriptive prose with a minimum of metaphor or sarcasm.
Contextualization: Labelling: labels can be hidden from view inside initial spans with display:none, or in titles, which can be indicated or serialized via UA (should we use class or wai:role or ARIA for this?) Example: for a comic dialog, each text element could be contain the speaker's nameIt is notable that translations can be provided via the 'switch' element. 'switch' can also be used to provide a textual fallback to graphical content, or vice versa.
Vision: High contrast
Cognitive disabilties: simple iconic images (see http://www.peepo.com/)
Typical instances might include:
SVG is used in dynamic or interactive form to allow user to control some sort of functionality.
It is essential that authors make certain that the interactivity is available to multiple input devices, such as mouse, keyboard, and switch; this includes navigation to, from, and within the interactive SVG, activation and manipulation of the interactivity, output from the interactivity, and the description of the methods by which the interactivity can be controlled. In addition, authors should provide some fallback method of input if any of the above are not met.
[use ARIA roles here]
Typical instances might include:
SVG is used in static or dynamic form to provide an aesthetic experience.
While no particular accessibility concerns are mandatory for artistic content, ideally the author will provide a textual or auditory component to supplement or describe the intent of the work. Any metadata supplied will also be useful to a more general audience.
Typical instances might include:
need special considerations for navigating into and out of the browsing context of the SVG
UA needs to differentiate between the various namespaces
In addition to providing a means of navigating around a document using SVG's native navigation facilities, authors should provide explanatory context for each focus point.
"Use consistent navigational techniques" - WCAG1
[describe SVG navigation here]