Developing Accessible User Interfaces
Consider the following scenarios:
A vision-impaired consumer wants to purchase a book from an online bookstore, but is stymied by the Web site's multiple Java applets and graphics, none of which the consumer's audio screen reader can decipher.
An employee needs to learn the company's new marketing software, but the application doesn't support keyboard input for commands. Because the employee has nerve damage that prevents him from manipulating a mouse, he can't use the new application.
If that Web site and the marketing application had been developed to support assistive technologies for the disabled, neither of those two scenarios could have happened. Fortunately, more developers are becoming attuned to the needs of the disabled, especially as computers become as important to daily life as the automobile and the credit card. These days, it's become critical for applications and Web sites to be accessible by anyone or any device that requires it.
For the developer, providing support for multiple types of users and access devices is not only simple good business; it's also the law in many cases. Under the Americans with Disabilities Act of 1990, employers are required to make "reasonable accommodations" for employees with disabilities. Government agencies are required to make their Web sites and other technology handicap-accessible for all users under Section 508 of the Federal Rehabilitation Act.
Judy Brewer, director of the World Wide Web Consortium's (W3C's) Web Accessibility Initiative, comments on the accessibility issue:
"There are so many reasons for making Web sites and applications accessible. In many casesif you want to do your tax forms or buy something or search for a job or interact in your workplaceit's become a necessity."
It's not only people with disabilities who stand to benefit from adherence to accessibility guidelines, however. As Brewer points out, there are also plenty of mobile users, people with low-bandwidth connections, elderly users, and Web surfers with sore wrists from too much point-and-clicking who would appreciate more flexibility in accessing the Web:
"Accessible design makes access easier for everyone. It emphasizes flexibility in accessing information through different modalities according to user needstext-based, auditory, tactile, refreshable Braille display, whatever. It's a useful design element for any site."
For Java developers, Sun Microsystems' Java Accessibility API (JAAPI) can help. The JAAPI is a standard extension of the Java platform and provides information that Java Applications need to be compatible with assistive technologies such as screen readers. As Peter Korn, accessibility architect at Sun, explains:
"The Accessibility API says that if an application is going to interact with assistive technologies such as onscreen keyboards, screen readers, magnifiers, and so forth, then every user interface elementevery scroll bar, menu item, text field, check boxmust implement the API."
Korn notes that for developers who use Swing, the Java Foundation Classes for constructing Java user interfaces, support for the Accessibility API is built-in.
Sun also offers the Java Access Bridge for Windows to enable Windows-based assistive devices to communicate with Java applications. The Bridge provides a dynamically linked library (DLL) on the Microsoft Windows system to communicate between the assistive technology and the native code of the Access Bridge, which, in turn, communicates with the JAAPI.
Whether a developer is creating a new Java application or a Web site, the ground rules for accessibility are much the same. They include:
Keyboard Navigation: Mouse users may be in the majority, but there are many people who can't use one. So it's critical to provide keyboard alternatives. For instance, establish keyboard accelerators, or equivalents, for component activation, such as Alt-F for File.
Descriptions, Captions and Labels: Visually impaired users who use voice output devices require text labels, captions, and descriptions for graphic elements, such as pictures, charts, videos, and icons. Conversely, deaf users need text equivalents of audio messages and presentations. Consistency and clarity are key factors in making labels and other descriptions useful. Also, avoid descriptions that only make sense when heard in context. For instance, "click here" is best avoided.
AppletsAccessibility Guidelines and Alternatives: Many of the browsers used by people with disabilities can't run Java applets. Therefore, developers need to provide text alternatives to the applets that can be inserted into the HTML code. Better yet, says Korn, use Sun's Web Start instead of applets. Web Start enables users to launch a Java application on their desktop independent of the browser. According to Korn:
"The application is still launched from the browser, but runs outside the browser frame. It's a much better way to deploy an accessible application to the Web."
Testing: No matter how carefully a developer tries to implement accessibility, there will be problems, so testing your application is a must. Rich Schwerdfeger, IBM's Software Group Accessibility Strategist and chair of the IBM Accessibility Architecture Review Board notes says that it's best to check both with some type of application error checker and, also, with an assistive technology.
"Source code checkers don't always work with dynamic content, so then you're limited to checking with a screen reader solution like JAWS," he says, noting that errors can creep in at any level of an application, such as through the Java Access Bridge translator which sits between a Windows device and the Java application. "You may think you've implemented accessibility correctly, but if you haven't tested it, it may not work."
One tool for testing Java applications is the Java Accessibility Helper. Other tools can be found at Sun's Accessibility Utilities site. A list of tools for checking Web site accessibility can be found here.