10.1 Basics of Accessibility

When producing web content, the most important thing you can do to help accessibility is to directly say what you mean. Prefer an image over a multimedia plug-in application. Prefer ordinary text over an image with text in it. Don't use a table unless you are providing truly tabular information. When the structure of your document and the structure of the markup align, current and future assistive technologies (not to mention users!) will have an easier time making sense of your information.

The view-source test is one of the simplest tests of accessibility, and it doesn't require any additional hardware or software. It shouldn't take an accessibility expert to create accessible web pages. To help developers in this regard, the World Wide Web Consortium (W3C) has released a series of documents providing guidelines for developers on how to create accessible web pages.

10.1.1 W3C Accessibility Guidelines

Version 1.0 of the W3C Web Content Accessibility Guidelines became a Recommendation in May 1999. A Version 2.0 with updated and simplified guidelines is currently proceeding through the W3C Recommendation track. Associated with each guideline are one or more specific techniques, found in a linked document.

Version 1.0 of the Web Content Accessibility Guidelines at http://www.w3.org/TR/WCAG10/ contains the following fourteen suggestions:

1. Provide equivalent alternatives to auditory and visual content.

2. Don't rely on color alone.

3. Use markup and style sheets and do so properly.

4. Clarify natural language usage.

5. Create tables that transform gracefully.

6. Ensure that pages featuring new technologies transform gracefully.

7. Ensure user control of time-sensitive content changes.

8. Ensure direct accessibility of embedded user interfaces.

9. Design for device-independence.

10. Use interim solutions.

11. Use W3C technologies and guidelines.

12. Provide context and orientation information.

13. Provide clear navigation mechanisms.

14. Ensure that documents are clear and simple.

Each guideline is divided into a number of checkpoints, each of which has a priority of one, two, or three, with one being the most important. Conformance to the guidelines is then based on multiple levels, with "A" meeting all priority 1 guidelines, "Double-A" meeting all priority 1 and 2, and "Triple-A" meeting all priority 1, 2, and 3. Note that the conformance levels themselves are spelled out so that text-to-speech systems will correctly render the phrase.

Of these checkpoints, the following fall into the category of basic good design, not specifically applicable to XForms: 1, 2, 3, 4 (through use of xml:lang attributes), 5, 7, 10, 12, and 14. The following come almost automatically by using XForms: 8, 9, and 11. Using a new technology like XForms actually makes it harder to fulfill point 6, since screen readers usually lag behind even mainstream browsers in adoption of new technologies. During a transitional period, it might be necessary for accessible pages that use XForms to maintain a fallback to a page that uses the older XHTML forms. The remaining point, number 13, can be accomplished for form controls through the careful use of host-language techniques for controlling navigation order and keyboard access, discussed in the "XForms-specific Design Hints" section.