XML Accessibility Guidelines

W3C WAI PF draft note - 17 February 2000

This Version:
Latest Version:
Daniel Dardailler (dd@w3.org)


This document explains how to design accessible XML languages. Compared to the HTML or MathML language, XML is one level up: it is a meta syntax used to describe these languages as well as new ones, and it provides no intrinsic guarantee of device independence or textual alternate support. In this context, guidelines are needed that explain to XML formats and tools designers how to include basic accessibility features - such as the ones present in HTML - in all their new development.

Status of this document

This document is a WAI PF draft note made available by the Protocols and Formats Working Group (PFWG).

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.


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

It can be seen as a simplication 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 (Hyperter Markup Language) 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>
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 Showder
   <PHOTO url="clam.jpg">A large creamy bowl of clam showder, with
       bread crumbs on top</PHOTO>
which may fit more closely the needs of their information system.

Within W3C, the HTML language is now migrating from SGML to 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 multi media), 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 the other.

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

According to this taxonomy, these guidelines only address User-centric DTDs. This does not imply that the first type of DTD doesn't have accessibility issues or features (see how XSL can help Braille formatting for instance). However since they are not directly conveying information presented to the end-user, they are out of our scope here.

In a sense, machine-centric DTDs have no connection to user interface accessibility, and one might ask if the commutative proposition is true: DTDs with no accessibility issues are the ones that have reached the right level of machine-centricity.

Problem statement

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

These features includes:

One area of concern with the advent of XML is that the freedom of design it brings will result is 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 Showder
   <PHOTO url="clam.jpg"/>  <-- no alt attribute or textual content model here
In this example, the problem is not that the author of this document didn't put an alt attribute, it's that the designer of the language didn't put the attribute in the language itself.

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

An XML DTD is accessible if it enables and 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.

As explained in the introduction, we're only considering User-centric 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 some semantics that can then be used to present the document in various media is paramount for pervasive access (i.e., you don't need a programmer, you just need a program).

The ICADD (International Committee on Accessible Document Design ) committee was a pioneer in this topic, for SGML accessibility and ways to convey arbitrary DTD semantics (using specific SGML binding mechanisms). A few years later, ICADD has not really been adopted, 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 UI-oriented XML tagset

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

  1. Ensure that authors can associate a text description with any non-text content (graphics, sound, multimedia, scripts, etc.)
    • make sure this is done in the most natural way possible
    • point at XHTML modules for OBJECT, MAP element, SMIL switch, etc
  2. Create semantically-rich languages.
    • Do not define presentation elements or attributes.
    • Enable the use of style sheets (linked or internal).
    • Use the standard linking mechanism.
    • Define element types that allow classification and grouping.
    • Define element types that identify important text content.
  3. Export semantics
    • Provide accessible documentation.
    • Provide schemas and a mean to access it.
    • Reuse accessible DTDs, schemas, etc. (xlink, xml:lang)
  4. Design an accessible user interface
    • Provide default style sheets for multiple output modes.
    • Describe navigable structures
    • Use CSS or XSLT to describe a basic outline view.
    • Document navigable structures. Describe how discrete, sequential, structured, and search navigation mechanisms should work.

An additional advice we give to DTD 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 SVG specification for an example of both practices.



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

The fact is: 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, we might want to have the XML designer indicate what constitutes a "list" element in a given markup, and this in turn can be implemented using various techniques:

Along with the choice of the metadata mechanism and vocabulary comes the issue of semantics availability: how does one access the DTD 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:

DTD: Even though we use the acronym DTD, we don't want people to assume we are only talking about a DTD as defined in XML 1.0 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. Schema or profile might be a better word for our usage.

An XML DTD is accessible if it enables and 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.


WAI Home page: http://www.w3.org/WAI/

WAI PF Home page: http://www.w3.org/WAI/PF