As your company makes more of its applications available on the Web, you will need to determine the level of accessibility for each of those applications. The term accessibility describes how IT hardware, software, and services address and/or neglect the needs of a user community, including users with disabilities. To achieve this aim, accessible applications often include or interface with assistive technology such as screen reader software, voice recognition, screen magnifiers, and special keyboards.
For WebSphere Web- and applet-based applications, accessibility compliance is primarily a consideration of user interface design:
- Information should not be lost when using an alternative presentation, such as with assistive technology (e.g., processing images with text-to-speech software).
- Site navigation and input controls should also be available in non-default usage scenarios (such as keyboard-only access).
- The overall user experience should not be a diminutive one for users with disabilities - resolve problems of information loss, inaccessible controls, and layouts that may be frustrating or long-winded from different views.
Users today expect higher levels of convenience and ease of use from software applications. However, wider adoption of the technology by new demographic groups, such as older users and special-needs communities, leads to new requirements of the software for accessibility. These requirements go beyond enhancements of convenience and constitute functional changes. Software compliance may address the needs of those with limitations of dexterity or mobility, vision impairments, loss of hearing, eye/hand coordination problems, and cognitive disability. Consider that images flashing at a certain frequency can incite epileptic seizures in some users; this is an example of why accessibility factors need to be taken seriously.
Some of the measures that address special-needs users include:
- Text-to-speech synthesizer software for visually impaired users
- Greyscale mode and high-contrast settings for color-blind users
- Keyboard-only alternative for users with limited hand usage
These few examples of functionality are detailed in government standards for accessibility. The most commonly referenced standard is Section 508 of the U.S. Rehabilitation Act, which places a requirement on all U.S. federal agencies to use products and services that are accessible to people with disabilities. Similar directives exist in the EU, Japan, Australia, and across the globe.
Assistive Technology Assistive technology includes software and hardware solutions such as screen reader software, voice recognition, screen magnifiers, special keyboards, and wireless communications. IBM provides screen reader software called Homepage Reader which is available as a beta download. Another example of assistive technology is the MS-Windows NT/XP operating system Accessibility Options (see Figure 1). These are reached via:Start Menu -> Settings -> Control Panel -> Accessibility Options.
These options include:
- Settings for cursor flashing
- The enabling of special keyboard settings such as StickyKeys, Filter Keys, ToggleKeys
- The settings for high-contrast mode, including different larger and bolder fonts, combined with customizable background/foreground color schemes
Figures 2 and 3 of the same Windows XP desktop illustrate the effect of high-contrast settings.
As shown in Figure 3, the application's background has become black and many of the fonts are now bolder and larger. The font settings are adopted from the new system settings. Note that the figures include a Web page in Internet Explorer 6.0 and windows from MS Outlook and MS Word applications. All of these applications converted properly to the high-contrast settings, but this is not guaranteed to be the case.
Readers are encouraged to try out these settings and explore how different software packages and applications are affected. The results will vary according to software and version, and depend on whether or not it ignores or blocks Windows systems settings or overloads functions such as special keys. In general, the software needs to support these APIs explicitly, so it is not safe to assume it will be accessible by default.
Web Design Considerations: HTML The main focus of accessibility considerations for Web applications is on how the content is presented using HTML, stylesheets, JavaScript, and media content. This is irrespective of whether the rendered pages are static or are created using dynamic server-side technology such as Servlets, JSPs, or Windows ASPs. Since it is the final product rather than the creation process that is key, the principles will apply to different types of architectures. This article focuses on WebSphere applications.
Clean Up the HTML Many browsers are flexible in accepting HTML that does not meet HTML and XML standards. You cannot assume your rendered HTML meets specification even if it looks acceptable in the predominant browsers such as Internet Explorer and Netscape. The HTML needs to be cleaned up; assistive HTML readers do more than handle basic presentation and therefore require a coherent base to interpret. They are not as flexible in handling unstructured HTML as are normal browsers.
Here are some areas that will need to be addressed:
- Add missing HTML end tags. Single tags such as <br> also require an end tag, as per XML guidelines.
- Avoid uppercase HTML tags. XML is case sensitive so use lowercase tags only.
- Use quotation marks in tag parameters.
Such changes will appear trivial at first, but if these formatting issues permeate most of the site's pages, a seemingly simple task becomes a large and tedious project.
There are tools to assist with the HTML cleanup work that automate fixing problems such as those highlighted above. IBM WebSphere Studio Application Developer 5.1 provides a facility to clean up HTML and JSPs. The "Cleanup" function is available via Web Perspective -> select HTML/JSP > right-click Cleanup Document (see Figure 4).
Clean Up the Forms Before using automated tools to clean up the HTML, first check the format of forms. This requires a manual process, otherwise, if the HTML is reorganized by a tool (e.g., WebSphere Studio -> Cleanup Documents -> Insert Missing Tags) and form tags are moved around, you will likely lose information that is intended for submission to the server, which will break the application's functionality.
For example, an existing form tag might have been inserted between a table tag and a table row <tr> tag. Although this is structurally wrong and should be avoided, it still works in common browsers, so you might already be using it.
<table>
<form name="form1">
<tr>
<td><input type="text"
name="text1" /><input
type="submit" name="sub1" />
</tr>
</form>
</table>
Experience has shown that cleanup tools often take liberties when reorganizing form tags, effectively removing tag information that you expect to be part of the form:
<table>
<tr>
<td><form name="form1"></
form><input type="text"
name="text1" /><input
type="submit" name="sub1" />
</tr>
</table>
This will render a button that does not react when clicked. It is recommended that you move the <form> tags outside the <table> tag altogether. This example also illustrates why you should conduct a functional regression test after making accessibility changes, even though they are largely considered to be "cosmetic" rather than functional.
Another area within forms to consider is the use of labels. Labels are generally located close to the entry field (on top of, or to the immediate left of), but that does not guarantee assistive technology will associate it with a particular form element. Use the <label for="id"> element to specify the association between the label and the entry field.
Images Need Alternative Text Images need text alternatives in the form of ALT attribute or LONGDESC attribute (for longer text) to describe their content in order for reader software to convey their message to users. This is particularly important if the image is a diagram with information content such as figures, pie-charts, etc. That information must be conveyed in a different format as well.
Image Maps Need Alternative Text Consider a dynamic image map such as a U.S. map of all 50 states in which you can access information for any state by clicking on, or hovering over the state (representing an image hot spot) with the mouse (see Figure 5).
An accessible version of this would need to convey the same level of information for the top-level image, such as the color schemes and what they indicate. It must also address how to navigate to each state via the keyboard.
Accessible Alternatives for JavaScript The preceeding example included hover-over popups for image maps. As hover-over popups, info boxes, and flyover menus become more common on Web sites, care must be taken to ensure that there is an accessible equivalent for the navigation and information delivery functionality. Flyovers are usually implemented using JavaScript which is not accessible by default. Turn off JavaScript and test the page again to get a better feel for the dependencies, and then limit these as much as possible. Also test the page's functionality in keyboard-only mode.
Easy Navigation and Shortcuts Many Web sites include a header and left-navigation section, allowing users to use links to jump directly to the page contents section.
The jump links can be achieved by creating a hyperlink and associating it with a one-pixel sized image that has alternative text.
<a href="#main"> <img src="pixel.gif" height="1" width="1" border="0" alt="Jump directly to main section" /></a>
...
<!-jump to here -->
<a name="main"></a>
In case a Web site is using frames to differentiate the screen sections, each frame should have a title in order to improve the ease of navigation among them.
Alternatives for Multimedia Content Multimedia content generally requires third-party utilities and is rarely accessible; therefore, you must provide accessible enhancements such as captions, visual queues for audio alerts, and volume controls. If enhancements such as these are not possible, you must provide an accessible alternative, for example, a text-only transcript.
Explanatory Text for Web Pages Consider a Web page that contains a table with sales figures per sales quarter.
In order to understand the numbers presented in any given data field (such as "$160"), the user visually checks the row header on the left, such as "Apples," and then the column header above, such as "2003/Q3." With an HTML reader users cannot perform the same correlations for that data since it is presented in a predominantly linear manner, word for word, as text.
Figure 6 shows how users with unimpaired vision can assume a birds-eye view and have the capability to refocus on special details, shift visual focus to jump around and correlate information, or drill down into other sections. This is very difficult with a reader, therefore special provisions are needed.
A basic technique is to provide explanatory text using a zero-sized image with ALT text. The ALT text will only be presented to the reader software, not to someone viewing the page using a normal browser.
<img src="pixel.gif" height="1" width="1" border="0" alt="Sales of Apples for Q3/2003" />
The example also includes three radio buttons: Details/Edit/Delete. If the radio buttons are not annotated for reader software, the values would be read without the description, such as:
Checked Unchecked Unchecked
More hidden text can be included to yield a less confusing result:
[More Details for Apples] Checked [Edit Apples Numbers] Unchecked [Delete Apples Data] Unchecked
A more elaborate strategy than hidden text would include using Model/View/Controller components and allowing the Model to be rendered differently in the View according to the client's settings. Portal software such as WebSphere Portal Server can be used to implement this strategy.
Data Tables vs Layout Tables HTML tables can be used both to store data and organize page layout. It is important to differentiate these usage types. Layout tables should be flagged so they are not interpreted as data tables. One convention is:
<table summary="layout">
Caution with Color Characteristics Colors are often used in Web pages to highlight or differentiate text segments, such as red text to point out critical information. However, these colors will not be picked up by reader software, color-blind users, or high-contrast settings.
Use a hidden ALT text image to highlight these characteristics. In the sales table example (see Figure 6), the Q3/2002 column has critically low sales figures highlighted in red, but that information needs to be conveyed to reader software explicitly.
Avoid Popups Popup windows are not recommended since many clients have activated popup blockers that disable them. Additionally they cause unnecessary disruptions to HTML reader software because they force a context-shift to the new window. Action is then required to close the popup or shift back to the previous window.
Allow Stylesheets to Be Deactivated What will your Web site look like with CCS stylesheets disabled entirely? Does this lead to information loss?
Rephrase Descriptions for Mouse Usage or Visual Cues Wording such as "view this" and "click here" will not address all users, so rephrasing these is appropriate.
Web Design Considerations: Java Applets Web applications are generally HTML-based and can be viewed directly in a Web browser. One other type of application is the Java applet that is loaded over the Web via an HTML page, but provides its own interface. Java Swing classes include an Accessibility package that should be used to set image labels and other accessibility options. Swing's system look and feel should also be used. If the applet (or Java stand-alone GUI) is still using the AWT classes, strongly consider migrating to Swing.
Other considerations for designing desktop applications as well as Java applets include:
- Alternatives to audio queues such as beeps
- Clear focus on the current part of the screen
- Easy navigation between components via both mouse and keyboard
- Access to the operating system
- Accessibility APIs such as customizable colors and high-contrast settings
- Provide queues such as labels for reader software
- Allow timed areas to extend the time permitted to perform action
- Avoid blinking text or graphics
These considerations also apply to HTML-based Web applications, but are less common.
Conclusion According to a survey in 1997, over 17% of the adult population in the U.S. had a disability. With corporate applications rapidly getting deployed on the Web, it is critical and at times mandatory to address accessibility for users with limitations of dexterity or mobility, vision impairment, loss of hearing, eye/hand coordination problems, and cognitive disability.
Accessibility cannot be considered an afterthought in Web page design since it touches on so many different areas of applications. For existing Web applications, it is possible to enhance the various accessibility options, but with the number of bulk changes that may be necessary, the effort should incorporate several iterations and must include testing. Testing application accessibility is very different from testing applications; testers need to detect problems in areas that are not visible to most users and that will not be addressed by Web development. Development and testing teams should agree on the scope, since there are potentially many grey areas to cover. The existing standards can help to define this scope, especially if compliance is required.
Useful Links
IBM Accessibility Center: www306.ibm.com/able/
Federal Rehabilitation Act (section 508): www.section508.gov, www.access-board.gov
W3C Web Accessibility Initiative: www.w3.org/WAI/
UK Disability Discrimination Act Code of Practice: www.drc.org.uk/open4all/law/Code%20of%20Practice.pdf
IBM Corporate Instruction 162: www-306.ibm.com/able/access_ibm/execbrief.html
|