Movatterモバイル変換

Abstract

This document provides guidelines for designing Extensible Markup Language(XML) applications that lower barriers to Web accessibility for people withdisabilities (visual, hearing, physical, cognitive, and neurological).XML, used to design applications such asXHTML,SMIL, andSVG,provides no intrinsic guarantee of the accessibility of those applications.This document explains how to include features in XML applications thatpromote accessibility.

Status of this document

This document is aWorking Draft of the XML AccessibilityGuidelines made available by the Protocols and Formats Working Group (PFWG). ThePFWG operates as partof theWAI Technical Activity. ThePFWG maintainsa page aboutissues, errata and corrigenda for thisspecification, and feedback is particularly invited on those.

This document is a W3C Working Draft made available for public review asper theW3C Process.This draft is expected to be updated or made obsolete within three months ofits publication (3 October 2002). Intermediate updates (publicly archivedmailing list:wai-xtech@w3.org.

Translations of this specification, or ofprevious working drafts, are made available by volunteers. ThePFWG thanks people whohave provided translations, but notes that the original English version of any draft is the only authoritative version

Patent disclosures relevant to this specification may be found on theWorking Group'spatent disclosure page, in conformance with W3C policy.At the time of publication, there are no declarations specific to thisdocument.

Publication of this document does not imply endorsement by the W3C, itsmembership or its staff. This is a draft document and may be updated,replaced, or obsoleted by other documents at any time. It is inappropriate touse 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 athttp://www.w3.org/TR/.

Table Of Contents

Introduction

This document specifies requirements that, if satisfied by designers ofXML applications, will lower barriers to accessibility. This documentincludes:

• This introduction, which provides context for understanding the requirements listed in section 2.
• 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.
• Section 3 explains how to make claims that XML Applications satisfy the requirements of section 2.
• An appendix lists all the checkpoints for convenient reference (e.g., as a tool for application developers to evaluate software for conformance)

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 wideracceptance in Web markets, but serving the same functionality ofextensibility and new language design.HTML (HyperTextMarkup Language), on the other hand, is one particular application of SGML,which covers one set of needs ("simple" hypertext documents) and one set ofelement and attributes.

For instance, in HTML, authors can write elements like:

 <title>XML and Accessibility</title> ... <address lang="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 theirattributes.

In SGML and XML, authors can define their own set of elements, and end upwith documents like:

<menu>New England Restaurant</menu> <appetizer>Clam Chowder   <photo url="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 calledXHTML - including a modularization of HTML to suitthe 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 newbuilding layer on top of which HTML is to be placed, next to other languagesdesigned by W3C, such as MathML (for representing mathematical formula), SMIL(for synchronizing multimedia), SVG (for scalable graphics), etc., and othernew languages designed by other organizations (such asOpen EBook,etc.).

Furthermore, it is important to understand that XML is not only a UserInterface technology (like HTML), but can and is often used in protocolcommunication, to serialize and encode data to be sent from one machine toanother.

XML Grammars, and The Scope Of XAG[[Note: this section may disappear orchange significantly]]

The XML grammars (often called schema in this document) can be classifiedalong different axes:

End-user-oriented:

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

Process-oriented:

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.

According to this taxonomy, these guidelines only addressEnd-user-oriented schema. This does not imply that there are notaccessibility issues or features in a Process-oriented schema - see, forexample, howXSL can assist in Braille formatting, butthey are out of the scope of this particular document.

Relation to other WAIGuidelines

"XML Accessibility Guidelines 1.0" is part of a series of accessibilityguidelines published by the Web Accessibility Initiative (WAI). The documentsin this series reflect an accessibility model in which Web content authors,format designers, and software developers have roles in ensuring that userswith disabilities have access to the Web. In this model:

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

Formats that conform to XAG 1.0 will support the features of the other WAIGuidelines. For instance, this document requires that formats includeelements and attributes that:

• Will allow authors to associate text alternatives with non-text content;
• Will allow user agent developers to recognize these alternatives and provide easy access to them in a reliable manner;
• 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.

The requirements of making the Web accessible to actual users do notalways match this model perfectly. In all the guidelines there are caseswhere there is a need for overlapping requirements to ensure that people canin fact use the Web. These are sometimes due to particular problems in widelyimplemented and used technology, and sometimes are provided as a "safetynet".

Note: The WAI Guidelines cross-reference one another. XAG 1.0 requirementsto satisfy the requirements of other WAI Guidelines should be interpreted tomean "Follow the requirements of other guidelines EXCEPT for those that inturn require conformance to XAG 1.0." Thus, if XAG 1.0 requires that thedocumentation of an XML application conform to WCAG 2.0, and WCAG 2.0 statesthat conforming content must also conform to XAG, read this as:"Documentation of an XML application must conform to WCAG 2.0 except for WCAG2.0 requirements that in turn require conformance to XAG 1.0."

Problem statement[[Note: This section is likely to be significantlyrevised]]

TheWAI (Web Accessibility Initiative) has doneextensive work in the HTML area, resulting in lots of new functionalitiesbeing added to the version 4.0 of the language (see theHTML4 Accessibility Improvementspaper [HTML-access]).

These features includes:

• Improved structure (such as fieldset, optgroup in form)
• Support of separate Style Sheets
• Better alternate content (required alt, longdesc, caption, etc)
• Easier navigation (tabindex, link, etc)

One area of concern with the advent of XML is that thefreedom ofdesign it bringshas and can result in a loss ofaccessibility features, present today because of HTML's pervasivepresence and widely available specification.

For instance, one could design a new XML language that would make it muchmore difficult to create accessible documents, by not including in theelement or attribute set a way to attach an alternate textual description fora photo:

 <menu>New England Restaurant</menu> <appetizer>Clam Chowder   <photo url="clam.jpg"/><!-- no alt attribute or                                 textual content model here --> </appetizer>

In this example, the problem is not that the author of this documentdidn't put an alt attribute or textual equivalent attached to the photoelement, it's that the designer of the language didn't put the attribute orthe proper support in the language itself (that is, in the schema or theDTD). This means that there is no reliable way for a user to find how anauthor tried to explain a particular image in text form.

This document specifies requirements for XML languages to ensure thatpeople can create documents in a given XML language which are as accessibleas possible to people with disabilities, who use a variety of differenttechniques and tools to access the Web.

Guidelines for designers of XML dialects

This section provides a list of four guidelines, which are generalprinciples of accessible design. Guidelines include rationale andcheckpoints. Each checkpoint expresses a requirement, includes someinformative text about the checkpoint and one or several Techniques, whereimplementations and examples of the checkpoint are discussed. Note that thecheckpoints are not prioritized at that point.

• Guideline 1. Ensure that authors can associate multiple media objects as alternatives

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

  1.1 Provide a mechanism to explicitly associate alternatives for content or content fragments.

  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.

  Techniques for 1.1

  T1.1.1 InSVG, thedesc 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>

  T1.1.2 Thesummary and thecaption elements in theXHTML 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>

  1.2 Defineflexible associations, where a given kind of relationship can link to or from objects of varying types without constraint.

  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 HTMLimg 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 theimg element could have content, like theobject element, this would have solved the problem to some extent. Another way would have been to add an "appliesTo" attribute to theimg 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.

  Techniques for 1.2

  T1.2.1 Intechnique 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 thedesc.

  <svg xmlns="http://www.w3.org/2000/svg" xml:lang="en">   <g>       <desc xmlns:mydoc="http://example.org/mydoc">          <mydoc:title>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>

  T1.2.2 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.

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

• Guideline 2. Create semantically-rich languages

  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.

  2.1 Ensure all semantics are captured in markup in a repurposable form.

  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.

  Techniques for 2.1

  See SMIL for instance.

  2.2 Separate presentation properties using stylesheet technology/styling mechanisms.

  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.

  Techniques for 2.2

  T2.2.2 Example:Right

  Support the inclusion and processing of external style sheets (note the importance ofGuideline 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>

  TW2.2.1Example:Wrong

  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>

  2.3 Use the standard XML linking and pointing mechanisms (XLink and XPointer).[[Note this checkpoint is under discussion and may change]]

  Xlink [XLINK] andXPointer [XPTR] have been reviewed for accessibility and their linking/pointing semantics may be recognized with certainty.

  Techniques for 2.3

  T2.3.2 Example:Right

  Using links that can be recognized reliably by XLink applications.

  <myxlinkxmlns:xlink="http://www.w3.org/1999/xlink"         xlink:href="http://mysite/myfile.xml">      Current List of references</myxlink>

  TW2.3.1 Example.Wrong

  User Agents have no way of knowing this is a link.

  <mylink linkend="http://mysite/myfile.xml">      Current List of references </mylink>

  2.4 Define element types that allow classification and grouping (header, section, list, etc).

  Make use of existing mechanisms (noting checkpoint1.2), or create them where necessary, following these guidelines.

  Techniques for 2.4

  T2.4.1 Think in terms of overall structure of your documents when you design a new dialect.

   <-- 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)+)>

  2.5 Provide for a full containment model with chunks of reasonable size.

  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.

  Techniques for 2.5

  T2.5.1 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.

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

  2.6 Define element types that identify important text content.

  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.

  Techniques for 2.6

  T2.6.1 Mark up your text with more semantics, such as datatype meaning "this is a date", or "this is an acronym".
  Code example: Using theXML Schema language [XSCHEMA] to identify data types, rather than simply leaving them as strings: a fully constrained ISBN number:

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

  2.7 Provide a mechanism for identifying summary / abstract / title.

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

  Techniques for 2.7

  T2.7.1 Example: XML using RDF andDublin Core elements [DC-elements].

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

  2.8 Don't overload element and attribute names.

  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 tocheckpoint 4.9.

  Techniques for 2.8

  T2.8.2 Example:Right

   <report>   <invoice>    <price>25</price>    <currency>Dollar</currency>....   </invoice>  <description>   <item>Widgets</item>   <quantity>25</quantity>  </description> </report>

  TW2.8.1 Example:Wrong

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

  In the example above, the meaning of all the elements is clear and none of the individuals elements is overloaded.

  2.9Reuse existing accessible modules, as originally specified / intended.[[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]]

  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.

  Techniques for 2.9

  T1.3.1 This example shows how to use an existing DTD module: the object from the XHTML language

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

  T2.9.1 Example: reusing SMIL switch

    ...  <par>    <video src="anchor.mpg" ... />    <switch>      <audio src="HiQuality.wav" systemBitrate="56000" ... />      <audio src="MedQuality.wav" systemBitrate="28800" ... />      <audio src="LowQuality.wav" ... />    </switch>  </par>

  2.10 Allow association of metadata with distinct elements and groups of elements.

  This permits authors to make even more semantic associations than what was originally intended by the language designer.

  Techniques for 2.10

  T2.10.1 In SVG for instance, there is ametadata 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 theSVG Accessibility note [SVG-access] for examples.

  Also, by providing ID for all your elements, you allow external metadata to point to them.

  2.11 Specific checkpoint for Final-form applications.

  Languages used only for presentation to a certain scope of users and media are called,Final-form and they should adhere to the following provisions:

  • Allow the author to identify by URI the source used to generate the final form instance.
  • In the application documentation, indicate that final form instances SHOULD NOT be served except upon explicit user request (e.g., through a configured preference).
  • 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.

  Techniques for 2.11

  TheXSL 1.0 specification [XSL10] contains the following example of such wording.

  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.

