You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1452 lines
76 KiB
1452 lines
76 KiB
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
|
|
<title>XML Accessibility Guidelines</title>
|
|
<style type="text/css">
|
|
<!--
|
|
h2.draft { background: #e0e0e5; margin-top: 1em; padding: 0.1em; }
|
|
ul.guidelines, ul.guidelines ul { list-style-type: none; }
|
|
ul.guidelines ul { margin-bottom: 0.7em; }
|
|
ul.guidelines dl dd { margin-bottom: 0.75em; }
|
|
.definition { margin-top: 1em;margin-bottom: 1em; border: 2px solid #a0a0a0;}
|
|
dl dl { margin-left: -1em; }
|
|
dl.techs { margin-left: 1em; }
|
|
dl.techs dt { font-weight: bold; }
|
|
dt.check { margin-bottom: 0.5em; }
|
|
dt.check { color: #007060; font-weight: bold; }
|
|
pre { font-family: monospace; white-space: pre;
|
|
text-align: left; font-size: 0.8em;
|
|
padding: 1em; }
|
|
ins { text-decoration: none; }
|
|
.proposed { color: #e05000; }
|
|
@media screen {
|
|
pre { border: 1px solid #a0a0a0; }
|
|
}
|
|
-->
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</style>
|
|
<link rel="stylesheet" type="text/css" media="screen"
|
|
href="http://www.w3.org/StyleSheets/TR/W3C-WD" />
|
|
</head>
|
|
|
|
<body xml:lang="en" lang="en">
|
|
|
|
<div class="head">
|
|
<p>[<a href="#toc" accesskey="c">contents</a>]</p>
|
|
|
|
<p><a href="http://www.w3.org/"><img height="48" width="72" alt="W3C"
|
|
src="http://www.w3.org/Icons/w3c_home" title="World Wide Web Consortium"
|
|
/></a></p>
|
|
|
|
<h1 id="Accessibil">XML Accessibility Guidelines</h1>
|
|
|
|
<h2 class="draft" id="Working">W3C Working Draft 3 October 2002</h2>
|
|
<dl>
|
|
<dt>This Version:</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2002/WD-xag-20021003">http://www.w3.org/TR/2002/WD-xag-20021003</a></dd>
|
|
<dt>Latest Version:</dt>
|
|
<dd><a href="http://www.w3.org/TR/xag">http://www.w3.org/TR/xag</a></dd>
|
|
<dt>Latest Editor Draft:</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/WAI/PF/XML/">http://www.w3.org/WAI/PF/XML</a></dd>
|
|
<dt>Previous Version:</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2001/WD-xmlgl-20010829">http://www.w3.org/TR/2001/WD-xmlgl-20010829</a></dd>
|
|
</dl>
|
|
<dl>
|
|
<dt>Editors:</dt>
|
|
<dd><a href="http://www.w3.org/People/danield/">Daniel Dardailler</a>, W3C
|
|
(<a href="mailto:danield@w3.org">danield@w3.org</a>)</dd>
|
|
<dd><a href="http://purl.org/net/sbp/">Sean B. Palmer</a> (<a
|
|
href="mailto:sean@mysterylights.com">sean@mysterylights.com</a>)</dd>
|
|
<dd><a href="/People/Charles/">Charles McCathieNevile</a>, W3C (<a
|
|
href="mailto:charles@w3.org">charles@w3.org</a>)</dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">Copyright</a>
|
|
©2000 - 2002 <a href="http://www.w3.org/"><abbr
|
|
title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a
|
|
href="http://www.lcs.mit.edu/"><abbr
|
|
title="Massachusetts Institute of Technology">MIT</abbr></a>, <a
|
|
href="http://www.inria.fr/"><abbr xml:lang="fr" lang="fr"
|
|
title="Institut National de Recherche en Informatique et Automatique">INRIA</abbr></a>,
|
|
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</a>,
|
|
<a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</a>,
|
|
<a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document
|
|
use</a> and <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software
|
|
licensing</a> rules apply.</p>
|
|
<hr title="Separator from Header" />
|
|
</div>
|
|
|
|
<h2><a name="abstract" id="abstract">Abstract</a></h2>
|
|
|
|
<p>This document provides guidelines for designing Extensible Markup Language
|
|
(XML) applications that lower barriers to Web accessibility for people with
|
|
disabilities (visual, hearing, physical, cognitive, and neurological). <a
|
|
href="/XML/">XML</a>, used to design applications such as <a
|
|
href="/WAI/References/HTML4-access">XHTML</a>, <a
|
|
href="/TR/SMIL-access/">SMIL</a>, and <a href="/TR/SVG-access/">SVG</a>,
|
|
provides no intrinsic guarantee of the accessibility of those applications.
|
|
This document explains how to include features in XML applications that
|
|
promote accessibility.</p>
|
|
|
|
<h2><a name="status" id="status">Status of this document</a></h2>
|
|
|
|
<p>This document is a <strong>Working Draft</strong> of the XML Accessibility
|
|
Guidelines made available by the Protocols and Formats Working Group (<a
|
|
href="/WAI/PF/">PFWG</a>). The <acronym
|
|
title="Protocols and Formats Working Group">PFWG</acronym> operates as part
|
|
of the <a href="/WAI/Technical/Activity">WAI Technical Activity</a>. The
|
|
<acronym title="Protocols and Formats Working Group">PFWG</acronym> maintains
|
|
a page about <a href="/WAI/PF/XML/issues">issues, errata and corrigenda for this
|
|
specification</a>, and feedback is particularly invited on those.</p>
|
|
|
|
<p>This document is a W3C Working Draft made available for public review as
|
|
per the <a href="/Consortium/Process-20010719/cover">W3C Process</a>.
|
|
This draft is expected to be updated or made obsolete within three months of
|
|
its publication (3 October 2002). Intermediate updates (<a
|
|
href="http://lists.w3.org/Archives/Public/wai-xtech/">publicly archived</a>
|
|
mailing list: <a href="mailto:wai-xtech@w3.org">wai-xtech@w3.org</a>.</p>
|
|
|
|
<p><a href="/WAI/PF/XML/translations">Translations of this specification</a>, or of
|
|
previous working drafts, are made available by volunteers. The <acronym
|
|
title="Protocols and Formats Working Group">PFWG</acronym> thanks people who
|
|
have provided translations, but notes that the original English version of
|
|
any draft is the only authoritative version</p>
|
|
|
|
<p>Patent disclosures relevant to this specification may be found on the
|
|
Working Group's <a href="/WAI/PF/XML/Disclosures.html"
|
|
rel="disclosure">patent disclosure page</a>, in conformance with W3C policy.
|
|
At the time of publication, there are no declarations specific to this
|
|
document.</p>
|
|
|
|
<p>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 <a
|
|
href="/TR/">http://www.w3.org/TR/</a>.</p>
|
|
|
|
<h2><a name="toc" id="toc">Table Of Contents</a></h2>
|
|
|
|
<div class="toc">
|
|
<ul class="toc">
|
|
<li class="tocline"><a href="#intro" class="tocxref">Introduction</a>
|
|
<ul>
|
|
<li><a href="#scope">XML Grammars and the Scope of XAG</a></li>
|
|
<li><a href="#Relationsh">Relationship to Other Guidelines</a></li>
|
|
<li><a href="#PB" class="tocxref">Problem statement</a></li>
|
|
</ul>
|
|
</li>
|
|
<li class="tocline"><a href="#Guidelines" class="tocxref">Guidelines for
|
|
designers of XML dialects</a>
|
|
<ul>
|
|
<li><a href="#g1_0">1. Ensure that authors can associate multiple media
|
|
objects as alternatives</a></li>
|
|
<li><a href="#g2_0">2. Create semantically-rich languages</a></li>
|
|
<li><a href="#g3_0">3. Design an accessible user interface</a></li>
|
|
<li><a href="#g4_0">4. Document and export semantics</a></li>
|
|
</ul>
|
|
</li>
|
|
<li class="tocline"><a href="#Appendices">Appendices</a>
|
|
<ul>
|
|
<li><a href="#techniques">Appendix A: Techniques</a></li>
|
|
<li><a href="#detaildefs">Appendix B: XML Accessibility
|
|
Definitions</a></li>
|
|
<li><a href="#acknowledgments">Appendix C: Acknowledgments</a></li>
|
|
<li><a href="#references">Appendix D: References</a></li>
|
|
<li><a href="#Appendix">Appendix E: Changes from the previous
|
|
Draft</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<hr />
|
|
|
|
<h2 id="intro">Introduction</h2>
|
|
|
|
<p>This document specifies requirements that, if satisfied by designers of
|
|
XML applications, will lower barriers to accessibility. This document
|
|
includes:</p>
|
|
<ul>
|
|
<li>This introduction, which provides context for understanding the
|
|
requirements listed in section 2.</li>
|
|
<li>Section 2 explains four general principles of accessible design, called
|
|
"guidelines". Each guideline consists of a list of requirements, called
|
|
"checkpoints", which must be satisfied in order to conform to this
|
|
document.</li>
|
|
<li>Section 3 explains how to make claims that XML Applications satisfy the
|
|
requirements of section 2.</li>
|
|
<li>An appendix lists all the checkpoints for convenient reference (e.g.,
|
|
as a tool for application developers to evaluate software for
|
|
conformance)</li>
|
|
</ul>
|
|
|
|
<p><a href="/XML/">XML</a> (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. <a href="/MarkUp/">HTML</a> (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.</p>
|
|
|
|
<p>For instance, in HTML, authors can write elements like:</p>
|
|
<pre><code> <</code><strong><code>title</code></strong><code>>XML and Accessibility</</code><strong><code>title</code></strong><code>> ...
|
|
<</code><strong><code>address</code></strong><code> lang="fr">Mas St Christophe</</code><strong><code>address</code></strong><code>> ...
|
|
<</code><strong><code>h1</code></strong><code>>Background</</code><strong><code>h1</code></strong><code>></code></pre>
|
|
|
|
<p>and they can only use elements (<code>title</code>, <code>h1</code>, etc.)
|
|
defined by the HTML specification (which defines about a hundred), and their
|
|
attributes.</p>
|
|
|
|
<p>In SGML and XML, authors can define their own set of elements, and end up
|
|
with documents like:</p>
|
|
<pre> <code><</code><strong><code>menu</code></strong><code>>New England Restaurant</</code><strong><code>menu</code></strong><code>>
|
|
<</code><strong><code>appetizer</code></strong><code>>Clam Chowder
|
|
<</code><strong><code>photo</code></strong><code> url="clam.jpg">A large creamy bowl of clam chowder, with
|
|
bread crumbs on top</</code><strong><code>photo</code></strong><code>>
|
|
</</code><strong><code>appetizer</code></strong><code>></code></pre>
|
|
|
|
<p>which may fit more closely the needs of their information system.</p>
|
|
|
|
<p>Within W3C, the HTML language is now being recast as XML - this is called
|
|
<a href="/TR/xhtml1/">XHTML</a> - including a modularization of HTML to suit
|
|
the needs of a larger community (mobile users, Web TV, etc).</p>
|
|
|
|
<p>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 <a
|
|
href="http://www.openebook.org/">Open EBook</a>, <a
|
|
href="http://www.xml.org/xmlorg_registry/index.shtml">etc</a>.).</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<h3><a name="scope" id="scope">XML Grammars, and The Scope Of XAG</a> <a
|
|
href="/WAI/PF/XML/issues#Scope" class="issue">[[Note: this section may disappear or
|
|
change significantly]]</a></h3>
|
|
|
|
<p>The XML grammars (often called schema in this document) can be classified
|
|
along different axes:</p>
|
|
<dl>
|
|
<dt>End-user-oriented:</dt>
|
|
<dd>Where the dialect is used to describe user-oriented data, such as
|
|
structured textual oriented content in Docbook, HTML, MenuML, OEB,
|
|
etc.; or specialized content - such as MathML, Scalable Vector Graphics
|
|
(SVG), MusicML, Synchronized Multimedia Integration Language (SMIL); or
|
|
any document storage format. An informal definition is 'anything for
|
|
which the question "is there a textual equivalent of all rich media
|
|
data bits?" makes sense'.</dd>
|
|
<dt>Process-oriented:</dt>
|
|
<dd>When the content being marked up is closer to a program than a
|
|
document. Examples: For expressing data processing (for example XSL -
|
|
Extensible Style Language), metadata, such as RDF (Resource Description
|
|
Framework), XML Schema languages, etc.</dd>
|
|
</dl>
|
|
|
|
<p>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 <a href="/TR/xslt">XSL</a> can assist in Braille formatting, but
|
|
they are out of the scope of this particular document.</p>
|
|
|
|
<h3><a name="Relationsh" id="Relationsh">Relation to other WAI
|
|
Guidelines</a></h3>
|
|
|
|
<p>"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:</p>
|
|
<ul>
|
|
<li>Format specifications (e.g., XHTML, SVG, SMIL, MathML) include features
|
|
that support accessibility, such as elements and attributes for
|
|
alternative text, navigation tools, semantics that respect user control
|
|
over presentation, etc. The current document (XAG 1.0) explains how to
|
|
design XML formats that include features to benefit accessibility. The
|
|
principles of this document apply for the most part to non-XML formats as
|
|
well.</li>
|
|
<li>Authors make use of these features when creating Web pages and Web
|
|
applications. The "Web Content Accessibility Guidelines 1.0" [WCAG10]
|
|
explains how to create more accessible content through features offered
|
|
by formats, and also through consistent design, clear writing, use of
|
|
multimedia, and more.</li>
|
|
<li>Authoring tools help authors create more accessible content through
|
|
support of formats with accessibility features, and through interactive
|
|
and automatic assistance (e.g., prompts for accessibility features,
|
|
validity checking, reuse of accessible content, etc.). The "Authoring
|
|
Tool Accessibility Guidelines 1.0" [ATAG10] explains the responsibilities
|
|
of authoring tool developers. ATAG 1.0 addresses the accessibility of
|
|
authored content but also the accessibility of the tool's user
|
|
interface.</li>
|
|
<li>User agents promote accessibility by implementing formats with
|
|
accessibility features, and by providing an accessible user interface,
|
|
allowing communication with assistive technologies, documenting
|
|
accessibility features, following operating environment conventions, etc.
|
|
The "User Agent Accessibility Guidelines 1.0 [UAAG10] explains to user
|
|
agent developers how to create more accessible browsers, multimedia
|
|
players, and other user agents.</li>
|
|
</ul>
|
|
|
|
<p>Formats that conform to XAG 1.0 will support the features of the other WAI
|
|
Guidelines. For instance, this document requires that formats include
|
|
elements and attributes that:</p>
|
|
<ul>
|
|
<li>Will allow authors to associate text alternatives with non-text
|
|
content;</li>
|
|
<li>Will allow user agent developers to recognize these alternatives and
|
|
provide easy access to them in a reliable manner;</li>
|
|
<li>Will allow authoring tool developers to design tools that reuse
|
|
recognized alternatives when the same non-text content (e.g., a corporate
|
|
logo) is reused by the author.</li>
|
|
</ul>
|
|
|
|
<p>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".</p>
|
|
|
|
<p>Note: The WAI Guidelines cross-reference one another. XAG 1.0 requirements
|
|
to satisfy the requirements of other WAI Guidelines should be interpreted to
|
|
mean "Follow the requirements of other guidelines EXCEPT for those that in
|
|
turn require conformance to XAG 1.0." Thus, if XAG 1.0 requires that the
|
|
documentation of an XML application conform to WCAG 2.0, and WCAG 2.0 states
|
|
that conforming content must also conform to XAG, read this as:
|
|
"Documentation of an XML application must conform to WCAG 2.0 except for WCAG
|
|
2.0 requirements that in turn require conformance to XAG 1.0."</p>
|
|
|
|
<h3><a name="PB" id="PB">Problem statement</a> <a
|
|
href="/WAI/PF/XML/issues.html#Definition" name="defNote" id="defNote"
|
|
class="issue">[[Note: This section is likely to be significantly
|
|
revised]]</a></h3>
|
|
|
|
<p>The <a href="/WAI/">WAI</a> (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 <a
|
|
href="/WAI/References/HTML4-access">HTML4 Accessibility Improvements
|
|
paper</a> [<a href="#HTML-acces">HTML-access</a>]).</p>
|
|
|
|
<p>These features includes:</p>
|
|
<ul>
|
|
<li>Improved structure (such as fieldset, optgroup in form)</li>
|
|
<li>Support of separate Style Sheets</li>
|
|
<li>Better alternate content (required alt, longdesc, caption, etc)</li>
|
|
<li>Easier navigation (tabindex, link, etc)</li>
|
|
</ul>
|
|
|
|
<p>One area of concern with the advent of XML is that the <strong>freedom of
|
|
design it brings</strong> <strong>has and can result in a loss of
|
|
accessibility</strong> features, present today because of HTML's pervasive
|
|
presence and widely available specification.</p>
|
|
|
|
<p>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:</p>
|
|
<pre><code> <</code><strong><code>menu</code></strong><code>>New England Restaurant</</code><strong><code>menu</code></strong><code>>
|
|
<</code><strong><code>appetizer</code></strong><code>>Clam Chowder
|
|
<</code><strong><code>photo</code></strong><code> url="clam.jpg"/> </code><em><code><!-- no alt attribute or
|
|
textual content model here --></code></em><code> </</code><strong><code>appetizer</code></strong><code>></code></pre>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
<hr />
|
|
|
|
<h2 id="Guidelines">Guidelines for designers of XML dialects</h2>
|
|
|
|
<p>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.</p>
|
|
<ul class="guidelines">
|
|
<li><h3 id="g1_0" class="guide">Guideline 1. Ensure that authors can
|
|
associate multiple media objects as alternatives</h3>
|
|
<p>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).</p>
|
|
<dl>
|
|
<dt id="cp1_1" class="check"><strong>1.1</strong> Provide a mechanism
|
|
to explicitly associate alternatives for content or content
|
|
fragments.</dt>
|
|
<dd id="cp1_1rationale" class="rationale">Authors using the
|
|
elements/attributes in your language must have the ability to
|
|
provide alternatives for any content, be it images, movies, songs,
|
|
running text, whatever.</dd>
|
|
<dt id="cp1_1tech" class="tech">Techniques for 1.1</dt>
|
|
<dd><strong><a name="L1856" id="L1856">T1.1.1</a></strong> In <a
|
|
href="/TR/SVG/index.html#minitoc">SVG</a>, the <code>desc</code>
|
|
element can be used to describe a graphic.</dd>
|
|
<dd><pre><code><svg width="6in" height="4.5in" viewBox="0 0 600 450">
|
|
<title>Network</title>
|
|
<</code><strong><code>desc</code></strong><code>>An example of a computer network based on a hub</desc>
|
|
</svg></code></pre>
|
|
</dd>
|
|
<dd><strong><a name="L1894" id="L1894">T1.1.2</a></strong> The
|
|
<code>summary</code> and the <code>caption</code> elements in the
|
|
<a
|
|
href="/TR/xhtml-modularization/abstract_modules.html#s_tablemodule">XHTML
|
|
table module</a> can be used to provide a rich textual description
|
|
of a non-textual media. cf. <a
|
|
href="/TR/WCAG10/#tech-text-equivalent">WCAG 1.0 checkpoint
|
|
1.1</a>.</dd>
|
|
<dd><pre><code><table border="1"
|
|
</code><strong><code>summary</code></strong><code>="This table gives some statistics about fruit
|
|
flies: average height and weight, and percentage
|
|
with red eyes (for both males and females)." />
|
|
<</code><strong><code>caption</code></strong><code>><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></code></pre>
|
|
</dd>
|
|
<dt id="cp1_2" class="check"><strong>1.2</strong> Define
|
|
<em>flexible</em> associations, where a given kind of relationship can
|
|
link to or from objects of varying types without constraint.</dt>
|
|
<dd id="cp1_2rationale" class="rationale"><p id="unconstrained1"><a
|
|
name="unconstrained"></a>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
|
|
<code>img</code> 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 <code>img</code> element could have content,
|
|
like the <code>object</code> element, this would have solved the
|
|
problem to some extent. Another way would have been to add an
|
|
"<code>appliesTo</code>" attribute to the <code>img</code> 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.</p>
|
|
</dd>
|
|
<dt id="cp1_2tech" class="tech">Techniques for 1.2</dt>
|
|
<dd><p><strong><a name="L1887" id="L1887">T1.2.1</a></strong> In <a
|
|
href="#L1856">technique 1.1.1</a> 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 <code>desc</code>.</p>
|
|
</dd>
|
|
<dd><pre><code><svg xmlns="http://www.w3.org/2000/svg" xml:lang="en">
|
|
<g>
|
|
<</code><strong><code>desc</code></strong><code> xmlns:mydoc="http://example.org/mydoc">
|
|
<mydoc:title id="</code><strong><code>title1</code></strong><code>">The sales bar chart by region</mydoc:title>
|
|
<mydoc:para>This description uses markup from the
|
|
<mydoc:emph>mydoc</mydoc:emph> namespace.</mydoc:para>
|
|
</</code><strong><code>desc</code></strong><code>>
|
|
</g>
|
|
</svg></code></pre>
|
|
</dd>
|
|
<dd><strong><a name="L1880" id="L1880">T1.2.2</a></strong> In the
|
|
example below, an imaginary mediaExample element allows for any
|
|
kind of content. In the example, those that have been included are
|
|
an image, a textual object and a video.</dd>
|
|
<dd><pre><code> <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></code></pre>
|
|
</dd>
|
|
</dl>
|
|
</li>
|
|
<li><h3 id="g2_0" class="guide">Guideline 2. Create semantically-rich
|
|
languages</h3>
|
|
<p>Increased structure in an XML application (i.e., elements and
|
|
attributes that correspond to meaningful terms in the chosen domain)
|
|
allows authors to encode their knowledge in a manner that user agents can
|
|
recognize reliably. XML applications deployed on the Web should include
|
|
linking semantics.</p>
|
|
<dl>
|
|
<dt id="cp2_1" class="check"><strong>2.1</strong> Ensure all semantics
|
|
are captured in markup in a repurposable form.</dt>
|
|
<dd id="cp2_1rationale" class="rationale">XML languages must be
|
|
designed so that they can be presented in a device independent way.
|
|
They must be repurposable with respect to input and output devices,
|
|
as well as spatially independent (don't make the user have to use a
|
|
mouse), temporally independent (don't require input within a finite
|
|
time interval), etc.</dd>
|
|
<dt id="cp2_1tech" class="tech">Techniques for 2.1</dt>
|
|
<dd>See SMIL for instance.
|
|
<p></p>
|
|
</dd>
|
|
<dt id="cp2_2" class="check"><strong>2.2</strong> Separate presentation
|
|
properties using stylesheet technology/styling mechanisms.</dt>
|
|
<dd id="cp2_2rationale" class="rationale">In non Final-form dialect,
|
|
authors must be able to mark up documents with proper structural
|
|
elements and control presentation with style sheets rather than
|
|
with presentation elements and attributes. This separation of
|
|
content from presentation facilitates the adaptation to users with
|
|
different presentational needs (larger font, better contrast, etc)
|
|
and it also facilitates the maintenance of the pages.</dd>
|
|
<dt id="cp2_2tech" class="tech">Techniques for 2.2</dt>
|
|
<dd><p><strong><a name="L1984" id="L1984">T2.2.2</a></strong>
|
|
Example: <strong>Right</strong></p>
|
|
<p>Support the inclusion and processing of external style sheets
|
|
(note the importance of <a href="#g4_0">Guideline 4</a> on
|
|
exporting semantics in this example, so that the user may override
|
|
the style)</p>
|
|
<pre><em><strong><code>mystyle.css</code></strong></em><code>: news { text-align: center; font: bold Arial }</code></pre>
|
|
<pre><code><?xml-stylesheet href="</code><strong><code>mystyle.css</code></strong><code>" type="text/css"?> ...
|
|
<news>Story 1</news>
|
|
<news>Story 2</news></code></pre>
|
|
<p><strong><a name="L19762"
|
|
id="L19762">TW2.2.1</a> </strong>Example: <strong>Wrong</strong></p>
|
|
<p>Do not include presentational attributes and elements in your
|
|
language.</p>
|
|
<pre><code> <news align="center" font="arial" weight="bold">Story 1</news>
|
|
<news align="center" font="arial" weight="bold">Story 2</news></code></pre>
|
|
<p></p>
|
|
</dd>
|
|
<dt id="cp2_3" class="check"><strong>2.3</strong> Use the standard XML
|
|
linking and pointing mechanisms (XLink and XPointer). <span
|
|
class="issue">[[<a href="/WAI/PF/XML/issues.html#Using">Note this checkpoint is
|
|
under discussion and may change</a>]</span>]</dt>
|
|
<dd id="cp2_3rationale" class="rationale"><a
|
|
href="/TR/xlink/">Xlink</a> [<a href="#XLINK">XLINK</a>] and <a
|
|
href="/TR/xptr-framework/">XPointer</a> [<a
|
|
href="#XPOINTER">XPTR</a>] have been reviewed for accessibility and
|
|
their linking/pointing semantics may be recognized with
|
|
certainty.</dd>
|
|
<dt id="cp2_3tech" class="tech">Techniques for 2.3</dt>
|
|
<dd><p><strong><a name="L1996" id="L1996">T2.3.2</a></strong>
|
|
Example: <strong>Right</strong></p>
|
|
<p>Using links that can be recognized reliably by XLink
|
|
applications.</p>
|
|
<pre><code><myxlink </code><strong><code>xmlns:xlink</code></strong><code>="http://www.w3.org/1999/xlink"
|
|
xlink:href="http://mysite/myfile.xml">
|
|
Current List of references
|
|
</myxlink></code></pre>
|
|
<p><a name="L19891" id="L19891">TW2.3.1</a> Example.
|
|
<strong>Wrong</strong></p>
|
|
<p>User Agents have no way of knowing this is a link.</p>
|
|
<pre><code><mylink linkend="http://mysite/myfile.xml">
|
|
Current List of references
|
|
</mylink></code></pre>
|
|
<p></p>
|
|
</dd>
|
|
<dt id="cp2_4" class="check"><strong>2.4</strong> Define element types
|
|
that allow classification and grouping (header, section, list,
|
|
etc).</dt>
|
|
<dd id="cp2_4rationale" class="rationale">Make use of existing
|
|
mechanisms (noting checkpoint <a href="#cp1_2">1.2</a>), or create
|
|
them where necessary, following these guidelines.</dd>
|
|
<dt id="cp2_4tech" class="tech">Techniques for 2.4</dt>
|
|
<dd><a name="L2001" id="L2001">T2.4.1</a> Think in terms of overall
|
|
structure of your documents when you design a new dialect.
|
|
<pre><code> <-- 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)+)></code></pre>
|
|
</dd>
|
|
<dt id="cp2_5" class="check"><strong>2.5</strong> Provide for a full
|
|
containment model with chunks of reasonable size.</dt>
|
|
<dd id="cp2_5rationale" class="rationale">If a document instance is
|
|
fully contained, i.e. adequate wrapper elements around PCDATA, then
|
|
both CSS and XSLT can be used to style content for presentation in
|
|
alternate formats. If content is in reasonable sized containers, it
|
|
enables the document to be skimmed quickly by non- visual readers.
|
|
If a logical hierarchy of elements is used, then a table of
|
|
contents or summary may be generated providing logical access to
|
|
document content.</dd>
|
|
<dt id="cp2_5tech" class="tech">Techniques for 2.5</dt>
|
|
<dd><strong><a name="L2008" id="L2008">T2.5.1</a></strong> In this
|
|
XML Schema example, a document is broken up into a number of
|
|
sections, and a sequence of nest-able sections with a consistent
|
|
structure may be used for both navigation and the automated
|
|
generation of a table of contents to whatever level.
|
|
<pre><code><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></code></pre>
|
|
</dd>
|
|
<dt id="cp2_6" class="check"><strong>2.6</strong> Define element types
|
|
that identify important text content.</dt>
|
|
<dd id="cp2_6rationale" class="rationale">Within most documents,
|
|
certain elements are key to its understanding. If these are both
|
|
clear, and identified for machine access, their content can be
|
|
presented to a user to gain a swift understanding of the semantics
|
|
of the element, section and eventually the whole document. Examples
|
|
of such important elements are numbers, dates, titles and
|
|
links.</dd>
|
|
<dt id="cp2_6tech" class="tech">Techniques for 2.6</dt>
|
|
<dd><strong><a name="L2015" id="L2015">T2.6.1</a></strong> Mark up
|
|
your text with more semantics, such as datatype meaning "this is a
|
|
date", or "this is an acronym".<br />
|
|
Code example: Using the <a href="/TR/xmlschema-0/">XML Schema
|
|
language</a> [<a href="#XSCHEMA">XSCHEMA</a>] to identify data
|
|
types, rather than simply leaving them as strings: a fully
|
|
constrained ISBN number:
|
|
<pre><code><xsd:simpleType name="</code><strong><code>ISBN-Type</code></strong><code>">
|
|
<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></code></pre>
|
|
</dd>
|
|
<dt id="cp2_7" class="check"><strong>2.7</strong> Provide a mechanism
|
|
for identifying summary / abstract / title.</dt>
|
|
<dd id="cp2_7rationale" class="rationale">Knowing how to extract that
|
|
information allow User Agents to present it to the end-user, thus
|
|
facilitating browsing of the content (e.g. deciding if yes or no
|
|
the document is of interest).</dd>
|
|
<dt id="cp2_7tech" class="tech">Techniques for 2.7</dt>
|
|
<dd><strong><a name="L2022" id="L2022">T2.7.1</a></strong> Example:
|
|
XML using RDF and <a href="http://dublincore.org/ ">Dublin Core
|
|
elements</a> [<a href="#DC-element">DC-elements</a>].
|
|
<pre><code> <someElement xmlns="http://xmlns.com/example">
|
|
<rdf:RDF
|
|
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
|
</code><strong><code>xmlns:dc</code></strong><code>="http://purl.org/dc/elements/1.1/">
|
|
<rdf:Description about="http://www.dlib.org/">
|
|
<</code><strong><code>dc:Title</code></strong><code>>
|
|
D-Lib Program - Research in Digital Libraries
|
|
</dc:Title>
|
|
<</code><strong><code>dc:Description</code></strong><code>>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></code></pre>
|
|
</dd>
|
|
<dt id="cp2_8" class="check"><strong>2.8</strong> Don't overload
|
|
element and attribute names.</dt>
|
|
<dd id="cp2_8rationale" class="rationale">If an element name may be
|
|
confused, within the context of the document instance, then it is
|
|
said to be overloaded. If each element name is unique within
|
|
context it is easier to access the document semantics. Note the
|
|
relation to <a href="#cp4_9">checkpoint 4.9</a>.</dd>
|
|
<dt id="cp2_8tech" class="tech">Techniques for 2.8</dt>
|
|
<dd><p><strong><a name="L2038" id="L2038">T2.8.2</a></strong>
|
|
Example: <strong>Right</strong></p>
|
|
<pre><code> <report>
|
|
<invoice>
|
|
<</code><strong><code>price</code></strong><code>>25</</code><strong><code>price</code></strong><code>>
|
|
<currency>Dollar</currency>
|
|
....
|
|
</invoice>
|
|
<description>
|
|
<item>Widgets</item>
|
|
<</code><strong><code>quantity</code></strong><code>>25</</code><strong><code>quantity</code></strong><code>>
|
|
</description>
|
|
</report></code></pre>
|
|
<p><strong><a name="L20311" id="L20311">TW2.8.1</a></strong>
|
|
Example: <strong>Wrong</strong></p>
|
|
<pre><code> <report>
|
|
<invoice>
|
|
<</code><strong><code>amount</code></strong><code>>25 dollars</</code><strong><code>amount</code></strong><code>>
|
|
....
|
|
</invoice>
|
|
<description>
|
|
<item>Widgets</item>
|
|
<</code><strong><code>amount</code></strong><code>>25</</code><strong><code>amount</code></strong><code>>
|
|
</description>
|
|
</report></code></pre>
|
|
<p>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.</p>
|
|
<p>In the example above, the meaning of all the elements is clear
|
|
and none of the individuals elements is overloaded.</p>
|
|
</dd>
|
|
<dt id="cp2_9" class="check"><strong>2.9</strong> <a name="cp1_3"
|
|
id="cp1_3"></a>Reuse existing accessible modules, as originally
|
|
specified / intended. <span class="issue">[[<a
|
|
href="/WAI/PF/XML/issues.html#Checkpoint">Note: This checkpoint is under
|
|
discussion, and may be changed to techniques, or may be augmented with
|
|
a list of modules that should be re-used</a>]]</span></dt>
|
|
<dd id="cp2_9rationale" class="rationale">Reusing accessibility
|
|
modules has the advantage that materials produced using your
|
|
language will be accessible to their clients. No need to create
|
|
"new" elements/attributes or re-invent the wheel just to satisfy
|
|
some creative fantasy. There's a non negligible cost for authors
|
|
(the people using your language) to learn new concepts. When using
|
|
modules from other schema, use them with the same semantics as
|
|
originally intended.</dd>
|
|
<dt id="cp2_9tech" class="tech">Techniques for 2.9</dt>
|
|
<dd><strong><a name="L1965" id="L1965">T1.3.1</a></strong> This
|
|
example shows how to use an existing DTD module: the object from
|
|
the XHTML language</dd>
|
|
<dd><pre><code><!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"
|
|
"</code><strong><code>xhtml-object-1.mod</code></strong><code>" >
|
|
%qnames;
|
|
%object;
|
|
]>
|
|
<i:inventory xmlns:i="http://www.my.org/xmlns/inventory">
|
|
<i:stockitem>
|
|
etc.
|
|
<</code><strong><code>xhtml:object</code></strong><code>...>
|
|
to include a picture or movie of the part.</code></pre>
|
|
</dd>
|
|
<dd><strong><a name="L2045" id="L2045">T2.9.1</a></strong> Example:
|
|
reusing SMIL switch
|
|
<pre><code> ...
|
|
<par>
|
|
<video src="anchor.mpg" ... />
|
|
<switch>
|
|
<audio src="HiQuality.wav" systemBitrate="56000" ... />
|
|
<audio src="MedQuality.wav" systemBitrate="28800" ... />
|
|
<audio src="LowQuality.wav" ... />
|
|
</switch>
|
|
</par></code></pre>
|
|
</dd>
|
|
<dt id="cp2_10" class="check"><strong>2.10</strong> Allow association
|
|
of metadata with distinct elements and groups of elements.</dt>
|
|
<dd id="cp2_10rationale" class="rationale">This permits authors to
|
|
make even more semantic associations than what was originally
|
|
intended by the language designer.</dd>
|
|
<dt id="cp2_10tech" class="tech">Techniques for 2.10</dt>
|
|
<dd><strong><a name="L2052" id="L2052">T2.10.1</a></strong> In SVG
|
|
for instance, there is a <code>metadata</code> 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 <a
|
|
href="/TR/SVG-access/">SVG Accessibility note</a> [<a
|
|
href="#ref-SVG-ACCESS">SVG-access</a>] for examples.
|
|
<p>Also, by providing ID for all your elements, you allow external
|
|
metadata to point to them.</p>
|
|
</dd>
|
|
<dt id="cp2_11" class="check"><strong>2.11</strong> Specific checkpoint
|
|
for Final-form applications.</dt>
|
|
<dd id="cp2_1rationale1" class="rationale">Languages used only for
|
|
presentation to a certain scope of users and media are called,
|
|
<strong>Final-form</strong> and they should adhere to the following
|
|
provisions:
|
|
<ul>
|
|
<li>Allow the author to identify by URI the source used to
|
|
generate the final form instance.</li>
|
|
<li>In the application documentation, indicate that final form
|
|
instances SHOULD NOT be served except upon explicit user
|
|
request (e.g., through a configured preference).</li>
|
|
<li>In the application documentation, indicate that final form
|
|
instances SHOULD NOT be the only form used to store information
|
|
persistently; a semantically rich source should be stored
|
|
instead or made available by dereferencing the URI required by
|
|
the first provision of this checkpoint.</li>
|
|
</ul>
|
|
</dd>
|
|
<dt id="cp2_1tech1" class="tech">Techniques for 2.11</dt>
|
|
<dd>The <a
|
|
href="/TR/xsl/slice1.html#section-N697-Tree-Transformations">XSL
|
|
1.0</a> specification [<a href="#XSL10">XSL10</a>] contains the
|
|
following example of such wording.
|
|
|
|
<blockquote cite="http://www.w3.org/TR/xsl/slice1">
|
|
<p>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.</p>
|
|
</blockquote>
|
|
</dd>
|
|
</dl>
|
|
</li>
|
|
<li><h3 id="g3_0" class="guide">Guideline 3. Design an accessible user
|
|
interface.</h3>
|
|
<p>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.</p>
|
|
<dl>
|
|
<dt id="cp3_1" class="check"><strong>3.1</strong> Provide default style
|
|
sheets for multiple output modalities.</dt>
|
|
<dd id="cp3_1rationale" class="rationale">The additional effort from
|
|
the language designer point of view in providing style sheets which
|
|
can represent an XML document instance in alternate modalities is
|
|
minimal and will have a multiplier benefit for all the authors
|
|
using the language and these style sheets. Readers of your
|
|
documents may prefer audio access, so providing an appropriate
|
|
stylesheet with your schema which will allow those readers to
|
|
utilize synthetic speech to produce a clear rendering of the
|
|
content.</dd>
|
|
<dt id="cp3_1tech" class="tech">Techniques for 3.1</dt>
|
|
<dd><strong><a name="L2059" id="L2059">T3.1.1</a></strong> Example:
|
|
See the <a href="http://www.w3.org/TR/CSS2/sample.html">sample
|
|
style sheet for HTML 4.0</a> [<a href="#HTML-style">HTML-style</a>]
|
|
provided with the CSS2 specification.</dd>
|
|
<dt id="cp3_2" class="check"><strong>3.2</strong> Define navigable
|
|
structures that allow discrete, sequential, structured, and search
|
|
navigation functionalities.</dt>
|
|
<dd id="cp3_2rationale" class="rationale">Navigable structures are
|
|
the key elements used for navigation around an XML application.
|
|
Define element types that allow classification and grouping, or
|
|
re-use existing accessible grouping and classification modules.</dd>
|
|
<dt id="g3_2tech" class="tech">Techniques for 3.2</dt>
|
|
<dd><strong><a name="L2066" id="L2066">T3.2.1</a></strong> Example:
|
|
See how the <a
|
|
href="http://www.loc.gov/nls/z3986/index.html">Digital Talking
|
|
Book</a> [<a href="#DTB">DTB</a>] provides elements for navigable
|
|
structures.</dd>
|
|
<dt id="cp3_3" class="check"><strong>3.3</strong> Use CSS or XSLT to
|
|
describe a basic outline view.<br />
|
|
</dt>
|
|
<dd id="cp3_3rationale" class="rationale">The language designer is
|
|
the best placed to provide a mapping of the new language constructs
|
|
to a basic outline format, which will facilitate the deployment of
|
|
content by making it understandable for all classes of users.</dd>
|
|
<dt id="cp3_3tech" class="tech">Techniques for 3.3</dt>
|
|
<dd><a name="L2118" id="L2118"><strong>T3.3.1</strong></a> The
|
|
following stylesheet provides a transformation to produce an HTML
|
|
outline or table of contents listing the title of each section, and
|
|
nesting them to match an original document example.</dd>
|
|
<dd><pre><code><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></code></pre>
|
|
</dd>
|
|
<dt id="cp3_4" class="check"><strong>3.4</strong> Use a
|
|
device-independent interaction and events model / module.</dt>
|
|
<dd id="cp3_4rationale" class="rationale">Any XML application which
|
|
contains user interaction may exclude readership if presumptions
|
|
are made about the technology used to access that application. What
|
|
happens when the application only support mouse interaction, and
|
|
the user is not mouse bound? The result could be lost sales, it
|
|
will be a loss of interest and a search for alternatives.</dd>
|
|
<dt id="cp3_4tech" class="tech">Techniques for 3.4</dt>
|
|
<dd><strong><a name="L2129" id="L2129">T3.4.1</a></strong> Using <a
|
|
href="http://www.w3.org/TR/DOM-Level-2-Events/events.html">DOM2
|
|
event</a> the right way in <a
|
|
href="http://www.w3.org/TR/SVG/interact.html">SVG</a>.
|
|
<pre><code><script type="text/ecmascript"> function DoOnActivate(evt) { .. } </script>
|
|
|
|
<g onactivate="</code><strong><code>DoOnActivate</code></strong><code>(evt)">
|
|
<rect id="button" x="500" y="500" width="250" height="40"/>
|
|
</g></code></pre>
|
|
</dd>
|
|
<dt id="cp3_5" class="check"><strong>3.5</strong> Allow for user
|
|
control of interaction timing - rate of change, external events
|
|
triggering document changes, etc.</dt>
|
|
<dd id="cp3_5rationale" class="rationale">If an XML application
|
|
presumes that all readers will take in content in a fixed time
|
|
period, will read at a certain rate, or access each page in a
|
|
certain time, then readers and users of that application will be
|
|
lost.</dd>
|
|
<dt id="cp3_5tech" class="tech">Techniques for 3.5</dt>
|
|
<dd><strong><a name="L2136" id="L2136">T3.5.1</a></strong> Ensure and
|
|
promote the work the user agent has to do to control - on behalf of
|
|
the end-user - the rate of change of content presentation, perhaps
|
|
using element attribute for pause facility or settable rate to
|
|
allow the user control of all interactions. Fixed time period
|
|
time-outs are not popular. See the <a
|
|
href="http://www.w3.org/TR/smil-animation/">SMIL-Animation</a>
|
|
specification [<a href="#SMIL-anim">SMIL-anim</a>] for examples of
|
|
such design.</dd>
|
|
</dl>
|
|
</li>
|
|
<li><h3 id="g4_0" class="guide">Guideline 4 Document and export
|
|
semantics</h3>
|
|
<p>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.</p>
|
|
<dl>
|
|
<dt id="cp4_3" class="check"><strong>4.1</strong> Provide explicit
|
|
human readable definitions for markup semantics.</dt>
|
|
<dd id="cp4_3rationale" class="rationale">Any schema which is
|
|
designed by a single person in a reasonable period will only be
|
|
understood by that person designing it. When exposed to document
|
|
authors, interpretations will vary. If the schema designer wishes
|
|
document authors to utilize the same semantics then those semantics
|
|
require documentation. The better the quality of that
|
|
documentation, the more likely the shared understanding.</dd>
|
|
<dt id="cp4_3tech" class="tech">Techniques for 4.3</dt>
|
|
<dd><strong><a name="L215711" id="L215711">T4.3.1</a></strong>
|
|
Example: TREX
|
|
<pre><code><element name="paragraph">
|
|
<xsd:annotation>the lowest level block container.</xsd:annotation>
|
|
<empty/>
|
|
</element></code></pre>
|
|
</dd>
|
|
<dt id="cp4_1" class="check"><strong>4.2</strong> Ensure that at least
|
|
one version of the XML application's documentation conforms to at least
|
|
level Double-A of the Web Content Accessibility Guidelines 1.0 [<a
|
|
href="#ref-WCAG10">WCAG10</a>].</dt>
|
|
<dd id="cp4_1rationale" class="rationale">Everybody should be able to
|
|
read and understand a technical specification, even one that is
|
|
purely intended for a particular class of users.</dd>
|
|
<dt id="cp4_1tech" class="tech">Techniques for 4.1</dt>
|
|
<dd><strong><a name="L21431" id="L21431">T4.1.1</a></strong> For
|
|
instance, blind users routinely author Web content that is intended
|
|
for sighted users, and they can do so because the HTML and the CSS
|
|
specifications are accessible (well structured, description of
|
|
pictures, etc).</dd>
|
|
<dt id="cp4_2" class="check"><strong>4.3</strong> Provide a
|
|
machine-understandable means/mechanism to get from a document instance
|
|
to the schema.</dt>
|
|
<dd id="cp4_2rationale" class="rationale">This allows programs to
|
|
automatically retrieve the documentation of a language.</dd>
|
|
<dt id="cp4_2tech" class="tech">Techniques for 4.2</dt>
|
|
<dd><strong><a name="L21501" id="L21501">T4.2.2</a></strong> Example:
|
|
Uses the W3C XML Schema language as the schema, referencing it via
|
|
the xsi:schemaLocation attribute.
|
|
<pre><code><?xml version="1.0" encoding="utf-8"?>
|
|
<my:doc
|
|
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
|
|
xsi:</code><strong><code>schemaLocation</code></strong><code>="http://www.example.org/schemas/doc.xsd"
|
|
xmlns:my="http://www.jenitennison.com/"
|
|
xmlns="http://www.w3.org/1999/xhtml"></code></pre>
|
|
</dd>
|
|
<dt id="cp4_4" class="check"><strong>4.4</strong> Use a schema language
|
|
that can support explicit human-readable documentation or annotation of
|
|
semantics.</dt>
|
|
<dd id="cp4_4rationale" class="rationale">It is important that the
|
|
schema language allows the language designer to explicitly attach
|
|
documentation to elements and attributes.</dd>
|
|
<dt id="cp4_4tech" class="tech">Techniques for 4.4</dt>
|
|
<dd><strong><a name="L21641" id="L21641">T4.4.1</a></strong> Example
|
|
<strong>Right</strong>: The need for the head element is clearly
|
|
described.
|
|
<pre><code><xsd:element name="head" type="xsd:string">
|
|
<xsd:annotation>
|
|
<xsd:</code><strong><code>documentation</code></strong><code> xml:lang="en-US">Title of the section.
|
|
Required for table of contents generation.
|
|
</xsd:documentation>
|
|
</xsd:annotation>
|
|
</xsd:element></code></pre>
|
|
</dd>
|
|
<dd><strong><a name="L2058" id="L2058">T4.4.2</a></strong> Example
|
|
<strong>Wrong</strong>: In the following DTD extract there is
|
|
documentation available but only by reading the source DTD. It is
|
|
possible to reliably extract only some of this and present it to a
|
|
user automatically. It is also not possible to provide rich
|
|
information here - it is plain text without any of rich media
|
|
features necessary to provide high-level conformance to WCAG.</dd>
|
|
<dd><pre><code><!-- 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 --></code></pre>
|
|
</dd>
|
|
<dt id="cp4_5" class="check"><strong>4.5</strong> Provide semantic
|
|
relationships to other schema where appropriate and possible.</dt>
|
|
<dd id="cp4_5rationale" class="rationale">This allows the authors
|
|
using the language to reuse their existing knowledge and tools.</dd>
|
|
<dt id="cp4_5tech" class="tech">Techniques for 4.5</dt>
|
|
<dd><strong><a name="L21711" id="L21711">T4.5.1</a></strong> This can
|
|
be done implicitly via subclassing/derivation of existing types, by
|
|
asserting equivalence of type (e.g. SVG <code>title</code> and SMIL
|
|
<code>title</code>) or by mapping to well known semantics.</dd>
|
|
<dd>Example: mapping the Menu example provided in the Introduction to
|
|
XHTML using XSLT:
|
|
<pre><code><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> </code><strong><code>
|
|
<h1>Menu of: <xsl:value-of select="menu/"/></h1></code></strong><code>
|
|
</code><strong><code><h2>Appetizer: <xsl:value-of select="menu/appetizer/"/></h2></code></strong><code> etc...
|
|
</body>
|
|
</html></code></pre>
|
|
</dd>
|
|
<dt id="cp4_6" class="check"><strong>4.6</strong> Document all features
|
|
of the XML application that benefit accessibility. <br />
|
|
</dt>
|
|
<dd id="cp4_6rationale" class="rationale">This is useful in order to
|
|
foster the development of state of the art assistive technologies
|
|
to identify all the features of a new language that make it more
|
|
accessible.</dd>
|
|
<dt id="cp4_6tech" class="tech">Techniques for 4.6</dt>
|
|
<dd><strong><a name="L21781" id="L21781">T4.6.1</a></strong> SVG has
|
|
provided <a href="/TR/2000/CR-SVG-20001102/access">a good example
|
|
of this</a> [<a href="#SVG10-acce">SVG10-access</a>] being a part
|
|
of the recommendation. For W3C Working drafts, include and document
|
|
those specific features which positively aid accessibility.</dd>
|
|
<dt id="cp4_7" class="check"><strong>4.7</strong> Include accessibility
|
|
requirements in conformance requirements.</dt>
|
|
<dd id="cp4_7rationale" class="rationale">This promotes the
|
|
development of accessible content in the community caring about
|
|
conformance.</dd>
|
|
<dt id="cp4_7tech" class="tech">Techniques for 4.7</dt>
|
|
<dd><strong><a name="L21851" id="L21851">T4.7.1</a></strong> SVG has
|
|
specific accessibility requirements as <a
|
|
href="/TR/SVG/conform.html">a part</a> [<a
|
|
href="#SVG10-acce">SVG10-access</a>] of the overall requirement
|
|
document. When the requirements are drawn up, specific clauses need
|
|
to be included which clearly state accessibility requirements
|
|
<p><strong><a name="T4.7.2" id="T4.7.2">T4.7.2</a></strong> A more
|
|
detailed explanation is given in <a
|
|
href="/WAI/UA/UAAG10/conformance#include-uaag-reqs">section
|
|
3.3 of the User Agent Accessibility Guidelines</a> [<a
|
|
href="#ref-UAAG10">UAAG10</a>]</p>
|
|
</dd>
|
|
<dt id="cp4_8" class="check"><strong>4.8</strong> Document techniques
|
|
for WCAG, ATAG, and UAAG with respect to the XML application.</dt>
|
|
<dd id="cp4_8rationale" class="rationale">The WAI suite of
|
|
accessibility guidelines [<a href="#ref-WCAG10">WCAG</a>],[<a
|
|
href="#ATAG10">ATAG</a>],[<a href="#ref-UAAG10">UAAG</a>] contain
|
|
detailed descriptions as to how to satisfy each individual
|
|
document's requirements. Therefore, it is important to review your
|
|
XML application to ensure that you have implemented a relevant
|
|
technique for each checkpoint in the WAI suite of accessibility
|
|
guidelines. For example, you could show how a (hypothetical)
|
|
instance of your application conforms to WCAG, how an authoring
|
|
tool which implements your application would enable an author to
|
|
create accessible content; how a user agent capable of supporting
|
|
your application must conform to UAAG, etc.</dd>
|
|
<dt id="cp4_8tech" class="tech">Techniques for 4.8</dt>
|
|
<dd><strong><a name="L21921" id="L21921">T4.8.1</a></strong> Still
|
|
using the MenuML language, here are examples of WCAG
|
|
technique<em>s</em>
|
|
<ul>
|
|
<li><em>WCAG checkpoint 1.1</em>: Provide a text equivalent for
|
|
every non-text element
|
|
<p><em>MenuML technique</em>: use the content of the
|
|
<code>photo</code> element to indicate the textual equivalent
|
|
of the picture.</p>
|
|
</li>
|
|
<li><em>WCAG checkpoint 3.5</em>: Use header elements to convey
|
|
document structure and use them according to specification.
|
|
<p><em>MenuML technique</em>: use the <code>appetizer</code>
|
|
element to introduce a new appetizer, not a <code>para</code>
|
|
and some bigger font</p>
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
<dt id="cp4_9" class="check"><strong>4.9</strong> Do not assume that
|
|
element or attribute names provide any information about element
|
|
semantics.</dt>
|
|
<dd id="cp4_9rationale" class="rationale">An element named may have a
|
|
fully contextualized meaning for the schema author, but is unlikely
|
|
to mean much to someone who does not speak the language of the
|
|
author. Equally, taken out of context, without semantic
|
|
explanation, element names often lose their meaning. Simply naming
|
|
an element is not enough to assure that document authors will
|
|
utilize that element in semantic conformance with the schema
|
|
authors intent. It is likely that confusion and misinterpretation
|
|
will arise if element or attribute names are relied upon to
|
|
document a schema.</dd>
|
|
<dt id="cp4_9tech" class="tech">Techniques for 4.9</dt>
|
|
<dd><strong><a name="L21991" id="L21991">TW4.9.1</a></strong> For
|
|
example, using TREX, avoid colloquial element names.
|
|
<p>Example: <strong>Wrong</strong></p>
|
|
<pre><code><element name="paragraph">
|
|
<xsd:annotation>
|
|
<xsd:documentation>paragraph</xsd:documentation>
|
|
</xsd:annotation>
|
|
<empty/>
|
|
</element></code></pre>
|
|
<p>Here the element name has been described using the element name
|
|
only, which adds no semantic value.</p>
|
|
<p><strong><a name="L22061" id="L22061">T4.9.2</a></strong>
|
|
Example: <strong>Right</strong></p>
|
|
<pre><code><element name="paragraph">
|
|
<xsd:annotation>
|
|
<xsd:documentation>The lowest level block container.
|
|
</xsd:documentation>
|
|
</xsd:annotation>
|
|
<empty/>
|
|
</element></code></pre>
|
|
<p>Here the element name has been described in an alternate form to
|
|
clarify semantics rather than re-enforce the name by repeating
|
|
it.</p>
|
|
</dd>
|
|
<dt id="cp4_10" class="check"><strong>4.10</strong> Document navigable
|
|
structures. Describe how discrete, sequential, structured, and search
|
|
navigation mechanisms should work.</dt>
|
|
<dd id="cp4_10rationale" class="rationale">In order to navigate
|
|
around a significant document, it is helpful to the reader if they
|
|
know what elements are available for such navigation.</dd>
|
|
<dt id="cp4_10tech" class="tech">Techniques for 4.10</dt>
|
|
<dd><strong><a name="L22131" id="L22131">T4.10.1</a></strong> Random
|
|
access to any part of a document via a detailed table of contents,
|
|
numbered headings which may be searched for, a hierarchical view
|
|
enabling fast access to sought parts, and a search capability aid
|
|
in this.</dd>
|
|
</dl>
|
|
</li>
|
|
</ul>
|
|
<hr />
|
|
|
|
<h2 id="Appendices">Appendices</h2>
|
|
|
|
<h3 id="techniques">Appendix A: Techniques Rationale</h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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:</p>
|
|
<ul>
|
|
<li>using the XHTML namespace and its <ins>elements</ins> (e.g. xhtml:ul,
|
|
xhtml:li)</li>
|
|
<li>invent new constructs but provide an XSLT binding (e.g. to a HTML UL/LI
|
|
pair of element)</li>
|
|
<li>using XML/RDF Schema (if a list primitive is available; or through a
|
|
new schema if a primitive is unavailable)</li>
|
|
<li>using Architectural forms with support for list semantics</li>
|
|
<li>etc</li>
|
|
</ul>
|
|
|
|
<h3><a name="detaildefs" id="detaildefs">Appendix B: Glossary</a></h3>
|
|
|
|
<p>The source of definitions used is the <a
|
|
href="/WAI/GL/Glossary/printable">WAI Glossary</a> [<a
|
|
href="#L5705">GLOSS</a>]</p>
|
|
|
|
<h3 id="acknowledgments">Appendix C: Acknowledgments</h3>
|
|
|
|
<p>In addition to the editors, the following people have contributed directly
|
|
to the content of this document:</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<h3><a name="references" id="references">Appendix D: References</a></h3>
|
|
<dl>
|
|
<dt>[<a name="ATAG10" id="ATAG10">ATAG10</a>]</dt>
|
|
<dd>"<a href="/TR/2000/REC-ATAG10-20000203/">Authoring Tool Accessibility
|
|
Guidelines 1.0</a>", J. Treviranus, C. McCathieNevile, I. Jacobs, and
|
|
J. Richards, eds., 3 February 2000. This W3C Recommendation is
|
|
http://www.w3.org/TR/2000/REC-ATAG10-20000203</dd>
|
|
<dt><a name="ref-ATAG10-TECHS" id="ref-ATAG10-TECHS">[ATAG10-TECHS]</a></dt>
|
|
<dd>"<a href="/TR/ATAG10-TECHS/">Techniques for Authoring Tool
|
|
Accessibility Guidelines 1.0</a>," J. Treviranus, J. Richards, I.
|
|
Jacobs, and C. McCathieNevile eds. The latest version is available at
|
|
http://www.w3.org/TR/ATAG10-TECHS</dd>
|
|
<dt>[<a name="DC-element" id="DC-element">DC-elements</a>]</dt>
|
|
<dd>"<a href="http://dublincore.org/documents/dces/">Dublin Core Metadata
|
|
Element Set, Version 1.1: Reference Description</a>" DCMI
|
|
Recommendation, 2 July 1999, available at
|
|
http://dublincore.org/documents/dces/</dd>
|
|
<dt>[<a name="DTB" id="DTB">DTB</a>]</dt>
|
|
<dd>"<a href="http://www.loc.gov/nls/z3986/index.html">Digital Talking
|
|
Book</a>" ANSI/NISO specification Z39.86. Available at
|
|
http://www.loc.gov/nls/z3986/index.html</dd>
|
|
<dt><a name="L5705" id="L5705">[GLOSS]</a></dt>
|
|
<dd><a href="/WAI/GL/Glossary/printable">WAI Glossary</a>. An internal
|
|
working draft. K Haritos-Shea, C. McCathieNevile, eds. Available at
|
|
http://www.w3.org/WAI/GL/Glossary/printable</dd>
|
|
<dt>[<a name="HTML-acces" id="HTML-acces">HTML-access</a>]</dt>
|
|
<dd>"<a href="/WAI/References/HTML4-access">HTML 4.0 Accessibility
|
|
Improvements</a>", I. Jacobs, J. Brewer, D. Dardailler. Available at
|
|
http://www.w3.org/WAI/References/HTML4-access</dd>
|
|
<dt>[<a name="HTML-style" id="HTML-style">HTML-style</a>]</dt>
|
|
<dd>"<a href="/TR/CSS2/sample.html">A sample CSS style sheet for HTML
|
|
4.0</a>" provided as an informative appendix to the CSS 2
|
|
specification. Available at http://www.w3.org/TR/CSS2/sample</dd>
|
|
<dt>[<a name="SMIL-anim" id="SMIL-anim">SMIL-anim</a>]</dt>
|
|
<dd>"<a href="/TR/smil-animation/">SMIL Animation</a>", P. Schmitz, A.
|
|
Cohen eds. W3C Recommendation 4 September 2001, available at
|
|
http://www.w3.org/TR/2001/REC-smil-animation-20010904/</dd>
|
|
<dt><a name="ref-SVG-ACCESS" id="ref-SVG-ACCESS">[SVG-ACCESS]</a></dt>
|
|
<dd>"<a href="/TR/SVG-access/">Accessibility of Scalable Vector
|
|
Graphics</a>", C. McCathieNevile, M.-R. Koivunen, eds. W3C Note
|
|
available at http://www.w3.org/TR/SVG-access. The latest editors'
|
|
version is available at http://www.w3.org/1999/09/SVG-access.</dd>
|
|
<dt><a name="SVG11" id="SVG11">[SVG10]</a></dt>
|
|
<dd>"<a href="/TR/2000/CR-SVG-20000802/">Scalable Vector Graphics 1.0
|
|
Specification</a>", J. Ferraiolo, ed., 4 September 2001. This W3C
|
|
Recommendation is available at
|
|
http://www.w3.org/TR/2001/REC-SVG-20010904/</dd>
|
|
<dt>[<a name="SVG10-acce" id="SVG10-acce">SVG10-access</a>]</dt>
|
|
<dd><a href="/TR/SVG/access">SVG 1.0 Appendix H - Accessibility
|
|
Support</a>. An appendix to the SVG 1.0 specification [<a
|
|
href="#SVG11">SVG10</a>] Available at
|
|
http://www.w3.org/TR/2001/REC-SVG-20010904/access</dd>
|
|
<dt><a name="ref-UAAG10" id="ref-UAAG10">[UAAG10]</a></dt>
|
|
<dd>"<a href="/WAI/UA/UAAG10/">User Agent Accessibility Guidelines</a>,"
|
|
J. Gunderson, I. Jacobs, E. Hansen eds. The latest version of the User
|
|
Agent Accessibility Guidelines is available at
|
|
http://www.w3.org/WAI/UA/UAAG10.</dd>
|
|
<dt><a name="ref-UAAG10-TECHS" id="ref-UAAG10-TECHS">[UAAG10-TECHS]</a></dt>
|
|
<dd>"<a href="/TR/UAAG10-TECHS/">Techniques for User Agent Accessibility
|
|
Guidelines 1.0</a>," J. Gunderson, I. Jacobs, E. Hansen eds. The <a
|
|
href="/TR/UAAG10-TECHS/">latest version of Techniques for User Agent
|
|
Accessibility Guidelines 1.0</a> is available at
|
|
http://www.w3.org/TR/UAAG10-TECHS/.</dd>
|
|
<dt><a name="ref-WCAG10" id="ref-WCAG10">[WCAG10]</a></dt>
|
|
<dd>"<a href="/TR/1999/WAI-WEBCONTENT-19990505/">Web Content Accessibility
|
|
Guidelines 1.0</a>," W. Chisholm, G. Vanderheiden, and I. Jacobs, eds.,
|
|
5 May 1999. This Recommendation is
|
|
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505. The latest version
|
|
is available at http://www.w3.org/TR/WCAG10/.</dd>
|
|
<dt><a name="ref-WCAG10-TECHS" id="ref-WCAG10-TECHS">[WCAG10-TECHS]</a></dt>
|
|
<dd>"<a href="/TR/WCAG10-TECHS/">Techniques for Web Content Accessibility
|
|
Guidelines 1.0</a>," W. Chisholm, G. Vanderheiden, and I. Jacobs, eds.
|
|
The <a href="/TR/WCAG10-TECHS/">latest version</a> is available at
|
|
http://www.w3.org/TR/WCAG10-TECHS/.</dd>
|
|
<dt>[<a name="XLINK" id="XLINK">XLINK</a>]</dt>
|
|
<dd>"<a href="/TR/xlink/">XML Linking Language (XLink) Version 1.0</a>",
|
|
S. DeRose, E. Maler, D. Orchard eds. W3C Recommendation 27 June 2001,
|
|
available at http://www.w3.org/TR/2001/REC-xlink-20010627/</dd>
|
|
<dt>[<a name="XPOINTER" id="XPOINTER">XPTR</a>]</dt>
|
|
<dd>"<a href="/TR/xptr-framework/">XPointer Framework</a>", P. Grosso, E.
|
|
Maler, J. Marsh, N. Walsh eds. The latest version of this W3C Working
|
|
draft is available at http://www.w3.org/TR/xptr-framework/</dd>
|
|
<dt>[<a name="XSCHEMA" id="XSCHEMA">XSCHEMA</a>]</dt>
|
|
<dd>"<a href="/TR/xmlschema-0/">XML Schema</a>", D. Fallside ed. W3C
|
|
Recommendation 2 May 2001, available at
|
|
http://www.w3.org/TR/xmlschema-0/</dd>
|
|
<dt>[<a name="XSL10" id="XSL10">XSL10</a>]</dt>
|
|
<dd>"<a href="/TR/xsl/">Extensible Stylesheet Language (XSL)Version
|
|
1.0</a>", S.Adler et al. W3C Recommendation 15 October 2001, available
|
|
at http://www.w3.org/TR/2001/REC-xsl-20011015/</dd>
|
|
</dl>
|
|
|
|
<h3><a name="Appendix" id="Appendix"
|
|
href="/TR/2001/WD-xmlgl-20010829">Appendix E: Changes from the 28 August 2001
|
|
Working Draft</a></h3>
|
|
|
|
<p>These changes were decided by the PFWG based on the <a
|
|
href="/WAI/PF/XML/issues.html">XAG issues list</a>.</p>
|
|
<dl>
|
|
<dt>Editorial Changes</dt>
|
|
<dd>Changes were made to the text of several checkpoints:
|
|
<ul>
|
|
<li>Checkpoint 2.8</li>
|
|
<li>Checkpoint 2.11</li>
|
|
<li>Checkpoint 3.1</li>
|
|
<li>Checkpoint 4.2 (which was checkpoint 4.1)</li>
|
|
<li>Checkpoint 4.6</li>
|
|
</ul>
|
|
</dd>
|
|
<dd>Checkpoints 4.1, 4.2 and 4.3 were reordered</dd>
|
|
<dd>Major issues now noted in document</dd>
|
|
<dd>The Abstract, Introduction and Problem Statement sections were
|
|
substantially rewritten</dd>
|
|
<dd>New Section in Introduction: relation to other WAI guidelines</dd>
|
|
<dd>Definition Section changed to reference to WAI glossary</dd>
|
|
<dd>Change History added</dd>
|
|
<dd>List of Checkpoints added as an appendix</dd>
|
|
<dd>New References section</dd>
|
|
<dt>Substantive Changes</dt>
|
|
<dd>Checkpoint 2.11 added</dd>
|
|
<dd>Checkpoint 1.3 merged into checkpoint 2.9</dd>
|
|
</dl>
|
|
|
|
<h3><a name="checklist" id="checklist">Appendix F: List of
|
|
Checkpoints</a></h3>
|
|
<dl>
|
|
<dt>Guideline 1: Ensure that authors can associate multiple media objects
|
|
as alternatives</dt>
|
|
<dd><ul>
|
|
<li>1.1 Provide a mechanism to explicitly associate alternatives for
|
|
content or content fragments.</li>
|
|
<li>1.2 Define flexible associations, where a given kind of
|
|
relationship can link to or from objects of varying types without
|
|
constraint.</li>
|
|
</ul>
|
|
</dd>
|
|
<dt>Guideline 2. Create semantically-rich languages</dt>
|
|
<dd><ul>
|
|
<li>2.1 Ensure all semantics are captured in markup in a
|
|
repurposable form.</li>
|
|
<li>2.2 Separate presentation properties using stylesheet
|
|
technology/styling mechanisms.</li>
|
|
<li>2.3 Use the standard XML linking and pointing mechanisms (XLink
|
|
and XPointer).</li>
|
|
<li>2.4 Define element types that allow classification and grouping
|
|
(header, section, list, etc).</li>
|
|
<li>2.5 Provide for a full containment model with chunks of
|
|
reasonable size.</li>
|
|
<li>2.6 Define element types that identify important text
|
|
content.</li>
|
|
<li>2.7 Provide a mechanism for identifying summary / abstract /
|
|
title.</li>
|
|
<li>2.8 Don't overload element and attribute names.</li>
|
|
<li>2.9 Reuse existing accessible modules, as originally specified /
|
|
intended.</li>
|
|
<li>2.10 Allow association of metadata with distinct elements and
|
|
groups of elements.</li>
|
|
<li>2.11 Specific checkpoint for Final-form applications.</li>
|
|
</ul>
|
|
</dd>
|
|
<dt>Guideline 3. Design an accessible user interface</dt>
|
|
<dd><ul>
|
|
<li>3.1 Provide default style sheets for multiple output
|
|
modalities.</li>
|
|
<li>3.2 Define navigable structures that allow discrete, sequential,
|
|
structured, and search navigation functionalities.</li>
|
|
<li>3.3 Use CSS or XSLT to describe a basic outline view</li>
|
|
<li>3.4 Use a device-independent interaction and events model /
|
|
module.</li>
|
|
<li>3.5 Allow for user control of interaction timing - rate of
|
|
change, external events triggering document changes, etc.</li>
|
|
</ul>
|
|
</dd>
|
|
<dt>Guideline 4 Document and export semantics</dt>
|
|
<dd><ul>
|
|
<li>4.1 Provide explicit human readable definitions for markup
|
|
semantics.</li>
|
|
<li>4.2 Ensure that at least one version of the XML application's
|
|
documentation conforms to at least level Double-A of the Web
|
|
Content Accessibility Guidelines 1.0 [WCAG10].</li>
|
|
<li>4.3 Provide a machine-understandable means/mechanism to get from
|
|
a document instance to the schema.</li>
|
|
<li>4.4 Use a schema language that can support explicit
|
|
human-readable documentation or annotation of semantics.</li>
|
|
<li>4.5 Provide semantic relationships to other schema where
|
|
appropriate and possible.</li>
|
|
<li>4.6 Document all features of the XML application that benefit
|
|
accessibility.</li>
|
|
<li>4.7 Include accessibility requirements in conformance
|
|
requirements.</li>
|
|
<li>4.8 Document techniques for WCAG, ATAG, and UAAG with respect to
|
|
the XML application.</li>
|
|
<li>4.9 Do not assume that element or attribute names provide any
|
|
information about element semantics.</li>
|
|
<li>4.10 Document navigable structures. Describe how discrete,
|
|
sequential, structured, and search navigation mechanisms should
|
|
work</li>
|
|
</ul>
|
|
</dd>
|
|
</dl>
|
|
|
|
<p>[<a href="#toc">contents</a>]</p>
|
|
|
|
<p></p>
|
|
</body>
|
|
</html>
|