Making Educational Software and Web Sites Accessible
Design Guidelines Including Math and Science Solutions

WGBH | NCAM | ACCESS TO PIVOT PROJECT

COMBINED VERSION TO PRINT

URL: http://ncam.wgbh.org/cdrom/guideline

Geoff Freed, Madeleine Rothberg and Tom Wlodkowski
The Access to PIVoT Project
January 2003
The CPB/WGBH National Center for Accessible Media
WGBH Educational Foundation
125 Western Avenue
Boston, MA 02134
(617) 300-3400 voice
(617) 300-2489 TTY
access@wgbh.org
http://access.wgbh.org

To order printed copies of these guidelines, please contact Mary_Watkins@wgbh.org

Funding provided by the National Science Foundation, award number HRD-9906159, through the Program for Persons with Disabilities. Additional funding provided by Mitsubishi Electric America Foundation (MEAF), dedicated to helping young people with disabilities, through technology, to maximize their potential and fully participate in society. Principal Investigator: Geoff Freed.

The original version of this document, Making Educational Software Accessible: Design Guidelines Including Math and Science Solutions, was published in 2000 with funding from the National Science Foundation, award number HRD-9623958.

Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation or the Mitsubishi Electric America Foundation.

Copyright 2003, WGBH Educational Foundation

Introduction

Students with disabilities are increasingly placed in inclusive classrooms where they learn alongside their peers. This poses a challenge to teachers and students because instructional materials may not be available in a form that is accessible to the disabled student. Inaccessible materials stigmatize students with disabilities by preventing them from using the same materials as their peers and can limit their educational opportunities. As technology becomes more prevalent in classrooms, students with disabilities face even more challenges in keeping pace with their classmates.

Publishers, educational software programmers and Web site developers are increasingly aware that they must consciously include students with disabilities in their audience. Producing materials that are accessible will increase their reach by broadening the market to include students who have been excluded until now. Additionally, policies are now in place or are under consideration in several markets that make accessibility a requirement for electronic educational materials. However, few developers understand why access is a critical need or how to provide it in their products. This document addresses both these points in detail.

These guidelines were first published in 2000 under the name Making Educational Software Accessible: Design Guidelines Including Math and Science Solutions. They represented an ambitious initiative to capture access challenges and solutions and present them in a format specifically designed to educate and assist educational software developers. This work was the result of a three-year project funded by the National Science Foundation's Program for Persons with Disabilities <http://www.ehr.nsf.gov/hrd/ppd.asp>.

In 1999, NCAM launched a four-year research collaboration with the Massachusetts Institute of Technology (MIT) called Access to PIVoT (Physics Interactive Video Tutor). Funding for this collaboration was provided by the National Science Foundation's Program for Persons with Disabilities, and the Mitsubishi Electric America Foundation (MEAF) <http://www.meaf.org/>. PIVoT <http://curricula2.mit.edu/> is a comprehensive on-line supplemental learning environment that augments MIT's introductory Newtonian physics class, one of the institute's most challenging freshman course offerings, even for students of MIT caliber. Using a sophisticated Web site and streaming digital video, PIVoT provides a unique 24-hour-a-day opportunity for students to conduct "virtual office hours" with the course's renowned physics professor, Walter Lewin. Students using PIVoT have access to a large amount of material ranging from a complete on-line textbook to a multimedia library containing a year's worth of lectures as well as dozens of tutorials centered around specific problems in the course. Non-MIT users may request a guest account at the PIVoT home page.

NCAM began the project by evaluating PIVoT for accessibility problems relating to multimedia, navigation, and the presentation of text, illustrations, graphs and tables. Project staff then worked with MIT to improve the accessibility of the PIVoT Web site through the use of accepted practices such as those detailed in the Web Content Accessibility Guidelines version 1.0 (WCAG) <http://www.w3.org/TR/WCAG10> from the World Wide Web Consortium's Web Accessibility Initiative (W3C/WAI) <http://www.w3.org/wai/>. Other techniques were developed by NCAM and MIT staff specifically for PIVoT (e.g., extended audio descriptions). NCAM also trained MIT students to write captions and audio descriptions for the multimedia library and to write image descriptions for two of the textbook chapters.

The culmination of the Access to PIVoT project is this new set of guidelines, essentially an updated version of the original Making Educational Software Accessible guidelines. As in the original document, readers are given:

• a basic understanding of the needs of users with different disabilities.
• a summary of various approaches to serve users with different disabilities.
• specific solutions for designing more accessible software.
• guidelines with specific checkpoints and detailed techniques for implementation.

To this list, the Access to PIVoT project has added:

• extensive information on making multimedia presentations accessible to deaf or blind students.
• examples of writing image descriptions for blind students.
• solutions for making forms and data tables accessible.
• information on making electronic and on-line textbooks accessible.

We hope that the information contained here will continue to address the need to create accessible software and Web sites which include images, multimedia, interactivity, data tables, graphs, and mathematical and scientific expressions.

Properly designed educational software and Web sites can and must be accessible to students with disabilities. Developers who incorporate access solutions may find that these modifications bring benefits to the wider student population, as studies of multimodal learning have shown. The principles of universal design, designing to meet the needs of as many users as possible, provide a new dimension for improving the usability of educational materials for all students.

Educational Issues for Students With Disabilities

We begin with some general issues related to the education of students with disabilities.

Inclusive Classrooms

Revisions to the Individuals with Disabilities Education Act (IDEA) have changed the focus of special education from providing separate services for students with disabilities to including more students in mainstream classrooms. The IDEA Amendments of 1997 were the first major revision to the Act in more than 23 years. The new legislation encourages schools to place students in inclusive classrooms, when appropriate, in order to provide the social and academic benefits of taking part in the general curriculum.

In the Twenty-First Annual Report to Congress on the Implementation of the Individuals with Disabilities Education Act <http://www.ed.gov/offices/OSERS/Policy/IDEA/regs.html>, the U.S. Department of Education noted that:

"Previous research findings suggest that social interactions between students with and without disabilities are enhanced when students with disabilities are served in regular classes, particularly if teachers use delivery techniques that promote interaction."

"Changes in instructional strategies designed to address the needs of students with disabilities were cited as beneficial for many students without disabilities."

Forty-six percent of students with disabilities were educated in regular classrooms in 1996-97. This was an increase from previous years according to data collected since the Act was passed in 1975. Visually impaired students are placed in inclusive classrooms in public schools at even higher rates than students with other disabilities. Sixty-seven percent of blind and low vision children are in a regular classroom. Seventeen percent of blind and low vision children are in a self-contained classroom within the regular school building. Students with disabilities placed in regular classrooms receive needed support services within the classroom or outside the classroom from an itinerant teacher or from a special teacher assigned to that school.

However, in inclusive classrooms, students with disabilities do not always have access to the same learning tools as their classmates. For example, students with visual impairments rely on alternative format books, such as large print or braille, which are often not ready in time for the beginning of the school year. While other students are receiving their books in print all at once, blind children may get a chapter at a time and must hope that the sections they need will arrive in time for them to keep up with their class. Other visual materials may never be adapted, and students must rely on teachers or classmates to describe them as best they can. Students with physical disabilities may also have trouble using printed textbooks and other classroom materials which require manual dexterity.

Educational Software Use

Educational software has become an important tool in our classrooms. Instructional materials are available as software or on the Web, and teachers are being trained to use the computers that are in their classrooms. Concern about the "digital divide" that is emerging as some students are exposed to technology while others are not has led to government and industry initiatives focused on disadvantaged students. Students with disabilities must be considered as more instructional materials move into digital form.

Educational software presents challenges for students with disabilities in a number of ways. While other students are using an interactive simulation to learn a biology lesson, the student with low vision may be sitting to one side listening to classmates as they describe what they are doing. Chances are, the sighted students will leave out some details and the visually impaired child will miss important information. Tools for graphing and solving equations in mathematics allow students today to approach math from an entirely new perspective, learning constructively rather than memorizing algorithms. But if blind students can't use the software that makes such an exploration possible, they will not have the same valuable learning experiences that other students have. A student with a hearing impairment may be unable to hear instructions for a lesson which are given only in audio and therefore have no way to begin the assignment. In some cases, the child with a physical disability may be "excused" from the computer lesson and sent to another area of the room for a different activity. This lack of accessibility stigmatizes children by preventing them from using the same materials as their peers and limits their educational opportunities.

Benefits of Accessible Software

Properly designed educational software can solve many of the problems discussed above. Both electronic textbooks, which present the kinds of information normally conveyed in print, and interactive educational software can be made accessible to students with disabilities; the modifications needed to achieve this will also bring benefits to the wider student population.

Electronic Textbooks

Accessible electronic textbooks can bridge the gap that often exists for students who require braille textbooks. While there are established braille production facilities that specialize in producing educational materials for blind children, major obstacles exist that force many students to begin class without the braille version of their books. These include last-minute decisions on what book will be used in class and the lack of availability of the electronic files needed to produce the braille version of the book. Math and science textbooks are among those most difficult to produce in braille. Too few transcribers are available with a knowledge of Nemeth Code, the braille code for math. And the electronic files that publishers provide for some textbooks are not properly coded to translate mathematics automatically the way other text can be translated. This has led to a serious shortage of math and science books for blind students.