• Guideline 3. Design an accessible user interface.

  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.

  3.1 Provide default style sheets for multiple output modalities.

  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.

  Techniques for 3.1

  T3.1.1 Example: See thesample style sheet for HTML 4.0 [HTML-style] provided with the CSS2 specification.

  3.2 Define navigable structures that allow discrete, sequential, structured, and search navigation functionalities.

  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.

  Techniques for 3.2

  T3.2.1 Example: See how theDigital Talking Book [DTB] provides elements for navigable structures.

  3.3 Use CSS or XSLT to describe a basic outline view.
  

  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.

  Techniques for 3.3

  T3.3.1 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.

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

  3.4 Use a device-independent interaction and events model / module.

  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.

  Techniques for 3.4

  T3.4.1 UsingDOM2 event the right way inSVG.

  <script type="text/ecmascript"> function DoOnActivate(evt) { .. } </script><g onactivate="DoOnActivate(evt)">  <rect x="500" y="500" width="250" height="40"/> </g>

  3.5 Allow for user control of interaction timing - rate of change, external events triggering document changes, etc.

  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.

  Techniques for 3.5

  T3.5.1 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 theSMIL-Animation specification [SMIL-anim] for examples of such design.

• Guideline 4 Document and export semantics

  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.

  4.1 Provide explicit human readable definitions for markup semantics.

  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.

  Techniques for 4.3

  T4.3.1 Example: TREX

  <element name="paragraph">    <xsd:annotation>the lowest level block container.</xsd:annotation>    <empty/></element>

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

  Everybody should be able to read and understand a technical specification, even one that is purely intended for a particular class of users.

  Techniques for 4.1

  T4.1.1 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).

  4.3 Provide a machine-understandable means/mechanism to get from a document instance to the schema.

  This allows programs to automatically retrieve the documentation of a language.

  Techniques for 4.2

  T4.2.2 Example: Uses the W3C XML Schema language as the schema, referencing it via the xsi:schemaLocation attribute.

  <?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">

  4.4 Use a schema language that can support explicit human-readable documentation or annotation of semantics.

  It is important that the schema language allows the language designer to explicitly attach documentation to elements and attributes.

  Techniques for 4.4

  T4.4.1 ExampleRight: The need for the head element is clearly described.

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

  T4.4.2 ExampleWrong: 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.

  <!-- 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 -->

  4.5 Provide semantic relationships to other schema where appropriate and possible.

  This allows the authors using the language to reuse their existing knowledge and tools.

  Techniques for 4.5

  T4.5.1 This can be done implicitly via subclassing/derivation of existing types, by asserting equivalence of type (e.g. SVGtitle and SMILtitle) or by mapping to well known semantics.

  Example: mapping the Menu example provided in the Introduction to XHTML using XSLT:

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

  4.6 Document all features of the XML application that benefit accessibility.
  

  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.

  Techniques for 4.6

  T4.6.1 SVG has provideda good example of this [SVG10-access] being a part of the recommendation. For W3C Working drafts, include and document those specific features which positively aid accessibility.

  4.7 Include accessibility requirements in conformance requirements.

  This promotes the development of accessible content in the community caring about conformance.

  Techniques for 4.7

  T4.7.1 SVG has specific accessibility requirements asa part [SVG10-access] of the overall requirement document. When the requirements are drawn up, specific clauses need to be included which clearly state accessibility requirements

  T4.7.2 A more detailed explanation is given insection 3.3 of the User Agent Accessibility Guidelines [UAAG10]

  4.8 Document techniques for WCAG, ATAG, and UAAG with respect to the XML application.

  The WAI suite of accessibility guidelines [WCAG],[ATAG],[UAAG] 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.

  Techniques for 4.8

  T4.8.1 Still using the MenuML language, here are examples of WCAG techniques

  • WCAG checkpoint 1.1: Provide a text equivalent for every non-text element

    MenuML technique: use the content of thephoto element to indicate the textual equivalent of the picture.

  • WCAG checkpoint 3.5: Use header elements to convey document structure and use them according to specification.

    MenuML technique: use theappetizer element to introduce a new appetizer, not apara and some bigger font

  4.9 Do not assume that element or attribute names provide any information about element semantics.

  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.

  Techniques for 4.9

  TW4.9.1 For example, using TREX, avoid colloquial element names.

  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.

  4.10 Document navigable structures. Describe how discrete, sequential, structured, and search navigation mechanisms should work.

  In order to navigate around a significant document, it is helpful to the reader if they know what elements are available for such navigation.

  Techniques for 4.10

  T4.10.1 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.

