XML Reference Guide

In our last section, we discussed ways to make your web applications more accessible. It's worth noting, however, that the only reason we were able to do that is because the authors of the HTML vocabulary and its descendants provided accessibility features such as the alt attribute for images and the summary attribute for tables.

When you're designing your own XML language, you need to keep some of the same considerations in mind to help you along. The World Wide Web Consortium's Web Accessibility Initiative Technical Activity group has provided a list of guidelines and checkpoints to follow.

The list hasn't been finalized yet, but the concepts are sound so let's take a look at the guidelines and some specific things to consider in adhering to them. (Also, the last draft was in October, 2002, so they're obviously not in a big hurry to make changes.)

First off, let's understand what we're trying to accomplish. We want to make end-user-oriented languages -- meaning those ultimately intended for display in some human-readable form -- that do the following:

• Allow for text alternatives for all non-text content.
• Allow browsers (and potentially other user-agents) to find those alternatives.
• Allow authoring tools to understand what content the alternatives are for.

For example, suppose I were creating an XML vocabulary for television scheduling information. If I created a commercial_video element, I could satisfy all of these goals by including commercial_description element as a child of the commercial_video element, as long as I provided a way for user-agent developers to know about the relationship so they could display the text instead of the video, if necessary. That same information would be available to developers of authoring tools, enabling them to make sure that whenever an author used a particular piece of video, the text went along with it.

That makes things seem pretty simple, but there's really more to the XML Accessibility Guidelines than that. The draft document lists four basic guidelines, each with a set of specific checkpoints. They are:

1. Ensure that authors can associate multiple media objects as alternatives.
2. Create semantically rich languages.
3. Design an accessible user interface.
4. Provide documentation and export semantics.

Basically, these guidelines cover the structure of the vocabulary, the form of the vocabulary, the use of the vocabulary, and the documentation of the vocabulary. Let's look at these guidelines in more detail:

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

   Notice that the guideline does not say "always add an alt attribute". What it means is that you should be able to associate different versions of the same content in such a way that tools can understand that they all represent the same content. One example of this in action is the XHTML object element, which can contain several different versions of the same content.

   In normal use, the browser picks the first version of the content that it understands and ignores the rest. You could, however, create a vocabulary in which users and tools can choose which version to use. For example, you might have a user-agent that displays the text, but includes a button the user can click to show the image, and vice versa.

   Basically, this guideline is intended to require you to enable associates in both directions, from text to non-text and back again, if necessary.

2. Create semantically rich languages.

   The basic gist of this guideline is that your vocabulary should provide a way to define what the content represents, rather than how it looks when displayed, or even how it functions on the page. For example, I may know that my TV listings will ultimately be displayed in a table, but I would use elements such as tv_movie and sitcom_episode rather than table_row, because they provide some kind of meaning.

   In addition, this guideline had more specific checkpoints, such as prohibiting the re-use of element names for different functions. For example, I'd want to have a commercial_video element and a sitcom_video element, rather than calling them both video and relying on the application to tell the difference by looking at the element's parent.

   This guideline also suggests re-using existing accessible structures, such as the XHTML object element, and using standard mechanisms, such as XLink and XPointer, where possible.

   Finally, this guideline requires that if your application serves the "final form" of a document, such as an XHTML transformation, that details of how to obtain the original XML should also be present.

3. Design an accessible user interface.

   This guideline is more about the application that accesses the data than it is about the data itself, but some suggestions affect the structure of the data. For example, the guideline requires that "navigable structures" such as lists, and guideline number 2 suggests you create classifications, groupings and lists top help organize the data. This guideline also prohibits dependence on a certain type of interaction such as a mouse click, or even on a particular device, going for device-independence instead. It also suggests providing a way for users to control the pace of a presentation, such as a "pause" button or link.

   The rest of the guideline requires you to step back and look at your creation, providing default stylesheets for each modality (i.e. screen, print, audio), and CSS or XSL to produce an outline of the data.

4. Provide documentation and export semantics.

   This guideline deals with one of the most important -- and most overlooked -- aspect of accessibility: documentation. If nobody can find the accessibility features for your language, nobody's going to use them. Much of the guideline focuses on the issue of the language schema. If you're defining a language, you're going to have one, because that is the definition. This guideline basically prohibits the use of DTDs to define a language by requiring you to use a schema that make's it possible to add machine-readable documentation about your elements and attributes. Because DTDs are generally unstructured, that's not possible. Note that the guideline does not require W3C XML Schemas. Using another schema language such as RELAX-NG is fine, as long as you include the proper documentation.

   Another aspect of this guideline is ensuring the usefulness of the documentation you create. First off, it must be accessible (using these guidelines), and it must be retrievable from information in the actual data. For example, you can use the xsi:schemaLocation element to tell an application where to get the schema.

   Within the documentation, you need to make sure that the information is actually useful. For example, you can't assume that element and attribute names mean anything, no matter how semantically careful you were in constructing them. For example, you can't define the commercial_video element as, say, "video for a commercial". You'd need a definition more like "Information and metadata about the audio-visual content of this advertisement.". Remember, there may be those following after you that don't speak the language you were using when you constructed the document.

   Finally, make sure that you document the accessibility features that you've built into your language, and require applications to support these features in order to be considered conformant.

Ultimately, this list may change, but the overall concepts are likely to remain. For a full (and current) list of checkpoints for each of these guidelines, see the XML Accessibility Guidelines.