Suggested introduction and other text for XAG 1.0

Per my action item of the 9 April 2002 PF meeting, please consider the following text as a new introduction to the XML Accessibility Guidelines. This text is meant as a substitute for the section entitled "XML Grammars and the scope of XAG".

This text has not been approved by anyone.

Relationship to other WAI Guidelines

"XML Accessibility Guidelines 1.0" is part of a series of accessibility guidelines published by the Web Accessibility Initiative (WAI). The documents in this series reflect an accessibility model in which Web content authors, format designers, and software developers have roles in ensuring that users with disabilities have access to the Web. In this model:

• Format specifications (e.g., HTML, XHTML, SVG, SMIL, MathML, etc.) include features that support accessibility, such as elements and attributes for alternative text, navigation tools, semantics that respect user control over presentation, etc. The current document (XAG 1.0) explains how to design XML formats that include features to benefit accessibility. The principles of this document apply for the most part to non-XML formats as well.
• Authors make use of these features when creating Web pages and Web applications. The "Web Content Accessibility Guidelines 1.0" [WCAG10] explains how to create more accessible content through features offered by formats, and also through consistent design, clear writing, use of multimedia, and more.
• Authoring tools help authors create more accessible content through support of formats with accessibility features, and through interactive and automatic assistance (e.g., prompts for accessibility features, validity checking, reuse of accessible content, etc.). The "Authoring Tool Accessibility Guidelines 1.0" [ATAG10] explains the responsibilities of authoring tool developers. ATAG 1.0 addresses the accessibility of authored content but also the accessibility of the tool's user interface.
• User agents promote accessibility by implementing formats with accessibility features, and by providing an accessible user interface, allowing communication with assistive technologies, documenting accessibility features, following operating environment conventions, etc. The "User Agent Accessibility Guidelines 1.0 [UAAG10] explains to user agent developers how to create more accessible browsers, multimedia players, and other user agents.

Formats, authors, and designers all have limitations. Formats generally do not enable authors to encode all of their knowledge in a way that a user agent can recognize 100%. A format may lack features required for accessibility. An author may not make use of the accessibility features of a format or may misuse a format (which can cause problems for user agents). A user agent designer may not implement a format specification correctly or completely. Some requirements of this document take these limitations into account.

Target formats

XML formats represent a continuum from very end-user-oriented (e.g., HTML, SVG) to very data-centric (e.g., XSLT, XML Schemas, RDF, etc.). The requirements of this document are more likely to make sense for end-user-oriented formats than for data-centric formats. This does not imply that there are not accessibility issues or features that make sense for data-centric formats; that is not the focus of this document.

Conformance and Accessibility

Conformance to the requirements of this document is expected to be a strong indicator of the accessibility of a format, but it is neither a necessary nor sufficient condition for ensuring a format's accessibility. Some formats may not conform to this document but promote accessibility for some users with disabilities. Conversely, some formats may conform to this document but lead to the creation of inaccessible content for some users with disabilities. Some requirements of this document may not benefit some users for some content, but the requirements are expected to benefit many users with disabilities, for general purpose content.

For these reasons, this document does not refer to "accessible formats" but rather "conforming formats": these formats will be more accessible by virtue of satisfying requirements known to reduce accessibility barriers. This document refers similarly to "content that conforms to WCAG" rather than "accessible content". Content that conforms to WCAG is built from formats that support accessibility, and is authored with attention to accessibility (e.g., with consistent navigation, clear writing, etc.).

Other suggestions:

1. Don't use the term schema with a small "s". Instead, use the term "format". I've looked through the document, and substituting format for schema would, in my opinion, reduce confusion substantially. Save "schema" for "xml schemas" or "rdf schemas". There's already enough confusion about those two.
2. I suggest leaving the first half of the section entitled "Problem statement" and deleting at the point starting "But let's start by defining...". Please just let a conformance section speak for itself: a XAG-conforming format must satisfy the indicated formats. Instead of ending abrubtly after the example, the section could end with something like:

   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). This document explains how such principles as device-independent design and machine-readable semantics promote accessibility. These principles also lead to additional benefits such as content reusability and maintainability.

   Note: 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.

3. Delete definitions of "accessible X" from Appendix B.