These provisions are applicable for both software applications and operating systems. They address program features that must be contained in software for the product to meet the standards. Because there are many programming languages from which a software producer may select, it is impossible to give specific coding techniques. In some cases it is possible that a particular programming language may not possess the features necessary to fulfill these requirements. In those instances, another language for creating the program would most likely have to be considered for the product to meet the standards.
To meet the standards, a product can either build all accessibility features in, or be compatible with assistive technology. Many of the provisions in this section are required to make software compatible with assistive technology. For example, how text is to be written to the display is required so assistive technology can read the text output of a program. Therefore, if the software is running on a product, such as a desktop computer, where it is possible to add assistive technology, that software must comply with this section.
No. By studying these provisions, a software producer can gain an understanding of what is to be achieved. However, as stated in 1194.5, equivalent facilitation, the provisions are not intended in anyway to discourage producers from developing their own approach to achieving the end result. Alternative approaches through equivalent facilitation are allowed as long as the alternative provides equivalent or greater access than the approach specified in these provisions.
(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.
When keyboard access to a programs' controls and features is provided, a person who cannot use a mouse or other pointing device will still be able to run the product. For example, a person with a disability that affects dexterity may find it impossible to move or hold a pointing device with enough accuracy to activate desired features. A person who cannot see the screen, therefore relying on assistive technology, may have no problems moving the pointer but will be unable to determine what is being pointed to.
All actions that can be identified or labeled with text are required to be executable from a keyboard. For example, most of the menu functions even in common drawing programs that allow a user to open, save, size, rotate, and perform other actions on a graphic image can all be performed from the keyboard. However, providing keyboard alternatives for creating an image by selecting a "drawing tool", picking a color, and actually drawing a design would be extremely difficult. Such procedures require the precise level of control afforded by a pointing device (e.g., a mouse) and cannot be given text labels because there is no way to predict what action the user plans to perform. Therefore, when a programmer is determining which functions need keyboard access, the best rule of thumb is to add keyboard shortcuts to any feature where the function can be identified with a text label.
(b) Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer.
Many commercially available software applications and operating systems have features built into the program that are labeled as accessibility features. These features can typically be turned on or off by a user. Examples of these features include: reversing the color scheme (to assist people with low vision), showing a visual prompt when an error tone is sounded (to assist persons who are deaf or hard of hearing), or providing "sticky keys" that allow a user to press key combinations (such as control-C) sequentially rather than simultaneously (to assist persons with dexterity disabilities). This requirement prohibits software programs from disabling these features when they have been activated prior to running the application.
(c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.
(d) Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text.
Examples of user interface elements include button checkboxes, menus, toolbars, scroll bars, and any other feature of a program that is intended to allow the user to perform some action.
This provision requires that text must be associated with each element. The text must identify the element and its current state or condition. For example, a button that shows a hand for getting more help must have the word "help" associated with the button. If a checkbox is present, a text label must indicate what is being checked, and whether the checkbox is checked or unchecked. There are many ways to accomplish this depending on the program language being used.
(e) When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application’s performance.
Most screen reading programs allow users to assign text names to bitmap images. If the bitmap image changes meaning during a program's execution, the assigned identifier is no longer valid and is confusing to the user.
(f) Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes.
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 programs use the standard protocols dictated by the operating system for displaying their own information or processing the output of other computer programs. When programs are written using unique schemes for writing text on the screen or use graphics, other programs such as software for assistive technology may not be able to interpret the information. This provision does not prohibit or limit an application programmer from developing unique display techniques. It requires that when a unique method is used, the text should also be written to the screen through the operating system.
(g) Applications shall not override user selected contrast and color selections and other individual display attributes.
(h) When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user.
The use of animation on a screen can pose serious access problems for users of screen readers or other assistive technology applications. When important elements such as push-buttons or relevant text are animated, the user of assistive technology cannot access the application reliably. This provision requires that in addition to the animation, an application shall provide an option to turn off animation.
(i) Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
No. This provision does not prohibit the use of color to enhance identification of important features. It does, however, require that some other method of identification, such as text labels, be combined with the use of color.
(j) When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided.
No. This provision is applied to those products that already allow a user to adjust screen colors.
This provision requires more than just providing color choices. The available choices must also allow for different levels of contrast. Many people experience a high degree of sensitivity to bright displays. People with this condition cannot focus on a bright screen for long because they will soon be unable to distinguish individual letters. An overly bright background causes a visual "white-out". To alleviate this problem, the user must be able to select a softer background and appropriate foreground colors. On the other hand, many people with low vision can work most efficiently when the screen is set with very sharp contrast settings. Because there is such a variance in individual needs it is necessary for a program to have a variety of color and contrast settings.
(k) Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz.
This requirement is necessary because some individuals with photosensitive epilepsy can have a seizure triggered by displays that flicker or flash, particularly if the flash has a high intensity and is within certain frequency ranges. The 2 Hz limit was chosen to be consistent with proposed revisions to the ADA Accessibility Guidelines which, in turn, are being harmonized with the International Code Council (ICC)/ANSI A117 standard, "Accessible and Usable Buildings and Facilities", ICC/ANSI A117.1-1998 which references a 2 Hz limit. An upper limit was identified at 55 Hz.
(l) When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
At present, the interaction between form controls and screen readers can be unpredictable, depending upon the design of the page containing these controls.
If keyboard alternatives are provided for navigating through a form, and all elements of the form are labeled with text located in close proximity to the field that is to be completed, the form will most likely meet this provision. Attention must be paid to the placement of field labels. On a webpage, a label can have a direct association with a particular field that is indicated in the HTML code. Assistive technology can interpret the HTML and correctly announce the appropriate label. There is no similar method for forms in software programs. Therefore, the label must be in a logical position relative to the input areas. For example, placing labels to the immediate left of where the user is to enter information is by far the most logical position for the label.