SVG Techniques for Web Content Accessibility Guidelines

Working Draft 18 March 2002

This version:

http://www.w3.org/2000/10/wcag2-svg-techs-020318

Latest version:

http://www.w3.org/2000/10/wcag2-svg-techs

Previous version:

http://www.w3.org/2000/10/wcag2-svg-techs-0010

Editors:

Charles McCathieNevile, W3C

Status

This document is prepared by Charles McCathieNevile for the W3C Web Content Accessibility Guidelines Working Group (WCAG WG) to provide techniques for Web Content Accessibility Guidelines. This is a very rough draft, and is known to contain errors. The original draft of this document was based on a draft of WCAG 2.0 which is no longer current.

Review of and comment on this document is actively solicited. Please send comments to w3c-wai-gl@w3.org. The archives for this list are publicly available.

This is a draft document and it likely that this document will be updated or obsoleted.

It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.

Copyright 2000, 2002 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document useand software licensingrules apply. Your interactions with this site are in accordance with our public and Member privacy statements.

Introduction

This draft is intended for internal discussion by the working group. The material here is based on several sources, including SVG 1.1 specification's Accessibility appendix and the W3C Note "Accessibility Features of SVG" [SVG-access].

Provide text equivalents for graphics.

• When the text content of a graphic (e.g., in a 'text' element) explains its function, no text equivalent is required. Use the 'title' child element to explain the function 'text' 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 visual presentation alone. (This might seem odd for a graphics language, but SVG is really an XML format with very good graphics rendering)

• Separate structure from presentation. If the document uses XML presentation attributes, provide a reference to a version which uses CSS styling to provide a structure mapping for the presentation model.
• Do not use color alone to convey information.
• Use consistent presentation for identifying links. !!! (although it can also be donme by user stylesheet
• Ensure adequate color contrast. Use style sheets so that users who require certain color combinations may apply them through user style sheets.

Use markup and style sheets and do so properly.

• Represent text as character data, not as images or curves. Style text with fonts. Authors may describe their own fonts in SVG.
• 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 grammar.
• Use style sheets to specify graphical and aural presentation.
• Use relative units in style sheets.

Clarify natural language usage.

• Use xml:lang to identify the natural language of content and changes in natural language.
• Ensure that text content is presented in a sensible reading order. For example when several lines of text are included, their rendering should be in normal reading order. (if they are presented using elements such as tref or use, the rendering order comes from the position of those elements in the source - normally it is just the order in the source for each text or tspan element)
• Structure text. For heading/text structures use the g element, to provide appropriate avigable nesting. For content where a more semantically rich markup language is available (e.g. MathML) use that in a foreignObject element or use mixed-namespace XML, or provide a pointer via the metadata element to a version that includes the original semantics. cf XSL-FO request for a pointer to the source

Ensure that dynamic content is accessible.

• Ensure that text equivalents for dynamic content are updated when the dynamic content changes - Provide a desc element for each animation element, to describe the intended effect - particularly focusing on the meaning this conveys. (If there is no meaning, then a desc element is not required).
• Ensure that SVG documents are usable when scripts or other programmatic objects are turned off or not supported.
• Use onfocusin, onfocusout and onactivate in the place of onmouseover, onmouseout and onclick to trigger scripts, and the corresponding event triggers for animation elements.

And also....

• Use consistent presentation for identifying links. !!! (although it can also be donme by user stylesheet
• group blocks of links in a g element
• For animations, use multiple symbols, with relevant desc for each, and animate the reference via a use element - see SVG-Access
• Use CSS-based effects, and provide stylesheets in multiple media modes
• Yes. CSS should be used, best to do it by classes - see SVG-Access.
• Define the structure of the image in SVG, and use CSS to provide visual styling (colour, and so on). @@
• Structure images from components, grouping the components in a meaningful hierarchy. Use RDF to describe more complex relationships between components of an image - see SVG-ACCESS and SVGX browser work.
• Provide audio using SMIL via namespaces for descriptions / titles. See SVG-Access
• @@ review base level implementations (there are no older technologies for SVG yet except for generic XML+CSS processing - need to think about that one). THis feeds to our requirement for establishing baseline capabilities we expect...
• Provide style sheets for generic XML+CSS (e.g. does text get presented, or desc, or what? @@CMN Can we write a single default one that is normally useful)
• Provide an XSLT to convert the text / desc into XHTML @@CMN

Glossary

@@need definitions

Content

Equivalent

Markup

Presentation

Semantics