| Home |
 |
This chapter contains the specific electronic and information technology (EIT) performance requirements related to the following subpart of Section 508:
EIT Technical Standard 1194.21, Software Applications and Operating Systems, Provisions (a) thru (l).
The requirements in this chapter cover the following:
• All software applications and operating systems used by the Postal Service (as defined by the Access Board), regardless of size or whether purchased or developed internally. "Software applications" refers to client-server and locally installed software applications that do not use a Web-based interface. Web-based information and applications are covered in Chapter 6, Web-based Information and Applications.
• All associated data, information, training material, and documents related to those software applications and operating systems.
Note: For applications that span more than one technical standard, you may need to synchronize general and specific requirements in this chapter with requirements given in other chapters in this handbook. For example, client-server application or application sub-system functionality usually must also comply with the requirements stated in Chapter 6, Web-Based Information and Applications. Software applications that include calls to video or multimedia or that are supersets of software that run on self-contained platforms or in kiosks may require synchronization with other chapters. When software applications are used to create informational output beyond direct interaction with the application itself, (e.g., reports, data files, dynamic forms, or media objects), this output must also be accessible to assistive technology users.
This chapter applies to anyone who buys or develops software applications and operating systems for the Postal Service (i.e., Postal Service employees, suppliers, contractors, and business partners). Software applications and operating systems include information technology solutions of all sorts, consisting of simple or complex purchases or development of software applications, operating systems, and all associated data, information, training material, and documents.
Each part of this chapter describes the specific requirements that support one or more provisions in the technical standards of software applications and operating systems. The technical standards of Section 508 were written primarily from a technology perspective. However, the Postal Service has consolidated some provisions to help Postal Service employees and business partners understand Postal Service compliance requirements from the perspective of designing for accessibility. Each specific requirement includes a rationale, techniques, testing methods, and references as shown below in section 5-2.
5-1, Overview
5-2, Keyboard Access (Provision §1194.21a)
5-3, Activated Accessibility Features (Provision §1194.21b)
5-4, On-Screen Focus (Provision §1194.21c)
5-5, User Interface and Programmatic Elements (Provision §1194.21d)
5-6, Consistent Use of Images (Provision §1194.21e)
5-7, Textual Information (Provision §1194.21f)
5-8, User-Selected Display Attributes, Color, and Contrast (Provisions §1194.21g and §1194.21j)
5-9, Animation (Provision §1194.21h)
5-10, Color Coding (Provision §1194.21i)
5-11, Video Frequency (Provision §1194.21k)
5-12, Forms (Provision §1194.21l)
Appendix 5-A, Checklist
Appendix 5-B, Testing Methods
Note: The exhibits used to illustrate various techniques that satisfy specific requirements often refer to the Microsoft Windows® operating system and its compatible applications. This is because the Microsoft Windows platform represents the largest base of installed systems within the Postal Service.
Software is the program that runs on electronic equipment. The general concept of software accessibility is that the assistive technology should work with the program to allow its features and functions to be understood.
Software developers are responsible for helping the screen reader understand the screen. For instance, a mouse can be used with a piece of software, but blind users do not use mice. They need another method to understand the functions of a toolbar, radio buttons, push buttons, drop-down menus, or pop-up messages explaining the function of an icon.
Since several different programming languages are used in software and operating system coding, specific code examples and techniques cannot be provided. The main goal of this chapter is to help developers create software applications that recognize and maximize the capabilities of the accessibility features installed and activated by a user (e.g., native hardware and operating system features or installed assistive technologies aids). Developers are required to make specific applications compliant with Section 508 by developing their own methods and approaches that result in compliant software. There are two main ways to do this. First, the developer can make the software application accessible using the native operating system accessibility features or, second, the developer can make the application compatible with assistive technologies. Section 3-3, Assistive Technologies, lists the assitive technologies with which software applications must be tested with in the postal computing environment.
Accessibility is accomplished by designing software that accommodates the widest range of users, including those with disabilities. Listed below are some general requirements that will help the Postal Service ensure continued accessibility of software applications and operating systems:
• The Postal Service should develop and procure software applications that take advantage of hardware and operating system built-in accessibility features when those features are available to both end users and software developers.
• The Postal Service will maintain standards for the following categories of assistive technologies that people with disabilities use to access software applications and operating systems:
• Screen magnifiers: Help visually impaired people by allowing them to enlarge any part of the screen (i.e., as with a magnifying glass).
• Screen readers: Help people who are blind by making on-screen information available as synthesized speech or for display as refreshable Braille.
• Voice input aids: Help mobility- or dexterity-impaired people by allowing them to control the computer with their voice instead of with a mouse or keyboard.
• On-screen keyboards: Help people who are unable to use a standard keyboard by providing an on-screen keyboard that can be used with a pointing device.
• Keyboard filters: Help people who have trouble typing by compensating for erratic motion, tremors, or slow response time.
• Alternative input devices: Help people who would prefer to control their computer with a device other than a keyboard or mouse.
• The Postal Service will develop software applications that recognize and maximize the capabilities of the accessibility features installed and activated by a user (e.g., native hardware and operating system features as well as installed accessibility aids). Software developers should do the following:
• Support native operating system and activated accessibility features for major operating systems that are integrated with input and output devices (e.g., keyboard, sound, display, or mouse). Standards for each operating system related to each specific requirement are shown in the "References" area under each specific requirement.
• Use standard controls for particular operating systems where possible (e.g., menus, buttons, lists, or windows). These standard controls often already support native operating system accessibility features. Using them will often eliminate the need for software to provide explicit accessibility support, unless the behavior of the standard controls has been enhanced.
• Be careful when using custom controls or enhancing standard controls, because accessibility aids may have difficulty identifying them (i.e., accessibility aids require specific information to work successfully with screen elements). When custom or enhanced standard controls are used, developers must use appropriate accessibility interfaces or application programming interfaces (APIs) (e.g., Sun's Java Access Bridge, Microsoft Active Accessibility, window messaging, off-screen model, etc.) to provide object information to accessibility aids. The information that must be provided by objects includes name, location, type, associated values, parent control, logical order for navigation, and event notifications, such as focus gain or loss.
• Provide flexibility in using a variety of input methods (e.g., keyboard or mouse) and output methods (e.g., color, sound, images, or text).
• Query accessibility aids in use by the operating system and configure the software applications automatically. For example, a Microsoft Windows application can check Windows system information (i.e., SystemParameterInfo) to determine when a screen reader is in use (i.e., SPI_GETSCREENREADER). Windows will also invoke a message when system information is changed so that the software can be reconfigured.
Finally, Postal Service employees are required to register all software applications and operating systems in the Enterprise Information Repository (EIR) at http://eir. This information will be used to report compliance and includes any related Section 508 noncompliance issues.
When testing software applications for compliance, it is important to be aware that a software application can include only functionality that is supported by the operating system on which it executes. For example, an application running on Microsoft Windows can provide all the graphical functionality that users have come to expect from the current generation of personal computers. However, if those same users operate their computers in MS-DOS operating system mode, they are restricted to a primarily character-based environment with little graphical capabilities. It is crucial to be aware of the software environment the user is accessing when considering review and accessibility compliance with Section 508. In addition, it is important to be cognizant of the functionality available to users with disabilities via the accessibility aids available on the operating system in use.
Manual testing, using the testing methods described in this chapter, is mandatory, because it simulates use by assistive technology users. Automated testing tools or integrated development environment (IDE) features can help automate these methods, but automated testing must be accompanied by manual testing. For example, a developer can use IDE tools to test for valid syntax (e.g., titling of all windows, naming of all objects, inclusion of alternative text, or closing of tags), but a manual inspection must still be done to validate semantics and proper rendering. In other words, the meaningfulness of the window titles or alternative text must also be considered for the end user who uses assistive technology.
When software applications are designed to run on a system that has a keyboard, software application functions must be executable from a keyboard, if the function itself or the result of performing the function can be identified or labeled with text (Section 508, Provision §1194.21a).
Keyboard access is essential for those who cannot use a mouse or another method to interact with a computer. People who are unable to see the screen or accurately control and use a mouse must be able to use the keyboard to access menus, toolbars, windows and dialogs, controls, and other software application and operating system user interface elements.
Operating system platforms use standard keyboard access keys and key combinations - called keyboard equivalents - which must be provided for in software applications. Keyboard access to controls must be provided in a logical order that makes sense to people who are visually impaired. Visually impaired users often explore window controls sequentially instead of scanning an entire window as sighted users would. Therefore, the contents of all application windows and dialogs must also be understandable by people who are visually impaired.
Provide the ability to navigate to and select each menu and menu item with standard access keys. This includes the menu bar, system menu, and context-sensitive menus.
Exhibit 5-2.2.1
Example of Keyboard Access to a Menu
|
Second, the user can access the menu items by pressing various keyboard equivalents (i.e., "shortcut keys" in the Windows Operating System) that are indicated in underlined characters (e.g., "R" key to restore the window size, "N" key to minimize the window, and "C" key to close the window). Screen readers will read aloud the menu item followed by the keyboard equivalent (e.g., "Restore," "R"). Third, the user can access these menu commands directly by typing the keyboard equivalent and not even invoking the menu. For example, the active window could be closed by typing the defined keyboard equivalent (ALT+ F4). |
Provide redundant menu items that allow users to access all toolbar actions or provide keyboard access to toolbars. Toolbar commands provide convenient access to frequently used functionality (i.e., saving or printing a file). However, toolbar objects are sometimes not available from the keyboard (i.e., they are not within the tab order of the window). Therefore, all toolbar functionality should be available through the menu items or documented access keys and key combinations.
Exhibit 5-2.2.2
Example of Keyboard Access to Toolbars
|
In this software application, all toolbars can be accessed using standard keyboard equivalents by first pressing the ALT key, then using CTRL+TAB to navigate sequentially between all available toolbars (e.g., standard, formatting, etc.) and toolbar items. Once a toolbar has been selected, specific toolbar items can be accessed using the keyboard ARROW keys. In Figure A, a "Save" toolbar item is selected as indicated by the blue highlight or outline surrounding the toolbar item's icon (i.e., a diskette). Pressing the RETURN key would activate the "Save" function just as if clicked on with a mouse. In addition, as shown in Figure B, this same "Save" function can be accessed via a keyboard accessible "File" menu by using ALT+F then pressing "S" or by CTRL+S. |
Provide the ability to move the focus between application windows, sections or panes of application windows, and dialogs using standard keyboard equivalents. It is common for software to use panes or splitter bars to display more information without requiring additional windows (e.g., Windows Explorer). Use standard keyboard equivalents to allow users to move, resize, minimize, restore, maximize, scroll, and close windows. Applications that employ nonstandard access keys and methods for performing these functions must provide and communicate the alternate keyboard access methods.
Exhibit 5-2.2.3
Example of Keyboard Access to Window Elements
|
In Figure A, the focus is currently on
the "Inbox" folder in
the "Folder List" window pane, as indicated by the blue
solid highlight around the word "Inbox." |
Provide the ability to operate every control in application windows and dialogs using the keyboard and to navigate logically between controls. Keyboard equivalents allow people to navigate between groups of controls (such as index tabs) and then select specific objects (i.e., check boxes, drop-down selection, or buttons) by using a combination of ALT, TAB, CTRL+TAB, the F6 key, and the ARROW keys. Pressing ENTER and SPACEBAR are conventions for operating controls.
Design navigation between controls using a logical tab order, so that the TAB key moves the keyboard focus from one control or item to the next. Normally, the tab order is from left to right and then top to bottom.
Allow users to scan the contents of application windows and dialogs before providing input by offering screen-level validation instead of control-level validation. When control-level input is required, valid, preselected default values prevent users from scanning through window controls sequentially without providing input. When it is not possible to preselect control-level input, use screen-level validation (i.e., validate user input when the user attempts to save all changes or submit input within the screen).
Exhibit 5-2.2.4
Example of Keyboard Access to Controls
|
This figure shows five tabbed groupings of related controls that can be accessed using the keyboard equivalent CTRL+TAB. The "Keyboard" group of controls is selected here. Within each grouping, the TAB key can be used to navigate logically among various controls such as check boxes and push buttons. The SPACEBAR key can be used to toggle the selection on the control that has focus (e.g., the "Use StickyKeys" checkbox has focus here). In addition, various dialog-level keyboard equivalents are offered, as each checkbox item and push button contains underlined characters that indicate a keyboard shortcut (e.g., pushing the "S" key will select the "Settings" for "StickyKeys"). |
Provide standard keyboard access keys or key combinations for functions that are most commonly used and that are normally provided through mouse operations. This includes commonly used commands such as text or object selection, clipboard commands (e.g., cut, copy, and paste), or graphic resizing.
Exhibit 5-2.2.5
Examples of Keyboard Access to Commonly Used Functions (p.1)
|
Exhibit 5-2.2.5
Examples of Keyboard Access to Commonly Used Functions (p.2)
|
Support keyboard equivalents that use operating system accessibility features that rely on latched and locked modifier keys (e.g., StickyKeys on the Windows platform). Developers must be aware of sequential keyboard access issues when creating nonstandard input routines. Beyond use of latched and locked modifier keys, appropriate on-screen focus and cursor representation must be provided (see Section 5-4, On-Screen Focus).
Exhibit 5.2.2.6
Example of Latched and Locked Keyboard Access
|
Manual inspection-based testing using the methods described in this chapter must accompany any automated tests. Some of these manual tests may be automated using testing tools or Integrated Development Environment (IDE) features, as long as testing occurs in the context of usage by assistive technology users.
Conduct a manual inspection of the software application without assistive technology to verify keyboard access. Unplug or disable all input devices except the keyboard, then attempt to access and operate the identified user interface elements that must be accessible using only the keyboard. See the references listed below for standard keyboard equivalents that should be tested on each platform. When nonstandard keyboard equivalents are used, ensure that they are communicated to the user via the application's user assistance. Whether using standard or nonstandard keyboard equivalents, the following keyboard operations should be tested:
a. Navigate to, display, and select each menu and menu item with keyboard equivalents. This includes the menu bar, system menu, and context-sensitive menus.
b. Access and select all functions provided on toolbars via redundant menu items or using keyboard equivalents (i.e., Alt+F4 or Ctrl+C). Ensure that all toolbar button functions can be performed using the keyboard.
c. Move the focus between application windows, sections or panes of application windows, and modeless dialogs using standard keyboard equivalents.
d. Move, resize, minimize, restore, maximize, scroll, and close windows using standard keyboard equivalents.
e. Navigate logically to every control in application windows and dialogs, and operate all controls using standard keyboard equivalents.
f. Perform functions that are normally provided through mouse operations, including commonly used commands such as text or object selection, clipboard commands (i.e., cut, copy, and paste) or graphic resizing using some keyboard access method (e.g., keyboard equivalents or menu items).
The following standard access keys and key combinations - which are normally specified in the platform's user interface style guide document - must be supported by software applications:
• Microsoft Windows Keyboard Design Guide
http://www.microsoft.com/enable/products/winkeyboard.htm
• Sun Java Application Design Guidelines: Keyboard
Operations
http://java.sun.com/products/jlf/ed2/book/HIG.Behavior3.html
• Sun Java: Developing Accessible JFC Applications
http://www.sun.com/access/developers/developing-accessible-apps/
• Macintosh Human Interface Guidelines
http://developer.apple.com/documentation/UserExperience/Conceptual/
AquaHIGuidelines/index.html
• UNIX Motif and CDE 2.1 Style Guide
http://zikova.cvut.cz/publikace/aix/motif/motifsg/toc.htm
• UNIX KDE User Interface Guidelines
http://developer.kde.org/documentation/standards/kde/style/basics/
index.html
• Gnome/Linux Keyboard Navigation for Gtk+2.0 Draft
http://developer.gnome.org/projects/gap/keyboardnav.html
Note: Postal Service developers and purchasing agents are strongly urged to obtain updated references for application or operating system accessibility references when designing or purchasing Postal Service applications.
Software applications must not disrupt or disable activated features of other products that are identified as accessibility features, if those features are developed and documented according to industry standards. Software applications also must not disrupt or disable activated accessibility features of any operating system, if the application programming interface (API) for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer (Section 508, Provision §1194.21b).
Assistive technology uses operating system accessibility features to provide information and feedback from software, making it easier for people with a variety of disabilities to use their computer. These accessibility features are activated and adjusted by the user and by assistive technology to make the on-screen focus, operation, and state of software components and information accessible via various input and output devices (e.g., keyboard, mouse, audio, or video).
For example, when a user tabs through an electronic form and the focus is on a radio button object, the user needs to know the following:
• That the object is a radio button.
• That the focus is on the radio button.
• That the radio button is selected.
Software applications must recognize and properly interact with the product or operating system's activated accessibility features without disrupting or disabling them. Software applications are required to use standard controls and reliable accessibility frameworks or application programming interfaces (APIs) that are documented by the manufacturer of the operating system or product.
Note that additional requirements for supporting user-selected display settings, which are often included in operating system accessibility features, are described in Section 5-8, User-Selected Display Attributes, Color and Contrast.
This accessibility requirement applies to all aspects of software application use including installation, operation, and removal.
Where possible, operating systems should provide accessibility features and application programming interfaces (APIs) for those features that make the operation and state of software application components and information accessible via various input and output devices (e.g., keyboard, mouse, audio, or video). The accessibility features and APIs should be documented by the manufacturer of the operating system so that software product developers can use them.
Where possible, use integrated standard operating system controls, frameworks, and APIs to provide object information, because they are integrated with operating system accessibility features. A control is defined as any user interface element or object that accepts input (i.e., menus, list boxes, and buttons). Use of integrated standard controls, frameworks, and APIs eliminates the need for additional programmatic work to expose an object's identity, role, and state. When using nonstandard controls, use reliable accessibility frameworks (or component object models) that use service interfaces, event systems, APIs, and proxies to provide object information for the nonstandard controls. Nonstandard controls must not disrupt or disable activated accessibility features. The information that must be provided about objects includes name, location, type, associated values, parent control, logical order for navigation, and event notifications, such as focus gain or loss.
Provide support for operating system audio accessibility features. These operating system features display visual indicators or cues when sounds are generated by certain operating system or software application events (e.g., flashing backgrounds, message or dialog windows, status indicators in a taskbar, or text messages in a status window, etc.). When software applications employ audio alerts, redundant visual cues must be provided. Software applications that use nonstandard controls must not disable or disrupt activated accessibility features. Note that when flashing is used, refer to the frequency guideline in section 5-11.
Exhibit 5-3.2.3
Example of Audio Accessibility Features
|
Manual inspection-based testing using the methods described in this chapter must accompany any automated tests. Some of these manual tests may be automated using testing tools or Integrated Development Environment (IDE) features, as long as testing occurs in the context of usage by assistive technology users.
Conduct a manual inspection of the software application to verify compatibility with operating system (OS) accessibility features. For each OS the software application runs on, list the set of operating system accessibility features (e.g., keyboard, audio/sound, display, mouse/input, or general). Then, do the following for each accessibility feature:
a. Turn on the operating system accessibility feature.
b. Exercise all software application functions to verify that information about associated controls (identity, role, and state) is accessible. When the focus is on the object or control, the assistive technology should be able to access and state the object name, its role (type), its state, and its current value.
c. Note any application function for which object or control name, role, state, and value is not accessible, or that disables, disrupts, or interferes with OS accessibility features.
d. Fix any functions that disable or interfere with OS accessibility features, then repeat this test to verify that the functions do not disable or interfere with OS accessibility features.
e. If object or control information remains inaccessible to the operating system and assistive technology, or if it continues to disable, disrupt, or interfere with activated accessibility features, fix then retest using this procedure.
• Microsoft Active Accessibility
http://msdn.microsoft.com/library/default.asp?url=/nhp/
default.asp?contentid=28000544
• Microsoft Developer Network: Accessibility
Information for Developers
http://msdn.microsoft.com/at/
• IBM Guidelines for "Java Accessibility API using JFC/Swing components or Custom Components"
http://www-3.ibm.com/able/guidelines/java/accessjava.html
• GNOME User Environment Accessibility Project.
http://developer.gnome.org/projects/gap/
The Accessibility Framework includes an Accessibility Toolkit
Application Programming Interface and an Assistive Technology
Service Provider Interface.
• Sun Java: Developing Accessible JFC Applications
http://www.sun.com/access/developers/developing-accessible-apps/
Note: Postal Service developers and purchasing agents are strongly urged to obtain updated references for application or operating system accessibility references when designing or purchasing Postal Service applications.
Operating systems and software applications must provide a well-defined on-screen indication of the current focus that moves among user interface elements as the input focus changes. The focus must be programmatically exposed, so that assistive technology can track focus and focus changes (Section 508, Provision §1194.21c).
The position on a screen where an action can occur is referred to as the focus. For example, when an item in a software application's menu bar is highlighted, this indicates that if the user clicks the mouse or presses the ENTER key, the associated feature will be invoked and that item has the focus. Providing a visual focus indicator - referred to as a cursor - allows someone to use a software application effectively. When a software application is being used by a person running assistive technology - especially those with visual or mobility impairments - the assistive technology must be able to discern and track the focus, so that it can describe, magnify, or manipulate the object for the user (e.g., a screen reader can translate information about the focused object into voice output).
Software applications must allow assistive technology to track the focused object and focus changes by programmatically exposing information about focused objects available to assistive technology. Software applications must also provide a visual indicator or cursor that identifies where the focus is, or where an action will occur if an input event (e.g., mouse click or keystroke) takes place.
Whenever possible, software applications must use standard controls to allow operating system accessibility features and assistive technology to access and track system focus. If nonstandard controls must be used, expose focus information to the operating and assistive technology and provide standard cursor representations.
Exhibit 5-4.2.1
Example of Using Standard Controls to Expose Focus Information
|
When a control is associated with another control or object (i.e., when interaction with one control affects another control or object), expose the information about each control to assistive technology. Visually impaired users may not be aware of on-screen changes resulting from the operation of a given control changes another control or object associated with the control the user operated. In this example, the software application must make sure the operating system is instructed properly that the change occurred so that any activated accessibility features or assistive technologies can process the change. This instruction is critical since the cursor moves with the system focus. In addition, associated controls can sometimes provide an automatic focus change (i.e., movement of the focus based on user operation of a control without additional user input such as a mouse click or keystroke).
This automatic focus change can be confusing to all users, especially people with visual impairments. When the focus is automatically changed, it is critical that associated information about changed, associated controls is exposed to assistive technology via the operating system (this exposure will also allow the operating system to move and or change the cursor).
Exhibit 5-4.2.2
Examples of Exposing Information for Associated Controls
|
Manual inspection-based testing using the methods described in this chapter must accompany any automated tests. Some of these manual tests may be automated using testing tools or Integrated Development Environment (IDE) features, as long as testing occurs in the context of usage by assistive technology users.
Conduct a manual inspection of the software application or operating system with and without assistive technology to verify that the on-screen focus is well defined.
a. Using only the keyboard and keyboard equivalents, navigate through the user interface of the operating system or software application (i.e., windows, menus, toolbars, and controls) to ensure that the focused object is tracked and that an appropriate operating system- standard cursor or highlight element is displayed for the various focused objects.
b. Use a screen reader to navigate through the user interface of the operating system or software application (i.e., windows, menus, toolbars, or controls) to ensure that the focused object is tracked and that a appropriate object information is read by the screen reader for the various focused objects. When the focus is on the object or control, the assistive technology should be able to access and state the object name, its role (type), its state, and its current value.
c. Use a screen magnifier to navigate through the user interface of the operating system or software application (i.e., windows, menus, toolbars, or controls) to ensure that the focused object is tracked and that an appropriate operating system standard cursor is displayed for the various focused objects.
d. Note any objects for which focus is not tracked, the object name, role, state, and value of which are not accessible to assistive technology, or which display an inappropriate standard cursor.
e. For the objects in question, fix then retest using this procedure.
• Microsoft Active Accessibility
http://msdn.microsoft.com/library/default.asp?url=/nhp/
default.asp?contentid=28000544
• Sun Java: Developing Accessible JFC Applications
http://www.sun.com/access/developers/developing-accessible-apps/
• UNIX/Linux GNOME User Environment Accessibility
Project
http://developer.gnome.org/projects/gap/
The accessibility framework includes an accessibility toolkit
application
programming interface and an assistive technology service provider
interface.
Note: Postal Service developers and purchasing agents are strongly urged to obtain updated references for application or operating system accessibility references when designing or purchasing Postal Service applications.
Sufficient information about a user interface element including the identity, operation, and state of the element must be available to assistive technology. When an image represents a program element or control, the information conveyed by the image must also be available in text as described in 5-7, Provision (f), Textual Information (Section 508, Provision §1194.21d).
People with disabilities use a computer with the aid of assistive technology such as a screen reader, screen magnifier, or Braille display. Assistive technology must be able to discern and track information about objects accessible to it so it can describe, magnify, or manipulate the object for the user (e.g., a screen reader can translate information about the focused object into voice output). To do so, assistive technology must be able to inform the user of the existence, location, role, and status of controls such as menus, toolbars, and other inputs (i.e., text inputs, checkboxes, radio buttons, or drop-down or list selectors).
Software applications must - using program code and user-visible text - provide information about all user interface elements so an assistive technology can locate and track the focus and tell the user what the focus object (identity) is as well as its role (operation), and state. For example, if you TAB through a form and focus is on a radio button, you need to know it is a radio button and whether or not it is selected.
Use standard controls to provide both displayed and underlying information about controls. Standard controls eliminate the need for additional development or programming to expose the information about the control's identity, role, and state (via text) to the operating system and to assistive technology. Information about controls is both displayed to the user (e.g., meaningful "ToolTips" or captions or meaningful window titles) and provided programmatically to assistive technology (e.g., windowing events, control role, or control state). This includes all window information (i.e., user-visible and underlying window titles or names), menu information, and toolbar information (i.e., user-visible or underlying alternate text description).
Exhibit 5-5.2.1
Use Standard UI Controls Example
|
This figure shows a "Security Warning" dialog box that is invoked by a Web browser software application that uses standard user interface controls. Because standard controls have been used properly, this dialog box is accessible to assistive technology. A screen reader would read the Window title, then the text of the warning message, the check box label ("Always trust content from Sun Microsystems, Inc.") and each label for the three push buttons ("Yes", "No", "More Info"). In addition, the default selection or focused object, the "No" button, is indicated clearly and available to assistive technology. |
When no other option is available, nonstandard controls must use reliable accessibility frameworks (or component object models) that use service interfaces, event systems, APIs, and proxies to provide object information to assistive technology.
Exhibit 5-5.2.2
Example of Using Reliable Accessibility Frameworks for Nonstandard UI Controls
|
This figure shows a floating toolbar in a word processing application. This toolbar uses nonstandard controls, but the information about the controls including their name, state, and value are accessible to assistive technology. For example, the highlight and line around the "F6-Next Window" object indicate that it has focus, and the label or ToolTip of "Next Window" would be read by a screen reader. |
Other user interface objects that are critical to the use of an application (i.e., images of text in a password-locked screen, an "About this Software," or other dialog box) must be accompanied by an accessible alternate text, equivalent in content and meaning.
Example of Key UI Object Accessibility
|
When system or application events cause an image to change automatically, expose the information about the changed image to assistive technology. Once this information is exposed, the operating system can allow activated accessibility features or assistive technology to process the change. If this is not possible, the software application must provide an alternate method to indicate the image change (i.e., use of a dialog window with accessible textual information that communicates the change).
Exhibit 5-5.2.4
Example of How to Make Changed Images Accessible
|
Some operating systems and software applications require that users respond or be active within a certain time limit to provide security and other features. When the time limit expires, a "timeout" can result, which can, in turn, cause an automatic refresh, an update of screen content, a redirection to another resource, a termination of a secure session, a disconnection, or a standby status due to resource limits.
Users with disabilities may require additional time to navigate, perform functions, and read information provided by operating systems and software applications. When a system or application uses a timeout, the timeout information should be provided to the user before use of the application.
Screen content must not be automatically updated or refreshed unless the update is based on a user selection or user notification that an update is going to occur. Resetting an application to an initial state or resets resulting from automatic screen updates should include an informative error message, if possible.
USPS Information Technology ACE Platform operating system and applications requiring the use of an inactivity timeout timer will obtain the timer settings from a global parameter defined nationally. This global parameter must not identify users by their disability or by and other personal information. Refer to ACE Standards & Guidelines for more information. Web-based applications have specific timeout requirements addressed in Section 6-16, Timed Responses.
Exhibit 5-5.2.5
Example of Timeout Security Dialogs for an Operating System
|
Some examples of a timeout security dialog for an operating system. Figure A shows the Windows 2000 Professional "Unlock Computer" dialog box. This computer is in use and has been locked after "timing out" based on some system standby settings provided by the operating system. Figure B shows the Windows 2000 "Power Options" control panel, where the user may adjust the inactivity period that the operating system will use to set the secure timeout of the system and display. |
Manual inspection-based testing using the methods described in this chapter must accompany any automated tests. Some of these manual tests may be automated using testing tools or Integrated Development Environment (IDE) features, as long as testing occurs in the context of usage by assistive technology users.
Conduct a manual inspection of the software application or operating system with assistive technology to verify that both underlying (programmatic) and user-visible information about user interface elements is both accessible and meaningful.
a. Use a screen reader to navigate through the user interface of the operating system or software application (i.e., windows, menus, toolbars, controls) to ensure that the focused object is tracked and that appropriate object information is read by the screen reader for the various focused objects. When the focus is on the object or control, the assistive technology should be able to access and state a meaningful object name, its role (type), its state or its current value.
b. Perform the same tests listed above using a screen magnifier to ensure that the application can be magnified.
c. Note any object for which focus is not tracked, or for which a meaningful object name, role, state and value is not accessible to assistive technology.
d. For the objects in question, fix then retest using this procedure.
• Microsoft Active Accessibility
http://msdn.microsoft.com/library/default.asp?url=/nhp/
default.asp?contentid=28000544
• Sun Java: Developing Accessible JFC Applications
http://www.sun.com/access/developers/developing-accessible-apps/
• UNIX/Linux GNOME User Environment Accessibility
Project
http://developer.gnome.org/projects/gap/
The Accessibility Framework includes an Accessibility Toolkit
Application Programming Interface and an Assistive Technology
Service Provider Interface.
• USPS Information Technology ACE Standards &
Guidelines
http://it.usps.gov/pls/itprodnp/page?psite_id=10&pnode_id=273
Note: Postal Service developers and purchasing agents are strongly urged to obtain updated references for application or operating system accessibility references when designing or purchasing Postal Service applications.
When images are used to identify or represent controls, status indicators, or other user interface or programmatic elements, the meaning assigned to those images must be consistent throughout a software application (Section 508, Provision §1194.21e).
Images can represent concepts or user interface elements within a software application (e.g., file folder, slider bar, or hourglass). Consistent use of images is critical for users to understand their meaning. The user-visible textual information (i.e., "ToolTips," alternative text) presented with images must also be consistent throughout the software application (i.e., "file folder" icon must have the same meaning and label throughout to indicate a function such as "open file").
Changing an image to identify status or events can be confusing to users and to assistive technology. When such changes occur, software applications must provide textual information about the change, using program code and user-visible text. The techniques in Section 5-5, User Interface and Programmatic Elements, describe ways to provide this textual information.
When an image identifies a user interface element (or application function), the meaning assigned to that image must be consistent throughout the application. In addition, consistent textual information (i.e., a label or description) must be provided and must be consistent in meaning.
Exhibit 5-6.2.1
Example of Consistent Meaning of Images
|
Manual inspection-based testing using the methods described in this chapter must accompany any automated tests. Some of these manual tests may be automated using testing tools or Integrated Development Environment (IDE) features, as long as testing occurs in the context of usage by assistive technology users.
Conduct a manual inspection of the software application or operating system with and without assistive technology to verify that images and their labels are consistent and meaningful.
a. List all images used in the user interface to represent a control or provide access to a tool, including their associated label. Identify the application functions associated with them.
b. Navigate the software application through usage scenarios and identify where the same image or label appears in different phases of the scenarios.
c. For duplicate images and labels, note where the image or label represents different application functions.
d. For duplicate images and labels that represent different functions, resolve the difference by changing image(s) and/or label(s) to ensure that the same image does not represent different functions.
e. Repeat steps b through d with screen reader and screen magnifier assistive technology, to ensure that the labels for images are stated (i.e., read) and that they are consistent and meaningful. When the focus is on the image object, the assistive technology should be able to access and state a meaningful object name, its role (type), its state, or its current value. Note any images functioning as an user interface object for which a meaningful object name, role, state, or value is not accessible to assistive technology.
f. For the image objects in question, fix then retest using this procedure.
• Sun Java Look and Feel Design Guidelines: Application
Graphics
http://java.sun.com/products/jlf/ed2/book/HIG.Graphics.html
Note: Postal Service developers and purchasing agents are strongly urged to obtain updated references for application or operating system accessibility references when designing or purchasing Postal Service applications.
Software applications must provide textual information using operating system functions for displaying text. The minimum information that must be made available is text content, text cursor location, and text attributes (Section 508, Provision §1194.21f).
The operating system is the "core" computer software that controls basic functions, such as receiving information from the keyboard, displaying information on the computer screen, and storing data on the hard disk. Other software applications - including assistive technology - use the standard protocols dictated by the operating system for displaying their own information or processing the output of other computer programs. For example, assistive technology will use operating system standard protocols to track the location and placement of both text and graphics, understand the attributes of text (i.e., dialog title, font, size, color, and style), and watch information being copied from one location to another (i.e., information being erased or overwritten by other text or graphics).
When software applications use nonstandard protocols for writing text on the screen or use graphics, assistive technology may not be able to interpret the information. This guideline does not prohibit or limit an application programmer from developing unique display techniques. It requires that when a unique method (i.e., a nonstandard protocol) or nonstandard text control is used, the text should also be written to the screen through standard operating system functions for displaying text.
Use standard operating system and application API calls to provide text to any user interface or programmatic elements. Standard operating system API calls eliminate the need for additional development or programming to expose text information, name, identity, role, and state to the operating system for use by assistive technology.
Textual information refers to both the text provided to or manipulated by the user (e.g., text input boxes, text displays, tool tips, captions, window titles, dialog text content, copied text, or "about this software" text information) and to textual information provided programmatically through the operating system for use by assistive technology.
When no other option is available, refer to the techniques stated in Section 5-5, User Interface and Programmatic Elements, regarding nonstandard controls. For nonstandard text display, make text attributes (i.e., character set, font, size, color, or style) available to the operating system for use by assistive technology.
Exhibit 5-7.2.1
Example of Using Standard OS Functions to Provide Textual Information
|
Software applications must make text cursor (i.e., system text caret) information available to the operating system for use by assistive technology. Assistive technology (e.g., screen readers or screen magnifiers) needs to know the position and contents of the focused object, so it can describe, magnify, or manipulate the object for the user. For additional techniques, refer to Section 5-4, On-Screen Focus.
Exhibit 5-7.7.2
Examples of Making Text Cursor Information Accessible
|
Manual inspection-based testing using the methods described in this chapter must accompany any automated tests. Some of these manual tests may be automated using testing tools or Integrated Development Environment (IDE) features, as long as testing occurs in the context of usage by assistive technology users.
Conduct a manual inspection of the software application with assistive technology to verify that text information in all client windows is accessible.
a. Navigate the software application using a screen reader (e.g., JAWS) through usage scenarios that cover all core functionality for the software application.
b. As you do, verify that the screen reader reads and provides meaningful information about text elements in all client windows (text content, text cursor location, and text attributes).
c. Verify that "About" information for the software application (i.e., software version, serial number, etc.) is accessible. This information is often critical basic information for use of software, including customer support. It is often located either in an "About" dialog box, or on a "splash" screen, or both.
d. Document which text elements are not accessible via the screen reader, including text content, text cursor location, and text attributes.
e. For the text element(s) in question, fix, then retest using this procedure.
• Microsoft
Input Method Editor and Text Services Framework
Accessibility
http://msdn.microsoft.com/library/default.asp?url=/
library/en-us/dnacc/html/ATG_TSF.asp
• Sun Java: Developing Accessible JFC Applications
http://www.sun.com/access/developers/developing-accessible-apps/
Note: Postal Service developers and purchasing agents are strongly urged to obtain updated references for application or operating system accessibility references when designing or purchasing Postal Service applications.
Software applications must not override user-selected contrast and color selections and other individual display settings (i.e., color schemes and background patterns that provide sufficient contrast, fonts, and sizes for the display of user interface elements). When a software application permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels must be provided (Section 508, Provision §1194.21g and Provision §1194.21j).
People who cannot differentiate between certain color combinations or have some other visual impairment may have difficulty navigating or interpreting software application or operating system content that depends on the ability to identify color or differentiate between colors with low contrast (i.e., when foreground and background colors are too close to the same hue or value). People who are sensitive to bright displays or who cannot focus on a bright screen need color choices that provide a softer background and appropriate foreground color. Persons with disabilities often increase their efficiency with a system by selecting operating system-level display settings that affect the presentation of user interface elements (e.g., windows, menus, toolbars, icons, standard controls, or display resolution).
Software applications must use standard display protocols to inherit operating system-wide display settings, offering the user a consistency of presentation in the user interface. When a software application disables or interferes with these operating system-wide settings, the system's accessibility is reduced. When software applications offer nonstandard display options, there must be an option that allows the user to use whatever settings are already in place (i.e., operating system-level display settings) instead of application nonstandard display settings. For example, the application can offer a checkable menu item called "Use System Display Settings" under a "View" or "Options" Menu. When software applications allow users to customize colors, the application must provide more than just a variety of color choices. The color choices must provide different levels of contrast.
Design software applications so that they inherit operating system (OS)-level display settings. These settings can be selected by the user and include color schemes and background patterns that provide sufficient contrast, fonts, and sizes for the display of user interface elements (e.g., windows, menus, toolbars, icons, standard controls, or display resolution). When some controls (e.g., menus) inherit these display settings, they can be resized automatically (e.g., application menus or contextual menus can expand to display menu items in the user-selected font and font size).
If a software application overrides these user-selected OS-level display settings or provides nonstandard display settings, the application must allow the user to select these settings within the application. These application-level settings must include the minimum display options offered by the operating system (e.g., a choice of color schemes that provide sufficient contrast between colors, fonts, or sizes).
Avoid use of fixed-size windows and dialog boxes. Provide options for either scaling the contents of windows or displaying more information in an alternate view. Also, use scroll bars for windows or individual controls when the content will no longer fit in the window. Do not display images behind or over text, as users in high-contrast settings cannot view them.
Exhibit 5-8.2.1
Example of OS-Level and Application Display Settings
|
Operating systems and software applications should avoid using color combinations that commonly are problematic for people who cannot differentiate between certain color combinations or who have other visual impairments. Do not use the following color combinations: green and red, green and blue, red and brown, and white and light green. Instead, use color combinations that differ significantly in hue, intensity, and value and provide sufficient contrast.
Exhibit 5-8.2.2
Selecting Appropriate Color Combinations
|
Manual inspection-based testing using the methods described in this chapter must accompany any automated tests. Some of these manual tests may be automated using testing tools or Integrated Development Environment (IDE) features, as long as testing occurs in the context of usage by assistive technology users.
Conduct a manual inspection of the software application without assistive technology to verify that the application inherits operating system-level display settings.
a. Access the operating system display preferences and select values for various individual display attributes (e.g., large fonts, nonstandard foreground, background, window element colors, and high contrast).
b. Navigate the software application (manually or using a test suite) through usage scenarios that cover all core functionality for the software application.
c. As you do, verify that the operating system-level display settings are maintained (i.e., color, contrast, background patterns, fonts and font sizes for windows, menus, toolbars, icons, standard controls, and display resolution). If the application supports a magnification or zoom function, verify that the display settings are maintained while being magnified.
d. Note and document any user interface elements or areas of the application that disable or change the display attributes without selection by user.
e. If the application offers nonstandard display settings, verify that a "Use System Display Settings" option is available. Also, verify that the application offers at least three custom display settings that provide high contrast and at least one custom display setting that provides a soft background with low contrast.
f. Ensure that problematic color combinations (green and red, green and blue, red and brown, and white and light green) are not used. Check the combinations used by setting the operating system or monitor display settings to high contrast. Often, these settings are located in the operating system's accessibility features, display appearance, or both.
g. Replace any problematic combinations with combinations that provide sufficient contrast (i.e., combinations that differ significantly in hue, intensity, and value).
• Web/Computer Color Chart for the Color Blind
http://www.toledo-bend.com/colorblind/colortable.html
• Considering the Color Blind: Web Techniques
http://www.webtechniques.com/archives/2000/08/newman/
• Microsoft Developer Network: "Can Color Blind People See Your Site?" http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/dnhess/html/hess10092000.asp
• Human-Computer Interaction Resource Network: Color
Vision
Deficiencies
http://www.hcirn.com/atoz/atozc/cvd.php
Note: Postal Service developers and purchasing agents are strongly urged to obtain updated references for application or operating system accessibility references when designing or purchasing Postal Service applications.
When animation is displayed, the information must be displayable in at least one nonanimated presentation mode at the option of the user (Section 508, Provision §1194.21h).
Animations that are controlled and displayed by software applications or operating systems (e.g., animated push-button controls or status indicators) are difficult for assistive technology to interpret. They can therefore pose serious problems for users that rely on screen readers or other assistive technology.
Software applications and operating systems must ensure that animated user interface elements are displayable in at least one nonanimated presentation mode. To do so, applications must offer a disable feature or an alternate format or access method for all animated user interface elements.
This guideline pertains to animated user interface elements displayed or controlled by the software application or operating system. Additional guidelines that relate to animation are in Chapter 6, Web-Based Intranet and Internet Information and Applications and Chapter 8, Video and Multimedia Products.
When operating systems or software applications use animated user interface elements to convey meaning, they must offer nonanimated alternate formats that provide equivalent information (e.g., user-visible or programmatically accessible textual information). Decorative animated user interface elements (e.g., visual transition effects or menu animation) do not require an alternate format if they are not used to convey meaning.
If animated user interface elements are used as a control or as an "access method" (e.g., the Microsoft Windows Office Assistant described in exhibit 5-9.2.2), the operating system or software application must offer an alternate access method. For example, the Microsoft Windows Office Assistant described in exhibit 5-9.2.2 offers a redundant way to access the main help system that can also be accessed by pressing the F1 key or by selecting from the "Help" menu.
Exhibit 5-9.2.1
Example of Alternate Formats or Access Methods for Animated Elements
|
Because animated UI elements can interfere with activated accessibility features of the operating system or with assistive technologies, operating systems or software applications must provide an option to disable the animated elements (i.e., a preference setting). Ensure that alternate formats or alternate access methods are available when animated UI elements are disabled (see Technique above). For more information, refer to Section 5-3, Activated Accessibility Features.
Exhibit 5-9.2.2
Examples of Offering User Preferences for Disabling Animations
|
||||
Manual inspection-based testing using the methods described in this chapter must accompany any automated tests. Some of these manual tests may be automated using testing tools or Integrated Development Environment (IDE) features, as long as testing occurs in the context of usage by assistive technology users.
Conduct a manual inspection of the operating system or software application without assistive technology to verify that animations can be disabled and that critical information is conveyed without animation.
a. Navigate through the operating system or software application through usage scenarios that cover all core functionality for the system or application. Note where animated user interface elements are used to convey meaning.
b. Ensure that, for all animated user interface elements used to convey meaning, the system or software offers a nonanimated alternate format that provides equivalent information (e.g., user-visible or programmatically accessible textual information).
c. For animated user interface elements used as controls or as an "access method" (e.g., the Microsoft Windows Office Assistant), ensure that the system or application offers an alternate access method (i.e., a redundant way to access the help system for the Microsoft Windows Office Assistant, such as pressing the F1 key or the "Help" menu item).
d. Check for a method to turn off or disable (as a preference) animated user interface elements individually in the system or application. Ensure that alternate formats or alternate access methods are available in place of the disabled animated user interface elements.
• Sun Java Application Design: Animation
http://java.sun.com/products/jlf/ed2/book/HIG.Visual4.html
Note: Postal Service developers and purchasing agents are strongly urged to obtain updated references for application or operating system accessibility references when designing or purchasing Postal Service applications.
Operating systems and software applications must not use color as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element (Section 508, Provision §1194.21i).
People who cannot differentiate between certain color combinations, are otherwise visually impaired, or who are blind may have difficulty using software applications or interpreting content that depends on the ability to identify color. In addition, when foreground and background colors are too close to the same hue, such people may not be able to distinguish between them.
Operating systems and software applications should not use color as the only method for conveying information, indicating an action, prompting a response, or distinguishing a visual event. Using color to enhance the identification of important features of the interface is acceptable as long as other methods of identification are also used (e.g., alternative or descriptive text, or image-based enhancement).
Operating systems or software applications must not use color alone to convey information, indicate an action, prompt a response, or distinguish an important visual event. For example, do not instruct a user to "select an item from those listed in green." Instead, relay that information without referring to color. If color is used, provide an accessible alternate format or method, such as a textual label or text formatting, to convey the equivalent information (e.g., use color and boldface text to indicate highlighted information).
Exhibit 5-10.2.1
Example of Combining Color With Alternate Formatting
|
This figure shows three distinct window display areas separated by panes in an e-mail client software application. The window areas include a "Folder List" area (shown on the left), a message listing area (shown on the upper right), and a message preview area (shown in the lower right). In the "Folder List" area, a number in parentheses is shown in blue to indicate the number of unread messages in the folder. Color is not used here alone to convey this important information; the folder names that contain the unread messages (i.e., "Deleted Items," "Inbox") are also shown in boldfaced text. |
Manual inspection-based testing using the methods described in this chapter must accompany any automated tests. Some of these manual tests may be automated using testing tools or Integrated Development Environment (IDE) features, as long as testing occurs in the context of usage by assistive technology users.
Conduct a manual inspection of the operating system or software application without assistive technology to verify that critical information or calls to action are conveyed without dependence on color alone.
a. Navigate through the operating system or software application through usage scenarios that cover all core functionality for the system or application.
b. Identify user interface elements that use color to convey meaning, indicate an action, prompt a response (e.g., error messages), or distinguish an important visual event. Include elements that change color based on some event (e.g., a new e-mail message is red when unread and then changes to black when read).
c. Ensure that, for all elements that use color to convey critical information or meaning, there is an alternate method used to convey the same information that does not rely on color (e.g., user-visible or programmatically accessible textual information). Alternate methods can include text labels or text formatting.
• W3C Accessibility Guidelines: Colors
http://www.w3.org/TR/WCAG10-TECHS/#tech-color-convey
• Sun Java: Developing Accessible JFC Applications
http://www.sun.com/access/developers/developing-accessible-apps/
Note: Postal Service developers and purchasing agents are strongly urged to obtain updated references for application or operating system accessibility references when designing or purchasing Postal Service applications.
Software must not use flashing or blinking text, objects, or other user interface elements having a flash or blink frequency between 2 and 55 cycles per second (2.0 Hz and 55.0 Hz). If provided, offer a way to change the frequency or disable flashing altogether (Section 508, Provision §1194.21k).
User interface elements and screen items that flash or blink can cause seizures or other involuntary responses, particularly if they flash in high intensity, with high contrast, and in the frequency range between 2 and 55 cycles per second (2.0 Hz and 55.0 Hz). The 2.0 Hz limit was chosen by the Access Board to be consistent with proposed revisions to the ADA Accessibility Guidelines that, in turn, are being harmonized with the International Code Council (ICC)/ANSI A117 (ANSI A1117.1-1998) standard, "Accessible and Usable Buildings and Facilities," which refers to a 2.0 Hz limit.
Operating systems and software applications must not use flash or blink rates in the range stated above. This includes, but is not limited to, flashing text, rapid screen writes, graphics that turn on and off, and repeatedly changing or animated user interface elements. If software uses flashing or blinking user interface elements, offer a feature that allows the user to change their frequency or disable them.
Software applications must avoid providing user interface elements that flash or blink in the frequency range between 2 and 55 cycles per second (2.0 Hz and 55.0 Hz) and that have a high level of contrast. Contrast means a difference in visual attributes (i.e., hue, lightness, saturation) of an object's foreground and background.
One possible development technique involves setting the flashing or blinking elements to the operating system cursor blink rate. The cursor blink rate can be set by the user, and can be set to a range between 0.2 and 1.2 seconds. The software application can use the cursor blink rate to control the blink rate of other user interface elements.
When software applications do provide flashing elements, development techniques must be used to allow the user to control certain aspects of the flashing element's flash or blink rate (so as to alleviate the risk of producing adverse physical affects). These development techniques include the following:
a. Providing the user with the ability to adjust the flash speed.
b. Minimizing the area of the screen that is flashing (smaller areas are less likely to cause seizures).
c. Avoiding flashing that has a high level of contrast between the states (some individuals are more susceptible to high-intensity flashing).
d. Disabling the flashing altogether.
Exhibit 5-11.2.1
Example of Using Only Acceptable Flashing and Contrast Ranges
|
This figure shows the Microsoft Windows XPTM Operating System's "Display" Accessibility Options control panel, which includes an option to allow users to set the cursor blink rate. This can be accessed by clicking the "Start" menu, then "Control Panels," then "Accessibility Options: Display (tab)." In the "Cursor Options" area of this control panel, users can click and move the "Blink Rate" slider to change the cursor blink rate. The rate can be set to 12 different options ranging from None (no flash or 0 milliseconds) to Fast (1.2 seconds). Developers of Windows-based software applications can set the software application to query this setting by calling "GetCaretBlinkTime." Aligning any blinking software user interface elements with this setting will help ensure acceptable flash rates for individual users. |
Manual inspection-based testing using the methods described in this chapter must accompany any automated tests. Some of these manual tests may be automated using testing tools or Integrated Development Environment (IDE) features, as long as testing occurs in the context of usage by assistive technology users.
Conduct a manual inspection of the software without assistive technology to test for acceptable frequency and a disable function for all flashing or blinking elements.
a. Navigate the software application through usage scenarios that cover all core functionality.
b. Search for flashing or blinking text, objects or other user interface elements. Also, search for elements that employ a quick change from dark to light (similar to strobe lights).
c. Use an electronic tester (i.e., screen calibrator) or a software test feature to determine the time interval between flashes for all blinking or flashing user interface elements.
d. If any flashing or blinking objects cannot be tested, they will need to be omitted from the software application altogether.
An example of keyboard
access to a global window menu that contains
commands for manipulating windows. The figure shows a global window
menu that is a standard control in the Microsoft Windows operating
system. The menu can be accessed from any active window by pressing
ALT and SPACEBAR at the same time.
An example of toolbar accessibility in a word processing
software application. 
An example of keyboard access to three distinct window
display areas separated by panes in an e-mail client
software application. 
An example of keyboard access to controls in the Windows
XPTM
operating system dialog window that allows the user to select
"Accessibility Options." 
An example of using standard user interface
controls to make UI and programmatic
elements accessible to assistive technology. 
An example of using reliable accessibility
frameworks to make information about
nonstandard user interface controls
accessible to assistive technology. 
An example of combining
color with another
alternate format to
convey important
information. 
An example of using acceptable flashing and contrast
ranges.