Some students do not use braille and instead use audiotaped books which lack many features of both print and electronic books, such as the ability to quickly locate specific sections and to place bookmarks for future reference. In addition to providing these important features, an electronic textbook ensures that every student in class is using the same book, and everyone gets it on the first day of school. The suggestions specific to math and science in these guidelines make both software and textbooks more accessible and reduce the barriers to studying these subjects that students with disabilities currently face.

Interactive Educational Software

Accessible interactive software can bring the benefits of multimedia and experimental learning to students who may otherwise be left out. Interactive learning experiences will be especially enriching for students who may otherwise have more limited experiences. Because students with disabilities may not be exposed to as wide a range of activities and environments as other students, software can contribute positively toward filling in some of those gaps. Chemistry experiments, for example, may be more easily carried out in a simulation than in a wet lab for some students. Biology lessons learned from dissections may be more meaningful to some students using simulation software with an effective keyboard interface than watching others use a scalpel. The importance of hands-on science learning should not be forgotten, but when electronic alternatives are appropriate they must be accessible if they are to benefit all students. The guidelines in this document, as well as the software accessibility guidelines listed in the section on selected development environments, make it possible to create accessible interactive software.

It is important to note that not every product can be made accessible. The educational goals of a program are sometimes incompatible with providing non-visual access, especially for students who are blind. For example, many programs for young children teach visual concepts, such as counting and color pattern matching. While blind students do need to learn to count and to make patterns, a program that uses only visual ways of teaching these skills is a poor candidate for adaptation. Low-vision students, however, may still learn from a visual program, provided it is well designed. Software should allow fonts to be adjusted, provide clear contrast for objects that students must locate and manipulate, include keyboard commands to reduce mouse dependence, and provide a system cursor that moves with important screen events so that magnifiers can track them. With these features in place, software with a range of educational goals can benefit students with some vision. More information on these adaptations is provided throughout this document.

Considering the Ages and Skill Levels of Students

Students of different ages and with different amounts of computer experience may need different kinds of accessibility features in educational software. Young children may not have been exposed to any assistive technology. For example, young children with visual impairments will have the most success with software that is designed to provide the flexibility they need directly through options a teacher can set for them, such as enhanced audio, larger fonts and icons, and high contrast backgrounds. Older students may have been taught to use a screen magnifier and can therefore rely less on adjustments available within the program itself.

Just as other computer users vary in the amount of experience and comfort they have in using software, users with disabilities vary greatly. Some students with visual impairments may receive keyboard training fairly early in their school career, while others may not use a computer until later. Some students may be comfortable using their assistive technology for only the most rudimentary tasks, while others will be more adept. Also, not all assistive technologies offer the same features, so some students may be able to use their assistive technology with a certain piece of software, while others will not. This range of skills, comfort levels and technology limitations should be considered when deciding how to provide accessibility in educational software.

Information on types of assistive technology can be found on page 15. Further discussion of providing accessibility with and without the use of assistive technology is found in the section on types of accessibility on page 16.

Preserving Pedagogy During Access Adaptation

Some kinds of access adaptations may change the nature of the lesson or may seem to give students with disabilities the "answer" to an assessment question. It is important to consider the intended learning goals of each lesson in order to pick the most appropriate adaptation. For example, if students are shown a photograph of a bird and asked to describe the main features of the bird in a sentence, providing an audio description of that photograph for blind students takes away the need for the students to write a description themselves. However, providing a tactile image of the bird may allow blind students to explore the image and create their own description of the bird's main features. It may be equally appropriate to modify the activity slightly. If the goal of the lesson is to understand how different birds are similar and how they are different, students could listen to (or read) descriptions of two birds and compare their main features in a sentence. Teachers who have tried this kind of modification have often found that it benefits all their students.

These kinds of adaptations are sometimes suggested in teacher's editions of textbooks. In some cases they are created as needed by teachers in inclusive classrooms. Educational software can provide alternative activities automatically or with a teacher's intervention within the lesson or through supplemental materials.

The National Center on Access to the General Curriculum at the Center for Applied Special Technology (CAST) <http://www.cast.org/> provides more information on access adaptations and the educational goals of instructional materials.

Benefits of Multimodal Learning

Making software and electronic textbooks accessible to students with disabilities has benefits for other students as well. These benefits are especially important for students learning English as a second language and those with reading difficulty. Accessible textbooks and software often provide multi-modal access to information, combining text with audio. Research shows that such multimedia materials can improve learning for non-disabled students. For example, Tindall-Ford and colleagues showed in several different experiments that when information is presented in audio and visual form, performance on complex tasks is improved (1997). J.R. Williams reviewed about 100 studies from the literature on use of multimedia in instruction and found that combining visual and verbal information can lead to enhanced comprehension (1998).

Policy Issues

Policies are now in place in several markets and jurisdictions that make accessibility a requirement for educational software. Each mandating agency generally establishes its own set of requirements, although the U.S. Federal government's Section 508 rules (see below) are rapidly becoming the example that many follow. Information in these guidelines will help software developers meet the expectations of the policies discussed below.

U.S. Federal Government Requirements

ADA and Section 504

Two Federal laws govern accessibility of education: Title II of the Americans with Disabilities Act (ADA) and Section 504 of the Rehabilitation Act of 1973 (as amended in 1998). All elementary and secondary schools and most postsecondary educational institutions are regulated under these laws. Title II and Section 504 have essentially the same requirements.

Regulations prohibiting discrimination in education are enforced by the Office of Civil Rights (OCR) at the U.S. Department of Education. Visit their Web site for more information on disability rights <http://www.ed.gov/ocr/disability.html>.

A useful legal analysis of these requirements is provided in the California Community Colleges' Distance Education Access Guidelines <http://www.htctu.fhda.edu/>.

The requirements of Section 504 and Title II of the ADA specify that institutions must be responsive to the needs of individual students and make programs and services accessible to them on request. This differs from the proactive requirements of Section 508, discussed below, which state that all technology purchased by the Federal government must be accessible whether it is initially intended for use by a disabled employee or not.

