DRAFT

Najjar, L. J. (2005). Accessibility guidelines for Java software applications. Unpublished manuscript.

Accessibility Guidelines for Java Software Applications

Lawrence J. Najjar, Ph.D.August, 2007

Section 508 of the Rehabilitation Act Amendments of 1998 are regulations that require the U.S. government to purchase only software that allows “Federal employees with disabilities to have access to and use of information and data that is comparable to the access to and use of information and data by Federal employees who are not individuals with disabilities” (General Services Administration).

The Federal accessibility requirements are spreading to U.S. state government procurements (Paciello, 2004; Williams, 2001). Other countries and international organizations are also developing accessibility requirements (Centro Nazionale per l’Informatica nella Pubblica Amministrazione, 2004; Commonwealth of Australia, 2003; European Union, 2003; Department of the Taoiseach, 1999; International Organization for Standardization, 2003; New Zealand E-government, 2003; Treasury Board of Canada, 2002).

So, to sell software applications to governments, we must make the applications accessible. To get a competitive advantage when selling applications to commercial customers, we should make our applications accessible.

Technology RequirementsThis document describes requirements that make software applications more accessible. In particular, I focus on software applications that run in Java.

By itself, Java is not accessible. To make Java more accessible, you need to use

Java 2 platform Java foundation classes “Swing” user interface components Java Accessibility Application Program Interface (JAAPI).

Assistive technologies (such as screen readers and screen magnifiers) allow people with certain disabilities (such as people with visual challenges) to use Java applications. To allow assistive technologies to get to Java applications running on Microsoft Windows, the assistive technology users need to install Java Access Bridge for Windows 1.1. Java Access Bridge is available at http://java.sun.com/products/accessbridge/.

1

DRAFT

Section 508 RequirementsThis document lists each of the Section 508 requirements for software applications. The Section 508 requirements are in three major categories:

Software applications and operating systems Functional performance criteria Information, documentation, and support.

After each requirement we provide specific techniques for meeting the requirement.

These requirements are for software applications only. There are separate Section 508 accessibility requirements for Web applications.

§ 1194.21 Software applications and operating systems.