Appendices

Appendix A: Techniques Rationale

In the presentation of guidelines for XML accessibility, we try toseparate abstract guidelines from implementation techniques. This allows usto talk about the general guideline principles without spending the timeup-front to solve the implementation issues.

In fact, there are several techniques for achieving the same result andpeople's decision will be a function of time and product available and theirown 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 varioustechniques:

• using the XHTML namespace and itselements (e.g. xhtml:ul, xhtml:li)
• invent new constructs but provide an XSLT binding (e.g. to a HTML UL/LI pair of element)
• using XML/RDF Schema (if a list primitive is available; or through a new schema if a primitive is unavailable)
• using Architectural forms with support for list semantics
• etc

Appendix B: Glossary

The source of definitions used is theWAI Glossary [GLOSS]

Appendix C: Acknowledgments

In addition to the editors, the following people have contributed directlyto 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.

Appendix D: References

[ATAG10]

"Authoring Tool Accessibility Guidelines 1.0", 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

[ATAG10-TECHS]

"Techniques for Authoring Tool Accessibility Guidelines 1.0," J. Treviranus, J. Richards, I. Jacobs, and C. McCathieNevile eds. The latest version is available at http://www.w3.org/TR/ATAG10-TECHS

[DC-elements]

"Dublin Core Metadata Element Set, Version 1.1: Reference Description" DCMI Recommendation, 2 July 1999, available at http://dublincore.org/documents/dces/