However, the settlements made between educational systems and the OCR in response to complaints of disability discrimination have sometimes required the educational institutions to make systemic and proactive changes in their procurement and use of instructional materials to ensure that textbooks and educational technology are accessible to students with disabilities. The California Community College guidelines mentioned above are one outcome of this process (Docket #11-01-1132); statewide requirements in North Carolina for textbook accessibility are another example (Docket #09-97-6001). For more information about OCR agreements contact the office at 1-800-421-3481 or see the contact information on the OCR Web site <http://bcol01.ed.gov/CFAPPS/OCR/contactus.cfm>. Also see the U.S. Department of Education Office for Civil Rights <http://www.ed.gov/ocr/disability.html> for information on how these laws are enforced.

Section 508

In order to ensure that its technology is accessible to its own employees and to the public, the Federal government has created regulations based on Section 508 of the Rehabilitation Act that require that electronic and information technology developed, procured, maintained or used by the Federal government be accessible to people with disabilities. These regulations apply to all Federal purchases of technology. Requirements in Section 508 may also impact state colleges and universities, pending policy decisions from the Department of Education Office of Civil Rights. For official information on Section 508 see:

The Access Board
<http://www.access-board.gov/>

Federal IT Accessibility Initiative
<http://www.section508.gov/>

U.S. State Policies

The Technical Assistance Project at RESNA (Rehabilitation Engineering and Assistive Technology Society of North America) maintains a partial list of states with accessibility requirements for government Web pages <http://www.resna.org/taproject/policy/initiatives/508/atprojects.html>.

The Texas School for the Blind and Visually Impaired maintains a list of states with requirements for publishers to provide electronic files of printed textbooks <http://www.tsbvi.edu/textbooks/afb/state-laws.htm> purchased in the state.

Some recent and interesting state requirements are summarized in this section.

California Higher Education Requirements

The California Community College (CCC) system has released Distance Education Access Guidelines and Alternate Media Access Guidelines. The Alternate Media Access guidelines serve as a guide for the implementation of California law AB422 requiring publishers to provide textbooks in electronic format to the three systems of higher education in California (the University of California, the California State University, and the CCC). The Distance Education Access Guidelines serve as a guide for the implementation of the CCC's agreement with the U.S. Department of Education's Office of Civil Rights to ensure that students with visual impairments are given full access to distance learning in the CCC system. This document includes a summary of legal requirements as well as access guidelines for specific modes of distance education instructional delivery. CCC's two sets of guidelines <http://www.htctu.fhda.edu/> are available from the CCC High Tech Center Training Unit

Maryland K-12 Educational Technology Requirements

Maryland enacted legislation in 2002 stating that any purchase of technology-based instructional products by school districts must include a requirement of equivalent access for students with disabilities, as defined by the Federal Section 508 requirements. This will also apply to teacher-developed instructional materials beginning in fiscal year 2005. Read the Equivalent Access for Students with Disabilities bill <http://mlis.state.md.us/2002rs/billfile/SB0226.htm> on the Maryland General Assembly Web site.

New York State K-12 Textbook Requirements

The New York State requirement for accessible textbooks mandates every school district to develop a plan for providing instructional materials to students with disabilities at the same time they are available to students without disabilities. It directs districts to amend their procurement policy to give preference to publishers who provide alternative format materials, including electronic files. An accessible electronic textbook might be a way to meet these provisions. Read the text of bill A07962 <http://assembly.state.ny.us/leg/?bn=A07926> on the New York State Assembly Web site.

Texas K-12 Print and Electronic Textbook Requirements

Texas has for several years been studying the issue of access to electronic books and educational software for students with disabilities. Two reports, one issued in 1997 and another in 1999, provide information on how educational materials can be made accessible. Texas requires publishers to provide electronic files for adopted print textbooks and now, since the announcement of Proclamation 2002 <http://www.tea.state.tx.us/textbooks/proclamations/index.html> (for materials that will be purchased for use in 2005-2006), requests that publishers meet Section 508 requirements as a part of their adoption submissions for electronic textbooks.

The Texas School for the Blind's Instructional Resources Page <http://www.tsbvi.edu/Education/index.htm#Textbooks> offers the two reports mentioned here, as well as additional information on accessible instructional materials.

Disabilities, Functional Limitations and Accessibility Tips

This section introduces several types of disabilities affecting vision, hearing, physical capacity and cognitive skills. Each disability presents unique challenges to computer users. The following subsections also include general strategies to meet those challenges and to increase accessibility for those users.

Resources

See the Trace Center Accessible Software Guidelines <http://www.trace.wisc.edu/world/computer_access/software/> for a comprehensive guide to creating accessible software.

This section is adapted with permission from a previous publication of the Trace R&D Center, the Application Software Design Guidelines <http://trace.wisc.edu/docs/software_guidelines/toc.htm>, written in 1994. The updated version is the IMS Guidelines for Developing Accessible Learning Applications <http://www.imsproject.org/accessibility/index.cfm>.

For People Who Are Blind

Many people who are legally blind retain some residual vision. Some may be able to see objects with the help of magnification. Others may be able to sense light and dark but little else. Because of the wide range of visual sensitivity found among those who are legally blind, a well-designed interface should assume that the end user has no vision, while allowing that person to make use of whatever residual vision he or she possesses.

To access online material, blind users depend on screen-reading software that digests the contents of the computer screen and sends information to a text-to-speech synthesizer or refreshable braille display.

Developers can do much to support screen-reading software and to help blind users perceive and understand screen content.

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 system standard on-screen controls whenever possible.
• define tools in toolbars, palettes, and menus as separate items, and avoid creating single graphics containing multiple objects. When tools and other objects are kept separate, the screen reader is better able to identify and name each tool for the user.
• embed descriptive text 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 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.
• 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. Locking the help balloon in place lets user 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 toolbars.

Finally, documentation and training materials are always more accessible when:

• documentation and on-line help can be understood independent of graphics. Text descriptions should stand on their own.
• synchronized audio descriptions are available to play alongside animated graphics or movies.

For People with Low Vision

"Low vision" refers to a range of vision problems including:

• poor acuity, meaning blurred or fogged vision.
• loss of all central vision; the ability to see only the outer ring of the visual field.
• tunnel vision; the ability to see only the center of the normal visual field.
• loss of vision in other parts of the visual field.
• other problems, including night blindness, reduced contrast and sensitivity to glare.

Computer users with low vision often depend on the ability to enlarge or otherwise enhance areas of on-screen information. Screen enlargement software can be tremendously helpful.

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 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.
• allow the user to zoom in on or magnify portions of the screen.

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 system 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 simultaneously two or more events occurring far apart from each other on the screen.

For People with Color Blindness

To improve access for colorblind users, developers can:

• make color coding a redundant or secondary means of conveying information.
• ensure that the program will run in monochrome mode.
• use variations in contrast and brightness in addition to color variations.

For People Who Are Hard-of-Hearing or Deaf

Many users with hearing losses need to have some method for adjusting volume or for coupling audio output directly to their hearing aids. These are hardware requirements that can be met by systems with built-in volume controls and headphone or audio output jacks. Users who have more severe hearing losses may choose to combine these solutions with visual display technologies designed for people who are deaf.

To increase the accessibility of software to users with hearing impairments, developers can:

• provide all auditory information visually.
• provide captions with all multimedia presentations.
• 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 signal and caption for each audio event.

Finally, telephone support staff should also have a text telephone (TTY) available in order to be able to assist deaf or hard-of-hearing customers.

For People with Physical Disabilities

The nature of physical disabilities varies widely. Some physically disabled users experience complete paralysis in some portion of their bodies. Others are restricted by muscular weakness. Some may have a very limited range of motion but may possess very fine movement control within that range. Others may have feeling in their limbs but little control over them. Still others have to work with uncontrolled, sporadic movements that interfere with their purposeful movements. Users with arthritis report that the joints in the hand and elsewhere are restricted in their range of motion both mechanically and by pain. Some users have posture difficulties that present problems solved only by mounting the computer screen in a non-standard orientation.

Physical disabilities by themselves do not usually affect a person's ability to perceive information displayed on the computer screen. They can, however, interfere with the interactive experience by preventing users from easily manipulating the interface.

To increase the accessibility of software for people with physical disabilities and ensure compatibility with assistive technologies, developers can:

• avoid timed responses or, when they cannot be avoided, lengthen the time allowed for a user to respond.
• 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 Sticky Keys, Slow Keys and Key Repeating.

For People with Language or Cognitive Disabilities

Language and cognitive disabilities are very difficult for developers to address, partly because of the diversity represented in the category. The group includes individuals with:

• general processing difficulties such as mental retardation, brain injury and others.
• specific deficits such as lack of short-term memory, the inability to remember proper names and others.
• learning disabilities such as dyslexia, dyscalculia, dysgraphia, auditory perceptual disabilities, cognitive disorganization, and visual perceptual disabilities.
• language delays.

In addition, the degree of impairment within each of these categories can range broadly, from minimal to severe. In general, software designed to be as user-friendly as possible will improve accessibility for those with language or cognitive impairments.

To improve accessibility for people with language or cognitive disabilities, developers can:

• allow all message alerts to remain on screen until dismissed by the user.
• make language and instructions as simple and straightforward as possible, both on screen and in documentation.
• use simple and consistent screen layouts.

It is important to bear in mind that those with language and cognitive disabilities often have difficulty processing print. To increase accessibility for this population, developers should take steps to make their software compatible with screen-reading software (for more information, see the section entitled "For People Who Are Blind.")

Tools for Access: Types of Assistive Technologies

Assistive technology (AT) is an umbrella term used to describe any product or technology-based service that helps disabled people to live, learn, work and enjoy life. In the context of on-line education, assistive technology refers to hardware and software technologies that enable people with disabilities to use a computer more effectively. The following is a brief overview of the main categories of these assistive technologies.

Screen Readers

Screen readers are software products designed for blind users, but they are also useful to users with learning disabilities. Screen readers locate information seen on the computer screen and vocalize it using text-to-speech software and, occasionally, hardware. Most screen readers work in close concert with the operating system, relying on the computer's built-in capabilities. Applications and software that conform to the standards of the operating system are more likely to be accessible. Applications and software that ignore the requirements of screen readers and the operating systems that support them may well prove unusable for some disabled people.

Refreshable Braille Displays

A refreshable braille display is a tactile device that raises or lowers dot patterns on command from an electronic device, usually a computer. The result is a line of braille that can change from moment to moment. Current refreshable braille displays range in size from one cell (six or eight dots) to an 80-cell line, most having between 12 and 20 cells per line. Braille displays are the primary means of access to computers for users who are deaf-blind.

Screen Magnifiers

Screen magnifiers are software solutions for people with low vision. These products allow the user to enlarge the size of images and text displayed on screen. Screen magnifiers may also permit the user to change the default colors of the display.

Compatibility between screen magnifiers and software can be a problem for developers. Typical screen magnifiers track the cursor or the active region of the screen and will automatically enlarge that portion of the display. Applications that use a custom cursor design may cause the magnifier to enlarge the wrong portion of the screen. Developers can avoid this problem by relying on standard interface practices, particularly those that apply to cursor control and display.

Adaptive Keyboards

Adaptive keyboards are designed for users with physical disabilities who cannot use a standard keyboard. Users with reduced range of motion may require smaller keyboards. Conversely, those without fine motor control may require a keyboard that is somewhat larger. Keyboards that offer fewer choices are helpful to users who benefit from a more structured learning environment and one-handed keyboards are helpful for those who can only type with one hand.

For users who are only able to use a mouse (or assistive technology that emulates a mouse), the keyboard itself can be represented on screen using software. Pointing at individual letters replaces the physical act of typing.

Developers can take steps to support users of these technologies. Applications and software that employ the operating system's standard methods of reading input from the keyboard should be compatible with all adaptive keyboards. Those applications that bypass the operating system and attempt to interrogate the keyboard directly will probably not be accessible to users who wish to substitute an adaptive keyboard.

Voice-Recognition Software

Voice-recognition software allows the user to input data or control the computer by speaking. Voice-recognition software benefits users who have difficulty typing or using their hands. Generally, applications and software that allow full access through keyboard commands are well suited for use with voice-recognition software.

Single Switches

Single switches are hardware solutions for users with physical disabilities who can control the computer only with one or two specific movements. Single switches are used with software scanning preset options on screen. The user triggers the switch when the option he or she wishes to choose has been highlighted during scanning. Single switches can be used in conjunction with on-screen keyboards and word prediction software. Scanning software can be used to create customized screen layouts for use with a variety of applications. However, every clickable spot in the layout must be identified in advance in order for the scanning software to find it.

Resources

See the Technical Glossary of Adaptive Technologies <http://www.utoronto.ca/atrc/reference/tech/techgloss.html> from the Adaptive Technology Resource Centre at the University of Toronto.

Equivalent Access Versus Alternative Access

When considering accessibility of learning applications, it is important to understand the differences between two types of access: equivalent and alternative.

Equivalent access provides the disabled user with content identical to that used by the non-disabled user. For the disabled user, however, that content is presented in a different manner. Providing a course textbook in braille format, on audiotape, or in digital format are examples of equivalent accessibility.

Alternative access provides the disabled user with a learning activity that differs from the activity used by the non-disabled user. However, the alternative activity is designed to achieve the same learning objectives. For example, a mobility-impaired student might be given the option of conducting a science experiment in a virtual laboratory, where the levels of dexterity, strength, and physical access are different from those required in a physical laboratory.

Equivalent access should be provided whenever possible. Alternative access should be provided only if equivalent access is not possible. However, there are numerous examples where software developed for alternative access has become the mainstream choice when its value to all learners was recognized. For example, the virtual microscope developed for disabled students by The Open University (UK) proved better able to achieve key learning objectives than its mainstream counterpart and so came to be used by all students.

Finally, when providing equivalent access via brailled textbooks or tactile graphics, consider timeliness. Ensure that the service provider receives the original materials as far in advance as possible. Depending on the subject matter, the length of the textbook and the complexity of the graphics, it may take up to several weeks to create the braille or tactile copies.

Direct Access Versus Compatible Access

Solutions designed to make education accessible can be grouped into two categories: direct access and compatible access.

A directly accessible product allows a person with a disability to operate all on-screen controls and access all content without relying on assistive technology. For example, to be accessible to users with low vision, directly accessible applications, software, or Web sites offer features that enlarge all controls and on-screen text. They are also designed using high-contrast colors or provide features that allow users to choose appropriate colors.

To be accessible to users who are blind, a directly accessible product should have a keyboard interface with audio output. Such a keyboard interface can also provide access for users with physical disabilities. Audio output should announce the presence and status of all on-screen controls and convey the atmosphere of the application, software, or Web site. A built-in method of using a single key to scan through choices in the application or software will provide access for users who can only use a single switch as input. Teachers of students who are visually impaired report that their younger students receive only limited training with assistive technology. For this reason, providing direct access in products targeted at elementary and middle school students is particularly important.

Direct access brings many benefits. The most important is that the user is able to access educational material without special assistive hardware and software. Thus, direct access helps to reduce costs for schools and individuals, and eliminates the technical difficulties associated with using assistive technology. Direct access also gives students with disabilities the option to use any computer, freeing them from dependence on adapted workstations.

Ideally, the directly accessible interface should be designed by the same people who create the application, software or Web site. These are the content experts; when they apply their understanding of educational goals to designing an accessible interface, the resulting educational experience will certainly be superior to the alternative-assistive technology paired with software not designed with users with disabilities in mind.

Alternatively, the compatibly accessible application, software or Web site is an application designed with assistive technology in mind. This level of access assumes that the user has a preferred assistive-technology package installed and is relatively competent and comfortable with it. A compatibly accessible product is designed with "hooks" built into the software that facilitate the use of a screen reader, screen magnifier or alternative input devices. These hooks are provided by developers using tools such as Microsoft Active Accessibility (MSAA) and the Java Accessibility API from Sun Microsystems. Exposing the system cursor, using standard controls and fonts, and following the operating system's human interface guidelines can also help make a product or Web site compatibly accessible.

Compatible access offers some advantages. It provides consistency of operation between applications for users who already know how to navigate with their assistive technology or who can become competent doing so. In some cases it may be less expensive to develop applications, software, and Web sites in this way. Relying on assistive technology for text-to-speech capability rather than adding it into the product itself, for instance, can save on disk space for larger applications. In reality, compatibly accessible products may be the only means of access for some users, such as deaf-blind braille users who depend on screen readers to interact with computers. Developers who are designing applications, software and Web sites to be compatible with assistive technology should use proven programming techniques to create software that works consistently well with the range of screen readers, alternative input devices (e.g., switches, on-screen keyboards, voice recognition), and any other input or output device that is not part of a standard computer.

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

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 and provides information on other ways to make software more accessible. The Microsoft Windows Guidelines for Accessible Software Design provide comprehensive information on 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 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 that has been programmed to read this information and convey it to the user.

Resources

Microsoft Accessibility Home Page
<http://www.microsoft.com/enable/>

Microsoft Active Accessibility: Introduction
<http://msdn.microsoft.com/nhp/Default.asp?contentid=28000544>

Microsoft Windows Guidelines for Accessible Software Design
<http://msdn.microsoft.com/nhp/Default.asp?contentid=28000544>

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 the following:

• 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 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 Web sites and educational software if the product is not compatible with this screen reader.

Apple also has a developer Web site 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 Disability Resources
<http://www.apple.com/disability/>
Contains links to information about built-in accessibility features for all Macintosh OSes, including the new Universal Access system preference in OS X. Also see the database of third-party disability products for the Macintosh.

Macintosh Human Interface Guidelines
<http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-2.html#avail1-0>
Accessibility information is sprinkled throughout this document.

Universal Access in Macintosh Human Interface Guidelines
<http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-40.html#MARKER-9-55>

Human Interface Design Principles in the Macintosh Human Interface Guidelines
<http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-16.html#HEADING16-0>
Key accessibility information is included in this section.

Alva Access Group
<http://www.aagi.com/>
Alva Access Group manages the development of the outSPOKEN screen reader and inLARGE, a screen magnifier, for the Macintosh. Programmers should download Alva's time-based demos of their products for testing purposes.

The Java™ Platform

The Java platform is an attractive development environment for creating accessible educational software for several reasons:

• Java is a platform-independent language that allows educational software to be accessed from both Macintosh and Windows.
• Accessibility features are built into Java technology's core structure and are supported by the Swing user interface components, which include an effective keyboard interface.
• The Java accessibility API, a standard extension in the Java 2 platform, eliminates any need for retrofitting to enable Java-based assistive technologies 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 assistive technologies, such as Windows screen readers.

The Java accessibility API contains several properties that enable developers to determine how assistive technology reports the presence and status of a particular object. Two of the most crucial properties are an object's accessible name and accessible description. Because the accessibility API is built in to Swing components, many UI elements will have their accessible name set automatically. Other components may need a label associated with the object, using the command setLabelFor().

The accessible description may be a longer piece of text needed to provide better context. Accessible descriptions can be set via Jcomponent.setTooltipText(), which has the advantage of updating the description automatically if the tooltip is changed. If an object's accessible name and accessible description are set manually, labels or tooltips added in future releases will not be automatically updated.

Further information on writing accessible Java applications is available from a number of resources:

Guidelines for Writing Accessible Applications Using 100% Pure Java
<http://www-3.ibm.com/able/snsjavag.html>

The Java Access Bridge
<http://java.sun.com/products/accessbridge/>

Sun Microsystems' Accessibility Program/Developer Information
<http://www.sun.com/access/developers/>

Java Accessibility Helper
<http://www.sun.com/access/>
Identifies areas in an application's UI where the accessibility support has been improperly used.

Developing Accessible JFC Applications
<http://www.sun.com/access/developers/developing-accessible-apps/>
Focuses on strategies for passing Java Accessibility Helper tool tests.

Java Accessibility Quick Tips: Ensuring and Verifying Basic Application Accessibility
<http://www.sun.com/access/developers/tips.html>

The Java Tutorial/Accessibility Section
<http://java.sun.com/docs/books/tutorial/uiswing/misc/>

Macromedia Products

Macromedia, Inc., produces popular software for creating, building and managing Web sites and stand-alone applications. Historically, Macromedia products have not been very accessible to authors or users with disabilities. However, the company is working to integrate accessibility features and enhancements into their product line. See the Macromedia accessibility page <http://www.macromedia.com/macromedia/accessibility/> for complete information.

Macromedia Director

Macromedia Director is a commonly used authoring tool for educational software, but it has significant limitations for accessible design. No comprehensive guidelines are available for creating accessible software in Director. If you are using Director to create content, use the information in the section on disabilities, functional limitations, and accessibility tips, and consult the general guidelines on software accessibility referenced at the beginning of that section.

Applications created with Director are not compatible with assistive technologies, but Director MX includes features that support the development of directly accessible applications via an included text-to-speech Xtra (a programmer's tool that expands the functionality of Director). These new accessibility features allow developers to associate text to be voiced with graphic members of the Director application. This provides additional textual information to help users understand and navigate the application and to create a tab order for keyboard users.

One challenge of directly accessible Director content is that developers must provide additional information about on-screen items in order for them to be useful. For example, a blind user might hear the words associated with an item- words on a button, for example- but not realize that the item itself is actually available unless the developer indicates this by adding informational text to be voiced.

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 use the accessibility features of Director MX to add code that permits the use of the Tab key to move the focus from item to item, and to have the Enter key or space bar trigger activation of the button. This keyboard support is not limited to Director MX, but advanced knowledge is required on the part of the developer in order to implement it in previous versions of Director.

In addition, the custom menu bars developers can create in Director look like Macintosh OS menu bars but do not behave in a standard way. They are not compatible with screen readers for Macintosh. All features available in the menus must be made available in some other way, such as with a keyboard shortcut or in an accessible dialog box. It may be also be possible to use the text-to-speech solution within Director MX. 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.

In some cases, a product can be designed to include default features for low-vision users, such as choice of font size or high-contrast colors. A Director Xtra can add text-to-speech to Director applications. See Macromedia Xtras Developer Support <http://www.macromedia.com/support/xtras/> for the most up-to-date information on Xtras and on implementing keyboard access. (Note that Macromedia Director MX includes a text-to-speech Xtra which can be accessed via the Library.) Also consult DirectXtras <http://www.directxtras.com/> to learn about Xtras related to text-to-speech, including DirectTTS, which provides applications with the ability to talk by transforming text to speech. Electronic Ink <http://www.printomatic.com/products.cfm> also has a text-to-speech Xtra, Yak Xtra, for Director and Authorware.

Video in a Director application can be made accessible by providing closed captions and audio descriptions. 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, then 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. See Guideline 2 for complete information on preparing captions and audio descriptions for digital multimedia.

Can Studios, a media design company in England, has developed Canvas Learning, a tool for creating and delivering accessible e-learning and assessment, which is based on Macromedia Director. One example is "The Street," an accessible 20-hour course that delivers key communication skills. The course targets high school and college students between the ages of 16 and 25. The Can Studios software is designed to be directly accessible, so that a person with a disability can operate all of the built-in access features of the product without relying on an assistive technology. The software offers a full keyboard interface and audio output for all visual commands and lessons. New titles created in Canvas Learning will also offer an integrated magnification tool. Visit Canvas Learning <http://www.canvaslearning.com/> for more information, including an overview of accessibility features and a demo. You may also view a sample of "The Street <http://www.the-can.com/nln_index.htm>."

Another example of a directly accessible Director application is available courtesy of NCAM's CD-ROM Access Project. The prototype accessible version of How the West Was One + Three x Four <http://ncam.wgbh.org/cdrom/guideline2000/west.html> (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. See a description of the accessible prototype <http://ncam.wgbh.org/cdrom/guideline2000/west.html> for more information.

Macromedia Flash

To help users get the most from a Flash experience, Flash Player 6 has integrated support for Microsoft Active Accessibility (MSAA). MSAA serves as a bridge between Flash Player 6 and assistive technologies such as the JAWS and Window-Eyes screen readers. By default, Flash Player 6 recognizes text symbols and text within movie clips and button symbols. Text elements and buttons in movies created in Flash 4 and 5 are therefore available to screen readers, without modification. This means the majority of Flash content available today will be significantly more accessible when used with Flash Player 6. However, this doesn't guarantee that the content was authored to be accessible.

Authors of Flash content may now also take advantage of accessibility features of Flash MX. Using the new Accessibility panel, authors can specify text equivalents for elements of Flash movies and provide control over how assistive technologies handle these elements. The Accessibility panel allows authors to specify a brief descriptive text equivalent (similar to HTML's alt attribute); authors may also write a longer text equivalent if necessary. MSAA then passes this information to assistive technologies, such as a screen reader.

Two resources for more information about Flash accessibility are:

MacGregor, Chris, et. al. The Flash Usability Guide. Birmingham: friends of ED <http://www.friendsofed.com/>, 2002.
Thatcher, Jim, et. al. Constructing Accessible Web Sites. Birmingham: glasshaus <http://www.glasshaus.com/>, 2002.

Macromedia Authorware

Authorware is commonly used by developers of on-line learning content, including Web-based tutorials, tests and simulations. Version 6.5 contains accessibility authoring features unavailable in previous versions. For example, authors can now add screen reader support to presentations as well as text alternates and equivalents for images. Authorware contains a new accessibility Knowledge Object with commands, models and techniques for text-to-speech that helps to create accessible user interfaces. It can also detect the presence of a screen reader, such as JAWS or Window-Eyes, on a user's computer. Blind or visually impaired users may operate Authorware with a screen reader, although some differences will exist between standard and Authorware key mappings.

For authors who wish to integrate accessible video and audio into an Authorware presentation, they should first caption or describe the multimedia using NCAM's Media Access Generator (MAGpie) <http://ncam.wgbh.org/webaccess/magpie/>. The accessible multimedia created by MAGpie can then be incorporated into the Authorware presentation. Authors should always provide an interface, such as a series of accessible buttons, for toggling the captions or audio descriptions on and off. See Guideline 2 for complete information on adding captions and audio descriptions to multimedia. For more information, read about Authorware's accessibility features <http://www.macromedia.com/macromedia/accessibility/features/authorware.html>.

W3C Recommendations

Content written in HTML can benefit from the extensive work on accessibility done by the World Wide Web Consortium (W3C), an industry consortium that aims to lead the World Wide Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability. The Web Accessibility Initiative (WAI) <http://www.w3.org/WAI/> at the W3C coordinates with organizations and industry representatives to ensure that the Web is accessible to people with disabilities.

Content written in HTML and other Web technologies should follow the Web Content Accessibility Guidelines <http://www.w3.org/TR/WCAG10/>. Production of version 2.0 of the guidelines is under way at the time of this writing; see the WCAG Web site <http://www.w3.org/WAI/GL/> for updates and more information. Software that allows users to author their own Web content should follow the Authoring Tools Accessibility Guidelines <http://www.w3.org/TR/ATAG10/>.

Resources are also available for those authoring content and software in the following formats:

XML (Extensible Markup Language)
WAI XML Accessibility Guidelines
<http://www.w3.org/TR/xag>

SMIL (Synchronized Multimedia Integration Language)
Accessibility Features of SMIL
<http://www.w3.org/TR/SMIL-access>

CSS (Cascading Style Sheets)
Accessibility Features of CSS
<http://www.w3.org/TR/CSS-access>

SVG (Scalable Vector Graphics)
Accessibility Features of SVG
<http://www.w3.org/TR/SVG-access>

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. Software that provides a proprietary interface to HTML content should follow the WAI User Agent Accessibility Guidelines <http://www.w3.org/WAI/UA/>. However, for maximum accessibility, users should be able to choose their own Web browser to view material the software provides. Students with disabilities can then take advantage of assistive technologies of which software developers may not be aware. 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 and Opera. Additionally, there are specially designed talking Web browsers on the market, such as IBM Home Page Reader <http://www-3.ibm.com/able/hpr.html>.

The Guidelines

The guidelines in this section lay out specific ways to make distance learning Web sites and educational software more accessible to students with disabilities. Each general guideline includes a number of checkpoints. Most checkpoints are followed by techniques detailing how the checkpoint may be addressed or options for providing access in different ways. Not every technique must be used to achieve the checkpoint's objective, but in many cases techniques are not mutually exclusive and implementing more than one improves the accessibility of the resulting software.

This document does not contain a comprehensive list of guidelines for accessibility of Web sites and software in general. That information is available from other sources, including the following:

The Web Content Accessibility Guidelines 1.0
<http://www.w3.org/TR/WCAG10>

The Trace R&D Center's Software Accessibility Guidelines
<http://www.trace.wisc.edu/world/computer_access/software/>

IBM Accessibility Guidelines (including Web and software)
<http://www-3.ibm.com/able/guidelines.html>

Guideline 1
Provide access to images for users who are blind or visually impaired.

Most Web sites use images to convey content and may have corresponding text referencing these images. When content is provided in photographs, diagrams, or charts people who are blind or visually impaired will miss some or all of the information. Related to this topic is the problem of data table accessibility. For more information, please see Guideline 4.

Currently, static images may be made accessible via alt-text and, where necessary, d-links (descriptive links), literally the letter "d" placed next to an image. A d-link leads to a text description of the image and provides more information than is possible or practical in alt-text. D-links can be supplemented by HTML's <longdesc> attribute; however, user-agent support for <longdesc> is not widespread so d-links are, for the time being, the most reliable method of providing a long description of an image.

Image maps are commonly used for navigation within a Web site. Client-side image maps may be made accessible through the use of alt-text in <area> regions. Avoid using server-side image maps, as they can't be accessed from a keyboard or with a screen reader. If you absolutely must use a server-side image map, always place redundant text links adjacent to the map so someone with a screen reader, or someone who can't use a mouse, can access the information.

Graphic buttons, such as those found in some kinds of forms, must always have alt-text explaining what the button does. See Guideline 3 for more information about forms and form controls.

A relatively new technique to consider is the use of Scalable Vector Graphics (SVG) for images, especially in HTML-based content. Accessibility features of SVG permit improved viewing and printing of images. SVG allows smooth enlargement of images, which can provide large, high-quality images for users with low vision, and metadata included in SVG can be used programmatically to provide text information about images to blind users. SVG may also be used in some multimedia players; for example, to provide captions which must display symbols not supported by text character sets.

For more information about SVG, see:

Scalable Vector Graphics (SVG) 1.0 Specification
<http://www.w3.org/TR/SVG>

Accessibility Features in SVG
<http://www.w3.org/TR/SVG-access>

Checkpoint 1.1
Provide text equivalents for all images.

A sufficient text equivalent can range from alt-text containing a single word or brief sentence to several sentences (e.g., via a d-link or <longdesc>) in order to convey information in a complex image adequately. When images are used for navigation, such as on a navigation bar or image map, alt-text may be enough. If an image is merely used to set atmosphere or provide decoration, it is not always necessary or even desirable to provide a description. In such cases, it is best to give that image a null description, such as blank alt-text, as demonstrated below. (A null description informs assistive technologies that the graphic does not need description. If no description [e.g., no alt-text] at all is included, assistive technologies may announce an unlabeled graphic, leading the user to wonder what is missing.)

Text equivalents can be provided automatically during the display of a document (as alt-text is displayed on a Web page) or they can be made available when the user issues a specific command to obtain the text equivalent (such as a d-link).

Technique 1.1.1
Provide meaningful alt-text for all images in a Web site.

HTML provides specific techniques for adding text equivalents to images. When using IMG, HTML requires authors to use the alt attribute. Alt-text should be used to specify a brief text equivalent. For example:

For client-side image maps, always include alt-text within each <area>. For example:

When it comes to special circumstances such as displaying scientific or mathematical expressions, first consider using specialized markup, such as MathML or SVG, rather than images. See Guideline 8 for more information and related resources. However, if you must use images to display scientific or mathematical expressions, always use alt-text that either describes the image or tells the user where to get a description. Which you use will depend on what the image represents. For example, if an equation can easily be reproduced in alt-text, do so:

Technique 1.1.2
Use the <longdesc> attribute and a d-link to provide an in-depth HTML description, where necessary.

If an image represents something that cannot be clearly reproduced in text, provide a longer, complete description of an image using one of these two methods:

a) The <longdesc> attribute of IMG. <longdesc> specifies a URL to a separate text file that contains a full description of the image. Using assistive technology that recognizes <longdesc>, users can to access this additional information. (Currently, IBM Home Page Reader and JAWS 4.2 and higher support <longdesc>.) For example:

D

Here is the description contained in figure_2-003desc.html:

Note that JAWS currently will not recognize a <longdesc> that has been applied to a linked image.

b) For compatibility with user agents that don't support <longdesc>, always provide a d-link, or description link. This is a link composed only of the letter "d", placed next to the image. When selected by the user, the d-link leads to a long description of the image. In fact, it can link to the same page referenced in the <longdesc>. It can be marked up like this:

To the left is what the image
and its corresponding d-link
look like on a user's screen.

D 

Technique 1.1.3
Write image descriptions.

It is important that anyone writing image descriptions have detailed knowledge of the subject matter. Writers must have good writing skills and an excellent command of the vocabulary associated with the subject, as well as adequate access to reference and support materials, such as textbooks and dictionaries, in order to ensure that the descriptions are as clear and accurate as possible. Finally, the descriptions should be reviewed for accuracy by someone other than the original writer.

If you are describing scientific or mathematical expressions, you should use words, rather than symbols, to write the descriptions themselves. Currently, no standard method exists for articulating complicated mathematical concepts, such as equations, graphs, charts, etc., in spoken English, but there are a few commonly used procedures. The Access to PIVoT project chose to use MathSpeak <http://www.rit.edu/~easi/easisem/talkmath.htm>, developed by Dr. Abraham Nemeth. MathSpeak provides a way to speak mathematical text in an unambiguous manner. MathSpeak can usually be learned in under one hour and contains many concepts already familiar to math and science students.

To the left is an example of an expression described in MathSpeak, taken from the on-line PIVoT textbook, Physics, by Hans Ohanian (New York: W.W. Norton Publishing Company, 1989, 2nd edition). The MathSpeak description is written as follows:

The description page should also contain a Back link, making it easy for the user to return to the correct location on the previous page.

Checkpoint 1.2
Allow images and screen layouts to be printed and enlarged.

Allowing images to be printed separately from the entire screen is a simple and broadly useful adaptation. Using a printed image, low-vision users can create enlarged images. Blind users can use the print feature to create tactile images using specialized equipment. There are tactile graphics printers available that can print an image and may also be able to emboss any corresponding text in braille. Braille printers also exist that emboss images using variable-height dots to create different textures on the paper. Use standard operating system drivers to create images and text to maximize usefulness. For example, send font and character information to the printer rather than images of text, because images cannot be converted to braille.

Technique 1.2.1
Provide commands for printing the entire screen or a specific image.

Flexibility in printing makes it easier for users to get the information they need.

Technique 1.2.2
Use the standard operating system print API.

Specialized printers can use the information sent to the OS to create a high-quality tactile image. For example, the ViewPlus Tiger Advantage Tactile Graphics and Braille Embosser <http://www.viewplustech.com/> converts text into a braille font for image titles and labels, but only if the text is sent to the printer as character information and not a bitmap.

Technique 1.2.3
Allow users to print to a file.

Technology for digitally enhancing images is available that can, for example, convert a photograph into a line drawing by enhancing the edges of objects. To permit these conversions, users need to print the screen or an image to a separate file.

Checkpoint 1.3
Provide tactile graphics or three-dimensional models for images.

For some blind students, reading a text description is far less useful than exploring a tactile image or model. Two-dimensional (2D) tactile graphics can be produced by a variety of means and when correctly constructed can add a great deal to a student's understanding. Three-dimensional (3D) tactile models may be most useful for complex images that depict physical objects or when 3D notation is used to describe an object, for example molecular structures for chemistry.

Technique 1.3.1
Provide tactile graphics for images.

Tactile graphics can be created by using "puff paper" that is heated to create raised lines where ink is applied. Professional-quality tactile graphics, which are more durable and more detailed than puff paper, may be created by a number of different methods. gh LLC <http://www.ghbraille.com/>, a company that produces several types of accessible documents for blind people, creates tactile graphics using its LaserLine technology.

Graphics may also be printed using a braille embosser, such as the ViewPlus Tiger Advantage Tactile Graphics and Braille Embosser <http://www.viewplustech.com/>, which uses variable-height dots to create different textures on the paper.

Tactile graphics may be most effective when accompanied by text that introduces students to the conventions used and guides them in exploring the graphic. Less information can be conveyed in a tactile graphic than in a visual one because the sense of touch has lower resolution than vision does, so it may take more than one tactile graphic to capture the information completely in a complex visual diagram.

Because creating tactile graphics requires a thorough knowledge of the perceptual processes of blind students, it may be best to contact one of the professional resources listed in Appendix 1, Braille and Tactile Graphics Production Resources. Once created, the set of tactile graphics can be made available either through the publisher's distribution mechanism or through an arrangement with the tactile graphic production facility. Availability of tactile graphics should be clearly documented on the Web site, including contact information. Availability of graphics should also be listed with the American Printing House for the Blind, a central source of information on how educators can locate accessible materials, listed in Appendix 1.

Visit Duxbury Systems for a directory of tactile graphics producers and printers <http://www.duxburysystems.com/resources/sourgr.asp>.

Technique 1.3.2
Provide 3D models for complex images.

In some cases, even a good 2D tactile graphic is less useful than experiencing the shape of an object. Perspective projections of 3D images onto 2D representations are generally ineffective for blind users. Neither a text description of an image of a DNA strand nor a flat tactile graphic, for example, best conveys the full information about the shape and structure of DNA. A tactile model of the DNA strand used in conjunction with text will better meet blind students' needs. Possible resources for creating 3D models are listed in Appendix 1. Once created, the models can be made available either through the publisher's distribution mechanism or through an arrangement made with the model production facility.

Availability of 3D models should be clearly documented in product help and in any appropriate teacher support materials. Availability of models should also be listed with the American Printing House for the Blind, a central source of information on how educators can locate accessible materials, listed in Appendix 1.

Guideline 2
Provide access to multimedia presentations for users with sensory disabilities.

Audio descriptions provide access to multimedia for people who are blind or visually impaired by adding narration that describes the visuals, including action, scene changes, graphics and on-screen text. Captions added to multimedia presentations ensure that the audio components of the presentation are accessible to individuals who are deaf or hard-of-hearing. Both audio descriptions and captions are useful learning tools for a wide array of users in addition to their originally intended audiences. Captions can provide a powerful search capability, allowing users to search the caption text to locate a specific video, or an exact point in a video. They are also useful for people learning to read or learning English as a second language. Audio descriptions can assist students with learning disabilities by reinforcing through audio what the user is watching on the screen.

Captions and audio descriptions may be integrated into multimedia as a user-selectable option (closed) or permanently recorded along with the main audio or video (open). Closed captions and descriptions may be toggled on and off by the user via a preferences setting, a menu option or, in some cases, a button on the player interface. Open captions and descriptions may not be turned off-everyone sees or hears them, whether they want to or not.

Samples of accessible multimedia delivered in the formats mentioned below, including source code and tutorials, are available from NCAM's Rich Media Access Project <http://ncam.wgbh.org/richmedia/>.

Creating Accessible Multimedia

There are two formats that support the inclusion of audio descriptions and closed captions in digital multimedia presentations-Synchronized Multimedia Integration Language (SMIL) and Synchronized Accessible Media Interchange (SAMI). SMIL is played by the QuickTime Player <http://www.apple.com/quicktime/> (versions 4.1.2 and later); RealPlayer <http://www.real.com/> (versions G2 and later); and the Oratrix GRiNS Player <http://www.oratrix.com/>. SAMI is played by Windows Media Player <http://www.microsoft.com/windowsmedia/> only.

SMIL

SMIL was developed by the World Wide Web Consortium (W3C), an international industry consortium that publishes protocols for the Web. The first SMIL recommendation (SMIL 1.0) <http://www.w3.org/TR/REC-smil> was published in 1998. SMIL 2.0 <http://www.w3.org/TR/smil20> was published in 2001 and contains accessibility features not available in SMIL 1.0. These new features are discussed in relevant sections of this document. Take note that not all of SMIL's accessibility features are supported by all SMIL players, however. In these cases, we offer workaround solutions that will work with existing players.

SMIL multimedia presentations are made up of elements-sound, video, pictures and text-that are stored separately and then synchronized at the time of playback. SMIL-formatted multimedia can be delivered via the Internet or locally via a CD- or DVD-ROM. SMIL players include the RealPlayer (G2 or later versions) from RealNetworks, the GRiNS Player from Oratrix and the QuickTime Player from Apple (versions 4.1.2 and later). Visit the W3C's Synchronized Multimedia Web page <http://www.w3.org/AudioVideo/> for complete information about SMIL.

When authored correctly, SMIL allows users to turn captions and descriptions on and off via a player interface. The QuickTime Player, GRiNS Player and RealPlayer each provide a menu selection or dialog box for this feature, but for better accessibility authors should consider adding accessible buttons to the player interface for easier toggling of tracks. In fact, this is crucial when embedding a player into a Web page. Below is a picture of caption and description buttons integrated into the QuickTime Player interface.

D

Alternatively, user preferences relating to captions and descriptions may be stored in a profile on a Web site. On the PIVoT Web site, caption and audio description tracks are controlled in this manner; when a student signs on from any computer, multimedia is delivered in the manner specified in the student's profile. Here is a picture of a user's video preferences, showing caption and description choices.

D

SAMI

SAMI is a Microsoft public specification that allows closed captions to be played in the Windows Media Player. When the Windows Media Player is used as a stand-alone player, viewers can turn the captions on and off using a menu selection. However, when the player is embedded in another application, such as a Web page, the developer must provide the toggling feature through a button in the application's interface. For additional flexibility, this interface can also provide options to change the font size or text color.

At the time of this writing, SAMI does not support closed audio descriptions. Instead, descriptions must be recorded permanently as open descriptions directly into a video's regular soundtrack. If this approach is used, authors should also provide a separate version of the video with the original program audio (without audio descriptions).

FLASH

Flash is an animation technology from Macromedia, Inc. Multimedia presentations authored in Flash can contain large amounts of information yet still remain reasonable in data size, making them easy to download and play. Since Flash uses vector-based graphics, presentations can also be resized without loss of clarity-a boon to users with visual impairments.

A recent development in Flash technology is the ability to include native Flash captions within the presentation itself. A sample captioned Flash movie and complete instructions for current authoring methods can be found at NCAM's Rich Media Resource Web site <http://ncam.wgbh.org/richmedia/>.

A free utility, the Media Access Generator (MAGpie) <http://ncam.wgbh.org/webaccess/magpie/>, can be used to create captions and audio descriptions for SMIL presentations, and captions only for SAMI and Macromedia Flash presentations. MAGpie was created by the CPB/WGBH National Center for Accessible Media (NCAM).

Checkpoint 2.1
Add audio descriptions to multimedia presentations.

Multimedia is often used to convey educational content. Without audio descriptions, students who are blind are at a distinct disadvantage as they have to depend on teachers or classmates to obtain the visual information. Students may be reluctant to ask others to describe the visuals to them, and untrained classmates or even teachers may not provide descriptions that meet the student's specific educational requirements. The techniques explained below show how to add audio descriptions to three popular multimedia formats.

Creating meaningful audio descriptions requires specialized training in how best to convey visual images verbally. The narration should be carefully written to fit precisely into the natural pauses in the program dialog. In cases where a longer description is necessary but there is not a sufficient pause in the program audio to accommodate it, consider authoring extended audio descriptions. In this situation, the program dialog and video are paused while the audio description plays. When the description has finished playing, the video and dialog resume playback. Extended and "regular" descriptions may be mixed in a single multimedia presentation.

When creating described multimedia presentations, it may be best to contact one of the resources listed in Appendix 2, Closed Captioning and Audio Description Resources, since these organizations have expertise in providing audio descriptions for an array of media (broadcast television, movies on video and multimedia). Check with service providers to be sure they can deliver the final product in your preferred file format.

Where budgetary constraints exist, or where it is simply more practical and convenient, students, teachers or others knowledgeable in the specific subject matter may be trained to write audio descriptions. As with image descriptions, audio-description writers must have good writing skills and an excellent command of the vocabulary associated with the subject, as well as adequate access to reference and support materials, such as textbooks and dictionaries, in order to ensure that the descriptions are as clear and accurate as possible. Finally, the descriptions should be reviewed by someone other than the original writer. Training materials used in the Access to PIVoT project may be found in Appendix 5.

Technique 2.1.1
Add audio descriptions to movies using MAGpie.

Both regular and extended audio descriptions can be digitally recorded and integrated into a SMIL presentation using NCAM's free utility, MAGpie 2.01 <http://ncam.wgbh.org/webaccess/magpie/>. You may also use any sound-editing program, such as SoundForge <http://www.sonicfoundry.com/>, to record the audio files, and then use MAGpie to integrate them into an accessible presentation. No matter how it is done, ensure that the descriptions convey as much information as necessary without being overly long. Describe all important details thoroughly, such as scientific or mathematical expressions, graphs and charts, and use a vocabulary that is appropriate to the subject matter or grade level.

For the best results, record the descriptions in a quiet environment using a high-quality microphone. To minimize errors or ambiguity, speak clearly and use a written script. Finally, when integrating the descriptions into the multimedia, time them precisely to play at the appropriate intervals when they will be the most useful. For example, if the video shows a professor writing an equation on a blackboard, wait until he has finished writing the entire equation before inserting the description describing what has been written.

See the MAGpie Web site <http://ncam.wgbh.org/webaccess/magpie/> for complete information on using the software to create and synchronize audio descriptions.

Technique 2.1.2
Integrate audio descriptions into multimedia presentations using SMIL.

SMIL

SMIL provides information about layout, synchronization and display of different media types for the player to interpret. In addition, SMIL provides test attributes that are used to determine, among other things, the viewer's player preferences for displaying captions and descriptions. The RealPlayer (G2 or later versions) from RealNetworks, GRiNS Player from Oratrix and the QuickTime Player from Apple (versions 4.1.2 and later) all use SMIL to integrate audio descriptions into a multimedia presentation.

You can use MAGpie to author accessible SMIL presentations, as described in technique 2.1.1, but if you wish to write SMIL code yourself, details are provided here. The RealPlayer and GRiNS Player provide reliable support for SMIL 1.0; as of this writing support for SMIL 1.0 in the QuickTime Player is available but less reliable, so for QuickTime presentations it may be safest to embed audio-description tracks directly into the movie as described in technique 2.1.3. See below for an important note regarding SMIL 2.0 and audio descriptions.

SMIL 2.0 and audio descriptions

When creating a described presentation for a SMIL player, authors must write a SMIL file that contains pointers or references to the video file and all audio-description sound files. MAGpie will do this automatically for you. Here is some sample code showing instructions on how and when the player will play the video and audio descriptions.

In this example, the presentation has a duration (<dur>) of 0:01:46.27 (timecodes are represented as hours:minutes:seconds.frames, although other units may also be used). The SMIL file is instructing the player to play the video track (mymovie.rm) in parallel (<par>) with the two audio tracks (ad1.rm and ad2.rm). The first audio description will play at the timecode 0:00:14.30, and the second at 0:00:28.16. The test attribute systemAudioDesc is used to determine whether or not to actually play the audio descriptions, based on the multimedia player's preferences settings. If the user has set the player's preferences to play audio descriptions, those descriptions will be played at the intervals stated in the SMIL file. If not, they will be ignored.

Here are pictures of the RealPlayer and GRiNS accessibility preference settings, showing choices for both audio descriptions and captions.

D

D

Some video clips have insufficient pauses in the dialog or program narration, thus restricting the amount of time available for the insertion of useful audio descriptions. In these cases, SMIL 2.0's "exclusive" element (<excl>) may be used to sequence an "extended" audio description by informing the player that the main media (and other tracks, such as captions) should be paused until the interrupting element-the audio description-has finished playing. These extended audio descriptions will lengthen the overall duration of the presentation, but they provide an effective method for adding description when it is most needed.

The following example shows the code that specifies an extended audio description:

Here, mymovie.rm is paused at 85.5 seconds while the first description (ad1.rm) plays. When ad1.rm is finished playing, the video will resume playing. At 164.5 seconds into the original timeline, the video pauses again while the second description (ad2.rm) plays, then resumes when the description is finished.

SMIL 1.0 and extended audio descriptions

At the time these guidelines were written, support by the RealPlayer, GRiNS Player and the QuickTime Player for SMIL 2.0 extended audio descriptions was not complete. Instead, authors who wish to incorporate extended audio descriptions may do so using a SMIL 1.0 workaround for the RealPlayer or embedded tracks for the QuickTime Player (see later in this section). The SMIL 1.0 solution is illustrated in the code below:

In this sample, mymovie.rm pauses at 85.5 seconds, allowing the first extended description (ad1.rm) to play for its full length of 11.2 seconds (from 85.5 to 96.7 seconds). Once the description has finished playing, the video resumes playing at 85.5 seconds until 164.5 seconds, at which time it pauses while ad2.rm plays for its full length of 82.3 seconds. This process is repeated as many times as there are extended audio descriptions. Note that this workaround only works with the RealPlayer. It is not an ideal solution-among its drawbacks is a brief black flash between the time the audio description ends and the next video segment begins-but it can be used as a temporary solution until multimedia players fully support SMIL 2.0's extended audio description capabilities.

Technique 2.1.3
Embed audio-description tracks in QuickTime movies.

While audio descriptions may theoretically be incorporated into QuickTime presentations using SMIL, Apple's support for SMIL was incomplete at the time these guidelines were written. For complete reliability, authors should embed the description track into the movie itself.

In a QuickTime movie, sound, video and text are contained in separate tracks. Sound tracks to accommodate different languages or audio descriptions can be added easily. The following instructions show how to add audio descriptions that fit into the pauses in the movie's dialog or program narration. The method applies to QuickTime Player for both Macintosh and Windows, with slight variations in keyboard commands:

1. Open the QuickTime Player and the clip to be described. Choose Get Movie Properties from the Movie menu, or press Command-J on Macintosh, or Ctrl-J in Windows.
2. Using any sound-recording software, record and edit the first description to be incorporated into the movie clip. Open this audio clip in a new window in QuickTime Player, then select, or highlight, the entire sound clip (or the portion you want to insert into the movie clip) and choose Copy from the Edit menu.
3. In the QuickTime Player with the video, move the slider to the end of the pause where the description will go. Hold down the Shift key and move the slider backwards until you reach the beginning of this pause. This selects the segment of the movie clip that will receive the audio description.
4. If you're using a Macintosh, hold down the option key, open the Edit menu, and choose Add. If you're using a PC, hold down the Ctrl and Alt keys, open the Edit menu, and choose Add. This adds the description to the movie as a new sound track. In the Get Movie Properties window, click on the left drop-down menu. You will see that "Sound Track 2" is now one of the menu choices.
5. Play the clip to hear the narration you've just inserted.

Repeat steps 2-5 to insert subsequent audio descriptions. Always remember to select the segment that will contain the audio description by first going to the end of that segment and then moving the slider backwards to the beginning. If you do not do this, the QuickTime Player will add the description to the end of the segment, rather than the beginning.

QuickTime can also incorporate extended audio descriptions, using a similar method:

1. Open the QuickTime movie.
2. Find the first spot in the movie where the video will pause and the extended audio description will play.
3. Select Export... from the File menu.
4. At the bottom of the dialog box, change the Export: combo box to Movie to Picture, and the Use: combo box to Uncompressed. This will export the frame that is currently in view. Click on the Save button after noting (or changing) the filename.
5. Open a new QuickTime Player window and then open the file you just created in step 4.
6. Choose Select All from the Edit menu, and then choose Copy from the Edit menu.
7. Using the sound-recording software of your choice, record and edit the first description you want to incorporate into the movie clip.
8. Open a new QuickTime Player window, and open the audio-description you recorded in step 7.
9. Choose Select All from the Edit menu.
10. Hold down the Option and Shift keys on a Macintosh (or the Shift, Control and Alt keys in Windows) and select Add Scaled from the Edit menu.
11. Save the combined sound/image file
12. Choose Select All from the Edit menu and then choose Copy from the Edit menu.
13. Click once on the window with the movie into which the extended audio descriptions will go.
14. Assuming that the slider has not been moved since the image was exported, choose Paste from the Edit menu. If the slider has moved, locate the exact point in the movie where the movie matches the exported image before pasting.
15. Repeat steps 2-14 as needed.
16. Choose Save As... from the File menu. Save your work frequently, always saving the movie as a self-contained file.

Technique 2.1.4
Add audio descriptions to Windows Media.

Windows Media currently has no support for closed audio descriptions, but audio descriptions (regular or extended) can be integrated into a Windows Media presentation by recording them along with the regular program audio. Since these descriptions are open (that is, they can't be turned off), authors should also provide a separate version of the presentation with the original program audio (without audio descriptions).

Checkpoint 2.2
Add closed captions to multimedia presentations.

The inclusion of closed captions in educational multimedia presentations dictates whether the student who is deaf or hard-of-hearing is an active learner or a passive learner when the media is used on-line or in class. While a good percentage of the presentation may be visual, any audio that complements the visual information must be captioned.

Providing closed captions is significantly different from providing a text transcript of the audio portion of the presentation (although it is recommended always to provide a text transcript in addition to captions. Transcripts provide an easy way to scan a movie's script, to search for particular terms, and can also be converted to braille.) For example, captions use special techniques to identify speakers and sound effects. And since the caption text is synchronized with the video, it is easier for viewers to associate the captions with the whole presentation. Because writing captions can be a complex process, it may be best to contact one of the resources listed in Appendix 2, Captioning and Audio Description Resources, to have the work done for you.

Where budgetary constraints exist, or where it is simply more practical and convenient, students, teachers or others knowledgeable in the specific subject matter may also write captions. Anybody with excellent writing, spelling and listening skills can write captions but, if possible, use people who demonstrate sufficient expertise in the subject at hand. Captioners must have adequate access to reference and support materials, such as textbooks and dictionaries, in order to ensure that the captions are as accurate as possible. Finally, the captions should be reviewed for accuracy by someone other than the original writer. Training materials used in the Access to PIVoT project may be found in Appendix 4.

Technique 2.2.1
Write captions for multimedia presentations using MAGpie.

The easiest method for adding captions to multimedia presentations is to use NCAM's free captioning utility, MAGpie. MAGpie allows authors to write captions once and output them in formats for RealNetworks' RealPlayer, Oratrix's GRiNS Player, Apple's QuickTime and Microsoft's Windows Media Player. These players each use proprietary text-display formats, so captions that play in one player will not play in another (except for the GRiNS Player, which plays RealNetworks' RealText format). See the MAGpie Web page <http://ncam.wgbh.org/webaccess/magpie/> for complete information on using the software to create and synchronize captions.

As of this writing, there are serious shortcomings with the display of scientific and mathematical expressions in captions. No standard method exists for displaying complex math or science notation within multimedia players. (Existing mathematical markup languages, such as MathML, are not supported in multimedia players.) Therefore, representing anything beyond simple mathematical expressions in captions can only be accomplished via text.

Research and development efforts will eventually make the proper display of scientific and mathematical expressions in captions possible. The World Wide Web Consortium (W3C) is currently considering defining a standard timed-text format that could eventually be adopted by all multimedia player manufacturers. This new format will, it is hoped, provide support for the display of scientific and mathematical notation. Not only would this improve the capability of captions to convey important mathematical or scientific information; it would also eliminate the need for multimedia players to use proprietary text-display formats.

SVG and Flash captions

One interim solution to the problem of displaying math symbols in captions is to use Scalable Vector Graphics (SVG) in place of text captions. Using SVG, fonts can be embedded in the caption file and rendered in an SVG viewer which itself is incorporated into a multimedia player via a plug-in. SVG captions can be created by transforming a MAGpie 2.01 XML file to SVG-currently a process that requires the use of additional software and a good deal of manual coding. Automated authoring tools are not available at the time of this writing. Currently the only major multimedia player with SVG support is the RealPlayer for Windows, using the Adobe SVG Viewer plug-in.

Below is a example of a complex expression rendered in SVG.

D

Complete instructions for creating SVG captions, as well as a sample SVG-captioned movie, may be found at NCAM's Rich Media Resource Web site <http://ncam.wgbh.org/richmedia/>.

Macromedia Flash is an animation technology from Macromedia, Inc., that displays vector-based text and graphics. Presentations authored in Flash can contain large amounts of information yet still remain reasonable in data size, making them easy to download and play. Flash presentations can also be resized without loss of clarity-a boon to users with visual impairments.

A recent development from Macromedia is the ability to include native Flash captions playable within the Flash player itself. Multimedia authors can write captions using MAGpie, then use MAGpie's XML project file that works in conjunction with a Flash SWF file for caption display. However, as with SVG captions, this requires a good deal of manual coding and the use of third-party software. Automated support for this process is expected soon. In the meantime, a sample captioned Flash movie and complete instructions for current authoring methods can be found at NCAM's Rich Media Resource Web site <http://ncam.wgbh.org/richmedia/>. Note that as of this writing it is not feasible to use Flash captions to display mathematical symbols.

Technique 2.2.2
Integrate captions into multimedia presentations using SMIL.

RealPlayer, the QuickTime Player and Oratrix's GRiNS Player use the W3C's Synchronized Multimedia Integration Language (SMIL) to sequence captions in a multimedia presentation. SMIL provides information about layout, timing and display of different media types (such as video and text) for the player to interpret. In addition, SMIL provides test attributes that are used to determine, among other things, the viewer's preferences for display of captions and descriptions.

When creating a captioned presentation for a SMIL player, authors must write a SMIL file that contains pointers or references to the video file and the text file containing the captions. MAGpie will do this automatically for you (see technique 2.2.1). If you need to author a captioned SMIL presentation in some other way, create a file using the code samples below as a guide. The first example shows the <layout> section of a SMIL file.

In t