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/.
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