Section 508 for Software Development Provisions

Module Introduction

The goal of the training module is to introduce you to the twelve software provisions and discuss approaches to developing software that conforms to Section 508. Where possible, examples of language-specific coding for each provision will be provided. Testing and remediation methods will also be discussed. By the end of this module, you will be able to:

• Identify guidelines for developing software that conforms to Section 508.
• Recognize the twelve provisions for Software Applications and Operating Systems, with the help of coding examples that conform to Section 508 for the following languages:
     – Oracle Forms.
     – Visual C++.
     – Visual Basic.
     – Java.
     – Cobol/CICS.
• Identify methods for assessment, testing and remediation.

Coding Languages

As you navigate your way through the course, you’ll be reviewing the general guidelines for developing software that conforms to the provisions of Section 508. As a developer, you may work in one particular language, or use a variety in your development activities. Within each provision, you will have the opportunity to review coding examples for the following languages: Oracle Forms 6i, Visual C++ 6.0, Visual Basic 6.0, and Java (Java 2 Platform Standard Edition, Version 1.2 and above).

These languages were selected to represent the majority of applications developed and have been included to allow you to view how each provision may be approached using each language. They are designed as a guideline for development to help you as you become familiar with Section 508.

Software Accessibility Guidelines

As a developer, it is your responsibility to make the software that you develop accessible to people with disabilities. This is accomplished by designing software that accommodates the widest range of users. You have two options available to accomplish software conformance.

Option 1: Make the software product compatible with assistive technology.
Option 2: Make the software product completely accessible.

Let's explore the development approach when dealing with built-in accessibility features.

Built-in Capabilities

Microsoft Windows© has built-in accessibility capabilities available to all users, if installed. For example, the Standard interface objects in the Windows environment are already accessibility-enabled.

Software should be designed so that it does not override built-in behavior. To learn more about the instances when software should provide explicit accessibility support, select these links:

• Providing a custom-designed interface specific to the application domain of the software.
• Creating custom controls or enhancing normal behavior of Standard controls.

Providing a Custom-Designed Interface Specific to the Application Domain of the Software

Windows provides accessibility features within individual controls. However, it is your responsibility as the developer to determine how the controls are combined into a software interface and made accessible. As an example, you would be responsible for defining the menu, menu item shortcuts, and window layout of controls for the software.

Specific approaches to providing a custom-designed interface will be discussed in the coding examples.

Creating Custom Controls or Enhancing Normal Behavior of Standard Controls

There are times when the standard controls provided by Windows cannot mimic the preferred interface design. In this case, custom controls may be purchased or created from scratch. Care must be taken to ensure that all controls or classes purchased or built from scratch follow the Section 508 guidelines for accessibility conformance.

The problem with creating custom controls is that assistive technology may have difficulty identifying them. Most assistive technology, such as screen readers and voice recognition programs, require specific information (e.g., color, text, etc.) in order to work successfully with screen elements.

The most common methods used to identify screen elements are:

• Active Accessibility: Assistive technologies use the Active Accessibility interface to retrieve information and get status change notifications directly from objects that support it. All standard Windows controls use Active Accessibility.
• Window Messaging: If an object has a window handle, an assistive technology can be informed via a message when objects are created or destroyed. The assistive technology can also look at the window class and retrieve standard information. All standard Windows controls utilize messaging.
• Off-Screen Model: Assistive technologies monitor drawing operations (e.g., text and graphic) on the screen and build a model of the screen’s contents. This method relies on complex heuristics, which does not provide meaning to the output, nor is it dependable. It should be used as a last resort.

Custom controls should utilize the Active Accessibility interface and messaging capabilities within Windows. The types of information that objects should provide are:

• Name, location, type, and associated value(s).
• Parent control (i.e., when controls are contained within other controls).
• Logical order in which controls are navigated.
• Event notification (e.g., when controls are created, destroyed, gain/lose focus, status changed [e.g., checked/unchecked], activated [e.g., button pressed]).

When developing custom controls, the developer must work more closely at the operating system level and be aware of how the operating system supports the accessibility features within the standard controls so they can be mimicked in the custom controls. This requires more intimate knowledge of the Windows Application Programming Interface (API). The most effective way for custom controls to be accessibility-enabled is to:

• Create COM objects representing individual custom controls or groups of controls that properly support the "IAccessible" interface.
• Call "NotifyWinEvent" when controls are created or destroyed, gain or lose focus, or otherwise change state.
• Handle the appropriate messages (e.g., WM_GETOBJECT, WM_GETTEXT) used to query properties of the object or objects.

General Guidelines

In addition to the specific guidelines you've just reviewed, take some time to become familiar with these additional general guidelines:

• Use standard Windows controls whenever possible because they are already fully compatible with assistive technology.
• Maintain compatibility with assistive technology when designing the overall interface and custom controls.
• Incorporate the requirement for developing software which conforms to the provisions of Section 508 into your overall software lifecycle (e.g., planning, analysis, design, coding, testing).
• Provide a customizable interface that accommodates a wide variety of user needs and preferences (e.g., colors, fonts).