[DTB]

"Digital Talking Book" ANSI/NISO specification Z39.86. Available at http://www.loc.gov/nls/z3986/index.html

[GLOSS]

WAI Glossary. An internal working draft. K Haritos-Shea, C. McCathieNevile, eds. Available at http://www.w3.org/WAI/GL/Glossary/printable

[HTML-access]

"HTML 4.0 Accessibility Improvements", I. Jacobs, J. Brewer, D. Dardailler. Available at http://www.w3.org/WAI/References/HTML4-access

[HTML-style]

"A sample CSS style sheet for HTML 4.0" provided as an informative appendix to the CSS 2 specification. Available at http://www.w3.org/TR/CSS2/sample

[SMIL-anim]

"SMIL Animation", P. Schmitz, A. Cohen eds. W3C Recommendation 4 September 2001, available at http://www.w3.org/TR/2001/REC-smil-animation-20010904/

[SVG-ACCESS]

"Accessibility of Scalable Vector Graphics", 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.

[SVG10]

"Scalable Vector Graphics 1.0 Specification", J. Ferraiolo, ed., 4 September 2001. This W3C Recommendation is available at http://www.w3.org/TR/2001/REC-SVG-20010904/

[SVG10-access]

SVG 1.0 Appendix H - Accessibility Support. An appendix to the SVG 1.0 specification [SVG10] Available at http://www.w3.org/TR/2001/REC-SVG-20010904/access

