Accessibility Support

This appendix is informative.

WAI accessibility guidelines

This appendix explains how accessibility guidelines published by W3C's Web Accessibility Initiative (WAI) apply to SVG.

  1. The Web Content Accessibility Guidelines 1.0 [WCAG] and Web Content Accessibility Guidelines 2.0 [WCAG2] explain how authors can create Web content that is accessible to people with disabilities.
  2. The Authoring Tool Accessibility Guidelines 1.0 [ATAG] explains how developers can design accessible authoring tools such as SVG authoring tools. To conform to the SVG specification, an SVG authoring tool must conform to ATAG (priority 1). SVG support for element grouping, reuse and navigation is relevant to designing accessible SVG authoring tools.
  3. The User Agent Accessibility Guidelines 1.0 [UAAG] explains how developers can design accessible user agents such as SVG-enabled browsers. To conform to the SVG specification, an SVG user agent must conform to to the Priority 1 accessibility guidelines defined in UAAG, and should conform also to Priorities 2 and 3. SVG support for scaling, the DOM, and metadata are all relevant to designing accessible SVG user agents.

The W3C Note Accessibility Features of SVG [SVG-ACCESS] explains in detail how the requirements of the three guidelines apply to SVG.

SVG content accessibility guidelines

This section explains briefly how authors can create accessible SVG documents; it summarizes and builds upon Accessibility Features of SVG [SVG-ACCESS].

Provide text equivalents for graphics.
  • When the text content of a graphic (e.g., in a text content element) explains its function, no text equivalent is required. Use the 'title' child element to explain the function of text content elements whose meaning is not clear from their text content.
  • When a graphic does not include explanatory text content, it requires a text equivalent. If the equivalent is complex, use the 'desc' element, otherwise use the 'title' child element.
  • If a graphic is built from meaningful parts, build the description from meaningful parts.
Do not rely on color alone.
  • Do not use color alone to convey semantic information.
  • Ensure adequate color contrast.
Use markup correctly.
  • Separate structure from presentation.
  • Use the 'g' element and rich descriptions to structure SVG documents. Reuse named objects.
  • Publish highly-structured documents, not just graphical representations. Documents that are rich in structure may be rendered graphically, as speech, or as Braille. For example, express mathematical relationships in MathML [MATHML] and use SVG for explanatory graphics.
  • Author documents that validate to the SVG RelaxNG grammar.
Use text for text, and graphics for graphics.
  • Represent text as character data, not as glyphs, images or curves.
  • Style text with fonts. Authors may describe their own fonts in SVG.
  • Do not use 'pi' fonts or picture fonts to represent small graphics. The resulting garbage text does not conform to [CHARMOD] and confuses text to speech engines.
Provide a default reading order.
  • Use 'textArea' elements to provide text that wraps in a box, rather than using script to wrap the text or using a sequence of unrelated 'text' elements.
Clarify natural language usage.
  • Use 'xml:lang' to identify the natural language of content and changes in natural language. This ensures that textual content can be spell-checked, or converted to speech.
  • Use the 'systemLanguage' conditional processing attribute to provide language-specific alternative text and/or graphics.
Allow for rich navigation.
  • Do not assume that all devices have a pointer device. Allow for keyboard navigation as well.
  • Provide links for 8-way directional navigation.
Ensure that dynamic content is accessible.
  • Ensure that text equivalents for dynamic content are updated when the dynamic content changes.
  • Avoid storing dynamic text in ECMAScript arrays or in XSLT stylesheets. This makes it less accessible, and also increases the difficulty of localizing the text or providing multilingual alternatives.
  • Ensure that SVG documents are still usable when scripts or other programmatic objects are turned off or not supported.
Provide semantic metadata.
  • Use the 'role' attribute with appropriate values to indicate the functionality of elements.
  • Indicate relationships between elements with extensible metadata attributes.
  • Use structured metadata with well-known semantics that are understood by accessibility tools, rather than arbitrary values (e.g., use "button" instead of "btn").

SVG user agent accessibility guidelines

This section explains how implementors of SVG user agents can make their software more accessible.

Provide access to color information.
  • SVG user agents should implement and document APIs so that assistive technologies can have access to color information on individual elements.
  • SVG user agents should provide an optional high contrast view.
Provide a text-only view.
  • SVG user agents should provide mechanisms that allow assistive technologies to achieve a useful text-only view. Examples include a DOM explorer, a synchronized text only view, or an XSLT style sheet to convert the textual content to XHTML.
Allow for rich navigation.
  • Provide links for 8-way directional navigation.
Allow multimodal navigation and interaction.
  • SVG user agents should provide access to zooming and panning through modalities other than a pointer device, if available
  • SVG user agents should allow animations, audio, and video to be started, stopped and paused using modalities other than a pointer device, if available.
Allow keyboard navigation.
  • Where a keyboard is supported, it should be possible to use it to zoom and pan, as well as start, stop, and pause animations, audio, and video.