The following topics are accessibility enhancements that are above and beyond Section 508 conformance. Whenever possible, go beyond what Section 508 mandates to provide an accessible product to the widest audience possible.

• Provide flexibility in using a variety of input methods (e.g., keyboard, mouse) and output methods (e.g., color, sound, images, text).
• Maintain consistency with the system-wide settings specified within the operating system (e.g., color schemes, contrast, font sizes, keyboard/mouse repeat rates and sensitivity).
• Identify accessibility issues inherent to the development environment, and purchase or develop workarounds.
• When phasing in accessibility conformance, prioritize the enhancements by identifying the features that affect the largest number of users, are used most frequently, and are required rather than optional.
• Rather than offering preferences that need to be set by the user, query the assistive technology in use and configure the software automatically. For example, check Windows system information (i.e., SystemParameterInfo) to determine when a screen reader is in use (i.e., SPI_GETSCREENREADER). Also, Windows will invoke a message when system information is changed so that the software can be reconfigured.
• Maintain action consistency (i.e., similar actions have a similar interface).
• Make actions reversible whenever possible; otherwise, request confirmation.
• Use common dialog boxes whenever possible; otherwise, follow common dialog box conventions when developing custom dialogs.
• Follow guidelines for ordering commands on menus.
• Use standard toolbar label images and text when supporting common actions.
• Avoid drawing over a variegated background, unless there is an option to omit the background. Although this technique can be pleasing to some, it can be very difficult to read for others.
• Provide counts when displaying items in a list.
• Avoid triggering actions on user navigation in the interface.
• Test for compatibility with common accessibility aids.

508 Conformance Evaluation Methodologies

Application Versus Operating System Reviews

The issues behind the adoption of Section 508 and the need to comply with its provisions are primarily driven by the user interface in the area of software development. Therefore, it is much more important to review and remediate software applications rather than the operating systems on which those applications reside. A software application is only able to include functionality supported by the operating system on which it executes.

For example, an application running on Microsoft Windows is able to 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 and assessing conformance to Section 508.

Manual Code Check Versus Automated Code Check

As the application developer, you should be cognizant of the functionality available to users with disabilities. It is entirely your responsibility to create code which conforms to the provisions of Section 508. As applications are designed and developed, manual reviews of the code and the application's functionality are imperative. An accepted method to accomplish this goal is the implementation of Peer Reviews.

Peer Reviews provide a means by which developers submit their designs and code to other developers, not including managers, for constructive criticism and comment. Since the emphasis of Section 508 conformance review tools is primarily focused on web-based applications and pages, very few tools exist which provide clues to software developers whether their application conforms to Section 508. Therefore, developers must employ the users’ tools (e.g. screen readers) in order to assess the application and perform a pseudo-automated review.

Introduction to the Section 508 Provisions for Software Development

By now you've had the opportunity to familiarize yourself with the issues that developers face when creating software products that conform to Section 508. The remainder of the course will discuss the provisions themselves, presenting each one individually. You'll gain an understanding of how each of the provisions affects development, and learn about assessment, development and remediation procedures.

Whether you’re developing new software or addressing the issues you've identified during the assessment of your existing software, you can use the guidelines to ensure that your software conforms to Section 508.

Remember, the developer plays a crucial role in addressing the need for Section 508 conformance. Once you complete this training, you'll be equipped to address this need and develop software products that conform to Section 508.

Provision A

Background

§1194.21(a) of Section 508 states that:

“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.”

Take a moment to consider how a person with low or no vision would launch a software program from the desktop. How would that person resize a window or use a scroll bar? Having access to software controls through keyboard alternatives is essential for people who cannot accurately control a mouse or for users with a visual disability who do not use a mouse.

However, detailed procedures that require the fine level of control afforded by a pointing device, such as painting an image with a brush, picking a color, and actually drawing a design do not have to have keyboard controls associated with them. The Access Board, which provides guidance on the provisions, has offered this rationale:

