This document provides (so far very little) guidance on creating SVG that is accessible to people with disabilities

This is a stub. The idea is to add to it until it turns into a document. That will take a lot of pull requests.

Hopefully one day this will be useful enough to replace appendix E of the SVG specification, and the W3C Note "Accessibility features of SVG"

Things that are still true

(i.e. since the publication of SVG 1 and the poor old SVG accessibility note)

basic shapes

SVG has a set of basic shape elements. They can be used to create simple geometric figures like rectangles, circles, ellipses, lines and polygons. When these elements are used, information about the shape is encoded into the SVG image where it may be used by assistive technologies.

*** Example: basic shapes.

SVG paths are used to create non-standard shapes (leaves or fish for example). Whilst paths make SVG very flexible, it is quite hard to translate the information encoded into the image into real shapes.

*** Example: path.

In most cases this doesn't matter, and the title and desc elements can be used to provide appropriate information about the contents of non-standard SVG shapes. There are cases where using basic shapes will make things clearer to people consuming SVG images using assistive technologies though.

*** Use cases?

Re-usable components"

the use element gives SVG something like what Web Components is still trying to bring to HTML a decade-odd later. The ability to take a well-known component, and re-use it with a bit of relevant styling or other tweaking in turn supports the Web as a medium for annotating objects identified by a URL (such as defs) to support accessibility.

<svg width="250" height="100">
  <defs>
    <rect id="theRect" width="100%" height="100%" style="fill: #c8a2c8;" >
      <desc>
        A purple rectangle, 2 and half times as wide as it is long.
      </desc>
    </rect>
  </defs>
  <use xlink:href="#theRect"> 
    <title id="c2title">Rectangle</title>
  </use>
</svg>

Authors should include a desc element for each graphical object defined in the defs that they reference with a use element.

Authors should use aria-labelledby referencing to a title element within the use element that clones the graphical object.

title and description

Providing an equivalent text alternative for SVG content helps make it accessible to people with disabilities. The text alternative fulfils the same function or purpose for people with disabilities, as the primary content does for people without a disability.

Text alternatives must be provided for all graphical (and other non-text) content. Refer to WCAG 2.0 Guideline 1.1 for more information.

The <title> and <desc> elements are used to provide text alternatives for SVG content. Each container or graphics element within an SVG image can have one (or more) title and desc elements.

• The <title> element provides a short human-readable name for the element that contains it. At least one title should be provided for every SVG image.
• The <desc> element provides a longer human-readable description of the element that contains it. A description should be provided for complex SVG content, or where the SVG fulfils a particular function or purpose.

The <title> and <desc> elements are not rendered as part of the SVG content by default. Browsers often make the title element available as a tooltip when focus moves to the element that the title belongs to, and CSS may be used to make the title and/or desc elements visible in other ways.

The <title> element maps to the accessible name property in the browser’s accessibility API, and the desc element to the accessible description property. Refer to the SVG Accessibility API mappings for more information. This means that assistive technologies can use the title and desc elements to identify and describe the SVG content to people with disabilities. For example, a screen reader will announce the title and description using synthetic speech.

The way you can use these at appropriate levels of structure is a very nice thing.

Because they are elements and not attributes you can do things like add lang attributes, to simplify the use of multilingual content. See the next section, too.

The xml:lang attribute

xml:lang in text elements and desc/title can be used to meet WCAG 2.0 requirement 3.1.1.

Allegedly it might be changed to lang, but that will mess with the lang attribute in fonts (how does that work now in SVG embedded in HTML5 ?)

Examples of using it in text, and in title/desc elements

DOM

Everything now uses the DOM, so it's helpful to have one.

Fonts

Now enhanced to match the new technology, fonts are a much nicer thing to do than simply adding a lot of paths to convey some text.

New improvements

tabindex

Being able to build a keyboard navigation map around an SVG is a great thing. Element-wise navigation is a fallback strategy for users who don't have a choice, but it is unlikely to be a good one if the author has done a half-way reasonable job.

Describe tabindex attribute, plus outcome of using -integer, 0, or +integer values.

And other keyboard related things, like the focusable attribute

ARIA attributes

The ARIA role attribute (5.10.1), based on the ARIA roles definitions. ARIA properties and states (5.10.2), as defined in ARIA states and properties. Plus implicit ARIA semantics (5.10.3).

For example, can use role="img" on the <svg> element. The role="presentation" can also be used to remove child shape elements from the accessibility API. The aria-labeland aria-labelledby attributes can be used to associate the <title> and <desc> elements. The aria-describedby attribute can also be used, but has poor AT support in spite of reasonable browser support.

Info on basic ARIA SVG support, plus simple SVG ARIA test cases.

Just different

onclick is accessible now

DOMActivate was dropped because it was unnecessary, and unhelpful. Lack of browser support and lack of author usage fed a vicious circle.

But onclick can be triggered by almost any mode of interaction - which was what DOMActivate tried to enable. So we have the functionality, even if it has a name that seems limiting.

Acknowledgements

The editor would like to Acknowledge Marja-Riitta Koivonen for making the original SVG Accessibility Note happen, and Doug Schepers and Jennifer Sutton for making this version happen.

This draft is all the better for contributions from Léonie Watson and others.