[contents]
Copyright ©2000 - 2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document explains how to design accessible applications using XML, the Extensible Markup Language. Compared to the XHTML or MathML languages, XML is one level up: it is a meta syntax used to define these languages, as well as new ones. As a meta syntax, XML provides no intrinsic guarantee of device independence or textual alternate support. It is essential, therefore, that XML formats and tools designers are provided with guidelines that explain how to include basic accessibility features - such as those present in XHTML, SMIL, and SVG - in all their new developments.
This document is a Working Draft made available by the Protocols and Formats Working Group (PFWG), for review by W3C members and other interested parties. The PFWG operates as part of the WAI Technical Activity. The PFWG maintains a page about issues, errata and corrigenda for this specification, and feedback is particularly invited on those.
This draft is provided for review by the working group prior to releasing a Public Working Draft to the W3C Technical reports page. This draft is expected to be made obsolete by a new draft before the middle of October 2002, but there are not expected to be many changes between this draft and the next.
Please send comments about this document and how you would like to see it evolving to the publicly archived mailing list: wai-xtech@w3.org.
Translations of this specification, or of previous working drafts, are made available by volunteers. The PFWG thanks people who have provided translations.
Publication of this document does not imply endorsement by the W3C, its membership or its staff. This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. 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 technical reports and publications, including working drafts and notes, can be found at http://www.w3.org/TR/.
XML (Extensible Markup Language) is a meta-syntax, used to create new languages.
It can be seen as a simplification of SGML (Standard Generalized Markup Language), designed to promote a wider acceptance in Web markets, but serving the same functionality of extensibility and new language design.
HTML (HyperText Markup Language), on the other hand, is one particular application of SGML, which covers one set of needs ("simple" hypertext documents) and one set of element and attributes.
For instance, in HTML, authors can write elements like:
<title>XML and Accessibility</title> ... <addresslang="fr">Mas St Christophe</address> ... <h1>Background</h1>
and they can only use elements (title, h1, etc.) defined by the HTML specification (which defines about a hundred), and their attributes.
In SGML and XML, authors can define their own set of elements, and end up with documents like:
<menu>New England Restaurant</menu> <appetizer>Clam Chowder <photourl="clam.jpg">A large creamy bowl of clam chowder, with bread crumbs on top</photo> </appetizer>
which may fit more closely the needs of their information system.
Within W3C, the HTML language is now being recast as XML - this is called XHTML - including a modularization of HTML to suit the needs of a larger community (mobile users, Web TV, etc).
XML is therefore not to be seen as a replacement of HTML, but as a new building layer on top of which HTML is to be placed, next to other languages designed by W3C, such as MathML (for representing mathematical formula), SMIL (for synchronizing multimedia), SVG (for scalable graphics), etc., and other new languages designed by other organizations (such as OpenEBook, etc.).
Furthermore, it is important to understand that XML is not only a User Interface technology (like HTML), but can and is often used in protocol communication, to serialize and encode data to be sent from one machine to another.
The XML grammars (often called schema in this document) can be classified along different axes:
According to this taxonomy, these guidelines only address End-user-oriented schema. This does not imply that there are not accessibility issues or features in a Process-oriented schema - see, for example, how XSL can assist in Braille formatting, but they are out of the scope of this particular document.
"XML Accessibility Guidelines 1.0" is part of a series of accessibility guidelines published by the Web Accessibility Initiative (WAI). The documents in this series reflect an accessibility model in which Web content authors, format designers, and software developers have roles in ensuring that users with disabilities have access to the Web. In this model:
The requirements of making the Web accessible to actual users do not always match this model perfectly. In all the guidelines there are cases where there is a need for overlapping requirements to ensure that people can in fact use the Web. These are sometimes due to particular problems in widely implemented and used technology, and sometimes are provided as a "safety net".
There are also cases where guidelines rely on each other in what seems to be a circular dependency. For example, these guidelines require that documentation conforms to WCAG, and WCAG suggests that content (i.e. the documentation) is written in a format that can conform to XAG. Rather than attempt to reproduce every requirement of WCAG as requirements in the XAG document for documentation, we feel that it is easier to make these references. In any case, we feel that to implement XAG it is important to have enough familiarity with the other guidelines to recognise a mutual dependency and be able to apply the requirements successfully.
The WAI (Web Accessibility Initiative) has done extensive work in the HTML area, resulting in lots of new functionalities being added to the version 4.0 of the language (see the HTML4 Accessibility Improvements paper [HTML-access]).
These features includes:
One area of concern with the advent of XML is that the freedom of design it bringshas and can result in a loss of accessibility features, present today because of HTML's pervasive presence and widely available specification.
For instance, one could design a new XML language that would make it much more difficult to create accessible documents, by not including in the element or attribute set a way to attach an alternate textual description for a photo:
<menu>New England Restaurant</menu> <appetizer>Clam Chowder <photourl="clam.jpg"/><!-- no alt attribute or textual content model here --></appetizer>
In this example, the problem is not that the author of this document didn't put an alt attribute or textual equivalent attached to the photo element, it's that the designer of the language didn't put the attribute or the proper support in the language itself (that is, in the schema or the DTD). This means that there is no reliable way for a user to find how an author tried to explain a particular image in text form.
This document specifies requirements for XML languages to ensure that people can create documents in a given XML language which are as accessible as possible to people with disabilities, who use a variety of different techniques and tools to access the Web.
This section provides a list of four guidelines, which are general principles of accessible design. Guidelines include rationale and checkpoints. Each checkpoint expresses a requirement, includes some informative text about the checkpoint and one or several Techniques, where implementations and examples of the checkpoint are discussed. Note that the checkpoints are not prioritized at that point.
Web content providers must able to offer alternative versions of their content if they wish to do so (as the Web Content Accessibility Guidelines tell them to do so). Textual alternatives, like a caption for a movie, or a table summary, can be repurposed for many different output devices, whereas audio content for instance is confined to a certain set of devices (those that can play sound).
desc
element can be used to describe a graphic.<svg width="6in" height="4.5in" viewBox="0 0 600 450"> <title>Network</title> <desc>An example of a computer network based on a hub</desc> </svg>
summary and the caption elements in the
XHTML
table module can be used to provide a rich textual description
of a non-textual media. cf. WCAG 1.0 checkpoint
1.1.<table border="1"summary="This table gives some statistics about fruit flies: average height and weight, and percentage with red eyes (for both males and females)." /> <caption><em>Statistics</em> about fruit flies</caption> <tr><th rowspan="2"></th><th colspan="2">average</th> <th rowspan="2">red<br>eyes</th></tr> <tr><th>height</th><th>weight</th></tr> <tr><th>males</th><td>1.9</td><td>0.003</td><td>40%</td></tr> <tr><th>females</th><td>1.7</td><td>0.002</td><td>43%</td></tr> </table>
Relationships between alternatives should
be explicit in markup to allow users to select which alternatives
are useful to them, and should allow multiple types of alternative,
not just text as an alternative for an image. For example, the HTML
img element lets you provide a text alternative in the
alt attribute, but it does not let you explicitly associate images
to text or markup. To do this people have to put up with less
adequate mechanisms, perhaps by adding "see figure 1" at the end of
a paragraph. If the img element could have content,
like the object element, this would have solved the
problem to some extent. Another way would have been to add an
"appliesTo" attribute to the img element, allowing you
to put the associated image elsewhere in the document. Satisfying
this checkpoint takes a lot of thought due to its subjective
nature, but it is very important.
T1.2.1 In technique 1.1.1 we showed that the desc element
in SVG can be used to provide an alternative for a graphic. Using a
different XML dialect it is possible to add any type of information
as part of the desc.
<svg xmlns="http://www.w3.org/2000/svg" xml:lang="en">
<g>
<desc xmlns:mydoc="http://example.org/mydoc">
<mydoc:title id="title1">The sales bar chart by region</mydoc:title>
<mydoc:para>This description uses markup from the
<mydoc:emph>mydoc</mydoc:emph> namespace.</mydoc:para>
</desc>
</g>
</svg>
<mediaExample>
<Obj xlink:role="http://example.au/equivalenceTypes/image" xlink:href="imageVersion" />
<Obj xlink:role="http://example.au/equivalenceTypes/shortText" xlink:href="shortText" />
<Obj xlink:role="http://example.au/equivalenceTypes/movie" xlink:href="movie" />
</mediaExample>End-user-oriented XML should contain precise methods of encoding the data for its particular scope. By increasing the semantics of your elements, and setting linking devices to outside presentations or further semantics, you allow your data to become "Webized" and hence to operate within many environments.
In some implementations of XSL/XSLT, the result of tree construction can be output as an XML document. This would allow an XML document which contains formatting objects and formatting properties to be output. This capability is neither necessary for an XSL processor nor is it encouraged. There are, however, cases where this is important, such as a server preparing input for a known client; for example, the way that a WAP (http://www.wapforum.org/faqs/index.htm) server prepares specialized input for a WAP capable hand held device. To preserve accessibility, designers of Web systems should not develop architectures that require (or use) the transmission of documents containing formatting objects and properties unless either the transmitter knows that the client can accept formatting objects and properties or the transmitted document contains a reference to the source document(s) used in the construction of the document with the formatting objects and properties.
Do not include presentational attributes and elements in your language.
<news align="center" font="arial" weight="bold">Story 1</news> <news align="center" font="arial" weight="bold">Story 2</news>
T2.2.2 Example: Right
Support the inclusion and processing of external style sheets (note the importance of Guideline 4 on exporting semantics in this example, so that the user may override the style)
mystyle.css: news { text-align: center; font: bold Arial }
<?xml-stylesheet href="mystyle.css" type="text/css"?> ... <news>Story 1</news> <news>Story 2</news>
User Agents have no way of knowing this is a link.
<mylink linkend="http://mysite/myfile.xml">
Current List of references
</mylink>
T2.3.2 Example: Right
Using links that can be recognized reliably by XLink applications.
<myxlink xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://mysite/myfile.xml">
Current List of references
</myxlink>
<-- menu - highest level block element
appetizer - first child of section, major block element
entree - second child of section, major block element
entity meal-sequence - common paragraph level blocks -->
<!ELEMENT menu (title , ((%meal-sequence;)| appetizer)+)>
<!ELEMENT appetizer (title? , ((%meal-sequence;) | entree)+)>
<xsd:schema xmlns="http://www.publishing.org" xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"> <xsd:element name="document"> <xsd:complexType> <xsd:sequence> <xsd:element ref="head"/> <xsd:element ref="section"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="head" type="xsd:string"> <xsd:annotation> <xsd:documentation>Section title</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="section"> <xsd:complexType> <xsd:sequence> <xsd:element ref="head"/> <xsd:element ref="section"/> <xsd:element ref="paragraph" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="paragraph" type="xsd:string"/> </xsd:schema>
<xsd:simpleType name="ISBN-Type">
<xsd:restriction base="xsd:string">
<xsd:pattern value="\d{5}-\d{5}-\d{5}"/>
<xsd:pattern value="\d{1}-\d{3}-\d{5}-\d{1}"/>
<xsd:pattern value="\d{1}-\d{2}-\d{6}-\d{1}"/>
</xsd:restriction>
</xsd:simpleType>
<someElement xmlns="http://xmlns.com/example">
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description about="http://www.dlib.org/">
<dc:Title>
D-Lib Program - Research in Digital Libraries
</dc:Title>
<dc:Description>The D-Lib program supports the community of
people with research interests in digital libraries and
electronic publishing.</dc:Description>
<dc:Publisher>
Corporation For National Research Initiatives
</dc:Publisher>
<dc:Date>1995-01-07</dc:Date>
<dc:Type>World Wide Web Home Page</dc:Type>
<dc:Format>text/html</dc:Format>
<dc:Language>en</dc:Language>
</rdf:Description>
</rdf:RDF>
<!-- .....other xml.... -->
</someElement>
<report>
<invoice>
<amount>25 dollars</amount>
....
</invoice>
<description>
<item>Widgets</item>
<amount>25</amount>
</description>
</report>
In the example above, the designer of the schema intended the first occurrence of the element "amount" to mean 'price' of the products purchased and the second occurrence to mean 'quantity' of the products purchased.
T2.8.2 Example: Right
<report>
<invoice>
<price>25</price>
<currency>Dollar</currency>
....
</invoice>
<description>
<item>Widgets</item>
<quantity>25</quantity>
</description>
</report>
In the example above, the meaning of all the elements is clear and none of the individuals elements is overloaded.
<!DOCTYPE document SYSTEM "myDTD.dtd" [
<!ENTITY % qnames
PUBLIC "-//W3C//ENTITIES XHTML Qualified Names 1.0//EN"
"xhtml-qname-1.mod" >
<!ENTITY % object
PUBLIC "-//W3C//ELEMENTS XHTML Embedded Object 1.0//EN"
"xhtml-object-1.mod" >
%qnames;
%object;
]>
<i:inventory xmlns:i="http://www.my.org/xmlns/inventory">
<i:stockitem>
etc.
<xhtml:object...>
to include a picture or movie of the part.
...
<par>
<video src="anchor.mpg" ... />
<switch>
<audio src="HiQuality.wav" systemBitrate="56000" ... />
<audio src="MedQuality.wav" systemBitrate="28800" ... />
<audio src="LowQuality.wav" ... />
</switch>
</par>
metadata element where RDF
statements can be declared, pointing at graphical elements and
adding more relational semantics (one object linked to another, or
on top of another) than what is provided by SVG itself. See the SVG Accessibility note [SVG-access] for examples.
Also, by providing ID for all your elements, you allow external metadata to point to them.
Web content is rapidly shifting from static pages to dynamic pages, called Web applications. This is most often done using a scripting language based on event callback. The language designers must ensure that the model they chose allows for user control of presentation. Always ensure that nothing in the presentational aspect of the document attempts to restrict user control of how the document instance is accessed.
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:output method="html"/>
<xsl:template match="/">
<html>
<head>
<title>Outline of x</title>
<body>
<-- This provides the link back to the full source document -->
<p><a href="source.xml">full source of document</a></p>
<h1>Outline view</h1>
<p> <xsl:for-each select="//section">
<xsl:number level="multiple" count="section" format="1.1.1"/>
<xsl:value-of select="title"/>
<br />
</xsl:for-each>
</p>
<xsl:apply-templates/>
</body>
</html>
</xsl:template>
<xsl:template match="*"/>
</xsl:stylesheet>
<script type="text/ecmascript"> function DoOnActivate(evt) { .. } </script>
<g onactivate="DoOnActivate(evt)">
<rect id="button" x="500" y="500" width="250" height="40"/>
</g>
Make sure that all people can understand your design and map to and from your elements, and easily make assertions about them. Furthermore, make sure that you provide your own first party assertions about your languages: for example, don't make users guess an element's purpose.
<?xml version="1.0" encoding="utf-8"?>
<my:doc
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
xsi:schemaLocation="http://www.example.org/schemas/doc.xsd"
xmlns:my="http://www.jenitennison.com/"
xmlns="http://www.w3.org/1999/xhtml">
<element name="paragraph">
<xsd:annotation>the lowest level block container.</xsd:annotation>
<empty/>
</element>
<xsd:element name="head" type="xsd:string">
<xsd:annotation>
<xsd:documentation xml:lang="en-US">Title of the section.
Required for table of contents generation.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- To avoid problems with text-only UAs as well as
to make image content understandable and navigable
to users of non-visual UAs, you need to provide
a description with ALT, and avoid server-side image maps -->
<!ELEMENT IMG - O EMPTY -- Embedded image -->
<!ATTLIST IMG
%attrs; -- %coreattrs, %i18n, %events --
src %URI; #REQUIRED -- URI of image to embed --
alt %Text; #REQUIRED -- short description --
longdesc %URI; #IMPLIED -- link to long description
(complements alt) --
name CDATA #IMPLIED -- name of image for scripting --
height %Length; #IMPLIED -- override height --
width %Length; #IMPLIED -- override width --
usemap %URI; #IMPLIED -- use client-side image map --
ismap (ismap) #IMPLIED -- use server-side image map -- >
<!-- USEMAP points to a MAP element which may be in this document
or an external document, although the latter is not widely supported -->
title and SMIL
title) or by mapping to well known semantics.<html xsl:version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/1999/xhtml>
<head>
<title>Mapping of language MenuML to html</title>
<body>
<h1>Menu of: <xsl:value-of select="menu/"/></h1>
<h2>Appetizer: <xsl:value-of select="menu/appetizer/"/></h2>
etc...
</body>
</html>
MenuML technique: use the content of the
photo element to indicate the textual equivalent
of the picture.
MenuML technique: use the appetizer
element to introduce a new appetizer, not a para
and some bigger font
Example: Wrong
<element name="paragraph">
<xsd:annotation>
<xsd:documentation>paragraph</xsd:documentation>
</xsd:annotation>
<empty/>
</element>
Here the element name has been described using the element name only, which adds no semantic value.
T4.9.2 Example: Right
<element name="paragraph">
<xsd:annotation>
<xsd:documentation>The lowest level block container.
</xsd:documentation>
</xsd:annotation>
<empty/>
</element>
Here the element name has been described in an alternate form to clarify semantics rather than re-enforce the name by repeating it.
In the presentation of guidelines for XML accessibility, we try to separate abstract guidelines from implementation techniques. This allows us to talk about the general guideline principles without spending the time up-front to solve the implementation issues.
In fact, there are several techniques for achieving the same result and people's decision will be a function of time and product available and their own commitment to access.
For instance, if an XML designer want to create some kind of "list" element in a given markup, this can be implemented using various techniques:
The source of definitions used is the WAI Glossary [GLOSS]
In addition to the editors, the following people have contributed directly to the content of this document:
Kynn Bartlett , Astrid Callista, Geoff Freed, Al Gilman, Vijay Gummadi, Katie Haritos-Shea, Ian Jacobs, Chris Lilley, William Loughborough, Jim Ley, Dave Pawson, Gregory J. Rosmaita, Michael Shaefer, Aaron Swartz and Carlos A. Velasco.
These changes were decided by the PFWG based on the XAG issues list