“…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 and cannot be given text labels because there is no way to predict what action the user plans to perform.” (http://www.access-board.gov)

A blind person can only interact with the system, or assistive technology, through the keyboard using keyboard substitutes or the accessibility options provided by Microsoft through the Operating System.

Keyboard or keypad commands provide a viable alternative for those who cannot use a pointing device or touch screen. Software that is designed to run on a kiosk and has a touch screen interface should also have a keyboard alternative that performs the same functionality as the touch screen.

Assessment Procedures

Determining whether your application conforms to §1194.21(a) of Section 508 is a relatively quick and simple process. Utilize the following steps to perform your test:

• Open the application to be tested.
• Navigate through the application using the keyboard only.
• Use all aspects of the application without using a mouse.
• Note any features that are inaccessible so that they may be addressed during remediation.
• Note: As of the writing of this course, there is only one automated assessment tool available on the market. Crunchy Technologies' WinScreamer can test software applications for 508 conformance. Due to the fact that not all twelve provisions can be tested automatically, a manual check should be used in conjunction with the automated tools.

Development and Remediation Guidelines

As §1194.21(a) specifies, software should be designed so that it is fully functional while using the keyboard. Mouse support should be considered optional, instead of the other way around, since users with motor or visual disabilities may not use a mouse.

The Windows Operating System provides provision keyboard equivalents for general interface behavior, such as navigating among controls and windows, activating controls, adjusting window and region sizes, and scrolling controls and windows. Software should be designed so it does not override this built-in behavior.

For details on the Microsoft Windows built-in key combinations, you can view the Microsoft Keyboard Guide at http://www.microsoft.com/enable/products/winkeyboard.htm.

Use these guidelines when providing explicit keyboard support:

• Access Keys—Provide access keys, denoted by an underlined character, for all menus and menu items. For example, press Ctrl+S to save a document in Microsoft Word, or press Ctrl+C to copy. Also, provide access keys to controls within a screen, such as to submit a form, when it provides a useful benefit and does not conflict with the menu. Be sure to follow industry standards when assigning keyboard equivalents. Refer to Microsoft Windows Keyboard Guide (http://www.microsoft.com/enable/products/winkeyboard.htm).
• Toolbar Commands—Toolbar commands provide quick access to common functionality. However, Toolbar objects are normally not available from the keyboard, which means a user cannot use the Tab key to access them. All toolbar functionality should therefore be made available through the menu items or documented shortcut keys.
• Tabbing Order—Provide a logical tabbing order among captions, text entry fields, and other focal points. Normally, this is left-to-right and top-to-bottom. This can be accomplished by assigning a tab number to each control on a screen. Unfortunately, since most users are proficient with a mouse, a verification of the tab order is often overlooked or missed in testing. Generally, captions before edit controls are not in the tab order, which increases tabbing speed for sighted keyboard users. However, having captions in the tab order is beneficial for a blind user, because it alerts them to what the next item in the tab order is going to be. Therefore, a solution would be to provide a preference for determining if captions are included in the tab order.
• Default Values—Prevent the user from getting stuck when tabbing through the objects within a window. Users with screen readers will generally tab through all the controls on a screen to understand the screen content before making any changes. Developers will sometimes employ control level validation, which prevents a user from exiting a control when the data is invalid. While this should be acceptable, sometimes controls are not filled with valid defaults, which prevents the user from exiting the control without changing the value. To prevent this issue, valid default values should be initially filled in (instead of leaving the value blank). When default values are not acceptable, validation techniques can be performed when a value changes or when the user attempts to save changes made on the screen/application.
• Scrolling—Provide keyboard support for scrolling vertically and/or horizontally when there is more information than will fit in the width of a window or control. Users work under many different resolutions. In some cases, applications are specifically designed for the lowest resolution and do not provide benefits to those users with higher resolutions. In other cases, a user is forced to be able to support a specific higher resolution for the software to be functional. An alternative is to allow the software to work under any resolution, providing the maximum benefit, regardless of the resolution available. Screens may require scrolling that must be accessible from the keyboard.
• Splitter Bars—It is becoming more common for software to contain splitter bars to allow more information to be available without requiring additional windows. When incorporating splitter bars, the developer should provide the user with the ability to adjust the bar using the keyboard.
• ToolTips—ToolTips provide additional information about a screen object. Since ToolTips are normally only available when using the mouse, an alternative method should be made available for displaying ToolTip information from the keyboard. A status bar is often used to reiterate or expand upon ToolTip information. Changes to the status bar text must also invoke a message to accessibility tools (e.g., signaling a screen reader to voice the new text).
• System Menus—All dialogs and windows should support a system menu that provides moving, sizing, restoring, minimizing, maximizing, and closing capabilities (as appropriate) and that is also accessible from the keyboard (i.e., Alt+Space). Most development environments use the Windows built-in capabilities to provide a system menu, but some applications override this behavior and add a customized window appearance. In this case, it may be necessary to manually provide adequate support for a system menu.
• Invalid Keystrokes—Indicate when a keystroke is invalid (i.e., no capability is available to respond to the request). For example, the last item in a list is already selected when the down arrow key is pressed.
• Customizable Keyboards Interfaces—Provide a customizable keyboard interface (e.g., select from predefined menu configurations: novice/intermediate/advanced, adjust the menu item order and display, shortcut keys, and create keyboard macros for common tasks) to further simplify the use of the software.
• Keyboard Equivalent Instructions—Provide clear instructions for using all keyboard equivalents as part of the user documentation.

Provision B

Background

§1194.21(b) of Section 508 states that:

“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.”

Some operating systems provide accessibility options that can be turned on and off by the user. These options are available to all programs through the Application Programming Interface (API). Having software that recognizes and utilizes the accessibility features selected by the user is necessary in order for the user to properly understand and anticipate a response from the software.

Features such as those found in the accessibility options included with Microsoft’s Windows applications provide the user with the capability to implement sticky keys, filter keys and/or toggle keys to make use of their keyboard easier and faster. Installation of software, such as a printer driver, that is necessary for the operation of the product should not interfere with those options. Accessibility options for Macintosh based computers can be located at http://www.apple.com/education/k12/disability/.

Assessment Procedures

In order to assess whether or not accessibility options have been disabled, utilize the following steps to perform your test:

• Set various accessibility options in the operating system.
• Open the software application to determine if the previously set accessibility options are still available.
• Take special note whether the accessibility options that were previously set are still available.
• Note: As of the writing of this course, there is only one automated assessment tool available on the market. Due to the fact that not all twelve provisions can be tested automatically, a manual check should be used in conjunction with the automated tools.

Development and Remediation Guidelines

When software either does not respond or ignores the accessibility features set by the user, it is considered to be disrupting the feature. There are two major features that you should be aware of: object sizing and sound.

Object Sizing
It is important for users to be able to control the size of the objects on the screen. Some users may prefer to see as many objects as possible (even if very small), while others have difficulty reading or interacting with small objects and would prefer fewer objects on the screen. Use these guidelines to assist in conforming to this provision:

• Windows provides user settings for fonts as well as spacing issues (the size of other objects, such as buttons, should be adjusted according to the font size). However, many software applications ignore some of these settings and hard code fonts and sizes into the interface. Thus, software applications should be designed to follow the system settings.
• Where possible, allow users to size or zoom individual regions on the screen (e.g., increasing the font in a text entry region without impacting other interface objects [e.g., buttons]).
• Avoid small fixed fonts (e.g., smaller than 10 pt) and small mouse targets (e.g., small specialized buttons).
• Avoid having fixed-size windows. Provide options for either scaling the contents or displaying more information. Also, use scroll bars when the content does not fit in one window.

Sound
Use sound only to enhance, emphasize, or reiterate information shown by other means. Do not use sound as the only means to convey information. Users with certain disabilities will not be able to distinguish sound and may not be able to obtain the information conveyed. For example, some software will beep when reaching the end of a list. There should also be other indicators, such as a status message, that could be identified by a screen reader, or by someone with a hearing disability.

Support the ShowSound and SoundSentry accessibility features. These features convey all information visually rather than by sound alone. The user sets both features from the Windows built-in accessibility options. However, it is up to the application to determine the current ShowSound setting and how to respond appropriately. The SoundSentry, on the other hand, automatically provides a visual indicator for all sounds sent to the internal PC speaker.

Configure the software to use the user-selected color scheme identified within the operating system when displaying all windows, menus and affected screen controls (GetSysColor).

Provision C

Background

§1194.21(c) of Section 508 states that:

“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 the focus and focus changes.”

Software should provide a visual indication on the screen identifying where an action will occur if a mouse select or keystroke takes place (i.e., referred to as the focus). Having a clear understanding of the focused object is essential for people who are visually disabled in order to retain context about what is being input or displayed onscreen. The focused object must be discernable by assistive technology programs. Applications must identify where the focus is and allow for assistive technology to track the focus and focus changes. For example, when viewing a file browser on the screen, the focus cursor shows which file will be activated when the Enter key is pressed. Assistive technologies can translate this information into voice output for people with visual disabilities, or allow voice input systems to insert text at the correct focus location.

Assessment Procedures

Determining whether your application conforms to §1194.21(c) of Section 508 is a relatively quick and simple process. Utilize the following steps to perform your test:

• Open the application to be tested.
• Navigate through the application using a screen reader.
• Check whether menu commands change state (i.e., highlighted, bolded, flashing) when focused upon.
• If using a screen enlargement program (i.e., Zoom Text), check to see if it follows the focus as it changes.
• To facilitate remediation, note any instances where a well-defined on-screen indication is not provided.
• Note: As of the writing of this course, there is only one automated assessment tool available on the market. Due to the fact that not all twelve provisions can be tested automatically, a manual check should be used in conjunction with the automated tools.

Development and Remediation Guidelines

Software must let accessibility aids locate and track the location of the keyboard focus in order to conform to Provision C. The Windows operating system provides built-in support for exposing the focus when using the standard controls of the operating system (such as standard buttons, lists, menus). The interface objects built into the Windows environment are already accessibility-enabled. Software should therefore be designed so it does not override this built-in behavior.

Use the System Caret (for example, vertical blinking bar in a text region, dashed rectangle on a button, highlighted cell within a grid) to expose the focus of the current control when attempting to provide specialized focusing support not provided by the Windows operating system. For example, some graphics software will display a rectangle around the image boundaries with anchor points that allow resizing. The System Caret can be programmatically controlled with API calls shown here:

• CreateCaret: Sets the caret size and shape.
• SetCaretPos: Changes the position of the caret.
• ShowCaret: Makes the caret visible.
• DestroyCaret: Allows a new caret to be specified.

When providing explicit focus support, you should prevent changes to an object currently in focus of which blind users may not be aware. An example would be changing the value in one control, which changes the focus to another control (selecting a radio button with the options: enter text or specify a file, and have the focus changed to a text entry control or an open file dialog). A possible solution would be to make sure Windows is notified of the change so that accessibility aids will process the change.

Provision D

Background

§1194.21(d) of Section 508 states that:

“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.”

Imagine that you have a visual disability and are using a screen reader to read a document in a software application, such as Microsoft Word. If the software has not been coded properly, the screen reader cannot inform the user of the existence, location and status of the controls available (such as checkboxes, menus, and toolbars). For example, ToolTips are provided by different applications for tool bar button identification, which allows assistive technology the ability to interpret any displayed graphics by using the text information.

Let’s take a look at another example. Imagine that you have a severe motor disability and must use speech input to interact with your computer. Without knowledge of the existence, location, and status of the onscreen controls, you would not be able to tell the speech input software to perform certain tasks, such as “check the ‘out of office’ check box”.

Assessment Procedures

Determining whether your application conforms to §1194.21(d) of Section 508 is a relatively quick and simple process. Utilize the following steps to perform your test:

• Open the application.
• Navigate through the application using a screen reader or software accessibility testing tool.
• Check to see if the screen reader can distinguish and read all control options, or if any violations appear in the testing tool.
• Note any control options that can not be read by the screen reader, or any violations that appear in the testing tool, so that they can be addressed during remediation.
• Be sure to understand how the screen reader works, and what keys to use to control it.
• Note: As of the writing of this course, there is only one automated assessment tool available on the market. Due to the fact that not all twelve provisions can be tested automatically, a manual check should be used in conjunction with the automated tools.

Development and Remediation Guidelines

§1194.21(d) addresses the need to allow assistive technologies to access information about user interface controls. These items need to be considered if you, as the developer, are to make this happen:

• Text.
• Owner Draw Capabilities.
• Images.
• Captions.
• Punctuation.
• Titles.

Text
Text displayed within the software must be properly exposed to accessibility aids in order for reliable interpretation of the information. The methods for accomplishing this are:

• Limit use to provision text controls such as the edit control, static text (i.e., text with a window handle), and RichEdit. All but RichEdit use Active Accessibility, while others may also use Windows messaging.
• Use other controls that are known to support Active Accessibility or other interfaces to expose text.
• Use calls within the Windows operating system to output text (e.g., TextOut, DrawText). This method provides some compatibility with accessibility aids that build off-screen models by monitoring screen-drawing operations.

Owner-Draw Capabilities
When using owner-draw capabilities (for example, using software code to control the display of the control) within standard controls, make sure a textual explanation is available to accessibility aids. An example of an owner-draw capability is having the font selection list display each item in the list using the unique font and item name. Another example is a color selection list that contains a graphical bar representing the color, but does not contain color names. How would a user with a visual disability discern what the control is, if not properly labeled with text?

Use the MSAAMENUINFO structure to expose the menu text to Active Accessibility, or provide a preference for using text-only menus.

Captions
Many controls do not have built in captions (e.g., edit controls, lists), while others do (e.g., check boxes, radio buttons). For those that do not, captions should be added so that accessibility aids can best associate the captions with the appropriate controls. Follow this guidance:

• Use static text controls for the caption.
• Provide meaningful and descriptive text to the caption and end it with a colon.
• Place the caption control to the left or directly above the associated control.
• Set the tab order of the caption control so that it precedes the associated control.

Provision E

Background

§1194.21(e) of Section 508 states that:

“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.”

Software should not change the meaning of an image that is used by a program to identify programmatic features (e.g., bitmap controls) during the operation of a program. Changing the meaning and behavior of an image during the operation of a program is effectively modifying the interface dynamically, which can be confusing to people with cognitive disabilities and other users that memorize the organization of the interface. In addition, changing the behavior of images dynamically may confuse a screen reader, meaning that it may not identify that the change has occurred, thus continuing to report the prior text and behavior.

Images that do not identify programmatic behavior are not applicable (for example, maps that are dynamically painted based on the selected location). Images are sometimes used without text to represent concepts within an application. Most screen readers allow users to assign text names to these images. If the meaning of the image should change during the running of an application, the assigned identifier may no longer be valid and may be confusing to the user. An example is an icon that looks like a floppy disk and is used to represent “SAVE” wherever the icon appears. An icon using the same image with a different meaning will be confusing to the user.

Assessment Procedures

Determining whether your application conforms to §1194.21(e) of Section 508 is a relatively quick and simple process. Utilize the following steps to perform your test:

• Open the application to be tested.
• Navigate through the application.
• Check to see if individual icons mean the same thing throughout the application.
• Note icons whose meaning changes and address the problem during remediation.
• Note: As of the writing of this course, there is only one automated assessment tool available on the market. Due to the fact that not all twelve provisions can be tested automatically, a manual check should be used in conjunction with the automated tools.

Development and Remediation Guidelines

§1194.21(e) addresses the need for consistent naming of bitmap images, when those images are used to identify controls, indicate status, or are used programmatically in any other capacity.

As the developer, you must prevent changes to objects of which users with disabilities may not be aware, for example, when a change in the value of a control adjusts text/graphics or the status of other controls on the screen.

Provision F

Background

§1194.21(f) of Section 508 states that:

“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.”

Software shall use the functions provided by an operating system when displaying text. Assistive technology, such as screen readers, may have difficulty interpreting text that is output by means other than the standard functionality provided by the operating system. The operating system provides these standard functions for displaying text in order to simplify software development.

The development of assistive technology software relies on the fact that these capabilities will be used. Methods of displaying text, other than using the standard functionality available within the operating system, may be used as long as the textual information is available for retrieval by assistive technology using the operating system functions. If an application uses custom text controls, it is responsible for assuring that the information about the text is available to assistive technology by sending the information through the operating system functions for displaying text.

Assessment Procedures

Determining whether your application conforms to §1194.21(f) of Section 508 is a relatively quick and simple process. Keep in mind that this provision may not lend itself to automated tools, since it requires human judgment to perform the test. Utilize the following steps to perform your test:

• Open the application to be tested.
• Navigate through the application using a screen reader.
• Note instances where the screen reader cannot identify/interpret text and address them.
• Note: As of the writing of this course, there is only one automated assessment tool available on the market. Due to the fact that not all twelve provisions can be tested automatically, a manual check should be used in conjunction with the automated tools.

Development and Remediation Guidelines

As §1194.21(f) states, text must be properly exposed to accessibility technology in order for reliable interpretation of the information. The methods for accomplishing this are:

• Limit use to standard text controls such as the edit control, static text (i.e., text with a window handle), and RichEdit that already use operating system functions to display text and maintain accessibility conformance.
• Use other controls that are known to only draw text using built-in Windows operating system calls.
• Manually use calls within the Windows operating system to output text (e.g., TextOut, DrawText). This method provides some compatibility to accessibility technologies that build off-screen models by monitoring screen-drawing operations.

Provision G

Background

§1194.21(g) of Section 508 states that:

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

Most operating systems have system-wide settings that designate features such as color, contrast, font, keyboard/mouse repeat rate and sensitivity. Under normal circumstances, these settings are recognized and used by all computer software; system-wide settings often need to be personalized in order to meet the needs of people with disabilities. If an application should override a customized setting, the software may be inoperable for users who have special display needs.

The purpose of this provision is to ensure that all applications allow a user to customize system-wide, display-specific settings.

Testing your application for conformance to Provision G, and remediating any issues identified, are relatively simple procedures.

Assessment Procedures

As mentioned earlier, determining whether your application interferes with user-selected contrast and color selections (as well as other display attributes) is a relatively quick and simple process. Keep in mind that this provision may not lend itself to automated tools, since it requires human judgment to perform the test. Utilize the following steps to perform your test:

• Customize/set display attributes on the test computer.
• Open the application to be tested.
• Navigate through the application.
• Target/utilize functions that will allow you to determine whether the test computer's personalized settings were maintained.
• Note any changes in user-defined settings so that they may be addressed during remediation.
• Note: As of the writing of this course, there is only one automated assessment tool available on the market. Due to the fact that not all twelve provisions can be tested automatically, a manual check should be used in conjunction with the automated tools.

What actions can be taken to develop an application that conforms to this provision? What can be done if an existing application does not conform?

Development and Remediation Guidelines

Applications need to be developed so that they do not interfere with customized settings required by people with visual disabilities. This can be done by:

• Determining if the high contrast mode is set.
• Using colors from the appropriate color scheme when updating/displaying all menus and affected screen controls.
• Drawing foreground objects using foreground colors and background objects using background colors.
• Creating user-customizable color setting preferences that are application-specific.

Provision H

Background

§1194.21(h) of Section 508 states that:

"When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user."

Animation can pose serious functional problems for people who use screen readers and other assistive technology. The reason for this is that animation (both text and objects) is difficult for some assistive technology to interpret. Animation can interfere with software use if key elements (such as buttons or relevant text) are affected. Due to the difficulties that can occur, it is essential that the user be given the option to view the animation in at least one non-animated form.

The purpose of this provision is to ensure that all applications display animated graphics in at least one non-animated mode.

Testing your application for conformance, and remediating any issues identified, are relatively simple procedures.

Assessment Procedures

As previously discussed, the assessment procedure for determining whether your application conforms to this provision is a simple process. Utilize the following steps to perform your test:

• Open the application to be tested.
• Search for animated objects.
• Make note of animation that does not convey its information by means of another method (i.e., captions). These are the animated objects that will need to be addressed during remediation.
• Note: As of the writing of this course, there is only one automated assessment tool available on the market. Due to the fact that not all twelve provisions can be tested automatically, a manual check should be used in conjunction with the automated tools.

What actions can be taken to develop animation that conforms to this provision? What can be done if existing animation does not conform?

Development and Remediation Guidelines

Two general approaches exist for avoiding or remediating usability problems associated with animation. The approach that should be selected is dictated by the animation type.

Select these links to learn more about animation types and to review associated general development and remediation guidelines.

• Decorative Animation.
• Informative Animation.

Development and Remediation Guidelines—Decorative Animation

Animation is considered decorative if it does not add value to the application or to the information being conveyed. Decorative animation is used to lend an eye pleasing and/or interesting facet to the application. An example of this type of animation is a logo that dissolves onto the screen.

Because animation of this type does not convey information critical to the operation of the application, your remedial action can take one of two forms. You can:

• Disable the element, or
• Add descriptive text to the element.

Development and Remediation Guidelines—Informative Animation

Informative animation provides the user with information that is considered key to learning or to operating the application. Animations of this type are often used to communicate a process, procedure, or hierarchical flow. An example of this type of animation would be the use of a graphic that depicts a pointing device on a computer screen. The pointer would be animated so that it provides a succinct visual explanation of how to execute a task. Animated software features (shown on the computer screen) would illustrate the outcome of each step.

Because this type of animation conveys information required by the user, the concept or knowledge being presented must be able to be translated and communicated using an alternative method (such as a screen reader). It is also necessary to either provide preferences for replacing or disabling animation within the software or set the program so that preferences are based on the accessibility aid already in use.

Provision I

Background

§1194.21(i) of Section 508 states that:

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

Relying on color to convey information or a directive, prompt a response, or distinguish between visual elements is difficult for people with limited sight and impossible for those with none. Users who cannot see or discriminate between colors may find it impossible to perform necessary actions such as reviewing key information and identifying certain color-coded controls, object states, or screen elements.

This fact does not mean that a developer must eliminate all use of color from an application. Color can be used if other methods of identification (such as text labels and different types of images) are provided so that the information can be conveyed to people with vision-related disabilities. For example, if an indicator turns from green to red to show an error condition, the user also needs to receive text that identifies the error.

The purpose of this provision is to ensure that software will not use color as the sole method for conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Testing your application for conformance, and remediating identified issues, are relatively simple actions.

Assessment Procedures

As discussed earlier, assessing whether your application conforms to this provision is simple. Utilize the following steps to perform your test:

• Open the application to be tested.
• Navigate through the application.
• Search for:
     – Objects that change color
     – Use of colors that do not have a significant difference in hue/intensity
     – Use of colors that are muted (low intensity)
• Note the use of items or text whose changing color is intended to convey information. These are the items that will need to be addressed during remediation.
• Note: As of the writing of this course, there is only one automated assessment tool available on the market. Due to the fact that not all twelve provisions can be tested automatically, a manual check should be used in conjunction with the automated tools.

What actions can be taken to develop an application that conforms to this provision? What can be done if an existing application does not conform?

Development and Remediation Guidelines

You now know which objects within your application present usability issues for people with visual disabilities. To learn more about how to remediate the problem, take a look at the information accessible through these links:

• Use text labels.
• Use symbols, graphics, and changes in font style.
• Eliminate specific colors and color combinations.

Development and Remediation Guidelines—Use Text Labels

Using text labels is one of the most effective approaches to take. To enable the image to be read by assistive technology such as a screen reader, insert text labels describing the image in your code.

Development and Remediation Guidelines—Use Symbols, Graphics, and Changes in Font Style

Certain symbols, graphics, and changes in font style may be used (along with color) in order to assist in communicating select information to users with disabilities.

Symbols
Let's take a look at an example of how symbols can be used. An application utilizes green and red line items to indicate positive and negative balances. If faced with this problem, an effective remedial approach for a developer to take would be to add text (plus and minus signs) to the colored balances.

Commonly used symbols include:

• + (positive)
• - (negative)
• ( ) (negative)
• * (flags a required item)
• | (surrounds changes)
• ? (help)

Graphics
It is difficult to effectively use a graphic to communicate information. If graphics are used in this manner, care must be taken to ensure that the information can be conveyed to users with visual disabilities.

Font Style
A change in the style of font (from normal to bold, italic, upper case, etc.) can be an effective means to communicate actions such as user selection of an item, an object's change in state, or required fields.

Let's discuss an example. An electronic form has been created in order to retrieve the name, mailing address, and telephone number of each user. The primary goal of the form is to capture the user's name and mailing address. The developer bolds the field labels for these two items to indicate that a response is mandatory.

Eliminate Specific Colors and Color Combinations
A user who is color blind will find it difficult (if not impossible) to discern between certain color combinations. For this reason, make sure to select colors that differ significantly in hue and intensity. Avoid muted colors with low luminance values (intensity). Combinations that are difficult to differentiate for a user who is color blind include:

• Green/red.
• Green/blue.
• Red/brown.
• White/light green.

Provision J

Background

§1194.21(j) of Section 508 states that:

"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."

In order to conform to this provision, your application needs to provide users with a variety of color settings that can be used to set a range of contrast levels. Having the ability to adjust the color and contrast of screen display is essential for people who have difficulty focusing on bright colors (e.g., characters become blurred, backgrounds wash out). Being able to set contrast levels also provides the user with the ability to more accurately distinguish the difference between colors.

Let's take a moment to look at an example that explains why the ability to change colors and contrast settings can be important. An application has been created for a commercial client. The display has been set up to utilize colors associated with the client's logo. The background selected is a medium yellow. The text color is black. Users who have difficulty focusing on bright colors might not be able to read text placed on such a bright background. To resolve this problem, the user needs to be able to change the contrast and/or color of the background or text.

The purpose of this provision is to ensure that all applications allow the user to adjust color and contrast settings and that a variety of color selections are available.

Testing your application for conformance, and remediating identified issues, are relatively simple actions.

Assessment Procedures

As mentioned earlier, assessing whether your application conforms to this provision is simple. Utilize the following steps to perform your test:

• Open the application to be tested.
• Navigate through the application.
• Determine whether the product allows auser to adjust color and contrast settings.
• Determine whether the product provides the user with a variety of color/contrast settings.
• If these items are not available, they will need to be addressed during remediation.
• Note: As of the writing of this course, there is only one automated assessment tool available on the market. Due to the fact that not all twelve provisions can be tested automatically, a manual check should be used in conjunction with the automated tools.

What actions can be taken to develop an application that conforms to this provision? What can be done if an existing application does not conform?

Development and Remediation Guidelines

Now that you have assessed your application, let's take a look at how to circumvent usability problems created by a lack of customizable settings (or lack of setting variety).

In order for your application to respect a user-defined color scheme, you must never alter or extend the use of color beyond the scheme designated by the operating system. An occasion may arise where an application requires the use of a unique color-related feature (such as specialized color for data entry). In these instances, you will need to provide additional color preferences (so that the user can select colors unique to their situation).

Provision K

Background

§1194.21(k) of Section 508 states that:

"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."

Flashing or blinking frequencies between 2 Hz and 55 Hz can trigger seizures in people who have photosensitive epilepsy. The likelihood of triggering a seizure is significantly increased if the intensity of the flash is high and if it falls within a certain frequency range. Because of this problem, developers must limit the flash or blink rates of all screen items. The requirement outlined in this provision applies primarily to software and web development; however, it also applies to hardware for flashing lights and controls. Common examples of frequently used flashing objects are “Hot” or “New” words.

The purpose of this provision is to ensure that flashing or blinking elements do not utilize frequency rates that may trigger adverse affects in people with photosensitive epilepsy.

Testing your application for conformance, and remediating issues identified, are relatively simple procedures.

Assessment Procedures

The assessment procedure for determining whether your application conforms to this provision is simple. Utilize the following steps to perform your test:

• Open the application to be tested.
• Navigate through the application.
• Search for flashing or blinking text, objects, or other elements.
• Use an electronic tester to determine if the item has a flash or blink frequency greater than 2 Hz and lower than 55 Hz.
• Make note of those animations that have a Hertz range of greater than 2 Hz and lower than 55 Hz. These are the items that will need to be addressed during remediation. Flashing or blinking objects need to be omitted from an application if they cannot be tested.
• Note: As of the writing of this course, there is only one automated assessment tool available on the market. Due to the fact that not all twelve provisions can be tested automatically, a manual check should be used in conjunction with the automated tools.

What actions can be taken to develop flashing text and objects that conform to this provision? What can be done if existing text and objects do not conform?

Development and Remediation Guidelines

Several programming techniques can be utilized which will allow a user to control certain aspects of an item's flash or blink rate. Providing the user with this type of control allows the developer to incorporate flashing screen items without running the risk of producing adverse physical affects. These programming techniques involve providing the user with the ability to:

• Customize all time-out features.
• Adjust the flash speed.
• Completely disable the flash itself.

Provision L

Background

§1194.21(l) of Section 508 states that:

"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."

Electronic forms are used by many government agencies and commercial businesses to gather information or to permit a person to apply for services, benefits, or employment. This provision is for software products not web sites. Web sites have a similar provision located in section 1194.22. An example of the use of this type of form is the Tax Preparation products often used by the public. Successful completion of an electronic form depends upon the user’s ability to access, understand, complete, and submit the form.

If all fields on an electronic form are not correctly populated, and if the form is not readable by assistive technology devices, a user with a mobility/dexterity, cognitive, or visual disability may not be able to utilize the document. The two primary characteristics of an effective form are:

1) Fields that are identified in a textual sense (i.e., they are labeled), and
2) Its ability to be completed using keyboard shortcut keys (Alt, Ctrl, Tab).

