DNo type of information technology is more prevalent in the modern workplace than software. Software applications include word processors, spreadsheets, database management, groupware that enables colleagues to work in a networked environment, e-mail, Internet browsers, financial management and accounting programs, and others.
Almost all software applications contain some barriers to people with disabilities. Among the communities most likely to face significant barriers are those who are blind, those with low vision, and those with multiple disabilities. People who cannot use a computer mouse -- including those with disabilities limiting manual dexterity or reach -- can also find it difficult to use mainstream software applications, unless the applications allow users to use keyboard input or other means of interacting with the software.
Federal components were asked to evaluate the accessibility of their 10 most commonly used software packages. The components were instructed to use the "Software Accessibility Checklist" developed by the Department of Justice for the objective portion of their survey. Agencies were also asked to evaluate these applications subjectively, by running them with assistive technologies commonly used by persons with disabilities such as screen readers.(2)
For each of the 10 software items evaluated, components were instructed to provide the following identifying and descriptive information:
Finally, agencies were also asked to prepare a comprehensive evaluation of electronic and information technology based on the evaluations completed by their components, any steps that the agency intended to take to improve accessibility, and recommendations for improving the accessibility of the Federal Government's software applications.
I. Objective Survey Tool: The "Software Accessibility Checklist"
The Department of Justice's Software Accessibility Checklist was based on the U.S. Department of Education's Requirements for Accessible Software Design (Requirements), including the technical guidance that appears as Appendix A to the Requirements.(3) The Requirements document and the appendix are available at:
http://gcs.ed.gov/coninfo/clibrary/software.htm
To aid the reader, this section is broken down into 3 subparts:
1. Does the software provide keyboard equivalents for all mouse actions, including buttons, scroll windows, text entry fields, and pop-up windows?
While providing a convenient "point and click" means of selecting options, a computer mouse also creates obstacles for persons with certain disabilities if "keyboard equivalents" are not provided. In general, persons affected by software requiring mouse input include several categories of disabilities:
While each of these groups may be excluded by software requiring mouse action, they may be able to use the software if "keyboard equivalents" for all mouse actions are provided. The simplest example of such a "keyboard equivalent" is the use of combination keystrokes to replace mouse action. For instance, instead of requiring the user to select the "File" menu item and then select "print" to print a document, a program should allow the user to simply hit the keystroke combination of "Control-P."
The responses by the federal components suggest that most software packages include keyboard equivalents for all mouse actions. See Table 1.(4) Components provided a "no" response for 221 of the 1,676 software reviews (13%).(5)
2. Does the program provide clear and precise instructions for use of all keyboard functions as part of the user documentation?
Users who require keyboard functions to use software need clear and precise instructions for using these keyboard functions. Unfortunately, user manuals and documentation (help files, instructions, etc.) often neglect the importance of these keyboard equivalents, focusing instead on mouse or pointer actions.
Therefore, users in any of the categories of disabilities described in the analysis accompanying Question 1 will also require clear and precise instructions for use of all keyboard functions as part of the user documentation. In addition, users with cognitive impairments or learning disabilities will require clear instructions for keyboard access in the user documentation since not all software programs use the same keystrokes for actions. Therefore, having clear instructions for keyboard actions for all users will help people with cognitive impairments and learning disabilities use multiple software packages with minimal error.
A response of "not applicable" to this question indicates either that user documentation does not exist, that keyboard functions are not provided, or that the agency misinterpreted this question. A response of "no" indicates that user documentation does not include clear and precise instructions for all keyboard functions. In either case, these responses indicate a potential barrier to access.
Twenty-six percent (428 of 1,676) of the software surveys indicated that the application does not provide clear and precise instructions for keyboard functions. See Table 2. This relatively high rate represents a substantial barrier to the efficient use of existing software applications by persons with disabilities but one that can be relatively easily corrected. All components that identified such lapses in their software documentation should contact the manufacturers and urge them to provide full instructions, preferably in an electronic format that can be posted to agency or private sector Web sites.
3. Are instructions regarding keyboard use widely available for all users in your component?
Even when instructions for keyboard functions are clearly and precisely written in the user documentation, users with specific disabilities may be excluded if these instructions are not widely available to all users in a component. Persons with disabilities, who may already be partially excluded from full interaction with other employees based on other technological barriers or difficulty in communicating, may have even less reason to know about instructions for keyboard use unless all users in a component have access to this information.(6)
Like Question 2, a response of either "no" or "not applicable" indicates a potential barrier to access by persons with disabilities. In almost 30% (496 of 1,676) of the software surveys, components indicated that the applications do not have keyboard instructions that are widely available to all users. See Table 3. This situation, too, represents a significant problem for people with disabilities. Addressing it should be assigned a high priority.
4. Does the software have a logical tabbing order among fields, text boxes, and focal points?
A "logical tabbing order" is a technique which all different user choices or options can be accessed by repeatedly hitting a particular key (typically the "tab" key) or combination of keys. For instance, if the software package includes icons at the top of the screen depicting user choices (e.g., "open file", "print", "save", etc.), repeatedly hitting the "tab" key may allow different options to become highlighted. Once highlighted, the user can select that option by hitting the "enter" key. The tabbing order has to be "logical" in the sense that it should scroll through all of the choices consecutively and in the same order each time. This technique is important because it ensures that the software can be used in the same way by all users.
A logical tabbing order among fields, text boxes and focal points is as crucial to the same groups of users as identified in Questions 2 and 3. Blind users may be unable to use a mouse and will require a logical keyboard tabbing order to ensure information clarity and ease of use. Users with low vision may not possess the ability to see the mouse pointer effectively, thus making a logical tabbing order necessary for information clarity and ease of use. Some people with physical disabilities may also be affected by the absence of a logical tabbing order. Finally, persons with cognitive impairments and learning disabilities may require a consistent tabbing order to assist with training and learning.
As almost all software requires user input and provides selection of user options, a "not applicable" answer does not make sense.(7) Therefore, an answer of either "no" or "not applicable" indicates problems with accessibility. In 14% (232 of 1,676) of the software surveys, components indicated that the applications do not provide a logical tabbing order among fields, text boxes, and focal points. See Table 4.
5. When navigating screens and dialog boxes using the keyboard, does the focus follow a logical tabbing order?
The screen of a typical computer program usually provides several user options. Frequently, one of the options is highlighted and can be accessed by hitting the "enter" key. The item which is selected and which can be invoked by hitting the enter key is the point of "focus." This "focus" usually changes depending on the screen that is currently before the user. For instance, if the user tries to save her work in a file that already exists, the program may generate a "dialog box" that asks whether the user wants to overwrite the existing file with a new one. The dialog box may include two buttons ("yes" and "no") and the "no" button may have a bold dark line around its perimeter. In that case, the "no" button is the "focus" and selecting "enter" will indicate that the user does not wish to overwrite her other file. However, the user can change the focus by using the "tab" key or other key combination. For instance, if the user hits the tab key, the bold dark line may disappear from the "no" button and switch to the "yes" button. In that case, the "yes" button has become the focus. Using the tab key in this example permits the focus to follow a logical tabbing order.
As the focus is critical to providing a keyboard alternative to the use of a mouse, the same groups of users identified in Question 4 may also be affected by this situation. In 14% (233 of 1,676) of the software surveys, components indicated that the applications do not ensure that the focus follows a logical tabbing order when the user navigated screens and dialog boxes using the keyboard. See Table 5.
6. Is there a well-defined focal point that moves with keyboard navigation (e.g., can you use the arrow keys to navigate through a list followed by pressing the ENTER key or space bar to select the desired item)?
As described in the analysis accompanying Question 5, a "focus" is that portion of the visual display which is a "default" user choice of input. A focus can be changed through software that permits a logical tabbing order among elements of the screen. However, that focal point must be well-defined (e.g., identifiable by a bold outline, highlighting, etc.) and must be moveable with keyboard navigation otherwise, a mouse click would still be necessary to make selections other than the one that is currently highlighted. A well-defined focus is important because screen readers can easily follow and properly read the well-defined focus.
The same groups of users identified in Questions 4 and 5 are affected by this situation according to responses in Question 6. In 18% (300 of 1,676) of the software surveys, components chose a "no" or "not applicable" response to this question, indicating that there is no well-defined focal point that moves with keyboard navigation. See Table 6.
7. Are shortcut keys provided for all pull-down menus?
Many modern software packages use a mouse for "point and click" access to functions that may otherwise be hard for a user to remember. "Pull-down menus" are a further simplification in software design that allows designers to organize related functions under a common heading. When a user clicks on the heading for a pull-down menu, a box drops down with a listing of several options that are all related to the heading. For instance, many software packages have a "file" and "edit" menu that includes commands that are very commonly used. The "edit" menu may contain, for instance, "copy", "cut", and "paste" commands that can be easily accessed by the user. If a user wants to "cut" text from a paragraph, he simply selects the text with his mouse, clicks on "edit" and then chooses "cut." He can then move that text to another portion of his document by simply selecting a location with his mouse, then again clicking "edit" and then "paste."
Unfortunately, using pull-down menus places heavy reliance on the mouse to "point and click" to gain access to functions hidden away under pull-down menus. If the software requires the use of a mouse, then users who cannot use a mouse may be excluded from accessing functions that other users could obtain by simply clicking on a menu heading.
One alternative to requiring the use of a mouse is to provide a "shortcut key" for the functions organized by the pull-down menus. In programs operating in the Microsoft Windows family of operating systems, simultaneously pressing the "control" key and the letter "x" will "cut" a selection, while "control" and "V" will "paste" that same selection. For very commonly used functions (like cutting and pasting), shortcut keys provide an accessible, convenient and fast way to use common functions. However, providing a shortcut key to all functions is impractical because many computer programs have a large number of rarely used functions and users are unlikely to remember all of the shortcut keys.
Another alternative to the mouse is by providing a "shortcut key" to the pull-down menu itself. In most Microsoft Windows programs, hitting the "alt" key followed by a letter (usually underlined in the heading of the menu) will pull down a particular menu. Then, a user can move the focus to an item on the menu (usually by using the "up" and "down" cursor buttons) and select that function by hitting the enter key. While not quite as "speedy" as a shortcut key to a specific function, this method is ultimately more versatile because it permits access to all functions of a program in exactly the same way that a mouse provides "point and click" access to important functions based on the menu to which the functions are logically related.
The groups of users in this situation have similar experience as those identified in Questions 4, 5, and 6. In 37% (618 of 1,676) of the software surveys, components chose a "no" or "not applicable" response to this question, indicating that shortcut keys are not provided for all pull-down menus. See Table 7.
8. Does the software support existing accessibility features built into the operating system (e.g., sticky keys, slow keys, repeat keys in Apple Macintosh OS or Microsoft Windows 95)?
An operating system is a computer "program" that creates an environment within which other programs operate. At the most rudimentary level, it defines certain sets of instructions that are used by other programs and which allow these programs to use the resources made available by the computer hardware. More advanced operating systems can also make certain resources (e.g., printers and other computers on a network) universally available to all programs operating on a computer. Desktop operating systems include Microsoft Windows 3.1, 95, 98, or NT, UNIX, LINUX, and Apple Macintosh, among others.
Several operating systems, such as Microsoft Windows and Apple Macintosh, can alter the way computers function to accommodate persons with disabilities. For instance, some operating systems can be told to ignore brief or repeated keystrokes. By activating special settings in an operating system, a person lacking fine motor control or having tremors can use a keyboard with fewer errors. Other operating systems allow users to change the screen colors to use high-contrast colors or low contrast color combinations (as needed), to select personalized color combinations, or to significantly magnify portions of the screen. These settings allow some users with low vision to be able to better read the screen. Blind users who are unable to use a mouse may require the ability to use "mouse keys," which allow the use of the keyboard cursor keys to make mouse movements. Other accessibility options in some operating systems allow people with hearing disabilities to utilize functions that provide visual cues associated with audio warnings or displays. Users with any combinations of these disabilities will be also affected by a software package's inability to inherit accessibility features of an operating system. Finally, users with cognitive impairments and learning disabilities may benefit from accessibility options built into many operating systems.
As useful as these accessibility features in an operating system may be, software running on that operating system may interfere with these features. If software interferes with these accessibility features, then a user with disabilities may again be excluded from using computer software. Since not all operating systems incorporate accessibility features, a "not applicable" response may be expected, while a "no" response indicates a problem with accessibility. In 14% (236 of 1,676) of the software surveys, components indicated that the applications interfere with accessibility features of the operating systems on which they run. See Table 8.
9. If timed responses are present, does the software allow the user to modify the timing parameters of any required timed responses?
Certain software packages require a timed response from the user. If a program encounters an error performing a task requested by the user, it may present a small window with information about the problems encountered with an "okay" button for the user to click to acknowledge the problem and continue, or a "cancel" button for the user to click if he wants to abort processing. However, in most circumstances, the program may include a timed response. If the user doesn't hit either the "okay" or the "cancel" button within 30 seconds, the program will continue processing as if the user had chosen the "okay" button.
Other computer programs use timed responses for varied purposes. One instance: to discourage unauthorized use of a computer, a computer program can automatically lock out a user after a timed period if no input is provided for two minutes. Another instance: screen savers, which can automatically turn on within a fixed period of inactivity, either to preserve the integrity of the computer monitor or to prevent energy loss.
While there are many legitimate reasons for software to require a timed response from users, these timed responses also have the potential for excluding users who, because of their disabilities, may not be able to respond within the time period required. For instance, blind users or users who have low vision may require additional time to become aware of, or familiar with, a dialog box or screen requesting a timed response. Users with certain physical disabilities may also need additional time to respond. Finally, users with learning, language, or cognitive impairments and learning disabilities may need more time to become aware of and familiar with the response requested.
As many or most computer programs do not require a timed response from a user, an answer of "not applicable" does not necessarily imply a problem with accessibility. By contrast, a "no" response does suggest a problem with accessibility. In 11% (185 of 1,676) of the software surveys, components indicated that the software application potentially creates barriers to access through the use of timed responses that cannot be modified by the user. See Table 9.
10. Are all descriptions or labels for fields positioned immediately to the left or directly above the control, and do they end in a colon, so that it is easy for screen reading software to associate the labels with the corresponding fields?
Screen reading software allows users with disabilities affecting vision to access information on a computer screen by converting text into a different format, such a speech output or refreshable Braille. While a screen reader "reads" the information on a screen, it traverses the screen from left to right and from top to bottom, following the basic course a sighted user's eyes move when reading the contents on a page.
Yet, when the screen reader "reads" the contents of a screen, descriptions and labels for fields may be easily confused with the contents of those fields unless the descriptions and labels are clearly and uniformly marked and placed above or to the left of their corresponding fields.
In 24% (402 of 1,676) of the software surveys, components reported that the software application does not associate the contents with description and field labels where they can be readily understood by users using screen readers. See Table 10.
11. Does every window, object, and control have a clearly named label?
Different operating systems, particularly modern graphic user interface (GUI) systems, can provide a large number of simultaneous screen elements. At any one time, a computer screen can be displaying a word processing program in one window, a spreadsheet in another window, and an e-mail system in a third window. To further complicate this array of information, each window can have different objects, tool bars, dialog boxes, and controls each of which affects the user's ability to use a program.
As confusing as the modern computer screen may be for a nondisabled person, it may be difficult or impossible for a user with a disability to access each window, object, and control unless it is clearly labeled. Without such a label, screen reading software cannot tell the user with which window, object, or control he or she is confronted -- thereby making the information presented hopelessly confusing for those who rely on that technology. Such information must be clearly linked with its associated information-- either by its proximity to related information or by creating an association that can be recognized by screen reading software. Clearly named labels also greatly assists those who use screen enlargement software and those with cognitive impairments and learning disabilities.
In 8% (139 of 1,676) of the software surveys, components reported that the software does not incorporate clearly named labels for every window, object, and control. See Table 11.
12. Does the software application use standard controls rather than owner-drawn or custom controls?
Default software controls for common functions and dialog boxes are often provided by the operating system supporting the program. When a user decides that she would like to print a document, the dialog box that appears is usually created by the operating system. These default controls are usually readable by screen readers and thus provide some level of accessibility for users of screen reading software, because they permit the screen reader to identify the title and desired action of each control. Furthermore, users of screen enlargement software also benefit from using standard controls, because familiar functions can be easily found.
By contrast, owner-drawn or custom controls may be quite different from the standard controls available to that particular software package. Such non-standard controls will likely not permit the screen reader to identify the type, name, or action required of each control. Users of screen enlargement software may also find it much more difficult to locate controls and identify actions required by that control if the control is different from the standard control.
Therefore, non-standard controls may tend to exclude persons who are blind or persons with low vision. In 15% (249 of 1,676) of the software surveys, components chose a "no" or "not applicable" response to this question. See Table 12.
13. Does the software have a user selectable option to display text on icons, i.e., text only icons or bubble help?
With the increasing popularity of software based on a so-called "graphic user interface" system (GUI), the use of icons is wide-spread. An icon is a pictorial representation of a function or action performed by the program; icons are typically used to represent the most commonly used functions. For instance, an icon of an open folder may represent "open a document," an icon of a computer disk may mean "save the file to disk," and an icon of a computer printer may mean "print this document." While convenient for nondisabled users, however, these icons are not independently accessible to screen readers because there is no text associated with the icon. Although a person may be able to discern the image of a printer in an icon, a computer screen reader cannot. Therefore, icons without associated text present a barrier to users who are blind. Also, users with low vision may not have sufficient visual acuity to discern the image represented by the icon. Finally, while some users with cognitive impairments and learning disabilities may prefer the use of icons for popular functions, others may require text to convey the function or action.
Although icons are not independently accessible to users with disabilities affecting vision or cognitive impairments and learning disabilities, combining these icons with text can make them accessible. For instance, if the user can select to have "text only" icons (i.e., short words to represent popular functions or actions) or can select to have "bubble help" (i.e., textual description of actions when the mouse or point of focus is moved over the icon), then all of these users may be able to use the icons presented by the program. Blind people will be able to use them because a screen reader will be able to detect the text that is associated with the icon. Similarly, users with low vision who cannot discern the image of a printer, for example, may be able to read the words, "print this document." Finally, users with cognitive impairments and learning disabilities who may be confused by an image will have associated text to either read or have audibly translated.
If a computer program does not use icons, the program will generally be accessible to persons with disabilities. Therefore, a response of "not applicable" has no bearing on the accessibility of the software program. In 18% (296 of 1,676) of the software surveys, components indicated that the software does not provide user-selectable text labels for icons. See Table 13.
14. Is the use of icons consistent throughout the application?
To use any computer program, it is very important for all users that the location of all functions be consistent and available at all times. It is crucial that icons representing basic functions (e.g., "open a file," "save a document," and "print a document") be routinely located in the same place.
For users with disabilities, this need is even greater because they have much more difficulty using software, if the location or image of an icon representing a particular function is changed from one program to another. Also, screen readers rely heavily on consistency to identify controls and icons. Low vision users also need consistency for identifying and differentiating icons. Finally, learning computer programs becomes dramatically more difficult for all users if different icons for the same function are used in different portions of the application, especially for users with cognitive impairments or learning disabilities.
If a computer program does not use icons, "not applicable" is a neutral answer, not reflecting negatively on the program's accessibility. Five percent (76 of 1,676) of the software surveys gave a "no" response to this question. See Table 14.
15. Are menus with text equivalents provided for all icon functions or icon selections on menu, tool, and format bars?
To make their programs as easy to use as possible, most manufacturers of computer software using icons try to carefully place their icons in the most convenient place possible. Software designers typically place these icons along one or more "bars," where the user can always look for important, commonly used, and related functions or actions. Sometimes, these bars are "detachable" allowing the user to position them anywhere on the screen. In most computer programs, they are positioned (by default) at the top of the screen.
The functions associated with the icons in the menu, tool, and format bars are typically the most important and commonly used functions. Software designers are very careful to ensure that only the most important functions take up valuable space on these bars because they are critical for ease of use for most users. In fact, many software programs allow users to select their own icons for these important locations.
If a function or action is important enough to justify a position on a menu, tool, or format bar, it is important to ensure that it is accessible to users with disabilities. Many users who are blind, have low vision, have certain physical disabilities, or have certain cognitive impairments or learning disabilities may not be able to use a mouse and may require keyboard equivalents (see analysis accompanying Questions 1-7). Keyboard access can be provided through menus with text equivalents for all of these important icons.
If a printer icon is located on the tool bar of a program, a menu equivalent of that icon that can be accessed through the keyboard may be as follows:
In 9% (149 of 1,676) of the software surveys, components gave a "no" response to this question. See Table 15.
16. If there are audio alerts, are visual cues also provided?
Many software programs incorporate audio alerts typically to indicate when a user has tried to perform an action that cannot be legally performed. For instance, if a user is editing a portion of a document and tries to print the document while editing the document, hitting the shortcut key associated with printing (e.g., "control" and "p") may generate a chirping audio alert indicating that the user has tried to perform an illegal action.
If an audio alert is not accompanied by some other visual cue, users who are deaf or hard of hearing may not be aware of the cue. In addition, some users with learning disabilities may have difficulty responding properly or efficiently to audio cues that are not accompanied by visual cues.
"Not applicable" is a neutral answer to this question and does not reflect negatively on the program's accessibility (for instance, when a computer program does not have any audio alerts). In 10% (167 of 1,676) of the software surveys, components chose "no," indicating that the software does not provide visual alerts for all audio alerts. See Table 16.
17. Does the software support the "show sounds" feature where it is built into the operating system?
"Show Sounds" is a feature provided by some operating systems, such as Microsoft Windows 95 and 98. For programs that support "Show Sounds," a visual representation is created for the sound. For instance, a screen may "blink" to notify the user of incoming e-mail.
The same group of users identified in Question 16 are also affected by the lack of availability of this special feature. Again, a response of "not applicable" may not be indicative of a problem, because the "Show Sounds" feature may not be built into the operating system. Eighteen percent (305 of 1,676) of the software surveys gave a "no" response to this question, indicating a problem with accessibility. See Table 17.
18. Can the user disable or adjust sound volume?
Sound volume affects different groups of users in different ways. Users who are hard-of-hearing may need to increase the sound volume to meet their needs. Some users with cognitive impairments or learning disabilities may need to turn up the volume to provide clarity for comprehension, while other users may find it distracting and need to disable or lower the sound volume.
In 10% (175 of 1,676) of the software surveys, components gave a "no" response to this question, indicating a problem with accessibility. See Table 18.
19. If information is provided in an audio format, is it also capable of being displayed by the user in a visual format?
Information can be conveyed to a user in a number of different ways. Most commonly, computer information is provided in visual format through the computer screen. Occasionally, however, information can also be conveyed through audio. When information is presented through audio, however, there is the potential for excluding certain groups of users.
This question, like Questions 16-18, relates to the usability of software by users who are deaf or hard of hearing or who need alternatives because they cannot comprehend audio formats. If a user is unable to hear audio, a text format should be provided. If a person is unable to process information audibly, an alternative format such as text can be used.
In 15% (225 of 1,676) of the software surveys, components gave a "no" response to this question, indicating a problem with accessibility. See Table 19.
20. Is the software application free of patterned backgrounds used behind text or important graphics?
Patterned backgrounds may be used behind text to create unusual or special effects, but they may present difficulties for several groups of users. Such backgrounds may present problems for users with low vision, who require clarity and contrast of the text and important graphics. Users with lack of color perception may also be affected because text or icons may disappear against a patterned background. Additionally, users with learning disabilities or cognitive impairments may be affected because their comprehension of important material may be clouded.
Since a "not applicable" response is not appropriate for this question, such a response may indicate a problem with accessibility. In 16% (265 of 1,676) of the software surveys, components indicated that the software is inaccessible in this respect. See Table 20.
21. Can a user override default fonts for printing and text displays?
Users with low vision may require enlarged display of text on computer screens to use their computers, where an enlarged display may make it easier to discern characters. This same concern applies to printed text.
Therefore, users with low vision may require that the software permits them to override default fonts for printing and text displays. This feature would allow them to choose a font size that is larger and easier to read.
Again, choosing "not applicable" is inappropriate. Accordingly, a response of either "no" or "not applicable" may indicate a problem with accessibility. Twenty-eight percent (472 of 1,676) of the software surveys gave responses of "no" or "not applicable" to this question. See Table 21.
22. Can a user adjust or disable flashing, rotating, or moving displays?
In addition to being potentially annoying to all users, flashing, rotating, or moving displays can cause seizures in people with visually-induced seizure disorders. Thus, this group of users may find it crucial to disable such displays or adjust them.
As many software packages intentionally do not include flashing, rotating, or moving elements, a response of "not applicable" may be appropriate without suggesting a problem with accessibility. Fourteen percent (240 of 1,676) of the software surveys gave a "no" response to this question, indicating a potential problem for people with visually-induced seizure disorders. See Table 22.
23. Does the software ensure that color-coding is never used as the only means of conveying information or indicating an action?
Information can be conveyed to a user in a variety of different ways. Most commonly, software will include buttons or menu choices for different functions. For instance, the buttons associated with printing a document can convey information with words (e.g., "print") or graphics (e.g., a picture of a computer printer). Other questions in this survey have addressed the accessibility problems associated with using graphic images (without associated text) for conveying information. A related question, however, is whether the software uses color as the only way of conveying information. The software may provide only a red and green square and then instruct the user to hit the green button to print a document or the red button to cancel.
Conveying information or indicating actions in this way--- solely through color-coding--- has obvious impact on users with disabilities affecting their perception of colors. Other groups of users with disabilities limiting vision are also affected. Users with low vision may be unable to distinguish colors. Furthermore, since screen reader software cannot distinguish colors, blind users and many users with low vision cannot use some functions of the software.
While many computer systems (particularly terminal systems and older systems) are monochromatic, software intended for such systems cannot use color. In this case, a component may respond "not applicable" without indicating an accessibility problem. In 13% (220 of 1,676) of the software surveys, components gave a "no" response to this question. See Table 23.
24. Does the application support user-defined color settings system-wide?
Some programs and operating systems allow users to change the color settings of their computers. If a user needs high-contrast colors (e.g., black on white), the user can select these options and have these choices carry over throughout the application or all programs using that operating system. On the other hand, other users may find high-contrast color choices difficult to view and may require "softer" color choices. Because different disability groups may require different color settings, it is important for software applications to support user-defined color settings that are respected system-wide.
Users with lack of color perception are affected by the ability of an application to support user-defined color settings. In addition, users with low vision may also need high-contrast or low-contrast color settings and are also affected by an application's ability to meet this requirement.
Because some computer systems do not have color settings because they use monochromatic displays; a response of "not applicable" does not necessarily reflect negatively on the software's accessibility. In 18% (294 of 1,676) of the software surveys, components gave a "no" response to this question. See Table 24.
25. Is highlighting also viewable with inverted colors?
As with user-definable color settings (Question 24), the ability to view text formatted in different ways is important to users with low vision and users with lack of color perception. This condition is particularly true with "highlighted" text, which is commonly displayed using different colors for the actual letters of the text (e.g., red letters) or the background immediately surrounding the text (e.g., highlighted portions in black letters on a yellow background). Both of these display options may cause problems for these users. Instead, a better option is to allow highlighted text to be viewable with inverted colors, so it is easily viewable by most users with lack of color perception or users with low vision who are able to discern text.
As some (albeit few) programs may not highlight text, a "not applicable" response does not reflect negatively on accessibility. The results show that 16% (260 of 1,676) of the software surveys indicated that the software does not allow highlighting to be displayed in inverted colors. See Table 25.
26. If the software application draws its own screen elements, does it pick up the size settings that the user has selected in the Control Panel?
As explained in the analysis accompanying Question 8, the operating system for computers can include accessibility features that are inherited by programs running on that operating system. One feature of operating systems such as the Microsoft Windows family of operating systems (Microsoft Windows 3.1, 95, 98, and NT) is the "control panel" that permits the user to set features (including accessibility features) for that operating system.
Among the settings that can be set in the control panel are size settings for fonts and graphics. This feature greatly enhances accessibility for users with low vision. If a software program creates its own screen elements, however, there is a possibility that these size settings will not be followed by that program, thereby potentially excluding the low vision user.
A "no" response may indicate a problem with accessibility. Fifteen percent (247 of 1,676) of the software surveys gave a "no" response to this question. See Table 26.
27. Are all manuals and documentation provided in electronic format as well as ASCII text files, including text descriptions of any charts, graphs, pictures, or graphics of any nature?
All users of software applications should be provided with adequate documentation including help files, user manuals, and instructions. Generally, users without disabilities may be able to use a printed manual to answer their questions about using a program. A printed manual, however, would not be effective for those who are blind (who may need Braille or speech output) or people with low vision (who may need large print).
To meet the diverse needs of these different groups of users, manuals and documentation should be provided in an electronic format. In particular, ASCII text is probably the simplest type of computer file that reduces all textual information into a form that can be "read" by almost any computer program. Textual descriptions of all graphic or pictorial information is also critical because screen reading software cannot discern and convey information depicted graphically. Another option for providing accessible text is HTML.
A "not applicable" response may be appropriate without affecting accessibility, as where a computer program has no manuals or documentation in any format. Thirty-seven percent (612 of 1,676) of the software surveys gave a "no" response to this question. See Table 27.
28. Can a user choose to have any report generated by the software made available in a "print to ASCII file" format?
Many programs can generate printed reports. Spreadsheet programs and word processors can all print out a paper copy of their documents. While useful, these printed copies may not meet the needs of all users. In particular, users who are blind or who have low vision may not be able to use a printed copy. As explained in the analysis accompanying Question 27, an electronic file may be the only way to meet the diverse accessibility needs of all users.
One way that a printout can be rendered in an electronic format is to have the computer program "print to disk". This process will make the computer program save an electronic copy of the printed material in an electronic format. Most commonly, this electronic format is plain ASCII text because this is a near-universal file format that can be read by almost any computer program. Another option for providing accessible text is HTML.
As some software may not generate printed reports (i.e., some data entry software), a "not applicable" answer may be appropriate without indicating the level of accessibility of a software package. According to the results, 26% (430 of 1,676) of the software surveys gave a "no" response to this question. See Table 28.
29. Is special training provided for users with disabilities that will enable them to become familiar with the software and learn how to use it in conjunction with assistive technology provided as an accommodation?
Specialized training, often provided one-on-one, may be necessary to enable users with disabilities to become familiar with software and with how to use the software in conjunction with assistive technology. Classroom-based computer training is inappropriate for blind users because they must pay attention to both the screen reader and the instructor speaking. In this example, the instructor must also be familiar with the needs of blind learners and the access tools they use. Therefore, training should be tailored to the individual's needs for all disabilities.
All disability categories are affected by whether training for using a computer program meets the needs of their disability. Given the importance of training-- particularly training in conjunction with assistive technology-- a response of "not applicable" is inappropriate because special training may be required for users with disabilities, even if training is not otherwise provided for other users. Fifty-three percent (882 of 1,676) of the software surveys showed that specialized training is not provided for users with disabilities.(8) See Table 29.
B. Summary of Impact on Disability Categories
The following chart (D) summarizes the survey questions and the disability categories that are affected by responses to those questions:
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | |
| Hard of Hearing | x | x | x | x | x | x | |||||||||||||||||||||||
| Deafness | x | x | x | x | x | ||||||||||||||||||||||||
| Disabilities Affecting Hearing and Vision | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | |||||||
| Blindness | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | ||||||||||
| Color Blindness | x | x | x | x | x | ||||||||||||||||||||||||
| Low Vision | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | |||||
| Tremor or Limited Strength or Dexterity | x | x | x | x | x | x | x | x | x | x | x | ||||||||||||||||||
| Cognitive Impairments or Learning Disabilities | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | |||||||||||
| Seizure Disorders | x | ||||||||||||||||||||||||||||
C. Objective Survey of Accessibility by Disability Category
The chart provides a general summary of the effect that survey responses to different questions will have on various groups of users with disabilities. Within each "category" of users with disabilities, different subgroups may find particular features more important than others. Also, the nature of the software package may affect the type of features that different users find important for accessability. Finally, accessibility and "ease of use" are largely individual and may vary with user preferences or experience with different types of user interfaces. Nevertheless, the following analysis provides an overview of how various categories of users with different disabilities are affected by software used by the federal agencies.
1. Users Who are Hard of Hearing
Questions 8, 16, 17, 18, 19, and 29 affect users who are hard of hearing. Each of these questions addresses features that may make software more accessible to specific individuals with disabilities affecting hearing, but no particular feature can make software packages accessible to all users who are hard of hearing. For instance, some users may require visual cues because their disabilities are sufficiently severe as to make any audio cues unusable (Question 16). By contrast, others who are moderately hard of hearing may simply require adjustable sound volume (Question 17).
Fewer than 2% (28 of 1,676) of the software packages completely excludes users who have disabilities affecting hearing because they do not provide any accessibility features that meet their needs. At the same time, however, over two-thirds (68%) (1,137 of 1,676) of the surveys indicated that the software packages do not meet at least one of these six questions, clarifying that some users who are hard of hearing may encounter barriers to access using these products. See Table 30.
2. Users Who are Deaf
Questions 8, 16, 17, 19, and 29 affect users who are deaf. Deaf users encounter many of the same problems with software as other users who have disabilities affecting hearing; the five questions addressing access by deaf users also affect accessibility for those who are hard of hearing. Of the six questions raising issues affecting users with other disabilities affecting hearing, only Question 18 (user adjustable sound volume) is irrelevant for deaf users. No particular question or subset of these five questions can accurately assess the accessibility of a software package to individual users.
In only 2% (34 of 1,676) of the software surveys, components indicated that the applications are inaccessible in all of these respects. However, in 66% (1,113 of 1,676) of the software surveys, components included at least one response to one of these five questions that indicated a problem with accessibility. See Table 31.
3. Users with Disabilities Affecting Hearing and Vision
A large number of questions affect usability by users with some combination of disabilities affecting both hearing and vision. Specifically, a total of 22 questions (Questions 1-9, 11, 13-15, 20-21, and 23-29) all affect accessibility by this group of users. This group includes users with disabilities affecting vision (low vision, blindness, or lack of color perception) and hearing (partial hearing loss or deafness). The three possible forms of disabilities affecting vision and two forms of disabilities affecting hearing considered in this survey lead to six possible categories of disabilities:
The following chart (D) summarizes those questions that affect each of these six groups of users:
| Disability Category | Questions Affecting Accessibility |
| low vision & deaf | 1-9, 11, 13-15, 20-21, 23-29 |
| low vision & partial hearing loss | 1-9, 11, 13-15, 20-21, 23-29 |
| lack of color perception & deaf | 20, 23-25, 29 |
| lack of color perception & partial hearing loss | 20, 23-25, 29 |
| blind & deaf | 1-9, 11, 13-15, 23, 27-29 |
| blind & partial hearing loss | 1-9, 11, 13-15, 27-29 |
Twenty-two questions affect users with low vision (both deaf and with partial hearing loss). In less than 1% (13 of 1,676) of the software surveys, software applications indicated problems in all of these questions. However, 84% (1,413 of 1,676) of the surveys showed that components gave at least one response suggesting a problem with accessibility for this group of users with respect to software applications. See Table 32.
As noted in the chart, users with lack of color perception (both deaf and partial hearing loss) are affected by the smallest subset of the 22 questions. Less than 2% (27 of 1,676 ) of the software surveys showed that software applications were inaccessible in all of these relevant respects. However, in 67% (1,125 of 1,676) of the surveys, components included at least one response suggesting that the software posed a problem with accessibility for this group of users. See Table 33.
The chart also indicates that blind users who are also deaf are affected by 17 of the 22 questions affecting users with various combinations of disabilities affecting hearing and vision. Less than 1% (13 of 1,676) of the software surveys signified that the software under review included problems in all of these questions. In 92.5% (1,550 of 1,67) of the surveys, however, components included at least one response suggesting a problem with accessibility for this group of users. See Table 34.
Finally, the chart indicates that blind users with partial hearing loss are affected by 16 of the 22 questions. In less than 1% (13 of 1,676) of the software surveys, the software showed problems in all of these questions. Moreover, 92% (1,548 of 1,676) of the surveys, components, however, included at least one response suggesting a problem with accessibility for this group of users. See Table 35.
4. Users Who Are Blind
Nineteen questions (Questions 1-15, 23, 27-29) affect users who are blind. In almost 1% (13 of 1,676) of the software surveys, components indicated that the software did not provide accessibility with respect to all of these questions. In 93% (1,552 of 1,676) of the surveys, however, components included at least one response suggesting a problem with accessibility for blind users. See Table 36.
5. Users Who Have Difficulties Discerning or Using Colors
To meet all of the needs of this group of users, the five questions (Questions 20, 23-25, and 29) must be correctly answered. In only 2% (27 of 1676) of the software surveys, components included a negative response to all of these questions. In 67% (1125 of 1676) of these surveys, however, agencies included a negative response to at least one of these questions. See Table 37. These figures include Questions 20 (patterned backgrounds) and Question 29 (training).
Only three questions directly target accessibility for users who have difficulty discerning or using colors. Questions 23, 24, and 25 specifically target these groups. Close to 4% (66 of 1,676) of the software surveys showed that software posed barriers to persons having difficulty discerning or distinguishing colors. In 30% (494 of 1,676) of the surveys, components indicated that the software included one or more of these barriers to access for persons having difficulty discerning or distinguishing colors. See Table 38.
6. Users Who Have Low Vision
As noted in the chart, over 80% of the questions in the software accessibility survey may affect usability by those with low vision. Specifically, responses to Questions 1-15, 20-21, and 23-29 all affect usability of the software by this group of users. In less than 1% (13 of 1,676) of the software surveys, components gave responses suggesting barriers to access with respect to all of these questions. By contrast, in over 93% (1,560 of 1,676) of the surveys, components indicated that the software contained at least one potential barrier to access by persons with low vision. See Table 39.
Unfortunately, because of the large number of questions involved and the different ways that users with low vision can be affected by software accessibility, the importance of the information provided by Table 39 is somewhat limited. A review of the 19 questions that comprise this section, however, reveals some patterns that affect different groups of users with low vision. Any of these questions may independently prevent a specific user from being able to meaningfully use the software, thereby making a "ranking" of importance impossible. Instead, different groups of users with low vision may be able to use software in different ways. Since users with disabilities affecting vision are so significantly affected by software accessibility, the following section analyzes accessibility for this diverse group of users based on the likely means that different types of users will use software.
Not surprisingly, many of the problems confronting users who are blind also affect users with low vision. The chart reflects this overlap; specifically, of the 24 questions affecting users with low vision, 19 affect users who are blind. This overlap is understandable because, like blind users, many users with low vision may require screen reading software and a large number of questions relate to the usability of software with screen reading software. The survey questions affecting users with low vision requiring screen reading software are therefore summarized in the section addressing usability by blind users.
However, not all users with low vision are served by screen reading software. Instead, they may benefit from screen enlargement technologies. Questions 20-21 and 24-26 affect users who have low vision, but not users who are blind. Of the questions affecting blind users, Questions 8-9, 14, 23, and 29 also affect users with low vision who do not require the use of screen reading software. In 1% (18 of 1,676) of the software surveys, components indicated that the software posed barriers in all of these areas. In 91% (1,524 of 1,676) of the surveys, components indicated that the application posed one or more barriers to access to this group of users. See Table 40.
7. Users Who Have Tremor or Limited Reach, Strength, or Dexterity
Users with tremors or limited reach, strength, or dexterity will be affected according to the responses to 11 questions (Questions 1-9, 15, and 29). These questions focus on keyboard equivalents for mouse actions, but also address special accessibility features of the operating system and training materials and documentation.
A little over 1% (24 of 1,676) of the software surveys indicated that software posed potential barriers in all 11 areas. In 92% (1,535 of 1,676) of the surveys, components indicated one or more problems with accessibility for this group of users. See Table 41.
8. Users Who Have Cognitive Impairments or Learning Disabilities
Users who have cognitive impairments or learning disabilities are affected by issues raised in 18 of the questions. Specifically, Questions 2-9, 11, 13-20, and 29 all affect users with cognitive impairments and learning disabilities. Since accommodating users with cognitive impairments and learning disabilities cannot be addressed in broad generalities and may require individual assessment of the user's abilities, a further refinement of these questions to target specific subgroups is difficult.
In less than 1% (15 of 1,676) of the software surveys, components indicated that the software had barriers in all of these areas. By contrast, 93% (1,552 of 1,676) of the surveys found one or more barriers to access for this group of users. See Table 42.
9. Users Who Have Visually-Induced Seizure Disorders
Question 22 focuses on users with visually-induced seizure disorders. In 14% (240 of 1,676) of the software surveys, components indicated possible accessibility problems for this group of users. See Table 43.
II. Subjective Software Analysis
Apart from objectively evaluating their software, components were also asked to subjectively evaluate each software package that they were reviewing. In addition, components were also asked to provide an overall comprehensive evaluation of their electronic and information technology, and a discussion of any plans or recommendations for improving accessibility of electronic and information technology. Each of these sections are analyzed separately below.
A. Question 30 of the Software Accessibility Checklist
While evaluating each component's 10 most popular software packages for usability by persons with disabilities and compatibility with assistive technologies commonly used by people with disabilities, components were also instructed to perform a subjective evaluation of their software using an assortment of assistive technologies:
30. After you have evaluated this application using the Checklist, test it by running the application with a sampling of the common assistive technologies used by persons with disabilities (including, at a minimum, screen readers, and, if possible, alternate input devices, screen enlargement software, and voice recognition software and devices). Describe the accessibility successes and problems you encountered during these testing exercises, as well as your plans for addressing any problems.
This subjective format evaluation tool was necessary because not all accessibility issues could be addressed adequately in an objective checklist-style evaluation. Additionally, the "hands on" experience of actually working with assistive technology greatly enhances the evaluators' awareness of accessibility barriers.
Many of the components' responses clearly indicate the need for greater understanding of assistive technology. Information technology officials who do not have a basic understanding of and access to assistive technology (such as screen reading software, Braille output displays, etc.) are unlikely to be prepared to meet their components' obligations to provide reasonable accommodations to qualified persons with disabilities under sections 501 and 504 of the Rehabilitation Act. If the federal agencies' equal employment opportunity (EEO) officers who traditionally work on reasonable accommodation issues are not consulted with respect to the selection and deployment of mainstream information technology, then employees and members of the public with disabilities are likely to experience undue delays in fulfilling (or, where the underlying software cannot be made compatible with assistive technology, denials of) their requests for reasonable accommodations. Not paying attention to accessibility can result in higher costs, decreased productivity, and a loss of valuable, skilled personnel.
DDespite the clear instructions given in Question 30, and the availability of assistance from the Department of Education and other agencies,(9) relatively few components tested their software applications for compatibility and usability with assistive technologies such as screen readers. Of the 1,676 software surveys completed by components, relatively few included a clear evaluation of the software package using assistive technology. Some responses to Question 30 were too vague to determine whether testing had been done. Half of the surveys indicated that no testing had been attempted; these were usually accompanied by a statement that the agency had no assistive technology with which to conduct the evaluations. Of those software applications that were tested, approximately 240 of the evaluations reflected a careful analysis of the accessibility strengths and weaknesses of the software applications, as revealed by testing them with assistive technologies.
Many components indicated that they did not have assistive technology available to test their software. The Department of Justice neither required nor expected agencies to purchase new assistive technology merely to facilitate their section 508 self-evaluations. Nevertheless, too many components stated that assistive technology was unavailable because it was only provided on an ad hoc basis, or because the component simply employed no people with disabilities. Some components indicated that they planned to perform testing in the near future. Others indicated that they would continue to rely on statements made by the software developer. Still others expressed confusion regarding the nature of assistive technology and noted that they could not find features such as "screen readers" in their existing software packages.
DAs already noted, components carefully evaluated 240 software applications using assistive technology.(10) Of these, half reportedly worked well with the assistive technologies with which they were tested. Seventy-five of the remaining 115 software packages had minor problems. Thirteen of these 75 were due to be replaced soon with more accessible products. Forty software packages that were tested had severe accessibility problems, 10 of which were due to be replaced soon with more accessible software.
Some barriers that were discovered stemmed from representations of graphic or tabular information, that posed problems when run with screen readers. Other software applications did not work at all with screen readers and other assistive technologies.
Due to the relatively small number of software applications tested, it is difficult to draw firm conclusions. The data suggest, though, that a potentially significant percentage of software used by components poses barriers for persons who use assistive technologies. The lack of precision with which these results were reported makes it difficult to discern clear patterns among the types of software applications that were problematic. Often, instead of writing tailored responses to Question 30 for each software application, agencies included a summary discussion in their overall agency evaluations. If the components had been more precise, it would have been easier to tell whether, as one would expect, spreadsheets presented greater difficulties for persons who use assistive technologies than, for instance, word processing software.
In 51 of the evaluations, components indicated that they did not perform testing but relied on the experiences of current users of assistive technologies. Generally, these users reported only minor difficulties. Lack of training and the inaccessibility of the assistive technology were the most common complaints. Users with disabilities were often unable to receive adequate training because training materials were not provided in alternate formats and trainers were unfamiliar with assistive technologies and how their use would affect the mainstream application. Better education about accessibility features for users and information technology specialists is part of the solution. Software manufacturers and developers can help people with disabilities by highlighting accessibility features in their products, either by providing accessibility user manuals or building accessibility help files into their products.
Another excellent recommendation provided by one component was to empower end-users by conducting "training needs surveys" for all users within an agency, including those who use assistive technologies. Too often, users are not aware of or may be reluctant to ask for special training for accessibility features in software. If components conduct regular surveys of all their employees' training needs, they may expect greater productivity from their employees and greater awareness among all employees of software accessibility features and their importance for users with disabilities. Certainly, given the low response rate of the components to Question 29, such awareness among information technology specialists may go a long way towards making software more accessible for all users.
Some users with disabilities did report problems working with some types of software. Some of these barriers can be overcome by adequate training to nondisabled personnel who should understand how to use the software to minimize barriers for their co-workers.
DB. Overall Agency Reports: Discussion of Software
Thirty-nine overall agency reports included specific findings and recommendations for software accessibility. Two positive changes were noted simply through conducting the survey. First, 14 of the components specifically reported that they found their software generally accessible and most promised to consult the software developers about the problems identified during their survey. Second, many agencies also agreed to consider accessibility an important feature for future software development and procurement.
The overall survey, however, revealed two potential problems among the federal agencies. First, 15 of the 39 components relied on policies of providing accommodations on an ad hoc basis for their software users. Although it is vitally important that agencies provide reasonable accommodations for their employees, section 508 requires accessibility of electronic and information technology regardless of whether individual requests are made. As a practical matter, providing accommodations on an ad hoc basis also does not meet the needs of individuals with disabilities for several important reasons. First, as noted by many components, many individuals within an agency are unaware of what equipment or training opportunities are available to them. Second, because some software is intrinsically inaccessible or difficult to use with assistive technology, an agency may never be able to provide reasonable accommodations for such software. For instance, if a component's database of shared files is maintained and accessed through software that does not include keyboard equivalents for all mouse "point and click" commands to accommodate an employee who cannot use a mouse, the component would have to provide an assistant to help the employee with a disability use the shared files. On the other hand, if the component were to purchase and use accessible software, then the employee with a disability could independently access the database of shared files and would have the opportunity to perform on a level playing field with his or her peers.
A small number of components reported that "hands on" testing of software using assistive technology was impossible because such equipment was unavailable or because agency personnel were unfamiliar with such equipment. During the Department's survey, components were not expected to purchase software or equipment simply to complete the survey. However, the fact that many of them could not test their software using assistive technology also reveals that the information technology infrastructure is indicative that such agencies may have great difficulty in providing such aids to software users with disabilities on a timely basis.
The agency reports also revealed that federal agencies used primarily commercial off-the-shelf (COTS) software. The Federal Acquisition Regulation (FAR) requires covered agencies to "acquire commercial items or nondevelopmental items when they are available to meet the needs of the agency." FAR, pt. 12, sec. 12.1(b).
C. Recommended Solutions
Agencies provided a wealth of recommendations and possible solutions for improving the accessibility of software used by the federal agencies. Also, in evaluating the agencies' responses, the Department identified special noteworthy solutions and "promising practices" adopted by particular agencies. All agencies should look to these solutions as a practical means for addressing accessibility needs within their agencies.
The first set of solutions recommended or implemented by various agencies affect the policies or procedures of those agencies. Many have created committees of employees with disabilities to help ensure that the agencies' information technology is accessible to persons with disabilities. For larger agencies, this strategy may be effective for ensuring the participation of users with disabilities.
Most agencies recognize their longstanding obligations for providing reasonable accommodations to employees with disabilities under sections 501 and 504 of the Rehabilitation Act. When an employee with a disability requests an accommodation, many agencies have a stated policy of providing reasonable accommodations, including training opportunities, on an ad hoc basis. In conducting their section 508 surveys, many agencies have noticed that employees with disabilities often do not take full advantage of accommodations and training opportunities to assist them. This lack of participation may be due to a lack of understanding by all employees of opportunities available within their agencies for receiving accommodations that may help them perform their jobs. Several agencies have made excellent recommendations for addressing these problems. Some of them have developed a "needs survey" for all employees. In addition to educating employees about accommodations and training opportunities within an agency, disseminating such a survey may help make an agency more "disability friendly" by raising awareness of disability issues among all employees and managers. Recognizing this need, one very large agency has developed a Web page on the agency's intranet to distribute information to its employees and to collect requests for accommodations and training. Because of the geographic diversity of this agency and the relative autonomy of its components, using an intranet Web site appears to be an excellent approach.
Employees may more effectively request needed training and accommodations if they are aware that such opportunities exist. Agencies can help their employees become more productive by making information about these resources available to everyone and by streamlining the process for requesting such assistance. We highly recommend that all large agencies consider these approaches in providing assistive technology and training for their employees.
Some agencies, such as the Department of Education, have created software testing centers for all software used within their agency, and we commend them for their commitment and leadership in helping achieve the goals of section 508. However, not all agencies have resources available for such testing centers.
DSeveral agencies expressed a strong interest in the development of clear guidelines and training for procurement officers and information technology specialists regarding accessible software design. Other agencies believed that participation in inter-agency initiatives, such as the Universal Access Working Group (UAWG), was important to making their agencies more accessible.
Agency resources and knowledge should be shared between the agencies. Inter-agency initiatives, such as the UAWG, are an important step for fostering the participation of all agencies in a collective efforts of making federal agencies' information technology more accessible. However, what agencies need most is very specific guidance in their procurement decisions. For instance, if a very small agency using standard operating system software is considering several COTS office suites, it may not make sense for it to spend its resources testing that software when thorough tests have already been performed by other agencies using the same operating system. To facilitate the collection of this very specific information, several agencies recommended the development of an inter-agency testing center. Such a center could provide testing facilities for software products and could act as a central repository of information about accessibility issues involving different software packages. It may also help information technology specialists at different agencies "network" to share experiences with different software packages.
Several agencies also recommended greater involvement of the private sector in helping make software packages more accessible. These agencies recognized that, while much of their software was once custom developed software, the vast majority of their current software is COTS software produced by very large software companies.(11)
Other agencies expressed frustration that there is not enough sharing of information among agencies.
One final recommendation is based on agencies' objective responses. As indicated in analysis of Question 29 of the Software Accessibility Checklist, between one-third and one-half of all software surveys indicated that specialized training was unavailable for employees with disabilities.(12) As training is particularly important for users with disabilities, specialized training should be a paramount concern for all agencies:
DD. Recommendations
The Department recommends the following:
1. Training Needs Surveys. Each agency should develop and distribute "training needs" surveys to all employees. These surveys should explicitly address training needs for people with disabilities, especially those who use assistive technology in conjunction with mainstream software applications. EEOC should provide guidance to agencies on this issue.
2. Appropriate, Periodic Training. Each agency should train all IT personnel, procurement officials, "help desks" and other support personnel, and users with disabilities, regarding basic accessibility issues. To conserve resources, GSA and the Access Board, in consultation with other key agencies and inter-agency groups, should create training modules that can be shared among agencies. GSA and the Access Board should also make available lists of appropriate training vendors. Each agency should ensure that specialized training is available for users with disabilities for all software packages for which training is generally provided, including training provided by third-parties on behalf of agencies.
3. Software Compatibility Testing Centers. As agencies update and centralize their IT architecture, they should create software compatibility testing centers at which software can be evaluated for compatibility with existing agency platforms and with commonly used assistive technologies. Larger agencies may wish to establish their own compatibility testing centers. An inter-agency software compatibility testing center should be established to assist smaller agencies, larger agencies without testing centers, and private software manufacturers and developers. Centers at Department of Defense, Department of Education, the Social Security Administration, Department of Veterans' Affairs, and GSA can serve as models.
4. Documentation (Instructions, Help Files, User Manuals, Etc.). Many software applications have accessibility features of which most users, trainers, 'help desk' personnel, and others are unaware. Other software applications (such as word processors, Adobe Acrobat, etc.) can be used to create information products. Knowledgeable users can use these applications to create information products that are relatively accessible. Other people may inadvertently use the same applications in such a way that the information products they create are largely inaccessible. Each agency should require its software vendors to include clear documentation of the accessibility features and appropriate uses of their products to maximize accessibility.
5. "COTS Software Accessibility Manuals". Because many of the Federal Government's current software applications may continue to be used for a long time, federal agencies must make the most of the accessibility features built into currently-used software, rather than rely exclusively on procurement of new accessible software. GSA and the Access Board, in consultation with other key agencies and inter-agency groups, should consult with software manufacturers and should develop and distribute supplemental manuals for users of commercial off-the-shelf (COTS) software applications. These manuals should include clear instructions for maximizing the accessibility of COTS applications currently used by federal agencies and for promoting accessibility and minimizing barriers in the information products some COTS applications (such as Adobe Acrobat) are used to produce. Specific information, such as macros developed to provide shortcut keys where none previously existed, should be incorporated into these manuals.
6. Government-Wide, Low-Cost Programming Solutions. GSA and the Access Board, in consultation with other key agencies and inter-agency groups, should contact manufacturers of COTS software to determine whether software updates, containing programming "fixes" of barriers identified in this Report, can be purchased for a low fee and distributed throughout all federal agencies. Each agency that has already developed programming solutions to remove barriers to COTS applications should be encouraged to continue this work and to share their results with all appropriate agencies.
1. This document is available on the Department of Justice's section 508 Web site (www.usdoj.gov/crt/508). People with disabilities may request copies in Braille, large print, or on computer disk by calling 1-800-514-0301 (voice) or 1-800-514-0383 (TTY).
2. A "screen reader" is a software application that makes text available to people who are blind, who have low vision, or who have cognitive impairments or learning disabilities that affect their ability to read. Screen readers read in an artificial voice text that appears on a computer screen. Most screen readers use a variety of voices; they may change from a male voice to a female voice, for instance, to indicate an Internet link or highlighting. Screen readers can also be used in conjunction with refreshable Braille displays. Refreshable Braille displays are units that are equipped with pins that move up and down to form the "dots" of Braille characters. As the user reads along, he or she can advance the Braille characters to the next line (or go back, if desired).
3. The Department of Education (DOE) has led the Federal Government in promoting accessibility for persons with disabilities in software design. Its work has benefitted not only its own agency, but also many state and local governments and private organizations interested in making software accessible to all computer users. To this end, the DOE has assembled an Assistive Technology Team in the DOE's Office of the Chief Information Officer Technology Center. This office continues to test new software, assist manufacturers and agencies to understand accessibility issues in software design, and refine their own standards for accessible design.
4. Accompanying this analysis are 4 sets of appendices, which include tables and descriptions of the data provided by the agencies. These Software Appendices can be summarized as follows:
5. The percentages throughout the discussion of software are raw data, not weighted values. That is, they do not reflect any overlap that would exist when multiple components evaluated the same software application, nor do they reflect the number of people who use a particular application. The Department did not receive reliable usage statistics on which to perform the necessary calculations.
6. As a practical matter, developers should include "keyboard shortcuts" in their Microsoft Windows help system for their application, where appropriate.
7. On each of the "Checklists," the Department structured the objective-format questions such that the answer indicating a product was more accessible was almost always "yes," while the answer indication that a product likely contained barriers was usually "no." Each page of the Checklists accordingly stated, "Any 'no' answer may indicate a problem with accessibility." Some evaluators may have selected "not applicable" as a response, even when doing so was inappropriate, to avoid choosing the "inaccessible" answer.
8. Some components, however, may have included a "not applicable" response because they did not have any employees with disabilities using the software package evaluated. Given the importance of training for all users (particularly users with disabilities) and the fact that training needs for users with disabilities should be considered whenever any training program is developed (regardless of whether there are currently users with disabilities), components should always have specialized training available for users with disabilities. As shown in Software Appendix B (Question-by-Question Responses to the Software Accessibility Checklist, Statistics by Agency Size), of the 882 responses where components chose a "no" or "not applicable" response, 322 were "not applicable" responses (19.2%); and 560 were "no" responses (33.4%) . The other 794 components chose "yes" responses (47.4%).
9. Other agencies, including GSA's Center for IT Accommodation, the Social Security Administration, and the Department of Defense's CAP Center, also expressed a willingness to assist other agencies in performing comprehensive and meaningful self-evaluations.
10. Other reviewers evaluated software packages using only accessibility features built into the operating system (62 responses) or accessibility aids, such as screen enlargement software (12 responses). For a very small number of other software packages (5 responses), components responded that testing was unnecessary because the software did not provide a commonly used user interface (e.g., anti-virus software that is not activated or operated by the user).
11. Since the Federal Government is a valuable customer of information technology, section 508 requires that federal agencies develop, procure, maintain, and use electronic and information technology that is accessible to persons with disabilities. Private software developers have a very strong incentive for making their products accessible. Some software companies, such as Microsoft and Sun Microsystems, were active participants in the Access Board's Electronic and Information Technology Access Advisory Committee (EITAAC), which developed recommendations for the eventual Section 508 Standards to be issued by the Access Board. Private software companies will also play a valuable role in responding to the Access Board's Notice of Proposed Rulemaking.
12. In reference to Question 29, the range of percentages where specialized training was unavailable to users with disabilities can be explained by whether a "not applicable" was considered an acceptable response to this question.