XML Accessibility Guidelines

Abstract

This document explains how to design accessible applications using XML, the Extensible Markup Language. Compared to the HTML or MathML languages, XML is one level up: it is a meta syntax used to describe these languages, as well as new ones. As a meta syntax, XML provides no intrinsic guarantee of device independence or textual alternate support. It is essential, therefore, that XML formats and tools designers are provided with guidelines that explain how to include basic accessibility features - such as those present in HTML, SMIL, and SVG - in all their new developments. Thus, the XML GL builds upon the model established by the Web Content Accessibility Guidelines (WCAG), the Authoring Tool Accessibility Guidelines (ATAG), and the User Agent Accessibility Guidelines (UAAG) as a means of providing such guidance.

Status of this document

This document is a Member-confidential WAI PF Internal Working Draft Note made available by the Protocols and Formats Working Group (PFWG) for review by the W3C membership.

Publication of this paper does not imply endorsement by the W3C membership. A list of current W3C technical reports and publications, including working drafts and notes, can be found at http://www.w3.org/TR/.

Please send general comments about the content of this document to the PF mailing list: w3c-wai-pf@w3.org. Send minor editorial comments directly to the editors.

Note that the priorities as assigned to the checkpoints are provisional, and under consideration by the group.

Table Of Contents

Introduction

XML (eXtensible Markup Language) is a meta-syntax, used to create new languages.

It can be seen as a simplification of SGML (Standard Generalized Markup Language), designed to promote a wider acceptance in Web markets, but serving the same functionality of extensibility and new language design.

HTML (HyperText Markup Language), on the other hand, is one particular application of SGML, which covers one set of needs ("simple" hypertext documents) and one set of element and attributes.

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

 <TITLE>XML and Accessibility</TITLE>
 <ADDRESS lang=fr>Daniel Dardailler</ADDRESS>
 <H1>Background</H1>

and they can only use elements (TITLE, H1, etc) defined by the HTML specification (which defines about a hundred), and their attributes.

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

 <MENU>New England Restaurant</MENU>
 <APPETIZER>Clam Chowder
   <PHOTO url="clam.jpg">A large creamy bowl of clam showder, with
       bread crumbs on top</PHOTO>
 </APPETIZER>

which may fit more closely the needs of their information system.

Within W3C, the HTML language is now being recast as XML - this is called XHTML - including a modularization of HTML to suit the needs of a larger community (mobile users, Web TV, etc).

XML is therefore not to be seen as a replacement of HTML, but as a new building layer on top of which HTML is to be placed, next to other languages designed by W3C, such as MathML (for representing mathematical formula), SMIL (for synchronizing multimedia), SVG (for scalable graphics), etc., and other new languages designed by other organizations (such a OpenEBook, XML-EDI, etc.).

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

XML Grammars, and The Scope Of XMLGL

The XML grammars (called schemata - but see the caveat about our use of the term "schema" in the definition section) can be classified along two different axes:-

Data-oriented:

Tagsets for: User Interface (UI)--oriented structural textual rendering, such as Docbook, HTML, MenuML, OEB, etc.; specialized rendering - for example MathML, Scalable Vector Graphics (SVG), MusicML, Synchronized Multimedia Integration Language (SMIL); or any generic data storage format. An informal definition is 'anything for which the question "is there a textual equivalent of all rich media data bits?" makes sense'. Data-centric schemata include both the interaction and behavioural aspects of an XML application.

Metadata-oriented:

When the content being marked up is metadata. Examples: For expressing data processing (for example XSL - Extensible Style Language), RDF (Resource Description Framework), Schema languages, etc.

According to this taxonomy, these guidelines only address Data-oriented schemata. This does not imply that there are not accessibility issues or features in a Metadata-Oriented schemata - see, for example, how XSLT, a component of XSL, can assist in Braille formatting. Since they do not convey data, however, Metadata-Oriented schemata are out of the scope of these guidelines.

Problem statement

The WAI (Web Accessibility Initiative) has done extensive work in the HTML area, resulting in lots of new functionalities being added to the version 4.0 of the language (see the HTML4 Accessibility Improvements paper).

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 the freedom of design it brings has can can result in a loss of accessibility features, present today because of HTML's pervasive presence and widely available specification.

