Section 508 Reference Guide Appendix B: Tips for Creating Accessible Products
- Software Accessibility Improvements
- Best Practice Principles for Accessibility in E-Learning
- E-Learning Accessibility Checkpoints
- Tips for Designing E-Learning for People with Blindness
- Tips for Designing E-Learning for People with Low Vision
- Tips for Designing E-Learning for People with Color Blindness
- Tips for Designing E-Learning for People with Hearing Impairment or Deafness
- Tips for Designing E-Learning for People with Mobility Impairment
- IBM Accessibility Checklists
Software Accessibility Improvements
To increase overall accessibility, software developers can:
- Make documentation available in electronic form and accessible by screen reading software, thus making it easier to use for people who cannot handle or read printed materials.
- Make product support staff aware of disability access issues, and aware that people with disabilities routinely depend on their software products.
- Establish a protocol to communicate accessibility and compatibility problems from product support staff to product designers. Keep the trigger level for such referrals low.
All properly trained support staff should be able to handle routine product use questions from users who have disabilities. Ideally, some individuals should also seek to specialize, to learn how to resolve specific incompatibility issues between software applications and AT. In this way, developers and support staff can create pools of expertise to deal with the widest possible range of problems and suggestions brought forward by users.
Best Practice Principles for Accessibility in E-Learning
The following principles are considered best practices for producing accessible software applications and accessible content for e-Learning. Developers, content providers, and educators involved in the creation of learning products should adhere to these guidelines from the outset of the design process, since retrofitting an inaccessible product is almost always significantly more difficult, labor-intensive, and expensive.
We offer six principles that address accessibility for people who have sensory or mobility disabilities. These principles also address accessibility issues faced by people with cognitive disabilities, though often to a lesser extent.
- Allow for customization based on user preference.
- Provide equivalent access to auditory and visual content based on user preference.
- Provide compatibility with AT and include complete keyboard access.
- Provide context and system orientation information.
- Follow Section 508, W3C, and IMS specifications and other relevant specifications, standards, and/or guidelines.
- Consider the use of XML for dynamic content generation.
E-Learning Accessibility Checkpoints
- All videos should be captioned for deaf and hard-of-hearing viewers.
- Videos should carry an audio component that describes images and visual cues for blind and low-vision users.
- Applications should offer key combinations (e.g. CTRL+F) for functions that are appropriate for users with mobility restrictions or vision impairments. For example, no key combination should require the use of more than one hand.
- Images and forms on websites should have labels (e.g., ALT text) for users who access content with the help of screen reading software. For example, visually impaired or blind students must be able to access mathematical equations that are presented as graphics.
- Testing protocols should be flexible enough to accommodate disabled users. For example, time-dependent tests can offer more time for mobility-impaired students.
- Administrative matters such as course listings and course registration should be accessible.
Tips for Designing E-Learning for People with Blindness
To support screen reading software, developers can:
- Use standard system tools to draw and erase all on-screen text and to display all cursors and pointers.
- Use standard system on-screen controls whenever possible (e.g., OK buttons, dialog boxes, drop-down menus).
- Define tools in toolbars, palettes, and menus as separate items. Do not create single graphics containing multiple objects. By keeping tools and other objects separate, the screen reader is better able to identify and name each tool for the user.
- Embed descriptive text (e.g. ALT text, tool tips) in graphic images in such a way as to make the text known to screen reading software. This addresses the problems that can arise when text is rendered as a graphic image and cannot be read by software.
- Assign logical and consistent names to controls, even if the name is not visible on the screen.
Screen readers can access this information and use it to describe the type and function of the control on the screen and track the system cursor with the mouse, even if the cursor is invisible. This allows the screen reading software to detect the mouse position when customized highlighting or focusing techniques are in use.
- Use consistent and predictable screen and dialog layouts.
- Avoid the use of help balloons that disappear whenever the hot spot or focus of the mouse changes. Try instead to lock the help balloon in place so that the user can move the cursor and continue to read the balloon.
- Use single column text whenever possible.
- Provide keyboard equivalents for all tools, menus, and dialog boxes.
Since screen readers can only read text (or give names to separately identifiable icons or tools), it is a good idea to:
- Avoid assigning unlabeled "hot spots" to pictures for use as controls, unless they are redundant with menu selections.
- Avoid non-text menu items when possible or at least incorporate visible or invisible text cues to accompany these items. Screen readers can see text even if that text is written to the screen invisibly.
- Avoid non-redundant graphic tool bars. Make any tool bar command available in a menu.
Finally, documentation and training materials are always more accessible when:
- Documentation and online help can be understood independent of graphics. Text descriptions should be included in all graphics.
- Synchronized audio descriptions are available to play alongside animated graphics or movies.
Tips for Designing E-Learning for People with Low Vision
To make on-screen information easier to see, developers can:
- Increase the contrast between text and the background.
- Place text over a solid-color background. A patterned background can make text harder to discern.
- Create consistent layouts for all screens and dialogs within the program.
- Provide access to tools via a menu bar.
- Follow line width guidelines when drawing lines on the screen. Use the line width information provided by operating system settings. This will ensure that the learning application will increase all lines proportionally should a user choose to enlarge the view (e.g., for horizontal separation in HTML, use HR tags instead of graphics).
- Allow the user to zoom into or magnify images.
- Provide volume controls for audio tracks.
To make software more compatible with other applications that offer low-vision access features, developers can:
- Use the system pointers whenever possible, as well as the system caret or insertion bar, if available.
- Include a highlight or focus indicator when dragging the mouse cursor, even at those times when the cursor is invisible. This adjustment will help screen enlargement software using "pan and zoom" features to track the user's movements more accurately.
- Add support for a high-contrast setting.
- Protect users from the need to monitor two or more events simultaneously, especially those that occur far apart from each other on the screen.
Tips for Designing E-Learning for People with Color Blindness
To make it easier for color-blind users to access their software, developers can:
- Make color-coding a redundant or secondary means of conveying information.
- Ensure that applications are usable on monochrome screens.
- Use variations in contrast and brightness in addition to color variations.
Tips for Designing E-Learning for People with Hearing Impairment or Deafness
To increase the accessibility of software to users with hearing impairments, developers can:
- Provide volume controls for audio tracks.
- Provide all auditory information visually.
- Ensure that all visual cues are noticeable even if the user is not looking straight at the screen. Important information should catch the user's attention, even through peripheral vision.
- Support the Windows ShowSounds feature that allows a user to assign a visual and caption for each audio event.
Telephone support staff should also have TTY available in order to be able to assist deaf or hard-of-hearing customers.
Tips for Designing E-Learning for People with Mobility Impairment
To increase the accessibility of software to people with physical disabilities and ensure compatibility with AT, developers can:
- Avoid timed responses.
- Provide keyboard access to all toolbars, menus, and dialog boxes.
- Allow the user to access helpful features already built into the operating system, such as Windows StickyKeys, SlowKeys, and Key Repeating.
IBM Accessibility Checklists
IBM's accessibility guidelines, checklists and techniques offer another perspective on accessibility for designers and developers. The checkpoints include detailed rationale, techniques and/or test strategies to assist in the development and testing of accessible products. http://www-306.ibm.com/able/guidelines/index.html