[UAAG10]

"User Agent Accessibility Guidelines," 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.

[UAAG10-TECHS]

"Techniques for User Agent Accessibility Guidelines 1.0," J. Gunderson, I. Jacobs, E. Hansen eds. Thelatest version of Techniques for User Agent Accessibility Guidelines 1.0 is available at http://www.w3.org/TR/UAAG10-TECHS/.

[WCAG10]

"Web Content Accessibility Guidelines 1.0," 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/.

[WCAG10-TECHS]

"Techniques for Web Content Accessibility Guidelines 1.0," W. Chisholm, G. Vanderheiden, and I. Jacobs, eds. Thelatest version is available at http://www.w3.org/TR/WCAG10-TECHS/.

[XLINK]

"XML Linking Language (XLink) Version 1.0", S. DeRose, E. Maler, D. Orchard eds. W3C Recommendation 27 June 2001, available at http://www.w3.org/TR/2001/REC-xlink-20010627/

[XPTR]

"XPointer Framework", 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/

[XSCHEMA]

"XML Schema", D. Fallside ed. W3C Recommendation 2 May 2001, available at http://www.w3.org/TR/xmlschema-0/

[XSL10]

"Extensible Stylesheet Language (XSL)Version 1.0", S.Adler et al. W3C Recommendation 15 October 2001, available at http://www.w3.org/TR/2001/REC-xsl-20011015/

