|
|
|
 |
Windows OS | Macintosh OS | The Java™ Platform | Web and HTML Access Issues for Selected Development Environments Some techniques for creating accessible software are specific to the development environment being used. This section provides information and further resources for developers working on the Windows OS and Macintosh OS, and for the Java environment, Macromedia Director, and Web developers. Windows OS 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 their state. It also exposes the focus of the screen. Using MSAA, software developers can use entirely custom graphical interfaces while still making each element known to an assistive technology which has been programmed to read this information and convey it to the user. Microsoft Accessibility Home Page
www.microsoft.com/enable
Macintosh OS
All Macintosh computers ship with several accessibility features already installed that support users with sensory or physical disabilities. Developers may want to test their products with these features invoked to determine whether their software is operable by users requiring assistive technology. Some of the pre-installed accessibility features include:
In addition to the built-in accessibility features for the Macintosh, Apple maintains a list of Mac-based assistive technology available from vendors outside of Apple. OutSPOKEN is the only screen reader developed for the Macintosh platform. For this reason developers should test their products with outSPOKEN. Users who are blind will not be able to use educational software if the product is not compatible with this screen reader. Apple also has a developer website that contains 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 the practice of 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 sprinkled throughout this document. Universal Access in: Macintosh Human Interface Guidelines The Human Interface Design Principles in: Macintosh
Human Interface Guidelines
Key accessibility information is included in this section. Alva Access Group The Java™ Platform
The Java™ platform is an attractive development environment for creating accessible educational software for several reasons:
As noted in the Nuts and Bolts section of Sun's Developing Accessible JFC Applications, The accessible name is a succinct explanation of the object's purpose. A user navigating a graphical interface will encounter many components, so the name of each component is preferably no more than one or two words, in order to avoid information overload . . . When using the standard JFC/Swing! components, objects containing non-editable text will have their accessible names set automatically. Examples of these types of objects are menu items, buttons, radio boxes, and items in a list. However, some objects contain no static text and must have their names set by the developer. If the object on the screen has a label associated with it, the programmer's job is easy. Simply label the object with an instance of JLabel and use setLabelFor() to set the correct properties in the AccessibleContexts. This association is important because changes to the label automatically propagate to the assistive technology. The Nuts and Bolts section of Sun's Developing Accessible JFC Applications also explains: The accessible description of an object is a more verbose explanation and should be provided in cases where additional information may be useful. Accessible descriptions are set automatically by setting a tooltip on an object, via JComponent.setTooltipText. This has the obvious advantage of not only aiding those with and without disabilities, but also ensures that the accessible description will be updated automatically with the tooltip. If an object's accessible name and accessible description are set manually, labels or tooltips added in future releases will not be automatically updated. Java applications or applets can also be made accessible by using IBM's Self-Voicing Kit (SVK), created by the IBM Accessibility Center. (At the time of this writing, it is the only stand-alone assistive technology package available for the Java platform). The SVK is code that Java programmers can add to their applications to automatically enable a speech interface. It also allows for extensions, called "perks," which developers can use to customize and fine tune the audio interface. NCAM's CD-ROM Access project has created a prototype accessible Java application, based on Photosynthesis Explorer, part of a series of biology simulations from Logal, Inc. This prototype demonstrates that a moderately complex interface can be easily adapted for use in a speech interface using the Java Accessibility API and IBM's Self-Voicing Kit for Java (SVK). An approach for presenting a visual graph through audio is also demonstrated. This prototype can be downloaded from the Photosynthesis Explorer Prototype section. Access to menus, buttons, sliders, and other controls in the Photosynthesis prototype is accomplished through implementation of Sun Microsystem's Java Accessibility API. Swing controls implementing the Accessibility API by default make much of the interface accessible, thus meeting the needs of users of platform-specific assistive technology using the Access Bridge as well as users of IBM's SVK. Once all of the options available through the Java Accessibility API have been exhausted, it is best to optimize the application to work with a specific assistive technology. Keep in mind that this approach will limit accessibility of the application for some users. Information about how the software has been optimized should be well documented in the product's help section and in any teacher-support materials provided with the software. The Photosynthesis prototype demonstrates how programmers can customize the audio interface using the SVK: Slider controls enable students to vary the light, temperature, humidity, and other inœuences on a plant. By default, when the temperature slider control has focus, the SVK announces "slider at 30." The default announcement is inadequate for an educational application because science materials always identify values with their units, such as "degrees Celsius." By writing a perk, the programmer customized how the SVK reports the temperature slider. With the perk in place, when the temperature slider has focus, the SVK says "Temperature 30 degrees Celsius." dWhile the original presentation of the material in Photosynthesis Explorer relies largely on visual displays for both input and output there is numeric information at the heart of the simulation. By using Swing controls to make all six input variables standard sliders and by writing a perk enabling the SVK to read the output as it changes, NCAM created an audio interface to this simulation. This allows blind students to learn interactively about the factors needed for successful photosynthesis alongside their sighted peers. Guidelines for Writing Accessible Applications using 100% PureÅ Java Macromedia Director Applications created with Director are not compatible with assistive technologies. For example, text drawn to the screen may be read by a screen reader, but no information about the object containing the text is communicated. This means a blind user might hear the words on a button but not realize that it is a button. In addition, many developers use graphics to draw their buttons and on-screen messages to create a customized visual design, but Director does not provide a way to label these graphics with text so that they can be interpreted by a screen reader. Director does not by default support using the keyboard to interact with on-screen controls. Developers generally create mouse interactions for each object. If an application has a series of buttons displayed, the developer must add code to permit use of the tab key to move the focus from item to item and to have the enter key or spacebar trigger activation of the button. In addition, the custom menu bars developers can create for the Macintosh OS in Director, look like operating system menu bars, but do not behave in a standard way. They are not compatible with screen readers for Macintosh. All features made available in the menus must be available in some other way, such as with a keyboard shortcut or in an accessible dialog box. Because of these limitations, developers using Director to create educational software must create directly accessible applications. This includes building a full keyboard interface so that students who cannot use a mouse can access the software, and providing full audio output for visually impaired users. Audio can be provided by recording a narrator voicing all text or by using text-to-speech software to voice text strings. A Director Xtra (a programmer's tool which expands the functionality of Director) adds text-to-speech to Director applications. In some cases, a product can be designed to include default features for low-vision users, such as a choice of font size or high contrast colors. Search Macromedia's web site at www.macromedia.com for the most up-to-date information on Xtras and on implementing keyboard access. Consult Electronic Ink at www.printomatic.com/products.cfm for the Yak Xtra for text-to-speech. Video in a Director application can be made accessible by providing closed captions and audio description. If QuickTime movies are embedded within a Director application, the access tracks can be controlled within Director by referencing the tracks by track number. For example, if the main video track is track one, the main audio is track two, the captions are track three, and the audio description is track four, buttons can be added to the user interface that allow users to turn captions and description on and off. Use the track numbers to send the information about which tracks to display to QuickTime. For more information consult the documentation for QuickTime and Director. Guideline 2 includes information on how to implement access features in digital video. An example of a directly accessible Director application is available from the CD-ROM Access Project. The prototype accessible version of "How the West Was One + Three x Four" (based on the original program from Sunburst Communications, Inc.) shows how a full keyboard and audio interface can be created using Director, allowing all students to use a math game that originally was inaccessible. This prototype can be downloaded from the West Prototype section. Web and HTML Software which presents content written in HTML and other web technologies should follow the Web Content Accessibility Guidelines. Software which allows users to author their own web content should follow the Authoring Tools Accessibility Guidelines. Both of these documents are available at the WAI web site. Software which provides a proprietary interface to HTML content should follow the User Agent Accessibility Guidelines. Users should be able to choose their own web browser to view material provided by the software. Students with disabilities can then take advantage of assistive technologies that software developers may not be aware of. Locking users into a specific browser can reduce the accessibility of even well-designed web content. Assistive technologies for use with HTML content may include a talking MathML browser or plug-in, or access features designed into mainstream browsers like Internet Explorer. Additionally, there are specially designed talking web browsers on the market like HomePage Reader and pwWebSpeak. Creating content according to the Web Content Accessibility Guidelines and allowing users to view it in the browser most accessible to them is the easiest method of creating accessible software. |
|
|   |
|
TABLE OF CONTENTS | CREDITS WGBH | NCAM | CD-ROM PROJECT |