“(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.”

Users who cannot see must use the keyboard because they cannot see where a mouse cursor is pointing. Users who have challenges moving their hands or making small, controlled hand movements (for example, due to muscle tremors) cannot use a mouse. Instead, these users often operate only the keyboard when using software applications.

[Requirement] Except for the tasks described in the second paragraph below, make all application functions available to users who can operate only a keyboard.

Provide keyboard alternatives when the function (for example, rotate figure in a graphics application) or the result of performing a function (for example, save file confirmation) can be discerned textually by the user. For example, provide keyboard alternatives for menu functions in common drawing programs that allow users to Open, Save, Re-size, Rotate, and perform other actions on a graphic image. The application displays these functions using text and users discern the result of performing the functions using text.

It is not necessary to provide keyboard alternatives for tasks that require precise mouse movements that cannot be discerned textually by users without user interface designers providing lengthy descriptions. For example, it is not necessary to provide keyboard alternatives for tasks that allow users to create an

2

DRAFT

image by selecting a paintbrush (which would require lengthy text to describe each paintbrush), picking a color, and actually drawing a design (which would require lengthy text to describe position on screen, cursor movements, resulting shape, etc.).

It is impossible or very difficult for users who cannot see or users who have low vision (poor vision) to perform drag and drop functions. Blind users cannot see the mouse cursor or the object being dragged. Low vision users operating screen magnifiers see a small portion of the computer screen at one time and have trouble locating the target to which to drag objects. Users with muscular control challenges such as tremors cannot use a mouse.

[Requirement] Provide keyboard alternatives for drag and drop functions.

Keyboard OperationsAllow users to operate only the keyboard to perform all functions. The generally accepted keyboard functions for Java applications are in “Appendix A: Keyboard Operations.” [insert anchor link]

Here are some examples of keyboard operations that are listed in “Appendix A: Keyboard Operations.”

Allow users to press the keyboard “Tab” key, “Shift-Tab” keys, up arrow key, down arrow key, space bar key, and “Enter” key to move to functions, move to choices, select choices, de-select choices, and submit functions and choices.

Define a tabbing order that makes sense to users. Start the focus at the top-left corner of the content area of the window. When users press the “Tab” key, move the focus right and down to the main functions on the window. Allow users to press “Shift” and “Tab” simultaneously to move backward through the tabbing order.

To move between the choices in a set of related check boxes, radio buttons or choices in a list box, combo box, or spin box, allow users to press the up arrow and down arrow.

Allow users to press the “F10” key to move to the menu bar (“File,” “Edit,” “View”) at the top of an application window. When the focus is in the menu bar, allow users to press the “Tab,” “Shift-Tab,” and right and left arrow buttons to move between menu bar choices (for example, “File, “Edit,” “View”). When the focus is on a menu bar menu, allow users to press the down arrow or up arrow to open the menu bar menu. When a menu bar menu is open, allow users to press the right arrow and left arrow to move between and open menu bar menus. Allow users to press the “Esc” key to close an open menu bar menu.

Allow users to press “Ctrl-F6” to move forward through open result views in the application.

3

DRAFT

Allow users to press “Shift-Ctrl-F6” to move backward through open result views in the application.

Allow users to press “F6” to move between split panes in a result view. Allow users to press “Shift-F10” to show the contextual menu for the

object on which the focus is positioned. Allow users to press “Ctrl-spacebar” to show the contextual menu for the

active window. Allow users to press “Ctrl-F4” to close an internal window (primary

window) that has the focus. Allow users to press “Ctrl-F9” to minimize an internal window. Allow users to press “Ctrl-Esc,” “Ctrl-Tab,” “Shift-Esc,” and “Shift-Tab” to

move first between open internal windows, then among minimized internal windows.

Allow users to press “Ctrl-F5,” “Enter,” or “Return” to open a minimized internal window (primary window) that has the focus.

[Requirement] Provide a tabbing order that makes sense to the user, such as moving the focus from the top-left of the window to the bottom-right of the window.

On forms that include instructions, be sure to include a tab stop for the instructions. That way, when the popular JAWS screen reader is in “forms” mode, users can hear the instructions for completing the form.

The application usually indicates the focus by putting a box around the object that has the focus. Allow users to tab to move the focus between every group of related components (such as a group of related radio buttons) and to use the up and down arrow buttons to move the focus within a group of related components. For components that are not in related groups, allow users to tab between the components.

Allow users to press the spacebar to select a choice and the “Enter” key to perform the default action on the window (for example, activate the “OK” button on a dialog window).

The initial focus is the starting point for the tabbing order on a window. A good place to place the initial focus is the top, left user interface component in the content area of a window (so not the menu bar).

[Requirement] Define initial focus for the first logical component on every window.

Users with accessibility challenges are likely to make input errors. It is also much more difficult, frustrating, and time-consuming for these users to correct an input error.

4

DRAFT

[Suggestion] Provide an easy way for users to undo at least the most recent user action.

Mnemonics [insert header level]Mnemonics (also know as “access keys”) are single, underlined alphanumeric characters that appear on textual user interface controls such as menu bar menus (for example, “File”), menu choices, toolbar button labels, radio buttons, check boxes, and toggle buttons (for example, ruler units in “in” or “cm”). Users activate mnemonics by pressing and holding down the “Alt” key, then pressing the mnemonic key (for example, Alt-f to open the File menu bar menu).

[replace or delete images and update Figure numbers]When users press and hold down the “Alt” key and press the key for the mnemonic character, the focus moves to the control with the mnemonic and usually activates the control. For example, to access the “File” menu bar item, users press “Alt-f.” The “File” menu opens and the focus appears on the first item in the opened menu.

[Note] If the same mnemonic (for example, f) appears in an active result view or secondary (dialog) window and the application menu bar, then Alt-f goes to the active result view or secondary (dialog) window rather than to the application menu bar. To move to the function in the application menu bar, users can press the F10 key. In an active secondary (dialog) window, mnemonics only work in the secondary window; the mnemonics don’t activate functions in the application menu bar or result views.

[Requirement] With one exception, provide a mnemonic for each menu bar item, choice in menu bar menus, and secondary (dialog) window component in your application.

In general, as shown in Figure 1, to move the focus to an entry field in a secondary (dialog) window, assign a mnemonic to the entry field label. When users activate the mnemonic, move the focus to the entry field.

Figure 1. When users press “Alt-n,” keyboard cursor appears in related text entry field.

The exception is when a component has a text label that conflicts with another component. For example, as shown in Figure 2, when a radio button has an associated entry field, it is not clear whether the mnemonic should select the

5

DRAFT

radio button or move the keyboard cursor to the entry field. In this case, assign the mnemonic to the first component (the radio button) and provide a tab stop to the second component (the entry field).

Figure 2. When users press “Alt-q,” focus goes to “Quarterly Growth” radio button. To move to related text entry field, users press “Tab” key.

You can create mnemonics for controls that are labeled with graphical languages, such as Kanji, that run on a standard keyboard. Add a roman character to the end of the graphical control label and make it a mnemonic.

Design unique mnemonics in each secondary (dialog) window. If you must re-use a mnemonic in a secondary window, (for example, use Alt-d twice in the same secondary window), design the mnemonic so that it moves between each of the controls but does not activate either control. In this case, users press the spacebar to activate the control.

If a long list of related radio buttons or check boxes prevents you from providing a unique mnemonic for every component in a secondary (dialog) window, then use one mnemonic to move the focus to the first component in the related group of radio buttons or check boxes, then use the up and down arrow keys to move the focus within the group of related radio buttons or check boxes.

You can re-use mnemonics in different contexts that don’t conflict functionally. For example, you can use Alt-f in both the application menu bar (as in “File) and in a secondary (dialog) window (as in “Print to File”). These sections of the user interface don’t conflict functionally because only one of them (the secondary window or the application window) is active at any time.

As another example, when you use Alt-f to open the “File” menu bar menu, you show a list of commands that users can activate from the open menu by pressing various alphanumeric keys (for example “n,” “u,” “p,” “x”). Since they don’t conflict functionally, you can re-use these alphanumeric keys as mnemonics in other menus, such as the “Edit,” “View,” and “Tools” menus.

I suggest that you reserve the following mnemonics for the application menu bar. Do not use these mnemonics in result views. However, you can use these mnemonics in secondary (dialog) windows.

6

DRAFT

Table 1.   Suggested Alt Mnemonics Reserved for Menu Bar

Letter Menu

A Action (Alt-A)

E Edit (Alt-E)

F File (Alt-F)

H Help (Alt-H)

T Tools (Alt-T)

V View (Alt-V)

W Window (Alt-W)

Where it makes sense for the user, you may design the mnemonic to activate the control with the mnemonic, but move the focus back to its prior position. For example, if users position the focus onto a row in a list box, then selects the mnemonic to activate a button command (for example, “Copy,” “Edit,” “Delete”), you can move the focus from the button back to the row in the list box.

[Requirement] Do not require users to enter capital letters to activate a mnemonic.

[Requirement] Do not provide mnemonics for “OK” (or the default button) and “Cancel” buttons in a secondary (dialog) window. Instead, for “OK” (or the default button) use the “Enter” key. For “Cancel” use the “Esc” key.

[Note] If you do not use “OK” and “Cancel” buttons (for example, use “Yes,” “No,” and “Cancel” in a confirmation window), make sure the default button (the button activated when users press the “Enter” key) is not destructive. So, for example, make the “No” button the default button in a delete confirmation window.

[Requirement] If users very frequently operate some user interface components on a primary (main) window, then provide mnemonics for the very frequently used components.

Use the following rules to define mnemonics (from Sun’s Java Look and Feel Design Guidelines (Second Edition) at http://java.sun.com/products/jlf/ed2/book/index.html) and Microsoft Official Guidelines for User Interface Developers and Designers at

7

DRAFT

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/appxB.asp.

1. Use the common mnemonics in the following tables.

Table 2.   Alphabetical List of Common Mnemonics 

Letter Menu Items

A Select All (Edit menu), Save As (File menu), About Application (Help menu), About, Always on Top, Apply

B Bold (Format menu), Back, Browse

C Copy (Edit menu), Close (File menu), Align Center (Format menu), Contents (Help menu)

D Delete (Edit menu), Details (View menu)

E Edit (for example, Edit menu or Edit button), Explore

F File menu, Find (Edit menu), Filter (View menu), Font, Forward

G Large Icons (View menu)

H Help (for example, Help menu Help button), Hide

I Index (Help menu), Italic (Format menu), Insert, Properties

L Align Left (Format menu), List (View menu), Link Here

M Small Icons (View menu), Move

N Find Again (Edit menu), New (File menu), Minimize, Send To, No, Next

O Open (File menu), Zoom Out (View menu), Insert Object, Options

P Paste (Edit menu), Print (File menu), Pause, Split

R Format menu, Redo (Edit menu), Align Right (Format menu), Refresh (View menu), Repeat, Restore, Resume, Retry, Run

S Save (File menu), Search (Help menu), Sort By (View menu), Show, Size, Stop

T Cut (Edit menu), Tutorial (Help menu), Tools

U Undo (Edit menu), Page Setup (File menu), Underline (Format menu)

V View menu

W Window

8

DRAFT

Y Yes

X Exit (File menu), Maximize

Z Zoom In (View menu)

Table 3.   Common Mnemonics (Organized by Menu)

Menu Titles Menu Items

File New, Open, Close, Save, Save As, Page Setup, Print, Exit

Edit Undo, Redo, Cut, Copy, Paste, Delete, Find, Find Again, Select All

Format Font, Style, Size, Bold, Italic, Underline, Align Left, Align Center, Align Right

View Large Icons, Small Icons, List, Details, Sort By, Filter, Zoom In, Zoom Out, Refresh

Help Contents, Tutorial, Index, Search, About Application

2. Use the first letter of the label for the control, unless another letter provides a better mnemonic association.

3. Use a distinctive consonant in the label.4. Use a vowel in the label.

[Requirement] To facilitate localization, put Java mnemonics in resource bundles.

[Note] To reduce visual clutter in Microsoft Windows 2000, Microsoft designed the keyboard mnemonics so the menu bar mnemonics only appear when users press the “Alt” key.

[Note]  When you create a mnemonic, Java assigns it to the first instance of the alphanumeric character in the text string. So, if you assign the mnemonic “a” to “Save As” it appears as “Save As” rather than “Save As.”

Shortcut Keys [create secondary header]Shortcut keys allow users to press “Ctrl” (usually) and another alphanumeric key (for example, “Ctrl” and “c”) to perform a very frequent menu bar action, even if the menu is not open. Shortcut keys perform the menu bar action regardless of the location of the focus. Shortcut keys perform the menu bar action without

9

DRAFT

opening the menu bar. Figure 3 shows shortcut keys in an “Edit” menu bar menu.

Figure 3. Shortcut keys in an Edit menu bar menu.

[Requirement] Do not use capital letters with shortcut keys.

To operate a shortcut key, allow users to press and hold down the “Ctrl” key and a single alphabetic key. For example, to copy an object, users select the object, then users press “Ctrl” and “c.” Since they are difficult for users to press, do not use multiple alphabetic keys in a shortcut.

Some shortcut keys use “Shift’ instead of “Ctrl.” A few rare shortcut keys use a direct key (such as “Delete” or “F1”) instead of an alphanumeric character (see the tables below).

[Requirement] Do not use “Alt” as a shortcut key.

“Alt” is used for mnemonics (for example, “Alt-f” opens the “File” menu bar menu). Many ALT+key combinations (such as ALT+TAB, ALT+ESC, and ALT+SPACEBAR) are reserved for system use.

Here is a list of common shortcut keys from Sun’s Java Look and Feel Design Guidelines (Second Edition) at http://java.sun.com/products/jlf/ed2/book/index.html and Microsoft Official Guidelines for User Interface Developers and Designers at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/appxB.asp.

10

DRAFT

Table 4.   Alphabetical List of Common Keyboard Shortcuts 

Sequence Equivalent

Alt+Enter Display property sheet for selected object

Alt+Esc Display next window

Alt+F4 Close active window

Alt+F6 Switch to next window within application (between modeless secondary windows and their primary window)

Alt+Print Screen Capture active window image to the Clipboard

Alt+Tab Display next primary window

Ctrl+A Select All

Ctrl+Alt+Delete Reserved for system use

Ctrl+B Bold

Ctrl+C Copy

Ctrl+E Align Center

Ctrl+Esc Access Start button on the taskbar

Ctrl+F Find

Ctrl+F6 Display next child window (Multiple Document Interface (MDI))

Ctrl+G Find Again

Ctrl+H Replace

Ctrl+Home In a text field, moves cursor to beginning of the text

Ctrl+I Italic

Ctrl+L Align Left

Ctrl+N New

Ctrl+O Open

Ctrl+P Print

11

DRAFT

Ctrl+R Align Right

Ctrl+S Save

Ctrl+Tab Display next tabbed page or child window (MDI)

Ctrl+U Underline

Ctrl+V Paste

Ctrl+W Close

Ctrl+X Cut

Ctrl+Y Redo

Ctrl+Z Undo

Delete Delete (Edit menu)

Esc Cancel, stop a function in process

F1 Help

F5 Refresh

Print Screen Capture desktop image to the Clipboard

Shift+Alt+Esc Display prior window

Shift+Alt+F6 Switch to prior window within application (between modeless secondary windows and their primary window)

Shift+Alt+Tab Display prior primary window

Shift+F1 Contextual help

SpacebarSelect (same as primary mouse button click) (if the focus is on a text entry component (such as a text entry field), then use Ctrl+Spacebar)

Combo Boxes [insert secondary header]Allow users to keep control. Do not process each choice in a combo box as users move over it with the keyboard. This technique causes unexpected changes in the user interface (such as new windows) and slows user interface response time.

12

DRAFT

Instead, allow users to press the keyboard up and down arrow keys to move up and down the list of choices in a combo box. Process a choice only after keyboard users position the focus on a choice and press the Enter key. Or, process a choice only after keyboard users position the focus on a choice, press the Enter key, then select a button (for example, Go, Submit, Enter, Next >).

[Requirement] In combo boxes, do not process a choice until users select a choice or until users select a choice and select a button to submit the choice.

Tool Tips[insert secondary header]To view a tool tip, users must be able to see and to use a mouse. So, by default, tool tips are not available to blind users who operate screen readers and keyboards. Since tool tips automatically close after four seconds, tool tips can be a challenge for users with cognitive challenges or users for whom the language in the application (such as English) is not their first language. For example, users who were born deaf to English speaking parents probably learned sign language as their first language and English as their second language.

[Requirement] Provide simple, alternative, accessible ways for users to access the text that is in a tool tip.

For a graphic (such as a toolbar button) that has a tool tip, provide an alternative text label that assistive technologies (such as screen readers) can read.

For an object such as a line of data in a table, you can provide tool tip text as a button or hyperlink labeled “Details,” “Summary,” or “Status.”

For other objects (such as databases in a navigation pane tree), you can provide tool tip text using the “Action” menu bar choice. When users select an object, the choices in the right-click contextual menu also appear in the “Action” menu. Include in the contextual menu (and automatically in the “Action” menu) a choice for “Show Details” or “Show Summary.” When users select “Show Details” or “Show Summary,” provide a secondary (dialog) informational window that shows the tool tip text or more detailed information for the object.

Help[insert secondary header]In most online help, we describe mouse techniques for performing functions (for example, “To open the contextual menu, right-click on the item”). However, users who operate only keyboards also need help. Keyboard users may have no idea which key or key combinations to press to perform a function.

In addition to providing help that describes mouse techniques for performing functions, always describe keyboard techniques for performing the functions. So, change “To open the contextual menu, right-click on the item” to “To open the

13

DRAFT

contextual menu, right-click on the item or move focus to the item and press Shift-F10.”

Also, avoid writing mouse-centric help. Instead of writing “Click on the Help button” use “Select the Help button.” Mouse and keyboard users know how to select objects.

[Requirement] When users perform an application function, display the results using at least text.

When you display the results textually, then users who operate assistive technologies (for example, screen readers, refreshable Braille displays) can perceive the results. So, for example, do not change only the color of an object as the result of a user action. Change the color and provide appropriate text.

Messages[insert secondary header]If you send important user interaction feedback messages (for example, warnings or errors) only to an application’s message’s window, then there is a good chance that many users will not perceive the messages. Users may choose to close the messages window. Users who can see may not notice a new message in the messages window. Users who cannot see do not know when a new message appears in the messages window.

User interaction feedback messages give users feedback on their interactions with the application. A sample user interaction feedback message might be “Error. Invalid data.” For improved accessibility and usability, rather than sending user interaction feedback messages only to an applications’ messages window, display the user interaction messages in a secondary (dialog) window that gets the focus. That way, users of screen readers will get notified of the message and can read the message. Send less important system messages (for example, “Database tool [x] is loaded”) to only the application’s messages window.

“(b) Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer.”

14

DRAFT

[Requirement] Do not disrupt or disable accessibility features developed and documented using industry standards that users turned on in other running applications.

Application accessibility features may include larger font sizes, tabular versions of information in graphs, alternative colors, keyboard operations, and captions for animations and movies. Make sure that your application does not affect the accessibility features in other applications that users turned on and are currently running.

[Requirement] Do not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer.

Operating system accessibility features may include changing the color scheme (to assist people with low vision), increasing the font size, showing a visual cue (such as flashing a window’s title bar) when an error tone is sounded (to assist persons who are deaf or hard of hearing), or providing "sticky keys" that allow users to press key combinations (such as Control-c) sequentially rather than simultaneously (to assist persons with dexterity challenges). In Windows 2000, you can turn on accessibility features by going to Start > Settings > Control Panel > Accessibility Options and Start > Programs > Accessories > Accessibility.

Make sure that your application does not affect the operating system accessibility features that users turned on and are currently running. Figure 4 shows the accessibility options in Windows 2000. Figure 5 shows the “Display” tab accessibility options.

15

DRAFT

Figure 4. Accessibility options in Windows 2000.

16

DRAFT

Figure 5. Accessibility display settings in Windows 2000.

"(c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.”

The focus shows users where an action will occur when users press keyboard keys or click mouse buttons. A dashed rectangle is a good focus visual indicator.

[Requirement] Provide obvious visual indicators for the current focus.

[Requirement] Programmatically expose the focus so that assistive technologies, such as screen readers and voice recognition applications, can track focus and focus changes.

When users move focus out of a window, then back into the window, it can be difficult for users to find and move focus to the object that had focus originally.

[Requirement] When users move focus back to a window, put the focus on the object that last had the focus.

17

DRAFT

“(d) Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text.”

For assistive technology to work well, the information technology must have access to the information about an application’s user interface controls. With this access, assistive technology can tell users the existence, location, and status of user interface controls. User interface controls include entry field labels, entry fields, checkboxes, radio buttons, toolbar buttons, and command buttons.

Some objects do not include static text (for example, text entry fields). Create and associate textual labels with these objects. In particular, always associate text fields with their labels (use the setLabelFor() method to associate the label with the text field).

Users with vision challenges may find it difficult to differentiate entry field labels from instructions, section titles, or other read-only text.

[Requirement] To help screen reader users associate an entry field label with its corresponding entry field, end each entry field label with a colon.

Figure 6 shows a colon at the end of an entry field label.

Figure 6. End each entry field label with a colon.

Provide information that allows users of assistive technology to receive information, enter information, and submit commands.

[Requirement] Make available to assistive technologies, such as screen readers and voice recognition applications, helpful information about each user interface element including the identity, operation, and state (for example, “checked” for a checkbox, “vertical” for a scroll bar) of the user interface element.

18

DRAFT

By default, screen readers do not read font style (for example, bold, italic) or font size. Users of screen readers will not usually get font style or size information for the text being read by the screen reader.

Users of screen magnifiers may not be able to tell that a font or font size changed.

[Requirement] Do not use changes in font or font size to convey information, indicate an action, prompt a response, or distinguish a visual element.

If you use a graphic to show a user interface function (such as a toolbar button icon) or essential information (such as a required field or current system status), provide an alternative text label that assistive technologies such as screen readers can read. You do not have to provide textual alternatives for graphics that are purely decorative or provide visual separation (for example, horizontal lines that separate groups of user interface controls).

Figure 7 shows the alternative text for a graphic being used redundantly as a tool tip.

Figure 7. Alternative text label for required entry identifier graphic.

[Requirement] Provide textual alternatives for graphics that provide user interface functions.

To accommodate users who cannot see or cannot see well, provide an option for users to view graphical information via text. So, provide an option for users to see bar charts, line graphs, pie charts, gauges and other graphical information in a table with a table label, column labels, row labels, and, if possible, an interpretation (for example, “Required memory increasing at approximately 21% per month over past seven months. Predict available memory will be exhausted in September, 2008.”) (Willuhn et al., 2003, Figure 3). Design the table so that for each cell, screen readers read the row header, column header, then the information in the cell.

[Requirement] Provide textual alternatives for information that is presented graphically such as bar charts, line graphs, pie charts, and gauges.

19

DRAFT

Users with visual challenges cannot easily identify the row header and column header that uniquely define each cell in a table. As a result, it is difficult for users with visual challenges to understand the meaning of information that is in a table cell. So, for each cell in a table, provide information that allows a screen reader to read the row, column, and cell contents. [Requirement] For each cell in a table, provide to screen readers the row header and column header with the information in the table cell (for example, in a body mass index table, “Row Height 5 feet 9 inches, column Weight 155, cell 22.9”).

To identify the object or section of the user interface in which they are working, users of screen readers and screen magnifiers need textual labels. Labels also help users with cognitive challenges and learning disabilities.

So, provide a textual label for each window in the user interface, each pane in the user interface, each table in a window, each row and column in a table, and each control. You do not need to provide labels for objects that are not functional, such as purely decorative graphics or horizontal lines that serve as visual separators.

[Requirement] Provide a textual label for every window, pane, table, and control in the user interface.

[Suggestion] If several user interface controls have a logical association, group the controls together and label the group with a helpful name.

“(e) When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application's performance.”

Most screen readers, such as JAWS, allow users to assign a textual name to a graphic (for example, icon, status indicator). If the function of the graphic changes, then users will get confused. Users with low vision, learning challenges (such as dyslexia), or other cognitive challenges benefit from consistent graphics. So, if you assign a function or meaning to a graphic, keep the same function or meaning throughout the application.

[Requirement] For graphics that provide application functions (such as icons) or information (such as status indicators), always use the same graphic for the same function or information.

20

DRAFT

“(f) Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes.”

Assistive technologies, such as screen readers, use operating system functions to access textual information for the user. Usually, this is not a problem because most application developers use the standard protocols of the operating system to display textual information. However, if application developers do not use the operating system to display textual information, then assistive technologies users may not be able to access the textual information.

You can create innovative ways to display textual information. Just be sure to also use the operating system to display the textual information, including text content, text input caret location, and text attributes.

[Requirement] Use operating system functions to display textual information including text content, text input caret location, and text attributes.

“(g) Applications shall not override user selected contrast and color selections and other individual display attributes.”

Users with visual challenges may take advantage of system-wide accessibility features offered by popular operating systems. To make applications easier to use, low vision users may change contrast (for example, high contrast black text on white background or low contrast black text on slate blue background), change the color scheme (for example, yellow text on black background), or increase the font size. In Windows 2000, you can turn on display accessibility features by going to Start > Settings > Control Panel > Accessibility Options and Start > Programs > Accessories > Accessibility > Display.

Design your application so that it does not override system-wide display options selected by the user.

[Requirement] Do not override display attributes, such as contrast and color, selected by the user.

“(h) When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user.”

21

DRAFT

Animations include automatically rapidly changing text (such as ticker text that automatically scrolls across the bottom of a page), graphics (such as animated real-time status data on a bar chart), and icons (such as a clock with moving hands to show a request is being processed). For users with certain cognitive challenges, animations are extremely distracting and the rapid visual changes are hard to comprehend. For blind users of screen reader software, animations are impossible to perceive.

So, generally avoid the use of animations in your applications. If you do provide animations, include a user selectable textual alternative way to present the animated information. Ideally, do not require users to perform an extra action to show the textual alternative (for example, for a request-being-processed icon, create a message dialog window that includes a static request-being-processed icon and “Request being processed” text).

Give users with cognitive challenges or users who are not familiar with the language a chance to process the information more slowly.

[Requirement] If you use animations, allow users to display the same information in a non-animated way, preferably via text.

[Suggestion] Provide a way for users to stop any animation.

“(i) Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.”

When you use color as the only way to communicate information, you make it difficult or impossible for users with low vision, no vision, or color deficiencies to perceive the information. Users who cannot see have difficult challenges with color-coded information because screen readers cannot read color.

Use color to enhance the user interface. For example, use color to help users notice and identify important information. But be sure to use color coding with another redundant communication technique such as text.

The use of color in graphical charts is a particular challenge. Differentiate lines in a line graph by using different line styles (for example, solid, dotted, dashed). Differentiate bars in a bar graph and pie slices in a pie chart by using different background patterns (for example, angled lines, cross-hatched lines).

22

DRAFT

Figure 8. Line graph with line style, color, and labels to differentiate lines.

Figure 9. Bar graph with line style, color, and labels to differentiate bars.

23

DRAFT

Figure 10. Pie chart with line style, color, and labels to differentiate pie slices.

[Requirement] Do not use color as the only way to communicate information, show an action, request a response, or distinguish a visual element.

“(j) When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided.”

Some users with visual challenges need high contrast displays. Other users with visual challenges have trouble with high contrast displays because bright backgrounds (such as white) wash out foreground text. Finally, since they have trouble perceiving colors, users with color deficiencies may use contrast differences to help differentiate colors.

So, users need to be able to change colors and the colors need to use a range of contrasts. Most major operating systems allow users to change colors and contrasts. For example, as shown in Figure 11, Windows 2000 allows users to change color settings by going to Start > Settings > Control Panel > Display >

24

DRAFT

Appearance. The operating system shows the new color and contrast settings system-wide, including all applications.

In general, allow users to change color and contrast settings via the operating system. If you need to allow users to change color and contrast settings only for your application (for example, to change color settings for a graph), then provide a variety of color settings that use a range of contrast levels.

[Requirement] If you allow users to change the color and contrast settings in your application, provide several color selections that use a range of contrast.

Figure 11. Changing displayed color and contrast in Windows 2000.

“(k) Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz.”

25

DRAFT

Bright, flashing objects or rapidly changing geometric patterns are annoying and can trigger seizures in some people. In particular, photosensitive epileptic seizures can occur when a very small proportion of epileptics (about 3%) looks at flashing lights or flickering images (Epilepsy.com, 2004a, 2004c). These flashing images can occur on computer displays, video games, and televisions (Carmant & Seshia; Epilepsy.com, 2004b; Epilepsy Action; Ishida et al, 1998; National Institute of Neurological Disorders and Stroke, 2004; Takahashi & Fujiwara, 2004). Photosensitive seizures seem to be triggered when the flickering images cause abnormal signals to be sent from the retina to the brain. These abnormal signals cause the nerve cells to fire at much higher rates producing seizures such as involuntary body movements and short periods of frozen staring.

Do not use flashing objects or rapidly changing geometric shapes in your user interface.

[Requirement] Do not blink any objects, including text, at a frequency between 2 Hz and 55 Hz.

“(l) When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.”

Assistive technologies, such as screen readers, may respond in unpredictable ways to electronic forms. Design your electronic forms to work well with assistive technologies. As described elsewhere in this document:

Provide mnemonics for all user interface controls that appear in a secondary (dialog) window.

Locate entry field labels very close to their related entry fields. Generally, put entry field labels to the left of entry fields.

To differentiate field labels from read-only text (such as section titles or instructions), put a colon at the end of each field label.

Provide a tabbing order on each window that makes sense to the user. Allow users to tab between controls. But in a group of related controls

(such as a long list of related check boxes or radio buttons or choices in a list box, combo box, or spin box) allow users to press the up arrow and down arrow buttons to move between choices.

Define an initial focus on each window. Show focus on each control. Expose focus programmatically so assistive technologies (such as screen

readers, screen magnifiers, and voice recognition applications) can use the focus.

Provide textual labels for all user interface controls.

26

DRAFT

Make available to assistive technologies helpful information about a user interface element including the identity, operation, and state of the user interface element.

Identify required inputs by using a graphical black asterisk and the alternative “Required” text.

Identify missed required inputs (for example, an entry field users did not fill in before submitting the window) by using a graphical red asterisk and the alternative “Check this required input” text.

[Requirement] Design the user interface of electronic forms (for example, dialog windows, results panes) so that users of assistive technology can access the directions, cues, information, field elements, and functionality needed to complete and submit the form.

To prevent errors, use hints to tell users what to type or select. Make it easy for users with accessibility challenges to identify and use the hints.

[Requirement] Place a hint (for example, (mm/dd/yyyy)) below and left-aligned with the object needing a hint. Place the hint in parentheses. Use a smaller black font (about 2 font points smaller than the label font) for the hint. So, if the label font uses Tahoma 11 point, then use Tahoma 9 point for the hint. Figure 12 shows the format to use for a entry field that needs a hint. Use this same format for other user interface elements that may need hints, such as check boxes and radio buttons.

Figure 12. Format for hint. Place hint below and left-aligned with object needing hint. Use slightly smaller font for hint.

[Requirement] Write your code so that the screen reader reads the hint before users have to enter information or make a choice.

For an entry field with a hint, write your code so that the screen reader reads the user interface elements in the following order:

1. Entry field label2. Hint3. Entry field.

27

DRAFT

Note that the screen reader reads the user interface elements in a different order than the screen shows the user interface elements. Do not force the screen reader to read the same hint two times for one entry field.

§ 1194.31 Functional performance criteria.

“(a) At least one mode of operation and information retrieval that does not require user vision shall be provided, or support for assistive technology used by people who are blind or visually impaired shall be provided.”

The assistive technology that is most popular for software users with visual challenges is the screen reader. The most popular screen reader among users with visual challenges is JAWS. JAWS is also the only popular screen reader that works with Java applications. JAWS Professional is available from Freedom Scientific at http://www.freedomscientific.com/fs_products/software_jaws.asp.

Make sure that your application is both accessible and usable by users with visual challenges. Use familiar accessibility conventions (for example, JAWS key commands). Use accessible interaction techniques that are simple and obvious. If you must use unique key combinations, document them in the accessibility sections of the online help and the user guide.

Ideally, ask representative users who are blind or visually impaired to perform typical tasks with your application using JAWS. Ask these users to give you feedback on accessibility and usability. Include tasks such as installing the application, opening the application, customizing the application, using the application (including retrieving information), reading product support documentation, and contacting customer support for assistance.

[Requirement] Test every window and every function to confirm that JAWS users can perform all application functions.

“(b) At least one mode of operation and information retrieval that does not require visual acuity greater than 20/70 shall be provided in audio and enlarged print output working together or independently, or support for assistive technology used by people who are visually impaired shall be provided.”

The assistive technology that is most popular for software users who can see, but not well (“low vision”) is the screen magnifier. The most popular screen

28

DRAFT

magnifier among users with low vision is ZoomText. ZoomText Magnifier is available from AI Squared at http://www.aisquared.com/Products/Products.htm.

[Requirement] Test every window and every function to confirm that ZoomText users can see all user interface controls and perform all application functions.

Make sure your application works well with ZoomText. Ideally, ask representative users who have low vision to perform typical tasks with your application using ZoomText. Ask these users to give you feedback on accessibility and usability. Include tasks such as installing the application, opening the application, customizing the application, using the application (including retrieving information), reading product support documentation, and contacting customer support for assistance.

“(c) At least one mode of operation and information retrieval that does not require user hearing shall be provided, or support for assistive technology used by people who are deaf or hard of hearing shall be provided. “

The Windows operating system provides settings to support users with hearing challenges. Turn on the Windows SoundSentry visual warning accessibility option. In Windows 2000, it is available by going to Start > Settings > Control Panel > Accessibility Options > Sound. Make sure that the Windows SoundSentry visual warning accessibility option works with your application when an error occurs and a tone usually sounds.

[Requirement] Provide at least one mode of operation and information retrieval that does not require user hearing, or provide support for assistive technology used by people who are deaf or hard of hearing.

Make sure all application functions, alerts, and information retrieval tasks are available visually and do not require users to be able to hear. For example, provide textual alternatives for any spoken words.

“(d) Where audio information is important for the use of a product, at least one mode of operation and information retrieval shall be provided in an enhanced auditory fashion, or support for assistive hearing devices shall be provided.”

[Requirement] Do not make audio information important for the use of a product.

29

DRAFT

Do not use sound as the only way to communicate information (for example sounding an auditory alert when users type an alphabetic character in a numeric-only entry field). Users who are deaf cannot hear the auditory alert. Users who cannot see and are using screen readers may not hear the auditory alert over the sound of the screen reader reading the text aloud.

[Requirement] Do not use sound as the only way to communicate information (for example typing an alphabetic character in a numeric-only entry field).

Make sure that the Windows SoundSentry visual warning accessibility option works when an error occurs on a window in your application. In Windows 2000, SoundSentry it is available by going to Start > Settings > Control Panel > Accessibility Options > Sound.

“(e) At least one mode of operation and information retrieval that does not require user speech shall be provided, or support for assistive technology used by people with disabilities shall be provided.”

Some users (such as users who cannot hear or users with cerebral palsy) have challenges speaking clearly. These users cannot use speech recognition to operate a software application.

[Requirement] Do not require user speech to use your application.

“(f) At least one mode of operation and information retrieval that does not require fine motor control or simultaneous actions and that is operable with limited reach and strength shall be provided.“

To select small items, such as a database in a pane navigation tree, users need fine motor control of a mouse. Fine motor control is difficult for users with muscular dystrophy, cerebral palsy, or other physical challenges.

To press several keyboard keys at the same time, such as Ctrl+p, users need to be able to use multiple fingers simultaneously. This is not possible for users who are partially paralyzed and use a mouthstick or head pointer.

To use a mouse and to press multiple keyboard keys simultaneously, users need good reach and strength. Users with muscular wasting diseases such as amyotrophic lateral sclerosis, myasthenia gravis or who have had certain strokes may not be able to perform these tasks.

30

DRAFT

[Requirement] Except for the tasks described in the second paragraph below, make all application functions available to users who can operate only a keyboard.

Provide keyboard alternatives when the function (for example, rotate figure) or the result of performing a function (for example, save file confirmation) can be discerned textually by users. For example, provide keyboard alternatives for menu functions in common drawing programs that allow users to Open, Save, Re-size, Rotate, and perform other actions on a graphic image. The application displays these functions using text and users discern the result of performing the functions using text.

It is not necessary to provide keyboard alternatives for tasks that require precise mouse movements that cannot be discerned textually by users without designers providing lengthy descriptions. For example, it is not necessary to provide keyboard alternatives for tasks that allow users to create an image by selecting a paintbrush (which would require lengthy text to describe each paintbrush), picking a color, and actually drawing a design (which would require lengthy text to describe position on screen, cursor movements, resulting shape, etc.).

Users with muscle weakness or muscle control challenges find it difficult to press several keys simultaneously. One way to address these challenges is to use “sticky keys” that can be pressed sequentially but get received by the applications as being pressed simultaneously.

In Windows 2000, the Windows Sticky Key accessibility option is available at Start > Settings > Control Panel > Accessibility Options > Keyboard.

[Requirement] Confirm that users can perform simultaneous key presses (for example, Ctrl+p) in the application by using the Windows Sticky Key accessibility settings.

Some users with muscle control challenges may have trouble lifting off a key before it starts to repeat. One way to accommodate these users is to change the keyboard settings so the application ignores repeated keystrokes. In Windows 2000, the Filter Keys accessibility option is available at Start > Settings > Control Panel > Accessibility Options > Keyboard.

[Requirement] Confirm that users can cause the application to ignore and slow down the key press repeat rate in the application by using the Windows Filter Key accessibility settings.

§ 1194.41 Information, documentation, and support.

31

DRAFT

“(a) Product support documentation provided to end-users shall be made available in alternate formats upon request, at no additional charge.”

As listed in the Section 508 regulation, the alternate formats may include, but are not limited to “Braille, ASCII text, large print, recorded audio, and electronic formats …” The regulation does not specify acceptable electronic formats, but likely electronic formats include Hypertext Markup Language (HTML), International Committee for Accessible Document Design (ICADD) Standard Generalized Markup Language (SGML), and Rich Text Format (RTF).

Hypertext Markup Language (HTML) is a good format to use for support documentation. Many assistive technologies can read HTML. When requested by US federal governments and some state governments, ask vendors to convert HTML support documentation to most of the alternate formats.

[Requirement] Provide support documentation in HTML.

Avoid using Portable Document Format (PDF) files. Most PDF files are not accessible. You can make accessible PDF files, but you have to use Adobe Acrobat 5 or higher, use a simple structural layout that reads well linearly, convert your text to a tagged format like HTML, create alternative textual descriptions for graphics, link table column and row headers to each table cell, convert the tagged format to PDF, and clean up the tagged PDF. In addition, your users must have Adobe Reader 5.0 or higher and the JAWS or Window Eyes screen readers. JAWS users also have to know to use the JAWS virtual cursor.

To meet the needs of their employees, government customers may ask you to provide support documentation in alternate formats. The Access Board (which interprets and answers questions about Section 508) stated that it is the responsibility of the government agency, not the application vendor, to provide product support documentation in alternate formats (D. Wakefield, personal communication, September 1, 2004). However, as a customer service and at customer request, be prepared to convert product support documentation to alternate formats for government customers’ users with disabilities. One vendor that can convert product support documentation to alternate formats is Braille Plus in Salem, Oregon, USA at http://www.brailleplus.net/.

Currently, there is one situation in which you must provide product support documentation in Braille. Under a regulation called the Braille Bill, some United States state governments (for example, California, Massachusetts, and Texas) require vendors to provide Braille versions of their product support documentation if the product is for an educational institution.

32

DRAFT

“(b) End-users shall have access to a description of the accessibility and compatibility features of products in alternate formats or alternate methods upon request, at no additional charge.”

Users with disabilities need to know the keyboard keys and key combinations to use to perform tasks in your application. This information is especially helpful to users with cognitive challenges such as learning disabilities. Also, since the different applications will use different accessibility keys, users need a list of the accessibility keys for your application.

[Requirement] In the HTML Help and the product support documentation, list “Accessibility” as one of the table of contents and index items.

[Requirement] In the HTML Help and the product support documentation, list the following terms in the index: accessibility, disability, keyboard, shortcut keys.

[Requirement] In the HTML Help, make the following terms searchable: accessibility, disability, keyboard, shortcut keys.

[Requirement] In the “Accessibility” section of the HTML Help and the product support documentation, describe the accessibility features of your application and list the popular assistive technologies with which it is compatible.

For accessibility features, assist keyboard-only users by describing how to use the keyboard to perform typical application functions and how to move around, select items, and perform functions in your application results pane. It might be helpful to provide this information in a table with columns for “Action” and “Keyboard Keys.”

List and describe each of the major panes in your application. Describe how to use the keyboard to move between the major panes.

For example, in an application that has a scope (navigation) pane, provide a table such as this:

Application Pane Navigation TreeAction Keyboard KeysOpen container Right arrowClose container Left arrowMove down navigation tree Down arrowMove up navigation tree Up arrowSelect object in navigation tree Enter keyGet functions for selected object Shift-F10

33

DRAFT

Describe how to use the keyboard to move around, select items, and perform functions in your application results pane. For the application results pane, provide a table such as this:

Results PaneAction Keyboard KeysMove between tabs Right and left arrowMove from a tab to content area Down arrowMove between groups of related user interface controls

Tab and Shift-Tab

Move within a group of related user interface controls

Up arrow, down arrow, left arrow, right arrow

Select radio button or checkbox Space bar

Tell users how, in tables, screen readers read the row header, column header, then value of the cell. Describe how the application uses mnemonics and shortcut keys. Tell readers that the application never users color alone to communicate information. Describe the other accessibility features of your application.

Users with visual challenges can easily get lost in a complex multiple pane user interface. Users with visual challenges need to know where they are, what they can do there, and how to go somewhere else.

[Suggestion] Provide a key or key combination (such as Ctrl-Alt-p) that announces to screen reader users the current location (pane) in which the keyboard cursor sits, the current window (if there can be more than one window in the pane) in which the keyboard cursor sits, the current entry input form (if any), and the current user interface control at which the keyboard cursor sits. Also announce the tasks users can perform in the pane and how to move the keyboard cursor to each of the other panes.

Also describe how to: Customize fonts Customize colors Access alternative descriptions for graphics that can be read by a screen

reader.

Using different versions of the popular assistive technologies, test every window and user interface control to confirm that they are compatible with the assistive technologies. Use the most recent version and the past version or two of the JAWS screen reader, ZoomText screen magnifier, and Dragon NaturallySpeaking Professional Solutions voice recognizer. In the HTML Help and the product support documentation, list each assistive technology tool and

34

DRAFT

version number that you found to be 100% compatible with your application. If you find accessibility exceptions, list them and submit requests to get them fixed.

Some Java applications and JAWS run only on the Windows operating system. Test your application on the accessibility options that come with the Windows operating system. In Windows 2000, you can get to the accessibility options by going to Start > Settings > Control Panel > Accessibility Options and Start > Programs > Accessories > Accessibility. In the HTML Help and the product support documentation, list each Windows operating system (for example, Windows Vista, Windows 2000, Windows XP Home, Windows XP Professional), each accessibility option (for example, Sticky Keys, Sound Sentry, High Contrast), and whether or not you found it to be 100% compatible with your application. If you find accessibility exceptions, list them and submit requests to get them fixed.

“(c) Support services for products shall accommodate the communication needs of end-users with disabilities.“

Users with vision challenges can communicate with customer support representatives by reading e-mail and talking on the telephone. Users with hearing challenges can use e-mail.

In the product and user documentation, provide the customer support telephone number and e-mail address.

[Requirement] Provide customer support services via telephone and e-mail.

Other Accessibility SuggestionsThe following accessibility suggestions are not in the Section 508 requirements for software applications. However, these suggestions will make your software application more accessible to your users.

Multimedia offers a very exciting user interface and can be a very effective way to communicate information (Najjar, 2001). However, multimedia creates accessibility challenges for our users. For example, a video with audio presents challenges to people who cannot see or cannot hear.

[Suggestion] Provide accessible equivalent alternatives for information that you present using multimedia.

Provide textual captions for videos. Provide textual versions of audio files. For Powerpoint presentation files, provide textual descriptions of graphics.

35

DRAFT

Users benefit when the equivalent alternatives are synchronized with the multimedia presentation. For example, to allow users with hearing challenges to see the speaker’s body language while the users read the video captions, synchronize the captions with the video.

[Suggestion] For multimedia information, synchronize the equivalent alternatives with the presentation.

Sometimes applications require users to enter a response within a certain period of time. For example, an automated teller machine (ATM) will give you a limited amount of time to enter your personal identification number (PIN). If you don’t enter the PIN within the allotted time, the ATM will return your ATM card and cancel the sign-in process. Users with physical or cognitive challenges may not be able to enter information within a certain period of time. It takes longer for users with no vision or low vision to become aware of and understand a dialog box with a timed response. Users with learning and language challenges need more time to understand information and instructions.

[Suggestion] Avoid requiring users to enter a response within a certain period of time.

[Suggestion] If your application must require users to enter a response within a certain period of time, alert users and give sufficient time for users to indicate they need more time.

When you use standard user interface controls, assistive technologies (such as screen readers) can usually identify the name of each user interface control and the actions users take to operate the control. Users of screen magnifiers can also find and operate functions more easily when the user interface controls are familiar.

However, when you use non-standard user interface controls (such as hyperbolic tree viewers), assistive technologies may not be able to identify control names and functions. Screen magnifier users may not be able to find and use unfamiliar controls and functions. Users with disabilities may not be able to operate non-standard user interface controls.

[Suggestion] Do not use non-standard user interface controls.

If you show a patterned background behind text or functional graphics, you make it more difficult for users with certain disabilities to perceive the text or graphics. Users with low vision need high clarity and contrast. For users with color deficiencies, text or graphics may disappear into a patterned background.

[Suggestion] Do not use patterned backgrounds behind text or functional graphics.

36

DRAFT

Users with low vision need to magnify the screen to read text. To read printed text, these users also need to use print fonts that are larger than the default print fonts.

[Suggestion] Allow users to change default print fonts to 18 point and larger.

If users can save output to a file that is usually printed, then users with accessibility challenges can operate assistive technologies (such as screen magnifiers, screen readers, and refreshable Braille displays) to read the output.

[Suggestion] Allow users to save print output to an ASCII file, an HTML file, or both.

Accessibility TestingTo make sure that you successfully designed and coded your application to make it accessible, test your work. Perform iterative accessibility tests.

Accessibility tests have two goals:1. Evaluate the accessibility of the user interface2. Evaluate the usability of the accessible user interface.

Both goals are important. For example, forcing users with disabilities to enter an unusual, hidden, multiple, simultaneous set of key presses to perform a function may make the function accessible, but it does not make the function usable. A tabular version of graphed data is accessible, but makes it difficult for users to perceive trends in the data.

Design your user interface so it is accessible and usable. Make the accessibility features simple, intuitive, familiar, and easy to perform.

To evaluate the accessibility and usability of your user interface, perform iterative accessibility tests.

Ask representative users with disabilities to perform typical tasks with your application.

Make sure the evaluation room is accessible for the users (for example, there are wheelchair ramps into the building and into the room).

Provide the assistive technologies the users need to interact with your application. The most popular assistive technologies for software are the JAWS screen reader from Freedom Scientific, the ZoomText screen magnifier from Ai Squared, and the Dragon NaturallySpeaking Professional Solutions voice recognition tool from Nuance.

Provide support services needed by the users (for example, deaf users may need a sign language translator).

37

DRAFT

Identify opportunities to make the user interface more accessible or more usable. Record whether each user successfully completes each task. After each task and at the end of the session, ask users to complete questionnaires with ease-of-use ratings and improvement suggestions.

Improve the application. Perform another accessibility evaluation, preferably with different

representative users with disabilities. Repeat this process until all users complete all tasks successfully with

high ease-of-use ratings. Pay the users for their service. Reimburse the users for their travel

expenses. Thank users for their assistance.

References

Carmant, L., & Seshia, S. Photosensitive seizures [On-line]. Available: http://www.epilepsy.ca/eng/left_menu/news_Update/NU_PhotosensitiveSeizures.htm

Centro Nazionale per l’Informatica nella Pubblica Amministrazione (2004). Law n. 4, January 9, 2004 (PubbliAccessó.gov.it) [On-line]. Available: http://www.pubbliaccesso.it/normative/law_20040109_n4.htm

Commonwealth of Australia (2003). National Office for the Information Economy. Accessibility [On-line]. Available: http://www.govonline.gov.au/projects/egovernment/better%5Fpractice/accessibility.htm

Department of the Taoiseach (1999, October). Report of the Interdepartmental Group – Recommended guidelines for public sector organisations [On-line]. Available: http://www.taoiseach.gov.ie/viewitem.asp?id=291&lang=ENG

Epilepsy.com (2004a). Frequently asked questions [On-line]. Available: http://www.epilepsy.com/info/family_faq.html

Epilepsy.com (2004b). Nintendo games may cause epileptic seizures in photosensitive children – epilepsy [On-line]. Available: http://www.epilepsy.com/newsfeed/pr_1085405403.html

Epilepsy.com (2004c, February). Reflex epilepsies [On-line]. Available: http://www.epilepsy.com/epilepsy/epilepsy_reflex.html

Epilepsy Action. Photosensitive epilepsy [On-line]. Available: http://www.epilepsy.org.uk/info/photo.html

38

DRAFT

European Union (2003). EUROPA - European Commission - Information Providers’ Guide – Rule no. 7: Accessibility [On-line]. Available: http://europa.eu.int/comm/ipg/rule7/rule7_en.htm#description

General Services Administration. Section 508 [On-line]. Available: http://www.section508.gov/index.cfm?FuseAction=Content&ID=12#Web

International Organization for Standardization (2003). Ergonomics of human-system interaction – Guidance on accessibility for human-computer interfaces (ISO/TS 16071:2003) [On-line]. Available: http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=30858&ICS1=13&ICS2=180&ICS3=

Ishida, S., Yamashita, Y., Matsuishi, T., Ohshima, M., Ohshima, H., Kato, H., & Maeda, H. (1998). Epilepsia. 39(12),1340-4.

Najjar, L. J. (2001). Principles of educational multimedia user interface design. In R. W. Swezey & D. H. Andrews (Eds.), Readings in training and simulation: A 30-year perspective (pp. 146-158). Santa Monica, CA: Human Factors and Ergonomics Society [On-line]. Available: http://www.lawrence-najjar.com/papers/Principles_of_educational_multimedia_user_interface_design.html

National Institute of Neurological Disorders and Stroke (2004). Seizures and epilepsy: Hope through research [On-line]. Available: http://www.ninds.nih.gov/health_and_medical/pubs/seizures_and_epilepsy_htr.htm

New Zealand E-government (2003). Web guidelines [On-line]. Available: http://www.e-government.govt.nz/web-guidelines/

Paciello, M. (2004, June 21). Online extra: A checkup for Section 508 [Online]. Available: http://www.gcn.com/vol1_no1/daily-updates/26304-1.html

Takahashi, Y., & Fujiwara, T. (2004). Effectiveness of broadcasting guidelines for photosensitive seizure prevention. Neurology, 62(6), 990-993.

Treasury Board of Canada (2002). CLF – Accessibility – Standards and Guidelines [On-line]. Available: http://www.cio-dpi.gc.ca/clf-nsi/inter/inter-01-tb_e.asp

Williams, J. (2001, September 7). Making Uncle Sam accessible – and accountable. Business Week Online [On-line]. Available: http://www.businessweek.com/smallbiz/content/sep2001/sb2001097_766.htm

39

DRAFT

Willuhn, D., Schulz, C., Knoth-Weber, L., Feger, S., & Saillet, Y. (2003). Developing accessible software for data visualization. IBM Systems Journal, 42(4), pp. 652-668 [On-line]. Available: http://www.research.ibm.com/journal/sj/424/willuhn.pdf

40

DRAFT

Helpful Information

Ai Squared. ZoomText [On-line]. Available: http://www.aisquared.com/Products/ZoomText8_mag/Z8Mag.htm

Andrews, M. Accessibility and the Swing set [On-line]. Available: http://java.sun.com/products/jfc/tsc/articles/accessibility/

Dunn, J. (2002, June 2). Developing accessible JFC applications [On-line]. Available: http://www.sun.com/access/developers/developing-accessible-apps/

Feigenbaum, B. A. (2002, October 1). Coding for accessibility – Use JFC/Swing to build accessibility into your Java applications [On-line]. Available: http://www-106.ibm.com/developerworks/java/library/j-access/

Freedom Scientific. JAWS screen reader [On-line]. Available: http://www.freedomscientific.com/fs_products/software_jaws.asp

IBM. IBM Java accessibility checklist [On-line]. Available: http://www-306.ibm.com/able/guidelines/java/accessjava.html

Internal Revenue Service. Section508 for software development [On-line]. Available: http://www.section508.gov/IRSCourse/

Nuance. Dragon Naturally Speaking Professional [On-line]. Available: http://www.nuance.com/naturallyspeaking/professional/

Schwerdtfeger, R. S. (2000, August 24). IBM’s guidelines for writing accessible applications using 100% pure Java [On-line]. Available: http://www-106.ibm.com/developerworks/java/library/j-access/

Sun Microsystems (2003). Accessibility quick reference [On-line]. Available: http://www.sun.com/access/developers/access.quick.ref.html

Sun Microsystems (2003). How to support assistive technologies [On-line]. Available: http://java.sun.com/docs/books/tutorial/uiswing/misc/access.html

Sun Microsystem. Java access bridge for Windows operating system [On-line]. Available: http://java.sun.com/products/accessbridge/

Sun Microsystems (2002). Java accessibility helper [On-line]. Available: http://java.sun.com/developer/earlyAccess/jaccesshelper/

41

DRAFT

Sun Microsystems. Swing component keystroke assignments [On-line]. Available: http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/doc-files/Key-Index.html

The Paciello Group (2004). Accessibility/Section508 Webinar series [On-line]. Available: http://sabaext.bmc.com/SabaWeb [Note: Requires BMC login]

University of Wisconsin (2001). Introduction to screen readers [On-line]. Available: http://www.doit.wisc.edu/accessibility/video/intro_scrn_rdrs.mov

42

DRAFT

Appendix A: Keyboard OperationsThis appendix is based on Sun’s Java Look and Feel Design Guidelines (Second Edition) at http://java.sun.com/products/jlf/ed2/book/index.html

Backing Windows and Internal Windows The following table lists the keyboard operations for backing windows (main windows) and internal windows (primary windows) used in Multiple Document Interfaces (MDIs). For details on internal windows and backing windows, see Working With Multiple Document Interfaces at http://java.sun.com/products/jlf/ed2/book/38422.

Table A1.  Keyboard Operations for Backing Windows and Internal Windows 

Keyboard Operation Action

Ctrl-F4 Closes internal window that has focus

Ctrl-F7 Moves internal window (that is, switches to internal window mode, in which users press arrow keys to move windows around)

Ctrl-F8 Resizes internal window (that is, switches to internal window mode, in which users then press arrow keys to resize window)

Ctrl-F9 Minimizes internal window

Ctrl-Esc, Ctrl-Tab, Shift-Esc, Shift-Tab

Navigates first between open internal windows, then among minimized internal windows (a description of the directions associated with these keyboard operations is at http://java.sun.com/products/jlf/ed2/book/38850. The Control and Shift keys work the same way with the Escape key here as they do with the Tab key in the explanation.)

Ctrl-F5, Enter, Return

Opens minimized internal window that has focus

Ctrl-F6, Ctrl-Shift-F6

Navigates among associated internal windows on the backing window and between an internal window and an associated secondary window (a description of the directions associated with these keyboard operations is at http://java.sun.com/products/jlf/ed2/book/38850. The Control and Shift keys work the same way with the Escape key here as they do with the Tab key in the explanation.)

Ctrl- Displays contextual menu in Multiple Document Interfaces

43

DRAFT

spacebar

Checkboxes The following table lists the keyboard operation for checkboxes. For more information on this component, see Checkboxes at http://java.sun.com/products/jlf/ed2/book/48281.

Table A2.  Keyboard Operation for Checkboxes

Keyboard Operation Action

Spacebar Switches the setting of the checkbox

Combo Boxes The following table lists the keyboard operations for combo boxes. For details on this component, see Combo Boxes at http://java.sun.com/products/jlf/ed2/book/41750.

Table A3.  Keyboard Operations for Combo Boxes

Keyboard Operation Action

Spacebar, down arrow, Alt-down arrow Posts associated list

Up arrow, down arrow When menu is posted, moves highlight up or down within list, selecting highlighted item

Enter, Return, spacebar Closes list, maintaining latest selection

Escape Closes list, returning to prior selection

Command Buttons The following table lists the keyboard operations for command buttons. For more information on this component, see Command Buttons at http://java.sun.com/products/jlf/ed2/book/41392.

Table A4.  Keyboard Operations for Command Buttons 

Keyboard Operation Action

Spacebar Activates command button that has focus

Enter, Return Activates default button (does not require focus)

Escape Activates Cancel button (does not require focus)

List Components

44

DRAFT

The actions listed in the following table assume multiple selection in list boxes and selectable lists. For more information on the appearance, behavior, and selection of these components, see List Boxes at http://java.sun.com/products/jlf/ed2/book/50575 and Selectable Lists at http://java.sun.com/products/jlf/ed2/book/1010483.

Table A5.  Keyboard Operations for Lists 

Keyboard Operation Action

Up arrow Moves focus up one row or line and selects the item

Down arrow Moves focus down one row or line and selects the item

Page Up Moves focus up one information pane minus one line, selecting the first line in the information pane

Page Down Moves focus down one information pane minus one line, selecting the last line in the information pane

Home, Ctrl-Home Moves focus to beginning of list

End, Ctrl-End Moves focus to end of list

Ctrl-A, Ctrl-/ Selects all items in list

Ctrl-\ Deselects all items in list

Spacebar Makes a selection and deselects any previous selection

Ctrl-spacebar Switches selection without affecting previous selections

Shift-spacebar Extends selection

Shift-down arrow Extends selection down one item

Shift-up arrow Extends selection up one item

Shift-Home Extends selection to beginning of list

Shift-End Extends selection to end of list

Shift-PgUp Extends selection up one information pane

Shift-PgDn Extends selection down one information pane

Menus The keyboard operations in this table apply to menu bars, drop-down menus, submenus, contextual menus, menu items, radio button menu items, and

45

DRAFT

checkbox menu items. For a discussion of menus, see Chapter 9 Menus and Toolbars at http://java.sun.com/products/jlf/ed2/book/44394.

Table A6.  Keyboard Operations for Menus 

Keyboard Operation Action

F10 Moves focus to menu bar and posts first menu

Shift-F10 Displays contextual menu

Right arrow and left arrow

Navigates right or left among titles in menu bar, posting current menu, displaying submenus (right arrow), and navigating back from submenu to higher-level menu

Up arrow Navigates within menus, displaying submenus

Down arrow Navigates within menus, moving to the next item without displaying a submenu

Enter, Return, spacebar

Activates menu item, dismisses menu, and goes to last window item that had focus

Escape

Dismisses menu without taking action and returns focus to last component that had focus; when in submenu, dismisses submenu and returns to higher-level drop-down or contextual menu

Radio Buttons The following table lists the keyboard operation for radio buttons. For a discussion of the appearance and behavior of this component, see Radio Buttons at http://java.sun.com/products/jlf/ed2/book/51976. Table A7. Keyboard Operation for Radio Buttons

Keyboard Operation Action

Spacebar Turns on radio button

Scrollbars Users can operate scrollbars from the keyboard when focus is anywhere in the scroll pane. If there are scroll panes within scroll panes, the keyboard operates the innermost scrollbar. For a discussion of the appearance and behavior of this component, see Scrollbars at http://java.sun.com/products/jlf/ed2/book/40018.

Table A8.  Keyboard Operations for Scrollbars 

Keyboard Operation Action

46

DRAFT

Up arrow Moves information pane up one line

Down arrow Moves information pane down one line

Page Up Moves up one information pane minus one line

Page Down Moves down one information pane minus one line

Ctrl-Home Moves to beginning of data

Ctrl-End Moves to end of data

Ctrl-PgDn Moves right one information pane minus one column

Ctrl-Pg Up Moves left one information pane minus one line or column

Secondary Windows and Utility Windows The following table lists the keyboard operations for secondary windows (dialog boxes and alert boxes). Utility windows use the same operations. For comprehensive treatment of dialog boxes and alert boxes, see Chapter 8 Dialog Boxes and Alert Boxes at http://java.sun.com/products/jlf/ed2/book/36299. For a discussion of utility windows, see Utility Windows at http://java.sun.com/products/jlf/ed2/book/997014.

[Note] Keyboard navigation support for the JdialogPane component is not fully operational in the Java 2 SDK. The action specified for the Escape key must be programmed by the developer.

Table A9.  Keyboard Operations for Dialog Boxes 

Keyboard Operation Action

Alt-F6 Navigates into secondary window; when in secondary window, navigates to the associated higher-level window

Escape Activates Cancel button (no need for focus)

Enter, Return Activates default command button (no need for focus)

Sliders The following table lists the keyboard operations for sliders. Sliders can be either vertical or horizontal, so keyboard operations are provided for each case. For details on this component, see Sliders at http://java.sun.com/products/jlf/ed2/book/42310.

Table A10.  Keyboard Operations for Sliders

47

DRAFT

Keyboard Operation Action

Arrow keys Changes value of slider

Home Moves to leading-edge value (in left-to-right reading order, the value at the left edge or bottom)

End Moves to the trailing-edge value (in left-to-right reading order, the value at the right edge or top of the slider)

Page Up, Ctrl-PgUp Jumps towards right or top (approximately 20% of the scale)

Page Down, Ctrl-PgDn

Jumps towards left or bottom direction (approximately 20% of the scale)

Split Panes The following table lists the keyboard operations for split panes. After users enter a split pane, pressing Tab cycles the focus to the components within the split pane. For a description of the appearance and behavior of this component, see Split Panes at http://java.sun.com/products/jlf/ed2/book/40018.

Table A11.  Keyboard Operations for Split Panes 

Keyboard Operation Action

Tab, F6 Navigates between split panes and gives focus to last element that had focus

F8 Gives focus to splitter bar

Arrow keys, Home, End Changes location of splitter bar in splitter pane

Tabbed Panes The following table lists the keyboard operations for tabbed panes. For a description of the appearance and behavior of this component, see Tabbed Panes at http://java.sun.com/products/jlf/ed2/book/38176. When a tabbed pane initially gets focus, the focus goes to one of the tabs, not to one of the content panes.

Table A12.  Keyboard Operations for Tabbed Panes

Keyboard Operation Action

Arrow keys Navigates through tabs

48

DRAFT

Ctrl-down arrow Moves from tab to its associated content pane

Ctrl-up arrow Moves from content pane to its associated tab

Ctrl-PgDn Moves to next content pane (changing the corresponding tab)

Ctrl-PgUp Moves to previous content pane (changing the corresponding tab)

Tables The following table lists the keyboard operations for tables. For a description of the appearance and behavior of this component, see Tables at http://java.sun.com/products/jlf/ed2/book/1010484.

Table A13.  Keyboard Operations for Tables 

Keyboard Operations Action

Enter (or Return) Deselects current selection and moves focus down one cell

Shift-Enter (or Shift-Return) Deselects current selection and moves focus up one cell

Tab Deselects current selection and moves focus right one cell

Shift-Tab Deselects current selection and moves focus left one cell

Down arrow Deselects current selection and moves focus down one cell

Up arrow Deselects current selection and moves focus up one cell

Page Down Deselects current selection, scrolls down one information pane, and selects the last visible cell in the current column

Page Up Deselects current selection, scrolls up one information pane, and gives focus to first visible cell in the current column

Ctrl-PgUp Deselects current selection, scrolls left one information pane, and gives focus to first visible cell in the current row

Ctrl-PgDn Deselects current selection, scrolls right one information pane, and selects the last visible cell in the current row

Home Moves focus and information pane to first cell in the current row

End Moves focus and information pane to last cell in the current row

49

DRAFT

Ctrl-Home Moves focus and information pane to first cell in the current column

Ctrl-End Moves focus and information pane to last cell in the current column

F2 Enables editing in a cell

Escape Resets cell to the state it was in before it was edited

Ctrl-A Selects entire table

Shift-down arrow Extends selection down one row

Shift-up arrow Extends selection up one row

Shift-left arrow Extends selection left one column

Shift-right arrow Extends selection right one column

Shift-Home Extends selection to beginning of row

Shift-End Extends selection to end of row

Ctrl-up arrow Navigates up one row without affecting the selection

Ctrl-down arrow Navigates down one row without affecting the selection

Ctrl-Shift-up arrow Navigate up one row and select the new item without deselecting any current selections

Ctrl-Shift-down arrow

Navigate down one row and select the new item without deselecting any current selections

Ctrl-Shift-Home Extends selection to beginning of column

Ctrl-Shift-End Extends selection to end of column

Shift-PgDn Extends selection down one information pane

Shift-PgUp Extends selection up one information pane

Ctrl-Shift-PgDn Extends selection right one information pane

Ctrl-Shift-PgUp Extends selection left one information pane

Text Areas and Default and Styled Text Editor Kits The following table lists the keyboard operations for text areas and the default and styled text editor kits. For details on the appearance and behavior of these components, see Text Areas at http://java.sun.com/products/jlf/ed2/book/40295,

50

DRAFT

Default Editor Kit at http://java.sun.com/products/jlf/ed2/book/44667, and Styled Text Editor Kit at http://java.sun.com/products/jlf/ed2/book/44667.

Table A14. Keyboard Operations for Text Areas and Default and Styled Text Editor Kits 

Keyboard Operation Action

Up arrow Moves insertion point up one line

Down arrow Moves insertion point down one line

Left arrow Moves insertion point to the left one component or character

Right arrow Moves insertion point to the right one component or character

Page Up Moves up one information pane

Page Down Moves down one information pane

Ctrl-PgUp Moves left one information pane

Ctrl-PgDn Moves right one information pane

Home Moves to beginning of line

End Moves to end of row or line

Ctrl-Home Moves to beginning of data

Ctrl-End Moves to end of data

Ctrl-left arrow Moves to beginning of previous word

Ctrl-right arrow Moves to beginning of next word

Ctrl-A, Ctrl-/ Selects all

Ctrl-\ Deselects all

Shift-up arrow Extends selection up one line

Shift-down arrow Extends selection down one line

Shift-left arrow Extends selection left one character

Shift-right arrow Extends selection right one character

Shift-PgUp Extends selection up one information pane

51

DRAFT

Shift-PgDn Extends selection down one information pane

Ctrl-Shift-PgUp Extends selection to the left one information pane

Ctrl-Shift-PgDn Extends selection to the right one information pane

Shift-Home Extends selection to beginning of line

Shift-End Extends selection to end of line

Ctrl-Shift-Home Extends selection to beginning of data

Ctrl-Shift-End Extends selection to end of data

Ctrl-Shift-right arrow Extends selection to next word

Ctrl-Shift-left arrow Extends selection to previous word

Text Fields The following table lists the keyboard operations for text fields. For details on this component, see Text Fields at http://java.sun.com/products/jlf/ed2/book/47440.

Table A15. Keyboard Operations for Text Fields 

Keyboard Operation Action

Right arrow Moves insertion point one character to the right

Left arrow Moves insertion point one character to the left

Ctrl-right arrow Moves insertion point to beginning of next word

Ctrl-left arrowMoves insertion point to beginning of current word, or, if insertion point is already at the beginning of the current word, moves it to the beginning of the previous word

Home Moves insertion point to beginning of text field

End Moves insertion point to end of text field

Shift-Home Extends selection to beginning of line

Shift-End Extends selection to end of line

Shift-left arrow Extends selection one character to the left

Shift-right arrow Extends selection one character to the right

52

DRAFT

Ctrl-Shift--left arrow Extends selection to previous word

Ctrl-Shift--right arrow Extends selection to next word

Ctrl-A Selects all characters in the text field

Toggle Buttons The following table lists the keyboard operation for toggle buttons. For details on this component, see Toggle Buttons at http://java.sun.com/products/jlf/ed2/book/42238.

Table A16. Keyboard Operation for Toggle Buttons

Keyboard Operation Action

Spacebar Switches button on or off

Tool Tips The following table lists the keyboard operations for tool tips. For details on this component, see Tool Tips at http://java.sun.com/products/jlf/ed2/book/43652.

Table A17. Keyboard Operations for Tool Tips

Keyboard Operation Action

Ctrl-F1 Displays or dismisses tool tip

Escape Dismisses tool tip

Toolbars The following table lists the keyboard operations for toolbars. For details on the appearance and behavior of this component, see Toolbars at http://java.sun.com/products/jlf/ed2/book/43503. Table A18. Keyboard Operations for Toolbars

Keyboard Operation Action

Arrow keys Navigates within toolbar

Spacebar Activates toolbar button

Tree Components The following table lists the keyboard operations for tree components. For details on the appearance and behavior of this component, see Tree Components at http://java.sun.com/products/jlf/ed2/book/37594.

53

DRAFT

Table A19.  Keyboard Operations for Tree Components 

Keyboard Operation Action

Right arrow Expands current node

Left arrow Collapses current node

Up arrow Moves selection up one node

Down arrow Moves selection down one node

Home Moves selection to first node in tree

End Moves selection to last node in tree

Page Up Scrolls up one information pane

Page Down Scrolls down one information pane

Ctrl-PgUp Moves left one information pane, if not everything is visible in a horizontal orientation

Ctrl-PgDn Moves right one information pane, if not everything is visible in a horizontal orientation

Ctrl-A, Ctrl-/ Selects all nodes in tree

Ctrl-\ Deselects all

Shift-up arrow Extends selection up

Shift-down arrow Extends selection down

Shift-Home Extends selection to beginning of tree

Shift-End Extends selection to end of tree

Shift-PgUp Extends selection up one information pane

Shift-PgDn Extends selection down one information pane

Ctrl-Shift-PgDn Extends selection right one information pane

Ctrl-Shift-PgUp Extends selection left one information pane

54