1EdTech Guidelines for Developing
Accessible Learning Applications
version 1.0 white paper
| WGBH | NCAM | SALT PROJECT | 1EdTech Consortium |
8. Guidelines for Developing Accessible Interfaces and Interactive Environments
Interactivity in online learning is the real power behind the medium. Compared to a passive text, a well-designed and highly interactive online lesson offers clear advantages in flexible content delivery as well as assessment.
Developers who create accessible interfaces, simulation and interactive exercises for mainstream computer environments face considerable challenges in making their applications accessible.
The following section offers accessibility guidelines for developers of applications delivered via the web, as well on platforms for assistive technology is not available, such as DVDs and kiosks.
Section 3 of this document "Principles for Accessibility in Online Distributed Learning", presents some general principles to guide developers when creating accessible e-learning software, applications, and content.
Section 5, "Guidelines for Accessible Delivery of Text, Audio, Images, and Multimedia" presents guidelines for creating accessible multimedia presentations.
This section provides additional information beyond that supplied in section 3. However, it does not address specific accessibility issues of operating systems or programming languages. Subsection 8.7 lists resources that support specific development environments.
A comprehensive guide to application software accessibility, Application Software Design Guidelines, is available from the Trace Center.
8.1 Interface Controls
When designing an interface, developers should consider compatibility. It is important to understand how people with disabilities actually use their assistive technologies (AT) and how those technologies integrate with software and underlying operating systems. Course designers, educators, and students all need to use the interface of a learning application, including buttons, text fields, text field labels, menus, and other components.
Common interface control accessibility problems include:
- controls that are labeled with images rather than text.
- controls that require the use of a mouse.
- display options that are not easily located or are not accessible using keyboard navigation.
Learning system developers may enhance the accessibility of interface controls for all users by following these practices:
- Follow accessibility guidelines for the operating system or development platform in use.
- Use the standard components available for the operating system or development platform, or follow accessibility guidelines on how to create custom controls.
- Ensure that all actions can be completed from the keyboard.
- Provide easy-to-use features that allow configuration of the interface according to the user's preferences.
- Provide help files, including an orientation to the interface and its functionality.
- Test interfaces using actual ATs.
8.2 Navigating the Interface
Many users of ATs encounter difficulty trying to use features normally accessed only by a mouse. Making the interface overly mouse dependant will surely cause difficulties for AT users, especially when navigating through content and other elements such as menu bars, tables of contents, and frames.
Common interface navigation accessibility problems include:
- indexing or navigation systems that use complex frames where the title or name attribute is absent.
- tables of contents with expand/collapse features (e.g., blue triangles, plus-minus signs) that lack text labels
- menu bars built using scripting languages that ATs cannot understand.
Learning system developers may enhance the accessibility of interface navigation for all users by following these practices:
- Provide names, titles, or text labels for each element of the interface.
- Ensure that the keyboard can access all parts of the interface. Clearly document all appropriate keystrokes.
Forms must follow interface control guidelines in general. But when a large number of interface elements are displayed together in a single form, problems can arise that require other solutions.
Common form accessibility problems include:
- illogical tab order among controls.
- complex layout of controls that makes it difficult to determine which label matches which control, or to determine how a series of related controls are connected.
- form fields in search utilities that do not accommodate keyboard navigation.
- visual-only modifications to form fields that users must perceive in order to proceed. Principle among these modifications are color-coded areas or areas flagged with an image meant to signal that a given field must be filled in or than an error has been entered.
Learning system developers may enhance the accessibility of forms for all users by following these practices:
- Ensure that the tab order makes sense.
- Use programmatic means, when available in the development environment, to indicate which label applies to which field.
- Ensure that all actions can be completed from the keyboard.
- Do not rely on color alone to differentiate information. For example, if the interface uses red text to indicate that a field is required, also include the word "required" next to those items.
- Provide a means for users to easily locate and correct form entries that have errors.
Content creators or educators may enhance the accessibility of forms for all users by following these practices:
- Use clear labels for each form item.
- Place a default value in edit boxes or on the top line of drop-down lists.
8.4 Interactive Exercises: Drag-and-Drop Exercises, Simulations, and Timed Tests
When designing complex interactive activities, developers should take care that interfaces remain independent of the input and output requirements of different users. For example, drag-and-drop activities should be usable with either mouse or keyboard, and keyboard commands should be made as easy to execute as possible.
Also consider the manner in which information is displayed. Simulations can be made accessible by allowing for multi-modal output. For example, in an computer-simulated chemistry experiment shows its results by changing the color of the liquid in an image from colorless to blue, be sure that the same information is available in text presented nearby or in a text tag associated with the image. Finally, remember that some users may respond more slowly than average to on-screen prompts, or may use an assistive technology (AT) that slows down their rate of response. To accommodate this difference, always allow the user to customize timing requirements.
Common interactive accessibility problems include:
- requiring the user to use the mouse even when not specifically drawing on screen.
- activities that require monitoring information at one side of the screen while simultaneously entering information on the other side.
- numerical information that is shown visually (e.g., thermometer readouts).
- lesson directions provided in audio without text transcript or captions.
- text that is displayed over a patterned background.
Learning system developers may enhance the accessibility of interactive exercises for all users by following these practices:
- Ensure that all actions can be completed from the keyboard.
- Provide features that allow users to access multiple sources of information separately, even when they are delivered simultaneously.
- Allow users to customize any timing of events, including having unlimited time to complete a task.
Content creators or educators may enhance the accessibility of interactive exercises for all users by following these practices:
- Present information in ways that are accessible to both blind and deaf users and to deaf-blind users. Include an accessible text representation of all information.
- Ensure readability of screens containing complex backgrounds by providing a visually simpler version as well.
- NCAM offers prototypes that demonstrate a talking math game and a talking science simulation.
- The Digital Field Trip to the Rainforest CD from Digital Frog International offers an "AT Version" with an accessible interface, descriptions of each image, and other access features.
8.5 Interactive Tutorials
Interactive tutorials present images of a software application in action are combined with audio or text narration, in order to teach users how to use that software. While adhering to interface guidelines, developers must also be sure to provide information in multiple modalities in order to meet the needs of all users. It is also important to remember that different users will need to know how to operate the software in different ways, depending on their accessibility needs.
Common interactive tutorial accessibility problems include:
- tutorial tasks that can only be completed using a mouse even though the skill being taught can be completed using a keyboard in the full program.
- narration that is provided in audio only without a text version for users with hearing impairments.
- references to items by spatial location without orientation for users who cannot see the screen (e.g., "select the window on the left").
Learning system developers may enhance the accessibility of interactive tutorials for all users by following these practices:
- Ensure that interactive tutorials can be operated by keyboard as well as by mouse.
Content creators or educators may enhance the accessibility of interactive tutorials for all users by following these practices:
- Provide directions for using the keyboard, in addition to the mouse.
- Provide text directions in place of, or alongside, audio directions.
- Provide descriptions of screen layouts in text to assist visually impaired users.
8.6 DVDs, Consumer Electronics, and Handheld Devices
Learning tools not available on computers may also present accessibility issues. Other solutions, for set-top boxes such as digital cable, are in development. Access techniques for devices such as handheld devices or personal digital assistants, require research. Accessibility techniques for these devices will inevitably be different than those provided for mainstream computer applications since assistive technology is not currently available on these platforms.
Common DVD, consumer electronic and handheld device accessibility problems include:
- on-screen menus that are visual and cannot be used by blind users.
- touch screen interfaces that are inaccessible to blind users and users with physical disabilities.
- handheld device interfaces with small buttons that may be difficult to operate.
Technology developers may enhance the accessibility of DVD, consumer electronic and hand held devices for all users by following these practices:
- Provide talking interfaces through built-in features. For example, DVDs and set-top boxes can provide talking menus (see "Examples and Resources" below).
- Consider using the emerging Alternative Interface Access Protocol for home networking and other IT products (see "Examples and Resources" below).
- When including multimedia presentations, ensure that access to content is provided by following Guidelines for Accessible Delivery of Text, Audio, Images, and Multimedia (section 5).
- Choose a platform that offers as many access features as possible given the range of learning features required.
- Prepare content so that it can be viewed and used on personal computers or other devices, in addition to the target device.
Examples and Resources:
- Technical details on how to create talking DVD menus are forthcoming from NCAM.
- Two accessible DVDs, are available from PBS: "Abraham and Mary Lincoln: A House Divided" and "Marcus Garvey: Look for Me In the Whirlwind" and include talking menus for access to navigation by blind viewers and access features for the program for both blind and deaf viewers. Both DVD's are available from PBS.
- Universal Studios' Dr. Seuss' "How the Grinch Stole Christmas" DVD also includes talking menus and other access features.
Set-Top Box Accessibility:
- Information and a prototype Electronic Program Guide are available from NCAM.
Accessible Kiosks and Touch Screen Interface Accessibility:
- Information is available from the Trace Center on their EZ Access Interface.
- Alternative Interface Access Protocol: The V2 committee of the US National Committee for Information Technology Standards (NCITS) is charged with developing national standards that will provide access features for users with disabilities. The site provides information about Technology Access Interfaces.
8.7 Accessibility Information for Operating Systems and Development Platforms
Some techniques for creating accessible software are specific to the development environment or operating system (OS). This section provides resources for developers working on the Windows OS and Macintosh OS, for Web developers, and for Java developers.
8.7.1 Microsoft's Windows OS Accessibility
Microsoft provides detailed information on building accessible software for the Windows platform. The Microsoft Accessibility and Disabilities Group has created tools, documents, and APIs that offer ways to take advantage of access features in the operating system. These tools also suggest other ways to make software more accessible. The Microsoft Windows Guidelines for Accessible Software Design provides comprehensive guidelines for creating accessible software.
In particular, the Microsoft Active Accessibility API (MSAA) uses programmatic means to help software communicate with assistive technologies. MSAA exposes elements of the screen and presents their current state. It also exposes the focus, the active area of the screen. Using MSAA, software developers can use entirely custom graphical interfaces while still making each element known to an assistive technology that has been programmed to read this information and convey it to the user.
8.7.2 Apple's Macintosh OS Accessibility
All Macintosh computers ship with several accessibility features already installed. These features support users with sensory or physical disabilities. Developers may want to test their products with these features activated in order to determine whether their software is operable by users requiring assistive technology. Some of these pre-installed accessibility features include:
- text-to-speech technology including the PlainTalk speech synthesizer.
- voice recognition technology.
- CloseView, a built-in screen magnifier for low vision users.
- StickyKeys, software that allows users to strike keys one at a time in cases where two or three keys would normally be pressed simultaneously, such as Shift+F9.
- MouseKeys, software that allows users to control all mouse movements by typing on the numeric keypad.
In addition to the built-in accessibility features for the Macintosh, Apple maintains a list of Mac-based assistive technologies available from vendors outside of Apple. OutSPOKEN is the only screen reader developed for the Macintosh platform. To ensure product compatibility on the Macintosh platform, developers should test their products using outSPOKEN. Macintosh users who are blind will not be able to use educational software if the product is not compatible with this screen reader.
Apple maintains a developer website that offers an array of resources including the Macintosh Human Interface Guidelines. This document provides "authoritative information on the theory behind the Macintosh 'look and feel' and guidelines for using individual interface components. This book includes many examples of good design and explains why one implementation is superior to another."
- Apple Education Disability Resources contains links to information about built-in accessibility features for the Macintosh, as well as a link to the Mac Access Passport, a database of third-party disability products for the Macintosh.
- Macintosh Human Interface Guidelines. Accessibility information is referenced throughout this document and is available comprehensively
- Universal Access information is found in Macintosh Human Interface Guidelines
- The Human Interface Design Principles are found in Macintosh Human Interface Guidelines. Key accessibility information is included in the following section on the Apple website.
- The home page for Alva Access Group, developers of the outSPOKEN screen reader and inLARGE, a screen magnifier. Programmers should download Alva's time-based demos of their products for testing purposes.
8.7.3 Web Accessibility
The definitive source for information on accessibility in Web technologies is the Web Access Initiative at the World Wide Web Consortium (the W3C WAI). The WAI provides recommendations for achieving accessibility using W3C technologies for Web content, authoring tools, and user agents such as browsers and media players. Information is available on W3C technologies including, XML, HTML, SMIL, CSS, and SVG.
8.7.4 The Java Platform
The Java platform is an attractive development environment for creating accessible educational software. Java's strongest feature is the accessibility support that is built into Java's core structure. Its Swing user interface components support accessibility. They include an effective keyboard interface. The Java accessibility API, a standard extension in the Java 2 platform, enables Java-based ATs to interact effectively with mainstream applications. The Sun access team has also developed the Java Access Bridge, which allows users to run Java applications with their platform-specific ATs. The Java accessibility API also contains several properties that enable developers to fine-tune the manner in which assistive technologies present their interfaces.
- Sun Microsystems' Accessibility Program - Developer Information
- The Java Access Bridge
- Java Accessibility Helper identifies areas in an application's UI where the accessibility support has been improperly used. Follow the link from Sun's Accessibility Program.
- The Java Tutorial - Accessibility Section
- Guidelines for Writing Accessible Applications using 100% Pure Java
8.7.5 Other Operating Systems
A longer list of accessibility techniques for additional development environments is available from the W3C.