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.

Status of this document

This document is a Working Draft made available by the WAI Protocols and Formats Working Group (PFWG), for review by W3C members and other interested parties. The PF group operates as part of the WAI Technical Activity.

Depending on the feedback received, this document may become a W3C Note, be integrated in the Web Content Accessibility Guidelines suite (e.g as a technique for XML) or enter its own Recommendation track.

Please send comments about the content of this document and how you would like to see it evolving to the publicly archived mailing list: wai-tech-comments@w3.org. Comments on this version can be sent until September 30th, 2001. Send minor editorial comments directly to the editors.

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 https://www.w3.org/TR/.

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 behavioral 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 end-user oriented 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 bringshas and can result in a loss of accessibility features, present today because of HTML's pervasive presence and widely available specification.

For instance, one could design a new XML language that would 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 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).

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

• 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, for instance, 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.

  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

  For example, the summary and the caption elements in the XHTML table module can be used to provide a rich textual description of a non-textual media. cf. WCAG 1.0 checkpoint 1.1.

  <table border="1"
         summary="This table gives some statistics about fruit
                  flies: average height and weight, and percentage
                  with red eyes (for both males and females).">
    <caption><em>Statistics</em> about fruit flies</caption>
    <tr><th rowspan="2"><th colspan="2">average
        <th rowspan="2">red<br>eyes
    <tr><th>height<th>weight
    <tr><th>males<td>1.9<td>0.003<td>40%
    <tr><th>females<td>1.7<td>0.002<td>43%
  </table>

  1.2 Define flexible associations, where a given kind of relationship can link to or from objects of varying types.

  By flexible, we mean so that it is not constrained by the language itself. For example, HTML lets you add "alt" to images, but it does not let you add images to runs of text/markup, so people have to put up with less adequate mechanisms, perhaps by adding "see figure 1" at the end of a paragraph. If the content of <img> was other than empty, this would have solved the problem to some extent. Another way would have been to add an "appliesto" attribute to the <img> element, allowing you to put the associated image elsewhere in the document. Satisfying this checkpoint takes a lot of thought due to its subjective nature, but it's very important. For example, if <img> were non-empty, or if it had an appliesto attribute, it is probable that many more people would be associating images with text/markup runs.

  Techniques for 1.2

  In SVG, the desc element can be used to fully described a graphic, using structured text from a different tagset for instance, and in the graphics itself, the description text can be reused.

  <svg xmlns="https://www.w3.org/2000/svg" xml:lang="en">
     <g>
         <desc xmlns:mydoc="https://example.org/mydoc">
            <mydoc:title id="title1">The sales bar chart by region</mydoc:title>
            <mydoc:para>This description uses markup from the
            <mydoc:emph>mydoc</mydoc:emph> namespace.</mydoc:para>
         </desc>
            <!-- now the picture which includes text referencing the description -->
          <rect x="10" y="20" ...>
          <text x="100" y="200" font-size="15" fill="red" >
             <tref xlink:href="#title1"/>
          </text>
     </g>
  </svg>

  1.3 Reuse existing accessible modules to indicate alternative-equivalent associations.

  Reusing accessible modules has the advantage of assuring that your "customers" can be confident 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 negligeable cost for your authors (the people using your language) to learn new concepts.

  Techniques for 1.3

  This example shows how to use an existing DTD module: the object from the XHTML tagset

  <!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="https://www.my.org/xmlns/inventory">
   <i:stockitem>
      etc.
    <xhtml:object...>  
      to include a picture or movie of the part.

