Table of Contents
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies."
C. A. R. Hoare
The next time you visit your favorite web site, try reading the page using only the view source command in your web browser. Can you make sense of the information there, or do you have to pick through a forest of extraneous tags inserted by the site's designers for visual layout? Browsing page source is a rough approximation of how many users experience web pages when using a screen reader, assistive technology that helps compensate for physical limitations such as blindness. The practice and study of creating web content that doesn't shut out such readers is called accessibility.
Accessibility matters, even for forms and web pages that don't have an expected audience of users with special visual or other needs. For example, even sighted persons are interested in eyes-free browsers, and making content accessible is closely related to improving usability. Designing an accessible web interface is often simply a matter of awareness of the many ways in which people use the Web (see http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/). Many devices are beginning to support speech interfaces, either alone or in combination with conventional visual interfaces. Other devices simply have limited processing capabilities, due to size or other constraints. No matter what the reason, keeping in mind principles of good design and accessibility is just good sense.
Later, this chapter covers some common design patterns for forms, some XForms-specific tips and tricks, and some guidelines for transitional issues.
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.
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.
Provide equivalent alternatives to auditory and visual content.
Don't rely on color alone.
Use markup and style sheets and do so properly.
Clarify natural language usage.
Create tables that transform gracefully.
Ensure that pages featuring new technologies transform gracefully.
Ensure user control of time-sensitive content changes.
Ensure direct accessibility of embedded user interfaces.
Design for device-independence.
Use interim solutions.
Use W3C technologies and guidelines.
Provide context and orientation information.
Provide clear navigation mechanisms.
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.