Appendix E: Changes from the 28 August 2001Working Draft

These changes were decided by the PFWG based on theXAG issues list.

Editorial Changes

Changes were made to the text of several checkpoints:

• Checkpoint 2.8
• Checkpoint 2.11
• Checkpoint 3.1
• Checkpoint 4.2 (which was checkpoint 4.1)
• Checkpoint 4.6

Checkpoints 4.1, 4.2 and 4.3 were reordered

Major issues now noted in document

The Abstract, Introduction and Problem Statement sections were substantially rewritten

New Section in Introduction: relation to other WAI guidelines

Definition Section changed to reference to WAI glossary

Change History added

List of Checkpoints added as an appendix

New References section

Substantive Changes

Checkpoint 2.11 added

Checkpoint 1.3 merged into checkpoint 2.9

Appendix F: List ofCheckpoints

Guideline 1: Ensure that authors can associate multiple media objects as alternatives

• 1.1 Provide a mechanism to explicitly associate alternatives for content or content fragments.
• 1.2 Define flexible associations, where a given kind of relationship can link to or from objects of varying types without constraint.

Guideline 2. Create semantically-rich languages

• 2.1 Ensure all semantics are captured in markup in a repurposable form.
• 2.2 Separate presentation properties using stylesheet technology/styling mechanisms.
• 2.3 Use the standard XML linking and pointing mechanisms (XLink and XPointer).
• 2.4 Define element types that allow classification and grouping (header, section, list, etc).
• 2.5 Provide for a full containment model with chunks of reasonable size.
• 2.6 Define element types that identify important text content.
• 2.7 Provide a mechanism for identifying summary / abstract / title.
• 2.8 Don't overload element and attribute names.
• 2.9 Reuse existing accessible modules, as originally specified / intended.
• 2.10 Allow association of metadata with distinct elements and groups of elements.
• 2.11 Specific checkpoint for Final-form applications.

Guideline 3. Design an accessible user interface

• 3.1 Provide default style sheets for multiple output modalities.
• 3.2 Define navigable structures that allow discrete, sequential, structured, and search navigation functionalities.
• 3.3 Use CSS or XSLT to describe a basic outline view
• 3.4 Use a device-independent interaction and events model / module.
• 3.5 Allow for user control of interaction timing - rate of change, external events triggering document changes, etc.

Guideline 4 Document and export semantics

• 4.1 Provide explicit human readable definitions for markup semantics.
• 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].
• 4.3 Provide a machine-understandable means/mechanism to get from a document instance to the schema.
• 4.4 Use a schema language that can support explicit human-readable documentation or annotation of semantics.
• 4.5 Provide semantic relationships to other schema where appropriate and possible.
• 4.6 Document all features of the XML application that benefit accessibility.
• 4.7 Include accessibility requirements in conformance requirements.
• 4.8 Document techniques for WCAG, ATAG, and UAAG with respect to the XML application.
• 4.9 Do not assume that element or attribute names provide any information about element semantics.
• 4.10 Document navigable structures. Describe how discrete, sequential, structured, and search navigation mechanisms should work

[contents]