This document introduces concepts related to XML Accessibility and provides guidelines for new DTD/Schema/Profile designers and editing tool developers. Compared to HTML or SMIL, XML is one level up: it is a meta language used to describe new languages, and in addition to the usual device independence issues, we need to pay attention to the issue of conveying semantics for otherwise unknown grammars. This presents the latest work in this area from the World Wide Web Consortium's (W3C) Web Accessibility Initiative (WAI).
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 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 documents like:
<TITLE>XML and Accessibiility</TITLE>
<ADDRESS>Daniel Dardailler</ADDRESS>
<H1>Background</H1>
and they can only use elements (TITLE, H1, etc) defined by the HTML specification (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>
</APPETIZER>
which 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 used in protocol communication, to serialize and encode data to be sent from one machine to the other.
The XML DTDs (Document Type Definition, the grammar used to express new XML family languages) can in fact be classified along two different axes:
Machine-centric:
- when the content being marked up is only for machine consumption.
Example: serializing/exchanging data (e.g. WebBroker, XML-EDI),
or expressing data processing (e.g. XSL - Extensible Style Language).
User-centric:
- for UI (User Interface) oriented structural textual rendering (e.g.
Docbook, HTML, MenuML, OEB),
or specialized rendering (e.g. MathML, SVG - Scalable Vector Graphics,
MusicML, SMIL - Synchronized Multimedia Integration Language).
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 http://www.w3.org/WAI/References/HTML4-access).
These features includes:
- Improved structure (such as FIELDSET, OPTGROUP in FORM)
- Support of separate Style sheet
- 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 will result is a loss of accessibility features, present today because of HTML pervasive presence.
Nothing in the XML specification prevents a markup language designed
to create a set of tags that would prevent the creation of accessible
document, such as:
<MENU>New England Restaurant</MENU>
<APPETIZER>Clam Showder
<PHOTO url="clam.jpg"/>
</APPETIZER>
with no way to include an alternate textual description of the photo, for instance.
But let's start by defining what we mean by accessible DTD and document.
(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.
According to the taxonomy introduced in the first section, these guidelines only addresses 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 do not directly convey 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 must reach the right level of machine-centricity.
For User-centric languages, 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, 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.
This section provides a list of abstract guidelines, checkpoints and techniques that DTD designers should follow to achieve accessibility when designing new UI XML DTDs. At the time of writing the article, this is still in draft stage ,and people are encouraged to check the WAI site for a more updated version.
The techniques are meant to point at existing or new mechanisms used to implement these guidelines through re-use and modularization of XML parts. A note at the end of this document explains why to distinguish guidelines and techniques.
As with the other WAI guidelines, we provide "abstract" guidelines, and associated checkpoints (verifiable points) and techniques (recipes).
They are 5 abstract guidelines:
1. Follow general principles of separation of structure/content and presentation
*rationales: end-users can adapt the content to their presentation
constraints
*checkpoints:
- no presentational elements or attributes in the markup
- support standard linkage of Style sheets
- provide default stylesheets for multiple media (e.g. aural),
not just graphical
techniques:
- list of typical style properties that should be avoided in
markup
- example of <?xml-stylesheet?> syntax
- example of aural css usage
2. Enable text-only presentation of your documents
*rationales: text is the lowest common denominator to all output
media
*checkpoints:
- make sure all "rich" non-textual media elements in your
markup can be bound to an alternate textual piece
- make sure this is done in the most natural way possible
*techniques:
- point at XHTML modules for OBJECT, MAP element
- audio/video: point at SMIL SWITCH
- graphics: point at SVG title/desc
3. Provide rich native structural/navigational constructs
*rationales: greatly facilitates non-visual browsing and scanning
*checkpoints:
- strong sectioning/auto generation of TOC
- grouping and reuse
- for specialized DTDs (SVG, SMIL, MathML), work on
one-dimensional (e.g. voice) scenario
- provide basic information of inline or block nature of
elements
*techniques:
- XHTML list, table, grouping structure/module
- navbar/toc RDF marker, clipart/outline class in SVG
- XSLT mydtd-to-xhtml mapping ?
- use DIV and TITLE on top of any markup
4. Provide atomic semantic markup
*rationales: to ease machine-understanding and machine-processing
of documents
*checkpoints:
- make sure the meaning of common things is available to user
agent for clever processing
- do not reinvent the wheel, reuse well known schema if
possible
- provide a DOM specific API to ease UA access to you data
- allow metadata linkage in your syntax
*techniques:
- use xlink for pointers, xml:lang for language variance
- XHTML phrasal module: acronym, abbrev, quote, etc
- publish new RDF/Schema documentation widely and openly
5. Support a key-based (discrete) input model
*rationales: discrete key access, if available, can easily be
remapped to all sorts of input mode
*checkpoints:
- provide a key based navigation model to your elements
- think in terms of symbolic events, not device dependent
events.
* techniques:
- onActivate, not onMouseClick
- look at image map info
- tab order, accesskey
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.
Approach on Guidelines/Techniques separation
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 that there are several techniques for achieving the same result, and people's decision will be a function of time and products available, as well as 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:
- providing an XSLT binding (to a HTML UL/LI pair of element)
- using namespaces and existing attributes (xhtml:ul, xhtml:li)
- using XML/RDF schemas (if a primitive is available; or through a new
schema if a primative is unavailable)
- re-using XHTML list modules directly
- using Architectural forms
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.
In this paper, we examined how to provide clear definitions and requirements related to XML accessibility. We believe abstract guidelines and verifiable checkpoints/techniques (using implementation mechanisms associated with abstract guidelines) are the best way to address this problem. Our primary message is: be device independent, and export your semantics as much as you can. We proposed five different guidelines for doing that:
1. Follow general principles of separation of structure/content and presentation
2. Enable textual presentation of documents
3. Provide rich native structural/navigational constructs
4. Provide atomic semantic markup (non structural/navigation)
5. Support a key-based (discrete) input model
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.
Accessible DTD:
An XMl DTD is accessible if it enables and promotes the creation of
accessible documents
Accessible document:
A document is accessible if it can be equally understood by its
targeted audience regardless of the device used to access it.
Promoting vs. enabling:
The word "promote" is important as "enable" alone does not cover the
case where a DTD 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 pay your taxes
but this doesn't "promote" accessibility as most author 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.
Device:
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 availibility (or lack thereof), where access to data becomes
impossible on slow connection because of their volume.
Equal understanding:
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:
This is a property of a system that can still function relatively error
free when the system is damaged or when the input stimuli is
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 do 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 degrade gracefully.
If the DTD designer hasn't provided a way to attach alternate content to some rich piece like an animated yellow wagon, the content provider will not be able to make an accessible document.
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 degrade gracefully: it's not as fast as a couple of mouse clicks, so there is some degradation in the system, but I can get to it.
Another aspect of "understanding" is that in order for a User Agent to make sense and gracefully degrade the content of an arbitrary DTD-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.
- WAI home page
- XML Home page at W3C
- Web Content Accessibility Guidelines 1.0
- International Committee on Accessible Document Design (ICADD)
- SVG Home page
Daniel DARDAILLER, Janvier 2000
Droits de reproduction et de diffusion réservés -
Colloque sur le livre numérique - BrailleNet-Cité des sciences-INSERM-UPMC