The purpose of this provision is to ensure that electronic forms are fully usable by people with disabilities.

Assessment Procedures

The assessment procedure for determining whether your application conforms to this provision is simple. Utilize the following steps to perform your test:

• Open the form to be tested.
• Navigate through the form.
• Note whether:
     – You can navigate using the keyboard.
     – It is readable by assistive technology devices.
     – The purpose of each field is defined.
• Any items noted will need to be addressed during remediation.
• Note: As of the writing of this course, there is only one automated assessment tool available on the market. Due to the fact that not all twelve provisions can be tested automatically, a manual check should be used in conjunction with the automated tools.

What actions can be taken to develop a form that can be utilized by people with visual disabilities? What can be done if an existing form does not conform?

Development and Remediation Guidelines

Several programming techniques can be utilized to produce (or remediate) a form so that it can be read by assistive technology. These techniques involve:

• Providing keyboard alternates for navigation purposes.
• Placing labels in a location relative to the associated data entry field.
• Designing form controls that have data entry fields follow a left-to-right, top-to-bottom format.

Module Conclusion

Congratulations! You have completed the training for Section 508 for Software Development. The goals of this module were to:

• Introduce you to the software provisions.
• Familiarize you with assessment, development, and remediation guidelines.
• Provide coding examples that can be utilized to remediate deficiencies.

Whether you’re developing new software or addressing issues in existing applications, you can use the information provided by this training to ensure that your application conforms to the provisions cited in §1194.21 of Section 508. Always take time to consult the provisions prior to and during development and remediation of your applications. Remember, you play a crucial role in addressing the need for accessibility for each and every person.