For instance, one could design a new XML language that would prevent the creation of accessible documents, by not including in the element or attribute set a way to attach an alternate textual description for a photo:-

 <MENU>New England Restaurant</MENU>
 <APPETIZER>Clam Chowder
   <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 document didn't put an alt attribute value attached to the PHOTO element, it's that the designer of the language didn't put the attribute in the language itself (that is, in the schema).

But let's start by defining what we mean by accessible schema and documents (Details on these definitions are provided at the end of this document):-

• An XML schema is accessible if it enables, and indeed actively promotes, the creation of accessible documents

• A document is accessible if it can be equally understood by its targeted audience regardless of the device used to access it.

  An accessible document is also defined as conforming to the Web Content Accessibility Guidelines.

As explained in the introduction, we're only considering Data-oriented languages here, and for them, the message is simple: be device independent and export your semantics as much as you can.

While the priority is stronger on the first aspect (multi-modality), both aspects are important, as without the knowledge of the meaning of the XML elements and attributes, there is little chance that alternative user agents can do something intelligent with just the document bits.

This semantics knowledge can be provided through human readable documentation of course, but having machine readable assertions of semantics that can then be used to present the document in various media is paramount for pervasive access (that is, you don't need a programmer, you just need a program). Enabling others to map from your language to exisiting ones, or vice versa, is a useful accessibility feature.

ICADD (International Committee on Accessible Document Design) was a pioneer in this topic, for SGML accessibility and ways to convey arbitrary schema semantics (using specific SGML binding mechanisms). A few years later, ICADD has not really been adopted (in fact, the ICADD DTD was replaced by HTML and its well known semantics), and people are still trying to solve the same problem, albeit with more experience in the field of HTML accessibility, and applied to XML this time.

Guidelines for Designers of Data-oriented XML Tagsets

This section provides a list of four abstract guidelines. Some examples of checkpoints are provided, and detailed checkpoints and techniques that schema designers can follow to achieve accessibility when designing new XML schemata still have to be defined by WAI and W3C.

• 1.0 Ensure that authors can associate multiple media objects as alternatives

  For example, textual alternatives can be repurposed for many different output devices, whereas non-textual content is often confined to a certain set of devices. Thus, by allowing and encouraging synchronized textual alternatives, you allow your tagset to be more interoperable, and hence accessible.

  1.1 Provide a mechanism to explicitly associate alternative equivalents for content or content fragments. [p1]

  For example, xml:lang to associate sign language video, the desc element of SVG, or the caption element for the XHTML tables module. SMIL's systemCaptions doesn't do it - it is defined as an operational processing thing, not as an association semantic. cf. WCAG 1.0 checkpoint 1.1.

  <?xml version="1.0" standalone="yes"?>
  <svg width="4in" height="3in"
       xmlns="http://www.w3.org/2000/svg">
       <desc xmlns:mydoc="http://example.org/mydoc">
         <mydoc:title>The sales bar chart by region</mydoc:title>
          <mydoc:para>The description uses markup from the
           <mydoc:emph>mydoc</mydoc:emph> namespace.</mydoc:para>
          <mydoc:para>The first region, North America is 60 per cent
  	    <!-- [...] -->
          </mydoc:para>
       </desc>
       <g>
         <!-- the picture goes here -->
       </g>
  </svg>
  

  1.2 Reuse accessible modules such as XHTML OBJECT, MAP element, SMIL switch, etc. [p2]

  <!DOCTYPE document SYSTEM "myDTD.dtd" [
      <!ENTITY % qnames "xhtml-qnames-1.mod">
      <!ENTITY % object "xhtml-object-1.mod">
      %qnames;
      %object;
      ]>
  <i:document xmlns:i="http://www.my.org/xmlns/inventory">
     <i:item>
     etc.
  
  <xhtml:object .......
  

  1.3 cf. Daniel's "natural association", and related talk on PF. @@ Need to draft text to accurately capture this as a guideline. [p@@]

• 2.0 Create semantically-rich languages

  Data-oriented XML should contain precise methods of encoding the data for its particular scope. By increasing the semantics of your tagset, and setting linking devices to outside presentations or further semantics, you allow your data to become "Webized" and hence to operate within many environments.

  2.1 Do not define presentation elements or attributes but enable the use of style sheets (linked or internal). [p1/2]

  Example: Wrong

      <p align="center" font="arial" weight="bold">Introduction</p>
  

  Example: Right

  <?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="application/xslt+xml"
  	media="visual"
  	href="style/page.xsl"?>
  <my:doc xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
          xsi:schemaLocation="http://www.jenitennison.com/
                              resources/schemas/doc.xsd"
          xmlns:my="http://www.jenitennison.com/"
      xmlns="http://www.w3.org/1999/xhtml">
  
  <my:p class="heading1">Introduction</p>
  

  Or, using Cascading stylesheets:-

  <?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet href="mystyle-visual.css"
  		type="text/css"
  		title="Visual"
  		media="screen"?>
  <?xml-stylesheet href="mystyle-base.css"
  			type="text/css"
  			title="Visual"
  			media="screen"?>
  <?xml-stylesheet href="mystyle-audio.css"
  			type="text/css"
  			title="Audio"
  			rel="alternate stylesheet"
  			media="aural"?>
  
  <p class="heading1">Introduction</p>
  

  2.2 Use the standard XML linking and pointing mechanisms (XLink and XPointer) [p2]

  XLink and XPointer have been reviewed for accessibility and provide known linking and pointing mechanisms.

  Example. Wrong

      <link linkend="http://mysite/myfile.xml">At my website</link>
  

  Example: Right

  <my:crossReference
  	xmlns:my="http://example.com/"
  	xmlns:xlink="http://www.w3.org/1999/xlink"
  	xlink:type="simple"
  	xlink:href="http://mysite/myfile.xml"
  	xlink:role="http://mysite/links/"
  	xlink:title="List of links"
  	xlink:show="new"
  	xlink:actuate="onRequest">
  	Current List of references
  </my:crossReference>
  

  2.3 Define element types that allow classification and grouping (header, section, list, etc). [p1]

  Make use of existing mechanisms, or create them where necessary, following these guidelines. Ensure that elements are present which can then be used for classification and grouping.

  That is, point to existing mechanisms where these exist, or create your own where necessary.

   <-- section - highest level block element
         subsect1 - first child of section, major block element
         subsect2 - second child of section, major block element
         entity para-sequence - common paragraph level blocks -->
   <!ELEMENT section (head , ((%para-sequence;)|  subsect1)+)>
   <!ELEMENT subsect1 (head? , ((%para-sequence;) | subsect2)+)>
  

  2.4 Provide for a full containment model with chunks of reasonable size. [p1/2]

  Example: If a document is broken up into a number of sections, then a sequence of nestable sections with a consistant structure may be used for both navigation and the automated generation of a table of contents to whatever level.

   <!ELEMENT section (head , ((%para-sequence;)|  section)+)>
  

  Or for a schema:-

  <xsd:schema xmlns="http://www.publishing.org"
  	  targetNamespace="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>
  

  Or... This is a recursive definition using TREX. A section is zero or more choicesof a paragraph, <p>, an unordered list <ul>, or another section. This uses TREX's <choice> specifier in the pattern below.

  <define name="section">
      <zeroOrMore>
          <choice>
        <element name="head"><anyString /></element>
              <element name="p"><anyString /></element>
              <ref name="unordered_list"/>
        <ref name="section"/>
          </choice>
      </zeroOrMore>
  </define>
  

  cf. Trex example for 2.4.

  2.5 Define element types that identify important text content. [p1]

  For example, by marking up the text with more semantics, such as saying "this is a date", or "this is an acronym".
  Code example: Using the XML schema language to identify data types, rather than simply leaving them as strings.

  <xsd:element name="paragraph">
       <xsd:complexType mixed="true">
         <xsd:choice minOccurs="0" maxOccurs="unbounded">
               <xsd:element ref="date"/>
         </xsd:choice>
       </xsd:complexType>
  </xsd:element>
  <xsd:element name="date" type="xsd:date">
       <xsd:annotation>
         <xsd:documentation>Date on which information was obtained
         </xsd:documentation>
       </xsd:annotation>
  </xsd:element>
  

  Better example:-

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

  Elements declared of this type must conform to one of the following patterns:-

  1. Pattern: 5 digits followed by a dash followed by 5 digits followed by another dash followed by 5 more digits, or
  2. Pattern: 1 digit followed by a dash followed by 3 digits followed by another dash followed by 5 digits followed by another dash followed by 1 more digit, or
  3. Pattern: 1 digit followed by a dash followed by 2 digits followed by another dash followed by 6 digits followed by another dash followed by 1 more digit.

  cf. xmlgl 2.5, improved example.

  2.6 Provide a mechanism for adding summary / abstract / title [p1]

  Example: XML.

      <?xml version="1.0">
      <document>
      <abstract-ref idrefs="abstract"/>
      <title-ref idrefs="title1 title2"/>
  
      ....
      <title id="title1">Main document title</title>
      ...
      <subtitle id="title2"/>
      <para id="abstract">This document describes ...... </para>
  
  
      </document>
  

  Example: XML using RDF and Dublin Core.

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

  cf. RDF Example for 2.6

  2.7 Don't overload the semantics of individual elements [p3]

  Example:-

  <report>
     <invoice>
      <amount>25 kilo</amount>
      ....
      </invoice>
    <description>
     <item>Widgets</item>
     <amount>25</amount>
    </description>
   </report>
  

  The amount element has two different meanings, a weight and a quantity.

  2.8 Reuse accessible modules from schemata, etc. (smil:switch, xml:lang), as originally specified / intended [p2]

  Example. When using modules from other schemata, use them with the same semantics as originally intended.

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

• 3.0 Design an accessible user interface

  Select default style hints for your languages, and provide them along with the documentation, or in the schema of the language itself (where possible).

  3.1 Provide default style sheets for multiple output modalities where possible [p2]

  Example:-

  <?xml version="1.0" encoding="utf-8"?>
  	<?xml-stylesheet href="mystyle-visual.css"
  			type="text/css"
  			title="Visual"
  			media="screen"?>
  	<?xml-stylesheet href="mystyle-base.css"
  				type="text/css"
  				title="Visual"
  				media="screen"?>
  	<?xml-stylesheet href="mystyle-audio.css"
  				type="text/css"
  				title="Audio"
  				rel="alternate stylesheet"
  				media="aural"?>
  
  <p class="heading1">Introduction</p>
  

  3.2 Describe navigable structures [p2]

  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.

  Example: (A subset of the example from guideline 3.4.)

  <?xml version="1.0" ?>
  <report>
  	<frontmatter>
  <navpoints idrefs="intro summary chap1 chap2"/>
  	  ...
  	</frontmatter>
  <body>
  	 <section>
  	  <head id="intro">...
  	   ...
  	 <section>
  	    <head id="summary">...
  	   ...
  	 <section>
  <head id="chap1">...
  
  	 <section>
  		<head id="chap2">
  	 </body>
  </report>
  

  Here the navigation points are identified by a simple list of ID values.

  3.3 Use CSS or XSLT to describe a basic outline view [p3]

  3.4 Document navigable structures. Describe how discrete, sequential, structured, and search navigation mechanisms should work [p2]

  Example: for a specific document

  <?xml version="1.0"?>
  <report>
    <frontmatter>
  <navpoints idrefs="intro summary chap1 chap2">
    <doc:description xmlns:doc="http://mysite/mydoc.xml">
       <doc:point idref="intro">Introduction</doc:point>
  <doc:point idref="summary">Document summary</doc:point>
  <doc:point idref="chap1">Chapter 1. Overview</doc:point>
    ...
    </frontmatter>
  <body>
     <section>
      <head id="intro">...
      ...
      <section>
        <head id="summary">...
      ...
      <section>
  	<head id="chap1">...
  
      <section>
  	  <head id="chap2">
    </body>
   </report>
  

  3.5 Ensure the model allows for user control of presentation [p1]

  For example the user may have a particular view of the document broken into smaller parts. See also UAAG guideline 2.
  Example: If one particular stylesheet only presents highlights of a source instance, ensure that the whole instance may be accessed from within that view.

  <?xml version="1.0" encoding="utf-8"?>
  <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                  version="1.0">
  
    <xsl:output method="html"/>
  
    <xsl:template match="/">
      <html>
        <body>
  <-- This provides the link back to the full source document -->
          <a href="http://link/to/full/source.xml">full 
              source of document</a>
   <!-- This view only presents headings, one per paragraph -->
          <xsl:for-each select="//section/head">
            <p><xsl:value-of select="."/></p>
          </xsl:for-each>
        </body>
      </html>
    </xsl:template>
  
    <xsl:template match="body">
     ......
  
  <xsl:template match="*"/>
  </xsl:stylesheet>
  

  3.6 Use a device-independent interaction model / module [p1]

  From a VoiceML Group example

  <?xml version="1.0"?>
  <!DOCTYPE vxml SYSTEM "/sgml/w3c/voicexml.dtd">
  <vxml version="2.0">
  <!-- Credit card example. -->
  <form id="get_card_info">
   <block>We now need your credit card type, number, and 
    expiration date.</block>
   <field name="card_type">
    <prompt count="1">What kind of credit card  do you have? 
    visa, mastercard or American Express</prompt>
    <prompt count="2">Type of card?</prompt>
    <!-- This is an inline grammar. -->
    <grammar>
      <rule id="r2" scope="public">
         <one-of>
         <item>visa</item>
         <item>master <count 
             number="optional">card</count></item>
         <item>amex</item>
         <item>american express</item>
         </one-of>
      </rule>
    </grammar>
    <help>Please say Visa, Mastercard, or American Express.</help>
   </field>
   <!-- The grammar for type="digits" is built in. -->
   <field name="card_num" type="digits">
    <prompt count="1">What is your card number?</prompt>
    <prompt count="2">Card number?</prompt>
    <catch event="help">
    <if cond="card_type =='amex' || card_type =='american express'">
         Please say or key in your 15 digit card number.
       <else/>
         Please say or key in your 16 digit card number.
       </if>
    </catch>
    <filled>
  <if cond="(card_type == 'amex' || card_type =='american express') 
            && card_num.length != 15">
         American Express card numbers must have 15 digits.
         <clear namelist="card_num"/>
         <throw event="nomatch"/>
       <elseif cond="card_type != 'amex'
                       && card_type !='american express'
                       && card_num.length != 16"/>
         Mastercard and Visa card numbers have 16 digits.
         <clear namelist="card_num"/>
         <throw event="nomatch"/>
       </if>
    </filled>
   </field>
   <field name="expiry_date" type="digits">
     <prompt count="1">What is your card's expiration date?</prompt>
     <prompt count="2">Expiration date?</prompt>
    <help>
       Say or key in the expiration date, for example one two oh one.
    </help>
    <filled>
       <!-- validate the mmyy -->
       <var name="mm"/>
       <var name="i" expr="expiry_date.length"/>
       <if cond="i == 3">
         <assign name="mm" expr="expiry_date.substring(0,1)"/>
       <elseif cond="i == 4"/>
         <assign name="mm" expr="expiry_date.substring(0,2)"/>
       </if>
       <if cond="mm == '' || mm < 1 || mm > 12">
         <clear namelist="expiry_date"/>
         <throw event="nomatch"/>
       </if>
    </filled>
   </field>
   <field name="confirm" type="boolean">
    <prompt>
        I have <value expr="card_type"/> number
        <value expr="card_num"/>, expiring on
        <value expr="expiry_date"/>.
        Is this correct?
    </prompt>
    <filled>
     <if cond="confirm">
      <submit next="place_order.asp" 
             namelist="card_type card_num expiry_date"/>
     </if>
      <clear namelist="card_type card_num expiry_date acknowledge"/>
    </filled>
   </field>
  </form>
  </vxml>
  

  cf. xml gl, 3.6 example

  3.7 Allow for user control of interaction timing - rate of change, external events triggering document changes, etc. [p1]

• 4.0 Document and export semantics

  Make sure that people can 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 Ensure human-readable documentation conforms to WCAG double A [p1]

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

  4.2 Provide schemata and a means to access them. Provide an accessible, useful, sensible, web-based automatable machine understandable mechanism for discovery of semantics - how to get to the schema from the document instance [p1/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"?>
  <?xml-stylesheet type="application/xslt+xml"
  	media="visual"
  	href="style/page.xsl"?>
  <my:doc xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
  	xsi:schemaLocation="http://www.jenitennison.com/
  	                    resources/schemas/doc.xsd"
  	xmlns:my="http://www.jenitennison.com/"
        xmlns="http://www.w3.org/1999/xhtml">
  

  4.3 Provide explicit human readable documentation / annotation of element / attribute / etc. semantics - for example these should be presented by an authoring tool, rather than just element names [p1]

  Example: Relax

      <elementRule role="para">
  	  <annotation> Lowest level block container </annotation>
  	  <mixed>
  	    <ref label="fnote" occurs="*"/>
  	  </mixed>
  	</elementRule>
  

  Example: XML Schema Language.

  <xsd:element name="internationalPrice">
   <xsd:annotation>
    <xsd:documentation xml:lang="en">
  	 element declared with anonymous type
  	</xsd:documentation>
   </xsd:annotation>
   <xsd:complexType>
    <xsd:annotation>
     <xsd:documentation xml:lang="en">
  	  empty anonymous type with 2 attributes
  	 </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
     <xsd:restriction base="xsd:anyType">
      <xsd:attribute name="currency" type="xsd:string" />
      <xsd:attribute name="value"    type="xsd:decimal" />
     </xsd:restriction>
    </xsd:complexContent>
   </xsd:complexType>
  </xsd:element>
  

  Example: TREX

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

  4.4 Use schema (in preference to DTD) to provide explicit documentation/annotation of element/attribute/etc semantics [p2]

  cf. 4.2

  4.5 Provide semantic relationships to other schemata where appropriate and possible [p2]

  4.6 Document accessibility features of the application. see "Accessibility features of SVG" for an example [p3]

  SVG has provided a good example of this being a part of the recommendation. For W3C Working drafts, include and document those specific features which positively aid accessibility.

  4.7 Include accessibilty requirements in conformance requirements.

  SVG has specific accessibility requirements as a part of the overall requirement document. When the requirements are drawn up, specific clauses need to be included which clearly state accessibility requirements [p2]

  4.8 Document techniques for WCAG, ATAG, UAAG with respect to the XML application - review your XML application and make sure that there is a relevant technique for each checkpoint of WCAG/ATAG/UAAG - show how a (hypothetical) instance of your application can conform to WCAG, how a user agent for your application can meet UAAG, etc. [p2]

  Taking as an example the docbook DTD and the UAAG guidelines.

  • Guideline 1. No interaction.
  • Guideline 2. For a docbook XML instance, all content is available. Stylesheeet application may not make all content available, though this will be accessible via a link to the XML source. 2.9 is satisfied by the usage of the <mediaobject> element and its <textobject> child. 2.10 is satisfied via inherited xml:lang attribute.
  • Guideline 3 and 4. All content is available for rendering as required by users. Selection between alternate modalities is supported by the provision of alternate forms.
  • Guideline 5. Information is provided to facilitate user control via the interface. The provided stylesheets may be overridden by user stylesheets.

  etc.

  4.9 Do not assume that element or attribute names provide any information about element semantics [p@@]

  For example, avoid colloquial element names.
  Good Example - TREX

  <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.
  cf. release
  Bad Example - TREX

  <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.
  cf. the related Mixing Schemata.

An additional piece of advice we give to schema designers is that in their specification itself (the documentation) they always emphasize the accessibility features of their new language and try to include accessibility as part of any conformance statement that they introduce (be it for the document themselves, or for readers/editors of the language). See the Conformance section of the SVG specification, and Writing Accessible SVG for an example of both practices.

Caveat About Presentational & Formatting Tagsets

Languages used only for presentation to a certain scope of users (that is, final form tagsets) should adhere to the following caveats:-

• They should not be promoted as being a generally suitable as a way of storing content that can be used across a variety of devices.
• The server should make sure the client wants this particular form before serving it. See the last sentence of the XSL Tree Transformations section for an example of such wording.

Notes

Guidelines/Techniques

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

In fact, there are several techniques for achieving the same result and people's decision will be a function of time and product available and their own commitment to access.

For instance, if an XML designer want to create some kind of "list" element in a given markup, this can be implemented using various techniques:

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

Along with the choice of the metadata mechanism and vocabulary comes the issue of semantics availability: how does one access the schema and possible XSLT or schemata from an instance document? This is sometimes referred to as XML packaging or related-resource discovery and is a very important feature for accessibility.

XML accessibility definitions:

• Schema: Even though we use the term "schema", we don't want people to assume we are only talking about a schema as defined in XML Schema but rather some document or collection of documents which contains all the references for interpreting a document which is encoded in accordance with the usage of some application or community of discourse. "Profile" might be a better word for our usage.

• An XML schema is accessible if it enables and actively promotes the creation of accessible documents

• A document is accessible if it can be equally understood by its targeted audience regardless of the device used to access it.

  An accessible document is also defined by conforming to the Web Content Accessibility Guidelines.

• The word "promote" is important as "enable" alone does not cover the case where a schema could include some open string representation somewhere and claim minimal accessibility.

  To take an example, suppose HTML didn't have an ALT attribute on IMG, it would still in theory "enable" the creation of accessible documents, since HTML files carry textual content and one could always describe images inline, as in:-

   <IMG SRC="Tax.gif"> How to pay your taxes
  

  but this doesn't "promote" accessibility as most authors will not want to repeat "How to pay your taxes" if the logo already says "How to pay your taxes" (assuming CSS cannot be used for that). Having ALT "promotes" accessibility as it allows images to be described without performance loss - such as duplication - for image viewer.

  In any case, accessibility is not just about alternative content, as the next section will show.

• The word "device" is also important as it encompasses more than just media independence: it's both output (graphical, voice, braille, text-only) and input (mouse, keyboard, voice, keypad, one-touch).

  This term also potentially carries with it the issues related to high bandwidth availability (or lack thereof), where access to data becomes impossible on slow connection because of their volume.

• The term "equal understanding" is critical as it permits some form of graceful transformation when presenting in one media content primarily designed for another media.

  Graceful transformation is a key concept in the area of accessibility. Let's define it.

  Definition:

  Graceful transformation is a property of a system that can still function relatively error free when the system is damaged or when the input stimuli are incomplete. In such systems, removing a symbol token only results in the loss of the information stored in that token, with no abrupt performance decline of the overall process.

  For instance, suppose I need to check the online yellow line train schedule and I don't have visual access to the Web. If the train Web site uses a yellow wagon animated icon to point me at the schedule, and does not provide a label somewhere saying that this is for the yellow line, thus only relying on my capacity to see the color, I suddenly cannot understand this site: it does not transform gracefully.

  If the schema designer hasn't provided a way to attach alternate content to some rich piece like an animated yellow wagon, the content provider will not reach all of his/her audience with this information.

  Suppose now in a different page this Web site provides a nice clickable 2D map with all the stops and ask me to select my start and destination. If a simple list of the line stops is provided in textual form, it does transform gracefully: it's not as fast as a couple of mouse clicks, so there is some "degradation" in the system, but a user reliant on text can obtain the information.

• Another aspect of "understanding" is that in order for a User Agent to make sense and gracefully transform the content of an arbitrary schema-based document some semantics have to be disclosed. By reusing or binding a priori unknown elements/attributes to well know ones (in XML core or HTML), this is achievable.

Acknowledgments

Geoff Freed, Al Gilman, Vijay Gummadi, Ian Jacobs, Chris Lilley, William Loughborough, Charles McCathieNevile, Stephane Maes, Eve Maler, Dave Pawson, Gregory J. Rosmaita, Henry S. Thompson, Carlos A. Velasco, Norman Walsh.

References

• W3C WAI Home page
• WAI PF Home page
• W3C XML Home Page