• Guideline 2. 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 Ensure all semantics are captured in markup in a repurposeable form.

  In general, languages must be designed so that they can be presented in a device independent way. 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 method 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.
  • They should allow the authors to associate the final form with the higher level semantics of the source, whenever applicable.

  Techniques for 2.1

  See the last paragraph of the XSL 1.1.1 section for an example of such wording.

  2.2 Separate presentation properties using stylesheet technology/styling mechanisms.

  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

  Example: Wrong

  Do not include presentational attributes and elements in your language.

   <p align="center" font="arial" weight="bold">News items 1</p>
   <p align="center" font="arial" weight="bold">News items 2</p>
   <p align="center" font="arial" weight="bold">News items 3</p>

  Example: Right

  Support the inclusion and processing of external style sheets.

  mystyle.css: .news { text-align: center; font: bold arial }

  <?xml-stylesheet href="mystyle.css" type="text/css"?>
  <p class="news">News items 1</p>
  <p class="news">News items 2</p>
  <p class="news">News items 3</p>

  2.3 Use the standard XML linking and pointing mechanisms (XLink and XPointer).

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

  Techniques for 2.3

  Example. Wrong

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

   <mylink 
    linkend="https://mysite/myfile.xml">
      Current list of references
   </mylink>

  Example: Right

  Links can be recognized reliably by XLink applications.

  <crossref	xmlns:xlink="https://www.w3.org/1999/xlink"
   	xlink:href="https://mysite/myfile.xml">
     	Current list of references
  </crossref>

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

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

  Techniques for 2.4

  Think about the overall structure of your documents when you design a tagset.

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

  In this XML Schema example, a document is broken up into a number of sections, and a sequence of nestable 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="https://www.publishing.org"
  	 xmlns:xsd="https://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

  Mark up your 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: 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

  Example: XML using RDF and Dublin Core well known semantics.

    <someElement xmlns="https://xmlns.com/example">
     <rdf:RDF
      xmlns:rdf="https://www.w3.org/1999/02/22-rdf-syntax-ns#"
      xmlns:dc="https://purl.org/dc/elements/1.1/">
      <rdf:Description about="https://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 the semantics of individual elements.

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

  Techniques for 2.8

  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.

  Example: Right

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

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

  2.9 Reuse accessible modules from schemata as originally specified / intended.

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

  Techniques for 2.9

  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

  In SVG for instance, there is a metadata element where RDF statements can be declared, pointing at graphical elements and adding more relational semantics (one object linked to another, or on top of another) than what is provided by SVG itself. See the SVG Accessibility note for examples.

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

  The additional effort from the language designer point of view in providing stylesheets 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 utilise synthetic speech to produce a clear rendering of the content.

  Techniques for 3.1

  Example: See the sample style sheet for HTML 4.0 provided with the CSS2 spec,

  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

  Example: See how the Digital Talking Book DTD 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

  <xsl:stylesheet xmlns:xsl="https://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 -->
   <a href="source.xml">full source of document</a>
   <h3>Outline view</h3>
   <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

  Using DOM2 event the right way in SVG.

  <script> function DoOnActivate(evt) { .. } </script>
  <g onactivate="DoOnActivate(evt)">
    <rect id="button" 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. We each do things in our own time, and dislike being dictated to.

  Techniques for 3.5

  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 orr settable rate to allow the user control of all interactions. Fixed time period time-outs are not popular. See the SMIL-Animation specification 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 Ensure human-readable documentation conforms to WCAG double A.

  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

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

  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="https://www.w3.org/2000/10/XMLSchema-instance"
     	xsi:schemaLocation="https://www.example.org/schemas/doc.xsd"
     	xmlns:my="https://www.jenitennison.com/"
      xmlns="https://www.w3.org/1999/xhtml">

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

  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.

  Schema allows the language designer to explicitly attach documentation to elements and attributes, thereby making the language more understandable.

  Techniques for 4.4

  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.5 Provide semantic relationships to other schemata where appropriate and possible.

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

  Techniques for 4.5

  This can be done implicitly via subclassing/derivation of existing types, by asserting equivalence of type (e.g. SVG title and SMIL title) 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="https://www.w3.org/1999/XSL/Transform"
        xmlns="https://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 accessibility features of the application.
  

  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

  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 accessibility requirements in conformance requirements

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

  Techniques for 4.7

  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

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

  The WAI suite of accessibility guidelines (WCAG, ATAG, and 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

  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 the photo 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 the appetizer element to introduce a new appetizer, not a para 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 a non-English speaker. 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 utilise 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

  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.

  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

  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 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 elements (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
• etc

Appendix B: 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 instead of a bitmap). Having the ALT attribute "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.

Appendix C: Acknowledgments

In addition to the editors, the following WAI Protocols and Formats Working Group (PF) participants have contributed directly to the content of this document:

Kynn Bartlett , Geoff Freed, Al Gilman, Vijay Gummadi, Ian Jacobs, Chris Lilley, William Loughborough, Charles McCathieNevile, Dave Pawson, Gregory J. Rosmaita, Aaron Swartz and Carlos A. Velasco.

Appendix D: References

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