Accessible Digital Media
Design Guidelines for Electronic Publications, Multimedia and the Web

WGBH | NCAM | BEYOND THE TEXT PROJECT

COMBINED VERSION TO PRINT

URL: http://ncam.wgbh.org/publications/adm

Geoff Freed and Madeleine Rothberg
The Beyond the Text Project
April, 2006
The WGBH National Center for Accessible Media
© 2006 WGBH Educational Foundation

The Media Access Group at WGBH
125 Western Avenue
Boston, MA 02134
(617) 300-3400 voice
(617) 300-2489 TTY

Please send comments and corrections to access@wgbh.org

The Beyond the Text Project was funded by the National Institute on Disability and Rehabilitation Research (NIDRR), U.S. Department of Education, under grant number H133G020091. However, the conclusions or recommendations expressed in this material do not necessarily represent the policy of the U.S. Department of Education, and you should not assume endorsement by the federal government. 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 #HRD-9623958. Version 2, Making Educational Software and Web Sites Accessible: Design Guidelines Including Math and Science Solutions, was published in 2003 with funding provided by the National Science Foundation, award #HRD-9906159, through the Program for Persons with Disabilities. Additional funding was 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.

Introduction

Properly designed e-books, software, Web sites and learning management systems can and must be accessible to all users with disabilities. Technology is prevalent everywhere, and learners of all ages and in all fields require equal access to content to keep pace with their colleagues and classmates. Whether they are high school students, IT professionals or research chemists, inaccessible materials prevent people with disabilities from using the same materials at the same time as their peers, and can limit their educational and career opportunities.

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 electronic materials for everyone. Producing accessible materials will increase their reach by broadening the market to include people who have been previously excluded. Developers who incorporate access solutions may also find that these modifications bring benefits to the general population, not just users with disabilities, as studies of multimodal learning have shown.

Moreover, publishers, educational-software programmers and Web-site developers are increasingly aware that they must consciously include people with disabilities in their audiences. Policies are now in place or are under consideration in many markets that make accessibility a requirement for distributing electronic materials. If the materials necessary for the job or the classroom are delivered electronically, publishers would be wise to design them so people with disabilities can utilize them. And more and more learning content is delivered electronically as early every higher education institution, some K-12 schools and many corporations have adopted learning management system (LMS) software, which organizes and delivers digital materials for on-line courses. However, few developers understand why access is critical or how to provide it in their products.

This document presents solutions to accessibility obstacles in a format designed to educate and assist digital publishers as well as Web and content developers. We hope that the information contained here will accelerate the creation of e-books, digital talking books (DTBs), software and Web sites with accessible images, multimedia, interactivity, data tables, graphs, and mathematical and scientific expressions.

These guidelines focus largely on content creation for educational materials, but the solutions and recommendations given here should not be interpreted as restricted to academic settings. Lifelong learning is expected of every individual in the 21st century and advancement in the workplace is often tied to learning new lessons and concepts. Corporate trainers and knowledge management experts in all fields are utilizing interactive and Web-based content for professional development, and learning materials of all types now include multimedia (movies and audio clips). The suggestions offered here for making on-line textbooks accessible apply with equal importance to on-line user guides for everything from software to power tools. The solutions provided to make digital classroom content accessible apply equally well to digital training materials offered via corporate intranet.

The guidelines are the culmination of the Beyond the Text project, conducted by the WGBH National Center for Accessible Media (NCAM) and funded by the National Institute on Disability and Rehabilitation Research (NIDRR) of the U.S. Department of Education (2003-2006; award #H133G020091). This document is a greatly expanded version of recommendations first published in 2000 and revised in 2003, under projects funded by the National Science Foundation (Awards #HRD-PPD-9906159 and #HRD-PPD-9623958, respectively).

The Beyond the Text project researched and developed methods for improving e-book multimedia navigation, and creating and integrating captions and descriptions for the video and audio presentations. NCAM staff analyzed e-book hardware and software devices, and created accessible e-books samples in several different formats that include embedded and linked multimedia clips, as well as DTBs containing in-line, linked and embedded multimedia. Staff also participated in technical-standards working groups, contributing expertise to work underway within the International Digital Publishing Forum (IDPF), the DAISY Consortium, the W3C Timed Text Working Group, and others. Visit the Beyond the Text Web site to download the e-book and DTB samples, and review a chart evaluating and comparing the accessibility of various e-book and DTB software and hardware devices.

We also encourage you to review the results of a separate NCAM initiative to promote the design of accessible learning management systems, used by many schools, universities and workplaces, as the framework for finding and displaying educational content. Through NCAM's Specifications for Accessible Learning Technologies (SALT) Partnership, an accessibility working group within the IMS Global Learning Consortium (IMS) was established to produce specifications for a universally designed infrastructure for adaptable learning systems. This work will result in an international standard from the International Organization on Standardization (ISO).

Please contact us if you have comments about these guidelines or suggestions for future revisions. We also encourage you to visit NCAM's Web site and explore other ongoing access initiatives.

Educational Issues for Students With Disabilities

Inclusive Classrooms

Revisions to the Individuals with Disabilities Education Act (IDEA) in 1997 changed the focus of special education from providing separate services for students with disabilities to including more students in mainstream classrooms. Schools are required to place students in inclusive classrooms, when appropriate, in order to provide the social and academic benefits of taking part in the general curriculum.

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 materials which require manual dexterity.

Educational Software

Educational software has become an important tool in classrooms. Instructional materials are available as stand-alone software or on the Web, and teachers are increasingly integrating technology into their curricula.

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. If lesson instructions are given only in audio, a student with a hearing impairment may not receive enough information to complete an assignment. A child who uses an assistive-technology device to operate a keyboard can be stalled by operations that require using a mouse. 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.

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 as other students, accessible 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 accessible simulation software 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 completely accessible. The educational goals of a program are sometimes incompatible with providing non-visual access for students who are blind or non-auditory access for students who are deaf. In addition, 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.

Digital Publications

Accessible electronic publications, such as textbooks, journals or training materials, can bridge the gap that often exists for students or workers who require adapted materials. Until now, the time-consuming process of turning books or other materials into braille, audiotape or large-print editions meant that students with disabilities often started the school year without their textbooks. (Information on the National Instructional Materials Standard (NIMAS), designed to address this problem, is provided in the policy and standards discussion and in Guideline D.)

E-books offer many advantages for all everyone, such as the ability to quickly locate specific chapters or sections and to place bookmarks for future reference. E-books can offer quick access to glossary definitions or indexed terms, adjustable fonts for easier reading, recorded or synthetic speech to aid in comprehension, and built-in practice questions, multimedia and interactive activities. In addition to providing these important features, a digital publication ensures that every student, new employee or worker undergoing training is using the same material, and everyone gets it on the first day of school or work.

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. 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 non-disabled 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 careers, 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.

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

Furthermore, it may be equally appropriate to modify the activity slightly. If the goal of the lesson is to understand the similarities and differences between certain birds, 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) provides more information on access adaptations and the educational goals of instructional materials.

Benefits of Multimodal Learning

Making software and digital publications 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).

Educational Policies and Standards

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 are rapidly becoming the example that many follow. Further, many publishers and developers of digital content for the classroom are finding schools increasingly interested in purchasing accessible materials. The No Child Left Behind (NCLB) Act was signed into law through the reauthorization of the Elementary and Secondary Education Act (ESEA) in 2001. NCLB requires K-12 schools to report the results of annual assessments of students' progress, disaggregated so that schools are accountable for adequate yearly progress of all student groups, including students with disabilities. Consequently, schools systems as well as individual teachers are under great pressure to advance the academic gains of students with disabilities and are therefore interested in purchasing materials that meet the needs of all their students. Information in these guidelines will help software developers meet the expectations of these policies.

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: institutions must be responsive to the needs of individual students and make programs and services accessible to them on request. Note that 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.

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. Settlements made between educational systems and the OCR in response to complaints of disability discrimination have sometimes required the educational institutions to make system-wide, proactive changes in their procurement and use of instructional materials to ensure that textbooks and educational technology are accessible to students with disabilities. One such settlement was made with the California Community College systems (Docket #11-01-1132); statewide requirements in North Carolina for textbook accessibility are another example (Docket #09-97-6001).

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:

Federal IT Accessibility Initiative
The Access Board

The National Instructional Materials Accessibility Standard (NIMAS)

The National Instructional Materials Accessibility Standard (NIMAS) is a structured digital format for K-12 printed instructional materials intended for use in creating accessible books for students with print disabilities. "NIMAS refers to a collection of consistent and valid XML-based source files created by K-12 curriculum publishers. From these well-structured source files accessible, student-ready alternate-format versions of core textbooks (i.e.; braille, digital talking book, etc.) can subsequently be created," as explained further on the Web site for NIMAS at CAST.

CAST operates two centers in support of the NIMAS effort:

1. The NIMAS Development Center will improve the original standard by identifying new research and technological advances relevant to the standard. The center will also explore existing and new distribution models for the provision of accessible materials to students with disabilities.
2. The NIMAS Technical Assistance Center will work with key stakeholders such as states, school boards, and publishers to raise awareness of the benefits of accessible materials. It will also advise stakeholders on the efficient production and distribution of NIMAS-compliant materials.

The National Instructional Materials Accessibility Center (NIMAC)

To expedite use of the NIMAS files created by publishers, a National Instructional Materials Access Center (NIMAC) has been established in Louisville, Kentucky, at the American Printing House for the Blind (APH). The NIMAC is responsible for receiving and cataloging publishers' electronic files of print instructional materials in the NIMAS format. The center will provide these standardized files to authorized textbook providers, who will then produce textbooks for blind and visually impaired students across the country. The combination of a standard format and a central repository should significantly expedite the time frame in which textbooks are delivered to students who need them in the classroom.

U.S. State Policies

Numerous states have requirements for publishers to provide electronic files of printed textbooks purchased in the state. The Information Technology Technical Assistance and Training Center offers an Overview of State Accessibility Laws, Policies, Standards and Other Resources.

CAST offers the U.S. States and Territories Accessible Curriculum Survey, a summary of state and territory laws pertaining to the provision of accessible materials for K-12 students with print disabilities.

While those surveys cover accessibility of state government resources and of K-12 textbooks, less information is available about requirements for accessible multimedia and interactive software. However, two states that have instituted accessibility policies for a wider range of instructional materials are described below.

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 all 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. The two sets of guidelines from CCC, and other resources, are available from the High Tech Center Training Unit.

In March 2004, the CCC distance learning accessibility requirements were incorporated into the general distance-education guidelines. This document was under revision at the time of this writing.

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 requirement has also applied to teacher-developed instructional materials since 2005. The regulations have been incorporated into the Code of Maryland Regulations (COMAR) 13A.05.02.13 H, Accessibility of Technology-Based Instructional Products.

Information on the Maryland State Department of Education's efforts to implement accessible technology for schools is available from the Instructional Technology and School Library Media Services Program and from the Department's page on accessibility standards.

Access For All: the Accessibility Metadata Standard

Fulfilling the promise of digital learning materials to enhance education at all levels requires helping educational software and publishing industries meet the needs of users with disabilities. This is not a one-time effort to fix a particular piece of software, but rather a shift in attitude to embrace universal design while being realistic about what can be achieved.

Making every piece of educational content fully accessible may not be entirely possible. The volume of material is great and while some types of media can be fixed easily, others require expert modification to ensure they provide an equivalent educational experience, particularly for learners with visual impairments. In addition, many resources that were created in the past are still in use but not easy to update. Improving the accessibility of as many resources as possible is, of course, an important goal, and teaching Web designers and curriculum developers the principles of universal design is crucial to making the next generation of materials accessible from the start.

Metadata for Accessibility

For any large collection of resources the greatest challenge is ensuring that users can find the materials they need among the many available, and this applies equally to accessibility. A solution for this problem comes from metadata.

The IMS Global Learning Consortium's Access For All Metadata Specification (AccMD) enables publishers and educators to record and share information about the accessibility of their resources and services. The metadata specification is designed to work in combination with a record of the user's needs and preferences as expressed in the IMS Accessibility for Learner Information Profile Specification (AccLIP). Together these are known as the Access For All specifications. Access For All is now in the process of becoming an international standard through the International Organization on Standardization. More information on the ISO standard is available from NCAM.

The Access For All specifications are intended to address mismatches between resources and user needs caused by any number of circumstances, including requirements related to client devices, environments, language proficiency or disabilities. They support the matching of users and resources despite shortcomings in resources. These profiles allow for finer-than-usual detail with respect to embedded objects and for the replacement of objects where the originals are not suitable on a case-by-case basis. The Access For All specifications are not judgmental but are informative; their purpose is not to point out flaws in content objects but to facilitate the discovery and use of the most appropriate content for each user.

Primary and Equivalent Resources

The Access For All metadata specification groups resources into two possible categories: primary resources and equivalent alternative resources. The primary resource is the initial or default resource. Most existing resources would be considered primary resources. An equivalent resource provides equivalent semantic and behavioral functionality and addresses the same learning objective as the referenced primary resource but in an alternative form.

Since the authors of most primary resources (and the authors of their metadata) are not likely to be informed about accessibility considerations and may not be motivated to create additional metadata, the metadata on the primary resources is kept to a minimum. Metadata regarding a primary resource simply describes what access modes are needed to use the resource (e.g., visual, auditory, text, etc.), whether the display and method of control is flexible, and whether there is a known equivalent resource.

The metadata describing whether a resource has flexible methods of display and control can be generated using existing accessibility evaluation tools that produce EARL (Evaluation and Report Language) files. Further work is underway in the IMS Accessibility Working Group to define EARL statements suitable for this use. In addition, the ISO version of Access For All includes metadata elements for declaring the most common needs directly. The IMS specifications will be updated to version 2.0 to match this advancement. This includes stating whether a resource can be used entirely from the keyboard, and whether the font face and font color are adjustable.

Unlike authors of primary resources, it is anticipated that authors of equivalent resources are likely to be both motivated and informed about accessibility considerations. The description of the equivalent resource is therefore much more detailed and closely matches the AccLIP specification. This permits resource portals to search for equivalent content that overcomes a mismatch between the user's required sensory modalities and the modalities included in a primary resource.

More information on the IMS Access For All specifications is available from the IMS Accessibility Support page. For a more detailed description of the use of the specifications read the IMS Access For All Meta-data Overview.

Using Accessibility Metadata

Integrating the accessibility specifications into infrastructure will require a number of coordinated efforts. Tools are being developed for authoring user profiles and resource metadata, or authors may be able to integrate the new data into existing personal preferences and resource metadata tools. Publishers and educators need to offer users the ability to record a set of accessibility preferences that can influence both the browsing interface and the way resources are located for the user. Finally, publishers need to add accessibility metadata to the metadata record for each resource, to the extent possible. The greater the amount of metadata available, the more powerful the system becomes.

Tools for authoring and using AccLIP and AccMD are emerging both inside and outside IMS. Publishers interested in a well-developed example (or even an open-source turnkey system) for an accessible digital library site should consider the Collection Workflow Integration System (CWIS) from the Internet Scout Project. CWIS offers a preferences editor for AccLIP data and transforms the library interface to match each user's preferences. CWIS can also edit and store AccMD data about resources and use them to highlight resources according to a user's AccLIP preferences.

Information about additional tools for using the Access For All Specifications is available from IMS Accessibility Support.

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 Trace Center Accessible Software Guidelines offer 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, written in 1994. The updated version is quoted from the IMS Guidelines for Developing Accessible Learning Applications

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.
• 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.
• 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 computers 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.

A general resource describing assistive technology is the Technical Glossary of Adaptive Technologies 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 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 technologies and Web developers.

Windows OS

Microsoft provides detailed information on building accessible software for the Windows platform. The Microsoft Accessible Technology 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.

For Windows operating systems up to Windows XP, the Microsoft Active Accessibility API (MSAA) provides 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.

Windows Vista introduces a new API for accessibility, Microsoft User Interface Automation. It is intended to "address the needs of assistive technology products and automated testing frameworks by providing programmatic access to the graphical user interface."

Resources

Microsoft Accessibility Home Page

Accessibility Information for Developers

Macintosh OS X

All Macintosh computers (OS 10.4 and higher) ship with many accessibility features already installed that support users with sensory or physical disabilities. Developers should test their products with these features to determine whether their software is operable by users requiring assistive technology. Some of the pre-installed accessibility enhancements include the following:

• VoiceOver screen reader
• Speakable items and talking alerts, an interface for controlling the Mac using voice commands
• Zoom, a built-in screen magnifier for low-vision users
• Sticky Keys and Slow Keys, 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. Visit Apple's Accessibility home for more information. Also visit Apple's Assistive Technologies page for a list of Apple products that provide support for users with disabilities. Finally, see the Macintosh Accessibility Documentation for Developers for complete technical information about Apple's accessibility support.

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:

Sun Microsystems Accessibility Program

Guidelines for Writing Accessible Applications Using 100% Pure Java

Coding for Accessibility

The Java Access Bridge

Sun Microsystems' Accessibility Program/Developer Information

Macromedia Products

Macromedia, Inc., now part of Adobe Systems, Inc., produces popular software for creating, building, viewing and managing Web sites and stand-alone applications. The accessibility of Macromedia products has steadily improved with time, and the company continues to work to integrate accessibility features and enhancements throughout their product line. Read more about Macromedia's accessibility initiatives.

Macromedia has released information about their products' accessibility in the form of Voluntary Product Accessibility Templates (VPATs). A VPAT is a standardized form that lists each point of the Section 508 guidelines and permits a company to state how a product complies (or does not comply) with specific guidelines. The information a company enters into the form is voluntary and unregulated, so a VPAT should be treated as a research tool to help determine a product's accessibility, not as a definitive statement about accessibility. Some companies update their VPATs as product revisions are released to the public.

Flash

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

While many of Macromedia's products are accessible to one degree or another to the user, they also help authors create accessible materials, such as Web sites or animation. One of Macromedia's most popular applications, Flash 8, contains numerous features to create accessible Flash elements, such as embedded animations and images. Using the Accessibility panel, for example, 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 (similar to HTML's longdesc attribute) if necessary. MSAA then passes this information to assistive technologies, such as a screen reader.

There are a number of resources for more information about Flash accessibility:

• Macromedia's Accessibility Resource Center
• Best Practices for Accessible Flash Design (PDF document)
• Macromedia's Accessibility Blog
• MacGregor, Chris, et al. The Flash Usability Guide. Birmingham: friends of ED, 2002.
• Thatcher, Jim, et al. Constructing Accessible Web Sites. Birmingham: glasshaus, 2002.
• NCAM's Rich Media Resource Center Flash Tutorials
• WebAIM's Creating Accessible Macromedia Flash Content (tutorial)

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 Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability. The Web Accessibility Initiative (WAI) at the W3C coordinates with organizations and industry representatives to ensure that the Web is accessible to people with disabilities. See the WAI Home Page for more information.

Content written in HTML and other Web technologies should follow the Web Content Accessibility Guidelines 1.0 (WCAG 1.0). Production of version WCAG 2.0 is under way at the time of this writing. Software that allows users to author their own Web content should follow the Authoring Tools Accessibility Guidelines (ATAG) 1.0.

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

• WAI XML Accessibility Guidelines
• Accessibility Features of SMIL
• Accessibility Features of CSS
• Accessibility Features of SVG

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

The Guidelines

The guidelines in this section lay out specific ways to make materials such as digital publications, distance-learning Web sites and educational software more accessible to students with disabilities. The guidelines have been organized to describe basic, broadly used techniques which can be applied to most materials, followed by techniques specific to multimedia and electronic textbooks. Each 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.

Please note that this document does not contain a comprehensive list of guidelines for creating accessible Web sites and software in general. That information is available from several sources, including the following:

• The Web Content Accessibility Guidelines 1.0 (WCAG 1.0)
  (As of publication time, version 2.0 of the Web Content Accessibility Guidelines was being prepared but was not yet ready for release.)
• The Trace R&D Center's Software Accessibility Guidelines
• IBM Accessibility Guidelines (including Web and software)

Guideline A
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, data tables or charts people who are blind or visually impaired will miss some or all of the information.

Static images may be made accessible via the alt attribute and, where necessary, supplemented by the longdesc attribute, which provides a longer description than is possible or practical in alt. longdesc can be retrieved by screen readers or other access technologies and is sometimes, but not always, made visible by browsers. Authors may also include a text description placed adjacently to the image on the page.

Image maps are commonly used for navigation within a Web site. Client-side image maps may be made accessible through the use of alt in the area element. 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 links.

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

A completely different approach to some types of images (e.g., graphs) is to use Scalable Vector Graphics (SVG), 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 graphics for users with low vision, and metadata included in SVG may 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) activity at the W3C

Scalable Vector Graphics 1.1 Specification

Accessibility Features in SVG

Checkpoint A1
Provide text equivalents for all images.

The alt attribute is required when the img and area elements are used. A sufficient text equivalent can range from alt containing a single word or brief sentence to several sentences (e.g., via longdesc) in order to adequately convey information in a complex image. When images are used for navigation, such as on a navigation bar or image map, alt 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 null alt, as demonstrated below. (A null description informs assistive technologies that the graphic does not need description. If no description [e.g., no alt] at all is included, assistive technologies may announce an unlabeled graphic, leading the user to wonder what is missing.)

Technique A1.1
Provide meaningful alt for all images.

HTML provides specific techniques for adding text equivalents to images. When using the elements img or area, authors must include the alt attribute. For example:

For client-side image maps, always include alt 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, or special creation and rendering devices, such as MathType and MathPlayer, rather than images. However, if you must use images to display scientific or mathematical expressions, always use alt 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, do so:

Technique A1.2
Use the longdesc attribute to provide an in-depth HTML description, where necessary.

If an image represents something that cannot be briefly summarized in alt, provide complete description of the image using longdesc, which specifies a URL to a discrete text file that contains a full description of the image. For example:

Assistive technology that recognizes longdesc will automatically or, in some cases, manually, provide users with access to this additional information. Here is the description contained in figure_2-003desc.html:

Note that the screen reader JAWS currently will not recognize a longdesc that has been applied to a linked image.

Technique A1.3
Write image descriptions.

Ideally, anyone writing image descriptions should have detailed knowledge of the subject matter. Writers should 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.

When describing scientific or mathematical expressions, consider using 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. One such method is MathSpeak, 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.

Here is an example of an expression described in MathSpeak, taken from the on-line 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.

A project at the WGBH National Center for Accessible Media (NCAM) is studying the development of a standardized approach to describing mathematical or scientific tables, illustrations and other visual material. See the Effective Practices for Describing Science Content project for more information. Also, gh LLC, a company based in West Lafayette, IN, is currently investigating a standard approach for using MathSpeak to properly render mathematical equations and scientific representations. For more information, see gh's MathSpeak Initiative.

Checkpoint A2
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, or combine embossed images with color ink (such as the ViewPlus Emprint printer). 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 A2.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 A2.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 braille printers from ViewPlus convert 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 A2.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 A3
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 A3.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 creates tactile graphics using its LaserLine technology. Graphics may also be printed using a braille embosser, such as those made by ViewPlus, which use 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.

Technique A3.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 B
Provide access to forms for users who are blind or visually impaired.

Forms are extremely useful for gathering all kinds of information. Web sites often present users with a log-in page that requires a name and password be entered into text fields. Radio buttons or check boxes are regularly used to determine user preferences, and users can answer test questions by typing answers into text fields. Forms can present problems for blind users when the elements aren't marked up in a manner that makes them accessible to screen-reading software. A screen reader might announce the presence of a text field, for example, but if it isn't labeled correctly, the user won't know what information to enter into the field.

To insure reliable access to information, use properly marked-up HTML forms instead of those created in proprietary formats, such as PDF or Flash. While some screen readers can access information in properly marked-up PDF or Flash, support is not necessarily 100% reliable. Providing a form in non-HTML formats may mean that screen-reader users or anyone who relies on keyboard-only navigation will be unable to use the form.

Checkpoint B1
Label all form elements and controls so they can be recognized by assistive technology, such as a screen reader.

Technique B1.1
Explicitly label all text fields, text areas, drop-down menus, checkboxes and radio buttons.

Each edit field or text area should have an explicit label associated with it that makes it clear what information to type into the box. A simple method is to use the label element. Below is a screen shot of a form containing text fields.

As a screen-reader user navigates this form, either by reading the entire page or by tabbing from field to field, the software will speak each label aloud. This is usually enough information for the user to know exactly what to type into the edit field itself. JAWS (a PC-based screen reader), for example, announces "First Name edit, Last Name edit," etc. The author has taken a simple approach and associated the visible label with the edit field, as shown in the markup below.

Text areas, where users can enter longer strings of text, can be marked up in a similar fashion:

In some cases it may be desirable to give the user more information than is available in the visible label. One approach is to use the title attribute to supply additional information:

You can also use in-line styles to provide a hidden label for the screen reader to announce. There are two ways to do this. The first uses the CSS property display:none; the example below illustrates how class="hidelabel" is used to define a hidden element:

In the body of the document, enter the text you want the screen reader to announce and place it within a <span> that refers to the style defined in the <head>:

The same thing can be accomplished with the property visibility:hidden; — define the style in <head> and then refer to the style at the appropriate place in the body. In both cases the screen reader will announce text which is invisible to sighted users. However, using visibility:hidden; will cause an in-line gap to appear on the page where the text would normally appear. Additionally, older browsers (such as Netscape 4.x) do not always support the visibility property properly.

Drop-down menus (also known as select menus or combo boxes) can also be marked up with label and id:

In this case, a screen reader will read the label ("Please tell us when you expect to graduate"), then the default text of the drop-down menu ("Expected year of graduation"), and will finally describe the form element itself: "Combo box, one of five. To change the selection, use the arrow keys." The user may then open the menu and use the arrow keys to make a selection.

To prevent the user's screen from changing unexpectedly, drop-down menus should never automatically redirect the browser to a new Web page (by using the onchange event handler, for example). Blind users or anyone who uses the keyboard instead of a mouse must be able to read through the entire list of choices before the action is executed. Instead, it's best to allow the user to make a selection and then press a button to invoke the action. For example:

Here, the user can make a selection from the list and then press the Go button in order to jump to that page. Automatically redirecting the user would cause the browser to act on the first item selected from the list and, in this case, a keyboard-only user would always be directed to the Administration department.

Other form controls, such as radio buttons, checkboxes and buttons, also need labels so users can identify and manipulate them. In the form below, three radio buttons are available. Each is associated not only with its adjacent label but also with its group identifier ("Please select a user type"), as shown below.

In order to ensure the group identifier is properly associated with the appropriate information, always place it before that information. Also note that the radio buttons themselves have been positioned before their labels. This approach ensures that all screen readers associate the proper labels with their respective form controls.

In situations where a single label must identify multiple form elements, use the title attribute to identify the elements. An example of using title on text fields is shown below, but this attribute can also be applied to radio buttons and check boxes if necessary.

Technique B1.2
Label all buttons.

Buttons, such as those that submit user information or invoke an action, must also be labeled. If text buttons are used, set the value to describe the button's function. If the button is a graphic, use alt that states what the button does — for example, "Search," "Go!," "Submit," etc. Either type of button can be easily made accessible. Below are two simple examples illustrating the use of text buttons.

Here is a code sample from a form that uses a graphic button and descriptive alt.

More information about creating accessible forms can be found in the Web Content Accessibility Guidelines.

Guideline C
Provide access to data in tables for blind users.

Reading and manipulating data tables is an important way of processing information and is a particular problem for blind users. Reading data in a table requires referring to the headings for each row and column in order to interpret the information in a single cell. When navigating tables, blind users often don't even know what cell they are in at any time, or the column and row headers. However, HTML can be used to provide programmatic information about reading location and which headers apply to each cell.

Checkpoint C1
Design all HTML data tables in accordance with the Web Content Accessibility Guidelines published by the World Wide Web Consortium's Web Accessibility Initiative (W3C/WAI).

Producing data tables in conformance with the Web Content Accessibility Guidelines exposes crucial information about the structure of a table.

Technique C1.1
Use HTML to mark up tables.

Here is an example of a simple HTML table.

Table 2.3: Variation of g with Latitude

Station	Latitude	g
Quito, Ecuador	zero degrees N	nine point seven eight zero m slash s sup two base
Madras, India	one three degrees N	nine point seven eight three m slash s sup two base
Hong Kong	two two degrees N	nine point seven eight eight m slash s sup two base
Cairo, Egypt	three zero degrees N	nine point seven nine three m slash s sup two base

Below is an excerpt of the HTML for this table. Note the use of the th element, used to identify each table header, and <scope>, used to differentiate table headers in each row and column. Also note that <summary> is used to provide a brief description of the table itself.

Someone using a screen reader will first hear the <summary> read aloud ("Table 2.3: Variation of g with Latitude"), then the headers ("Station, Latitude, g"), then the information in the data cells. The user can press specific key combinations to navigate each table cell, receiving feedback about position relative to each row and column header.

The information provided in this data table has been presented in MathSpeak, a method of unambiguously speaking mathematical and scientific data. More information about how best to read mathematical and scientific information are available in Appendix 4, Guides to Spoken Mathematics.) Note that two projects are currently underway to study the best way to present scientific and mathematical data. gh LLC is developing a method for rendering MathSpeak using specialized markup and tools. See the MathSpeak Initiative for full details. And a project at the WGBH National Center for Accessible Media (NCAM) is studying the development of a standardized approach to describing mathematical or scientific tables, illustrations and other visual material. See the Effective Practices for Describing Science Content project for complete information.

Technique C1.2
Provide alternative access to static tables.

For tabular data that the user cannot change, pre-produced audio can provide useful access to tables. The entire data table can be read aloud, or the equivalent script can be provided in text. Techniques for how best to read tables of data are available from the National Braille Association Tape Recording Manual, or from MathSpeak. (See Appendix 4.)

Tables can also be created in braille, though there are formatting challenges, especially for long lines of text. Professional brailling firms can advise the best way to braille tables. (See Appendix 1.) Once created, the set of brailled tables can be made available through the publisher's distribution mechanism, through an arrangement made with the braille production facility or via the course itself. Availability of braille tables should be clearly documented on the Web site, including contact information. Availability of braille tables 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 D
Provide access to digital publications.

Accessible electronic books (e-books), digital talking books (DTBs) and on-line, HTML-based textbooks and training materials can bridge the gap that often exists for students or workers who require adapted reading materials, such as braille or audio recordings. Electronic versions of learning materials, if properly designed, can make curricular content equally accessible to all learners, at the same time.

While there are established digital talking book services, braille-production and tactile-graphic 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. At the K-12 level, teachers must identify all the texts that will be used in class well ahead of time and request adapted versions. At the post-secondary level, students must anticipate their own needs for adapted texts in each course they plan to take and request adapted versions. Often, these are custom requests, which must be created from scratch since teachers at all levels and in all fields keep current with new materials. The result is that students who require adapted textbooks, such as braille or audio recordings, often do not receive them before class begins.

Moreover, electronic files are 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 braille textbooks, especially those in the fields of math and science, for blind students.

Blind or low-vision students can use audiotaped books or books on CD for some content but this format is linear, does not allow easy navigation or bookmarking, is expensive, and is only available for popular trade books. Many learners who rely on audio versions of textbooks or professional publications utilize digital talking books (DTBs).

Strictly speaking, a DTB is a multimedia representation of a print publication that provides access to the text through digitally recorded human voice or synthetic text-to-speech technology. DTBs are largely aimed at blind or visually impaired users, but are also used to help improve reading and comprehension skills in students with learning disabilities. They provide various levels of navigation, from partial to complete, and can be read on dedicated hardware devices or on software players that run on Windows or Macintosh computers.

As more and more publishers issue electronic textbooks, it is anticipated that integrated multimedia will become more common in these materials. Biology texts would be able to illustrate cell division through the use of a short movie in addition to words and static images, for example. Audio-only clips could also be used to embed early recordings of famous speeches into a student's political science text. These types of media can all be made accessible through the use of captions and audio descriptions, and all can be integrated into e-books, DTBs and HTML texts.

A fully accessible electronic textbook can ensure that every student in class is using the same book, and that everyone receives it on the first day of school. The suggestions specific to math and science in these guidelines can reduce the barriers to studying these subjects that students with disabilities currently face and contribute to greater representation of people with disabilities in science and math-focused professions.

Checkpoint D1
Provide accessible on-line HTML books.

HTML-based on-line textbooks are similar to Web sites in that they can be made accessible by using proper markup. The following structural elements are commonly encountered in on-line textbooks and may be made accessible using techniques found throughout these guidelines as well as the Web Content Accessibility Guidelines.

• images
• image maps
• charts and graphs
• tables
• forms
• multimedia
• scientific or mathematical expressions

Navigation features required for accessibility in an on-line textbook include:

• links for moving forward or backward by chapter, placed at the beginning and end of each page or section.
• links which move the user to the top of the page or beginning of a chapter.
• links that lead directly to the table of contents and/or index.
• headers to divide chapters or sections of information.
• search capability.

Checkpoint D2
Provide accessible electronic books (e-books).

There are three factors that must be addressed for e-books to fulfill their potential to provide equal access to all readers — the content format, the use of accessibility techniques within that format, and the device used to render the material (text, images, multimedia, etc.) itself.

While there are several popular e-book formats available, not all are entirely accessible to blind or visually impaired users. E-books which are created using basic accessibility techniques tend to give the user the greatest chance of having an accessible reading experience. Such techniques include the use of alt on all images, properly worded links and the use of headers to divide chapters or categories of information.

Two software e-book readers, Adobe Reader and Microsoft Reader, have made efforts to offer accessible reading experiences through the use of built-in text-to-speech engines that offer the user varying degrees of control over the document's presentation. The usability of these readers will vary according to the individual's needs. Adobe Reader, for example, will read the document's text aloud to the user, but offers very little else in terms of true accessibility: it has no provision for distinguishing alt text from body text, and it doesn't announce headers or hyperlinks. This may be not be problematic for users with mild visual impairment, but will not necessarily be helpful for someone who is reliant on text-to-speech technology. However, in many cases PDF e-books can be quite accessible to a screen reader when authored according to basic Web-accessibility principles.

The Microsoft Reader is entirely inaccessible to screen readers but comes with a text-to-speech feature that gives the user a reasonably accessible experience: in addition to reading aloud text, it identifies hyperlinks and allows the user to activate them; it identifies images through alt text, and permits the user to operate the software entirely from the keyboard.

Multimedia can be accommodated by directly embedding elements such as video or audio clips into the book, or by using internal or external links to launch and play the media. See Guideline H for complete information on creating accessible multimedia, and Guideline I for details on integrating accessible multimedia into e-books.

Other e-book formats may not offer enough accessibility to be useful to blind or some visually-impaired readers, although their accessibility may satisfy most deaf or hard-of-hearing users. For example, the desktop versions of MobiPocket and Palm eReader (PRC and PDB formats, respectively) will offer screen-reader users limited accessibility: desktop and laptop users may be able to access the text of these formats by using specific screen-reader modes (such as screen-reader cursor mode), but doing so only allows access to text, not images, hyperlinks or other information. External links to multimedia presented in these formats (embedded multimedia is not supported) will likewise be inaccessible to anyone who cannot see the screen or use a mouse.

In addition, the accessibility of the device used to read an e-book should be taken into consideration. E-books which can be read on laptop or desktop computers tend to provide the greatest flexibility for users of assistive technology. Handheld devices, such as dedicated e-book readers, PDAs or even cell phones, can be used to read certain formats of e-books but provide limited or no accessibility for blind or visually impaired users. (Deaf or hard-of-hearing users, however, may find these devices sufficient for reading e-books.) See the Beyond the Text Web site for more information about e-book formats and device accessibility.

Digital Rights Management (DRM)

Accessibility problems in e-books are sometimes linked to issues surrounding digital rights management, or DRM. DRM can be used to control how the content is presented to the user as well as how much control the user is given over the e-book. For example, some e-books can be printed on paper in their entirety by the user, whereas some allow only certain pages to be printed. Others allow no printing at all. Similarly, some e-books can be issued so that the built-in text-to-speech feature is disabled, or so that screen-reader access is limited.

DRM can be applied through various methods. Software reading devices themselves do not normally apply DRM; rather, the e-book content arrives with DRM restrictions already in place and the devices implement the requested restrictions. Most hardware reading devices are also capable of implementing or enforcing DRM.

Open standards

While many e-book formats are proprietary or locked in some fashion using DRM, there exists one non-proprietary method of authoring e-books: the Open eBook Publication Structure (OEBPS) format. OEBPS is an XML-based framework specification for content, structure and presentation of electronic books. It was created by the International Digital Publishing Forum (IDPF, formerly the OEBF, the Open eBook Forum) as a way for authors, editors and publishers to create and distribute texts that can be used by a variety of electronic publishing systems and reading devices (collectively known as reading systems).

OEBPS-formatted materials can be read by any reading system that supports the format. There are at least three native OEBPS-format e-book readers — Mentoract Reader (still in beta), eMonocle and the OpenBerg Reader (still in beta) —, meaning they render native OEBPS publications, just as a Web browser reads HTML files directly. A number of distilled formats also exist, such as Microsoft's LIT, MobiPocket's PRC, and eBook Technologies' IMP. These are optionally DRM-restricted e-books created directly from OEBPS source files. These reading systems will not, however, read native OEBPS files themselves.

(Note: while LIT-format e-books can be read with the Microsoft Reader, it is possible to extract text from some types of LIT books and read it on other devices. One utility that accomplishes this conversion is ConvertLIT. ConvertLIT essentially decompiles a LIT file, then reverts it back to its original OEBPS state (its current compatibility is with OEBPS 1.0.1). The new files can then be read using an OEBPS reading system or other reading device.)

The OEBPS format is inherently accessibility friendly. At a minimum, an OEBPS book consists essentially of a control file (such as a package file with the extension .opf [Open eBook Package File]), a series of source files which are conformant with XHTML 1.1, such as HTML, and optional styling information using Cascading Style Sheets (CSS). OEBPS also supports the inclusion of images in PNG and JPG formats. Documents may integrate Scalable Vector Graphics (SVG), MathML and other XML languages, as long more basic HTML or image fallback representations are also included. Although OEBPS itself can embed multimedia using the <object> element, most available OEBPS reading systems do not actually support embedded video or audio clips yet. However, authors can link to these multimedia presentations outside the book, either locally or remotely (the latter provided the user has an Internet connection).

Authors familiar with creating accessible Web sites will find creating accessible OEBPS files to be a similar process. By following the basic principles discussed in these guidelines, as well as those detailed in WCAG 1.0, it is possible to create a highly accessible e-book (with or without multimedia) in the OEPBS format.

However, the accessibility of OEBPS-format e-books to users who rely primarily on screen readers is largely a function of the user agent (the software or hardware used to read the book), not just the way the book is structured. Creating an OEPBS document that follows accepted accessibility guidelines is one thing; finding a compatible reading device that is accessible to blind or visually impaired users is another. Currently only the beta version of the OpenBerg Reader provides reasonable (but not complete) access to a screen reader.

Despite the existence of this non-proprietary format, however, there remains the problem of content availability. Compared with the number of titles available in distilled formats such as PDF or LIT, there are few native OEBPS e-books circulating today. In addition, there are no simple-to-use applications for creating books in this format. While authors can use automated tools to create an HTML version of the e-book, the .opf file, which controls the presentation of the material, is usually constructed by hand or created with tools generally targeting a particular distilled format. While not necessarily difficult for anyone familiar with XML, creating the .opf file may not be a task that a casual author or small publisher will want to handle.

Two current standardization efforts within the IDPF may enhance the accessibility of OEBPS content. First, the Unified OEBPS Container Working Group is developing a standard for the packaging of all OEBPS e-book components (the package, HTML markup, style sheets, images, etc.) into a single file entity. While one application of the container will be for the delivery of e-book content from publishers and other content creators to the sales or distribution channel, it is likely that future OEBPS reading systems will natively render this format. Such native rendering abilities may allow accessible content to flow directly to users in need of such functionality. Second, the OEBPS Working Group has been re-chartered. Its mission is to develop the next generation of the OEBPS content standard; continuing and extending the accessible nature of such content is a high-level requirement of the working group.

Other non-proprietary approaches are also being explored. Currently in development, the new OpenReader format is a next-generation XML-based publication framework inspired by the OEBPS 2.0 work done by OEBF/IDPF between 2001 and 2003. It is a cross-platform approach to authoring many types of digital publications, from books to newspapers to certain types of business and government documents. As with OEBPS, OpenReader is not a software or hardware reader, but is an XML-based file framework which can be read by such devices. No OpenReader-compatible devices have been released yet although one company, OSoft, has created a Java-based reader that supports the delivery of open-standards documents. Called ThoutReader, it is available for a number of platforms and operating systems. In late 2005, OSoft announced that it will support the OpenReader format in open-source, Perl-based software due for release in mid-2006.

Because of its modular, extensible design, OpenReader will be able to support documents of other XML vocabularies. In later versions, OpenReader is planning support for SMIL, a non-proprietary multimedia-integration language from the W3C. Read the complete OpenReader user-agent feature set to learn more about what the format will include. Assuming that OpenReader-compatible reading devices are accessible to assistive technology such as screen readers, OpenReader has the potential to provide an accessible reading experience for all users.

Technique D2.1
Create accessible PDF e-books

The Adobe Reader — the primary reading device for PDF e-books — can provide a reasonably accessible reading experience for blind and visually impaired users provided authors and publishers take care to create accessible documents and not shut out features through overly strict application of DRM. Adobe Acrobat provides a convenient method for applying "tags" which provide structural information to assistive technologies which in turn can deliver content in an accessible manner to users. Documents containing text, pictures and links can, generally speaking, be made quite accessible, while some structural elements, such as forms and data tables, are still not very accessible in PDF. Adobe's ongoing efforts to make PDF more accessible are described at Adobe's accessibility site.

Two resources detailing what is necessary to create accessible PDF documents are shown below.

• Adobe's Creating Accessible PDF documents, a detailed set of instructions for creating accessible PDF documents.
• WebAIM's PDF accessibility tutorial, a concise set of instructions and shortcuts for creating accessible PDF documents.

Acrobat offers a number of accessibility features through the Advanced/Accessibility menu, including support for automatic tagging. However, Acrobat's tagging feature should not be considered a foolproof approach to providing accessible PDF documents. After adding tags, authors must still test the document for proper reading order, tab order, element identification, etc., using a screen reader. Similarly, Acrobat's built-in accessibility checkers (Quick Check and Full Check) should be used as supplements to, not as substitutes for, rigorous testing with a screen reader and keyboard.

In addition to implementing the advice offered in the above tutorials, authors should provide a set of access instructions at the beginning of the book. These instructions can include information about navigational structure as well as multimedia clips if they are used (how to access and control them, for example, or where they are located in the book). Ensure that the access instructions are available in the table of contents; authors can even place a link to the instructions on the title page. You can see an example of an access-instruction link in a PDF e-book in the image below, or you can download one of the PDF e-books from the Beyond the Text site.

Complete information about providing accessible multimedia in PDF e-books can be found in Guideline I.

Technique D2.2
Create accessible LIT e-books

LIT is Microsoft's proprietary e-book format readable with the Microsoft Reader for Windows or Windows Pocket PC/Mobile operating systems. There are other software readers that will open non-copy-protected LIT e-books; two are the OpenBerg Reader and Tiny eBook Reader. It is also possible to extract text from some types of LIT books and read it on other devices. One utility that accomplishes this conversion is ConvertLIT. ConvertLIT essentially decompiles a LIT file, then reverts it back to its original OEBPS state. The new files can then be read using an OEBPS reading system or other reading device.

The Microsoft Reader comes with a number of features designed to make LIT e-books as accessible as possible, including zoomable text, user-selectable type, keyboard operability and a text-to-speech engine (desktop/laptop only). It does not allow the user to print pages from the e-book. Microsoft Reader is inaccessible to screen-reading software.

There are two popular applications for creating LIT e-books. The first is OverDrive ReaderWorks. ReaderWorks is available in two versions: Standard (free), for personal or non-commercial use, and Publisher ($119), which is a more sophisticated application that can be integrated into a publisher's production system. Only Publisher permits the user to enable DRM and other high-level features.

ReaderWorks can use HTML, text, OEBPS or Word (.doc) files as source documents. Authors can use CSS to control appearance, but keep in mind that Microsoft Reader only supports a subset of the full CSS recommendation. In fact, Reader only supports a subset of HTML. A list of HTML elements and CSS properties supported by Microsoft Reader can be found on the OverDrive Web site or in the ReaderWorks Help manual, included with the software. In addition, LIT e-books can contain images in the JPG, GIF or PNG formats. OverDrive provides tutorials for using either version of ReaderWorks.

For maximum accessibility to LIT e-books, always author the materials following accepted accessibility practices such as those described in these guidelines as well as in the Web Content Accessibility Guidelines 1.0. Doing so ensures that Reader's text-to-speech engine will deliver as much information to the user as possible, such as alt for images, headers for navigation and structure via a table of contents. Keep in mind that data tables are not interpreted correctly by Reader's text-to-speech feature, and forms cannot be integrated into LIT e-books.

Authors should also provide a set of access instructions at the beginning of the book. These instructions can include information about navigational structure as well as multimedia clips if they are used (how to access and control them, for example, or where they are located in the book). Ensure that the access instructions are available in the table of contents; authors can even place a link to the instructions on the title page. You can see an example of an access-instruction link in a LIT e-book in the images below, or you can download one of the LIT e-books from the Beyond the Text site.

Another method for creating LIT e-books is to use Microsoft's Read in Microsoft Reader (RMR). RMR is a free add-in for Microsoft Word that converts documents to the LIT format in a few steps. RMR has limitations (for example, it has no support for DRM) so read its documentation carefully. It is best suited for personal use.

To create an e-book using RMR, first download and install the RMR add-in. An RMR button will be automatically added to the Word toolbar, as shown below, and will also appear as a choice in the File menu.

Author the Word document as normal, keeping in mind that you must add alt to all images if they are to be recognized by Microsoft Reader's text-to-speech engine. To add alt to an image embedded in a Word document, double-click on the image to reveal the Format Picture dialog. Click on the Web tab to reveal the alternative-text edit field, as shown below.

Type the alt here, following the conventions discussed in Guideline A. Repeat this process for each image in the document.

For maximum accessibility to LIT e-books, always author the materials following accepted accessibility practices such as those described in these guidelines as well as in the Web Content Accessibility Guidelines 1.0. Doing so ensures that Reader's text-to-speech engine will deliver as much information to the user as possible (such as alt for images, headers for navigation and structure via a table of contents). Authors should also provide a set of access instructions at the beginning of the book. These instructions can include information about navigational structure as well as multimedia clips, if they are used (how to access and control them, for example, or where they are located in the book). Ensure that the access instructions are available in the table of contents; authors can even place a link to the instructions on the title page. You can see an example of an access-instruction link in a LIT e-book in the images below, or you can download one of the LIT e-books from the Beyond the Text site.

Once you have converted the source to a LIT e-book, open it in Microsoft Reader. Although Reader is not accessible to screen readers, it can provide a reasonably accessible reading experience for blind or visually impaired users through the use of its text-to-speech feature. To hear the text of the book read aloud, press Ctrl+P. To stop reading, press Ctrl+S.

In addition to reading the text of the book, Microsoft Reader can provide navigational cues as well as read aloud the application's menu system, using the Book-to-Speech feature. To turn on Book to Speech, choose Settings from the library page or press Alt+S. Press Alt+G, then press O to access the Voice Settings page, then select the Verbosity checkbox. Once you do so, Reader will begin speaking. You can also elect to have text highlighted as it is read aloud by checking the "highlight text" checkbox.

Once you have turned on Book-to-Speech, return to the Library page by pressing Alt+L. Choose the book you want to open, then press Ctrl+P to hear the book read aloud. To stop reading, press Ctrl+S. Use the left and right arrow keys to move forward or backward word by word; use Ctrl+left/right arrow to move sentence by sentence, and use Alt+left/right arrow to move paragraph by paragraph. To hear details about where you are in the book (e.g., page number), press F5.

When Reader encounters a hyperlink, it will emit a pinging sound and announce "hyperlink" or "internal hyperlink," as appropriate, before reading the text of the link. To invoke the link, press Ctrl+Enter. If the link leads to a Web page, the page will open in an external browser; if the link leads to a multimedia clip, that clip will open in an external player appropriate to the format of the clip. At this point users must have access to a screen reader to navigate the Web page or multimedia player as Reader's Book-to-Speech feature works only within Microsoft Reader.

To adjust the read-back speed of Book-to-Speech, open the Start menu, then open Settings/Control Panel/Speech. In the Speech Properties Window press Alt+C and then the arrow keys to determine the read-back rate. You can also choose the voices from the Voice Selection menu (Alt+V).

While Microsoft Reader has text-to-speech features that provide a reasonably accessible e-book (provided they have not been disabled by DRM), it cannot properly interpret information in data tables. For example, if the source document contains an HTML data table, that accessible table will be inaccessible in Reader even if it has been marked up to be accessible to a screen reader. Therefore, avoid using data tables in LIT e-books. Forms cannot be used in LIT e-books because Reader provides no method for properly displaying or interacting with them.

Technique D2.3
Create accessible OEBPS e-books

As discussed previously, there are no software applications currently available that create cross-reading-system OEBPS e-books. However, authors can create the source material in HTML (styled with CSS) which can then be prepared for use in an OEBPS-compatible reader. (Note that OEBPS documents can contain a broad subset of HTML and CSS, but not a complete implementation. Read the list of supported HTML elements and attributes and CSS properties before authoring the OEBPS e-book.)

The accessibility of OEBPS-format e-books to users who rely primarily on screen readers is largely a function of the user agent (the software or hardware used to read the book), not just the way the book is structured. Creating an OEPBS document that follows accepted accessibility guidelines is one thing; finding a compatible reading device that is accessible to blind or visually impaired users is another. Currently only the beta version of the OpenBerg Reader provides reasonable (but not complete) access to a screen reader. Other OEBPS-compatible reading devices include the Mentoract Reader (still in beta), and eMonocle.

With this caveat in mind, the techniques below outline the basic process for creating an OEBPS publication that could be accessible to all users. Authors interested in a more in-depth approach to creating OEBPS e-books should read the Open eBook Publication Structure 1.2 specification. Portions of the material below were adapted from this document.

Create the HTML source, following the accessibility practices outlined in these guidelines as well as the techniques detailed in WCAG 1.0. Once you have finished writing the source, create an Open eBook Package File that uses the extension .opf for the filename. The OPF is an XML file consisting of specific information about the contents and structure of the book. The major parts of the OPF are as follows:

• the package identity
• metadata, such as title, author, publisher, date, etc.
• the manifest, a list of items that comprise the publication (HTML pages, images, etc.)
• the spine, which lists the elements of the book arranged in a linear reading order
• tours (optional), giving the reader alternative reading sequences of the book
• guide (optional), locating the a table of contents, forward, bibliography, etc.

Note that "tours" and "guide" are optional. All other elements are mandatory.

Below is an example of a basic .opf, showing mandatory elements only.

Begin the OPF file by declaring the DOCTYPE:

Next, enter metadata describing the publication. OPF metadata are based on Dublin Core metadata within a <dc-metadata> element. Any number of Dublin Core elements may be used, including multiple instances of the same type. A few are shown below.

Multiple dc:Identifier elements may be specified, generally including a scheme attribute to declare the type of identifier (e.g. ISBN, DOI). At least one dc:Identifier must have an id attribute; the top-level package element must reference one of these ids via its unique-identifier attribute to specify the publication's primary identifier.

Once you have finished describing the contents in the metadata, create a <manifest> containing all elements of the publication, including style sheets, images and, if applicable, multimedia elements (such as movies, audio clips, etc.). The <manifest> does not require that these elements be listed in any particular order.

Note the use of the fallback attribute, which is used by reading devices which do not support certain media types specified in the manifest. Typically, fallback items are in the formats specified by the OEBPS core media types. OEBPS-compatible reading devices must support all of the core media types and may optionally support others. If you are providing non-core media types in your publication (such as a QuickTime movie), for example, you must also include a valid fallback.

Next, in the <spine>, list all the components of the publication. The <spine> requires that all components be listed in the desired sequential reading order.

In the example above, the first item the reader will see in the book is the title page, taken from the file href="vo_coverpage_oeb.htm", and the next item will be the actual body of the document, taken from the file href="vo_oeb.htm". The final item is the additional notes found in notetext.

The author may include <tours> and <guide> elements, if desired. A <tours> may be used to lead the reader to specific areas of interest in the publication. A <tours> may include multiple <tour> elements. Here is an example of <tours> code.

Finally, the .opf may contain a <guide> element, which is used to identify important components of the publication. An OEBPF-compliant reading device may use the <guide> to provide access to specific sections of the book, similar to a table of contents.

Technique D2.4
Create NIMAS files

NIMAS (the National Instructional Materials Accessibility Standard) requires publishers to provide electronic files in a consistent format designed to make digital talking book (DTB) and braille production of K-12 texts easier and faster.

NIMAS, an XML format, is a subset of the DAISY ANSI/NISO Z39.86 standard. The full specification includes all the tags needed to mark up a digital book, with some exceptions (mathematics, multimedia) that are still subject to ongoing work in the DAISY/NISO maintenance committee.

The original committee that formed to develop the standard (the National File Format Technical Panel) agreed to a list of baseline tags that would be part of NIMAS and therefore required in files provided by textbook publishers. The committee also agreed that the remaining tags in the DAISY/NISO spec would be optional: publishers can provide those tags if they wish, or they may be added afterward where needed by organizations developing accessible materials for student use.

The NIMAS Web site also provides exemplars, which are complete NIMAS files for use by organizations developing NIMAS files or tools. Below is a fragment from one exemplar.

The following image shows how a simple visual style sheet might render a page from this book.

Detailed information describing the structure of NIMAS documents is available on the NIMAS at CAST Web site. The full DAISY/NISO specification is available at the DAISY Web site.

The value of the NIMAS format is that it can be transformed in many ways, to produce braille, large print, audio books, or accessible electronic text. This is just one example of what is possible.

Checkpoint D3
Provide textbooks for handheld devices.

While they haven't disappeared entirely from the market, dedicated hand-held e-book readers have lost popularity to multi-use devices such as laptops, PDAs and even cell phones. The eBookwise 1150 and the ETI e-book readers are among the few dedicated hardware e-book readers still available in North America. Sony has also announced plans to issue a new E-Ink-based hardware reader in 2006, called the Sony Reader. Another device, the iRex iLiad, due for release in mid-2006, will also feature E-Ink technology.

For the time being, for those authors planning to include multimedia in e-books who also want to provide versions for handheld-device users, the practical choices are restricted to Palm and Windows Pocket PC/Mobile (2003/2003SE and Windows Mobile 5) operating systems. There are several e-book readers for these OSes, such as Adobe Reader (Palm and Windows Pocket PC/Mobile) and MobiPocket Reader (Palm only), plus iSilo and eReader Pro (Palm and Windows Pocket PC/Mobile), and Plucker (Palm only). No handheld reader currently supports embedded multimedia, but some will link to remote clips through players such as Windows Media Player or Kinoma Player. Note that while screen readers are slowly becoming available for Windows Pocket PC/Mobile OS devices (such as Dolphin's Pocket Hal, Humanware's Maestro or CodeFactory's Mobile Speak Pocket) these have yet to be proven reliably compatible with e-book software. For now, cautious authors may still want to view handheld e-book software as inaccessible to blind users. However, deaf or hard-of-hearing users may benefit from reading e-books on these devices, and videos or audio clips incorporated into handheld e-books can, in most cases, include captions (see Guideline H).

Checkpoint D4
Provide textbooks as digital talking books (DTBs).

Strictly speaking, a digital talking book (DTB) is a multimedia representation of a print publication that provides access to the text through digitally recorded human voice or synthetic text-to-speech technology. DTBs are largely aimed at blind or visually impaired users, but are also used to help improve reading and comprehension skills in students with learning disabilities. They provide various levels of navigation, from partial to complete, and can be read on dedicated hardware devices or on software players that run on Windows or Macintosh computers. There is also at least one DTB player for Windows Pocket PC/Mobile devices. See the comparison table at the Beyond the Text Web site for a listing of DTB hardware and software players.

In addition to providing accessible text to blind or visually impaired users, even the most basic DTB reader can accommodate accessible audio clips — that is, in-line audio clips with integrated audio descriptions. These described clips can be inserted directly into the DTB's structure wherever they are necessary, and will be played automatically by the DTB reader when the user is listening to recorded speech.

Properly created DTBs are based on the DAISY ANSI/NISO Z39.86 standard. As with any XML-based markup language, DTBs can be coded entirely by hand using any text editor, but there are a variety of software applications which simplify and speed the creation of DTBs . See the DAISY Consortium's list of DTB production tools for more information. DTBs can also accommodate linked and embedded multimedia; for instructions on creating books with these features, see Guideline J.

Checkpoint D5
Provide accessible multimedia in on-line textbooks.

Multimedia may be embedded in an electronic textbook or it may be launched in a separate, stand-alone player. Embedding a video or audio clip in a Web page can make for neater design, but most embedded clips don't offer full keyboard access to caption or audio-description preferences, making it difficult for deaf or blind users to find these features. Some embedded players can't be controlled without a mouse, making them impossible for keyboard users to manipulate. Giving the user the option of launching a stand-alone player is often the safest way of presenting multimedia because users can more easily control the presentation.

For details on creating accessible multimedia and adding it to e-books, see Guideline I.

Checkpoint D6
Provide alternative presentations of electronic or on-line textbooks.

Hard copies of the textbook should be available for those who wish to read with magnifying hardware, and braille copies complete with tactile graphics should also be available. Once created, the brailled textbook can be made available through the publisher's distribution mechanism, through an arrangement made with the braille production facility or via the course instructor. Availability of brailled materials should be clearly documented on the Web site, including contact information. Brailled books 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. Also see Appendix 1 for information on braille services.

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.

Guideline E
Provide access to interactive activities for all users with disabilities.

The basic principles of creating accessible interactive activities come from general software design guidelines. However, there are some aspects of an interactive activity that deserve particular attention in educational software. Techniques for meeting these checkpoints are found in the software design guidelines for specific development environments, as well as in the general software accessibility guidelines at The Trace R&D Center's Software Accessibility Guidelines.

Checkpoint E1
Ensure that all actions can be completed from the keyboard.

Providing a complete keyboard interface for an activity means that users who cannot use a mouse will be able to complete the activity. Users who are blind or have low vision rely on the keyboard for input and interaction. Some users with physical disabilities also use the keyboard or an alternative input device that passes keystrokes to the operating system. Pay particular attention to activities where users are expected to "drag and drop" one item onto another or must use the mouse to select an item from among alternatives. The Windows OS provides a common and well-known model of a keyboard interface to a graphical user interface. Using the conventions provided by this model allows users to avoid learning a new keyboard interface.

Note that it is possible to provide access to all users on platforms that do not include a keyboard, such as kiosks. See the Trace R&D Center for information about kiosk accessibility.

Checkpoint E2
Present information in ways that are accessible to both blind and deaf users.

Users who are deaf need visual access to any information presented in audio. Users who are blind will benefit from audio access to visual information (and at a minimum must be able to convert visual information into audio or braille through use of a screen reader).

Multimedia presentations are one clear example of the need for multimodal information, but other aspects of a program's educational content and interface should be considered as well. If important warnings or instructions are provided in more than one mode, they will be immediately useful to more users. And when educational content is provided multimodally, many other students can benefit in addition to those with disabilities. For example, Tindall-Ford and colleagues showed in several different experiments that when information was presented in audio and visual form, performance on complex tasks was improved (1997). And 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). The groups of students who may better understand text both seen and heard includes those with learning disabilities or difficulty reading, students learning English as a second language, and students who learn better auditorily rather than visually.

Checkpoint E3
Allow users to customize any timing of events.

Users of assistive technology may not be able to respond to on-screen events as quickly as other users. For example, it may take longer to hear a message using text-to-speech technology than it would to read it visually. A user with a magnified screen may need extra time to locate a message on screen before reading it. And users with physical disabilities may have slower response time to messages. For all of these reasons, users should have the option to change or eliminate any requirement for timed responses. This includes the ability to freeze and repeat any audio or visual presentations. Allowing changes in the timing of required actions also helps to solve some of the problems described in Checkpoint E4 for users who cannot attend to two sources of information at once.

Checkpoint E4
Provide features that allow users to access multiple sources of information separately when they are delivered simultaneously.

Users with disabilities may not be able to monitor two sources of information at once. For example, blind users with screen readers can monitor only one portion of the screen at a time. If important information appears simultaneously in two places, they may need to check each location separately. A user with a magnified screen cannot see two widely separated parts of the screen at the same time and may need extra time to locate new information or may not be aware of both pieces of information. Users who are hard of hearing may be able to use some auditory features but will have difficulty attending to two sounds at the same time. And users with cognitive disabilities may find it difficult to focus on more than one new piece of information at a time.

Separate access to multiple components must be considered when planning multimedia. For example, if instructions for an activity are given in audio but the user must watch something happen at the same time to understand the instructions, a deaf user reading captioned audio may not be able to follow along visually. Users must be able to pause any action to give them time to read the instructions and see the context for those instructions. Similarly, if there is an audio description for blind users simultaneous with audio in the program, it is best to freeze the audiovisual presentation and allow the audio description to play completely, then resume the audiovisual presentation.

Checkpoint E5
Provide a simpler version of any screen with complex backgrounds.

Users with low vision may have difficulty distinguishing important screen elements or text from background images. Avoid placing background images near important elements or under text. If this cannot be avoided, provide a feature that simplifies the screen when needed and ensure that this feature is clearly documented.

Guideline F
Provide access to graphs for users who are blind or visually impaired.

Graphs are frequently used in math and science materials to present and summarize data. In visual form, they are not accessible to users who are visually impaired, although the data being graphed can be expressed in nonvisual ways. Viable alternatives include generation of a tactile graph, delivering the information in text, interaction with an audio graph, or a combination tactile/audio approach. Consider using Scalable Vector Graphics (SVG) format for graphs, especially in HTML-based content. Accessibility features of SVG will permit improved viewing and printing of graphs as well as providing other benefits. SVG allows smooth enlargement of images to provide large, high-quality graphs for users with low vision, and metadata included in SVG may be used programmatically to provide text information about graphs to blind users. For more information see:

• Scalable Vector Graphics (SVG) 1.1 Specification
• Accessibility Features in SVG

This guideline refers to all graphs including static graphs (provided as part of the instructional materials in a piece of software) and dynamic graphs (generated by the user as part of the product curriculum). Some techniques are only useful for static graphs.

The following resources may be useful for finding products and services that translate charts and graphs into alternative formats:

• The CoGenTex Chart Explainer
  Chart Explainer automatically generates natural-language summaries of charts and tables.
• ViewPlus Technologies
  ViewPlus offers a number of products that use audio to interpret charts, graphs and equations.
• gh LLC
  gh creates tactile graphics using its LaserLine technology.

Checkpoint F1
Allow all graphs to be printed.

Allowing graphs to be printed separately from an image of the entire screen is a simple and broadly useful adaptation with benefits similar to those of printing other kinds of still images, as discussed in Guideline A1. Using a printed graph, low-vision users can create enlarged images. Blind users can print tactile graphs using specialized equipment. There are tactile graphics printers available that can print a graph and emboss any corresponding text in braille. Standard operating system drivers can create images and text of maximize usefulness. For example, send font and character information to the printer rather than images of text, because images cannot be converted to braille.

Checkpoint F2
Allow all graphs to be enlarged on screen.

A zooming or scaling feature, similar to one common in word processors, will improve access for users with low vision by allowing them to enlarge graphs to view smaller features. Ensure that lines and fonts are smooth and legible at the enlarged size. If enlarged graphs can be printed in larger sizes, it is easier for blind users to convert on-screen graphs into tactile images.

Checkpoint F3
Allow users to control the width of lines and characteristics of fonts for viewing and printing graphs.

Allow users to control the width of lines and characteristics of fonts for viewing and printing graphs.

Some users can better read text and view graphs if they can adjust the thickness of lines and the size, color, and typeface of fonts. Allow these features to be customized within the product. Also, some operating systems allow users to set a default typeface and line thickness. Check the accessibility features of the operating system for which the software is being developed to see if there are default values that can be used throughout the software.

Checkpoint F4
Provide a complete description in text for static graphs.

In recordings of textbooks on audiotape or CD for use by blind students, narrators routinely describe graphs and charts in words. A carefully scripted description can convey the main points of a graph. This text can be displayed on screen for use by assistive technology, delivered directly by the product with text-to-speech, or delivered programmatically through an accessibility API. See the section on access issues for selected development environments for information on accessibility APIs. The text should describe the layout of the graph, the location of variables on the graph, and the overall trend. Here is an example from the National Braille Association Tape Recording Manual (listed in Appendix 4, Guides to Spoken Mathematics):

Figure 5. "The relationship between the vapor pressure of water and its temperature." This is a line graph whose x axis is temperature in degrees centigrade, running from zero to one hundred degrees. The y axis is pressure in millimeters of mercury and runs from zero to 800 millimeters. The curve starts at the origin and rises so that when x is 25 degrees, y is approximately 40 millimeters. When x is 50, y is 100. When x is 75, y is just under 300. When x is 100, y is about 760. End of Figure 5."

A project at the WGBH National Center for Accessible Media (NCAM) is currently studying the development of a standardized approach to describing mathematical or scientific tables, illustrations and other visual material. See the Effective Practices for Describing Science Content project for more information.

Checkpoint F5
Provide summary information about dynamic graphs.

A dynamic graph probably has certain aspects, such as the range of the axes or the variables being graphed, that are known to the program. If so, this information is useful to blind users in determining which graph they are editing or printing. For example, if there is a user-editable graph, create a descriptive summary including the graph title, the names of any variables included in the graph, and the range of values for that variable. This text can be displayed on screen for use by assistive technology, delivered directly by the product with text-to-speech, or delivered programmatically through an accessibility API. See the section on access issues for selected development environments for information on accessibility APIs.

Checkpoint F6
Provide alternate formats for graphs.

Graphs presented in alternate formats provide more options for visually impaired users.

Technique F6.1
Provide tactile graphs for static graphs.

One of the most thorough ways of conveying information contained in static graphs to people who are blind is to generate a professional-quality tactile rendering of the graph. Consider creating a set of tactile graphics that represent the complete contents of the software. This set of tactile graphs can be made available either through the publisher's distribution mechanism or through an arrangement made with a tactile graph production facility. Availability of tactile graphs should be clearly documented in product help and in any appropriate teacher support materials that may accompany the software. There are several professional production facilities that have a wealth of experience producing tactile graphs. See Appendix 1 for a list of these organizations. 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.

Technique F6.2
Provide a brief orientation in text.

While tactile graphs are helpful, many blind students find initial orientation to the graph difficult. A brief text explanation of the graph's layout will significantly improve students' ability to access and interpret the information conveyed on the graph. Teachers and students may also read the text to decide which graphs warrant more exploration. Text can be delivered within the software through an accessibility option or programmatically though an accessibility API, or could be included as a separate hard-copy document shipped with the tactile graphs. This short orientation should give the title of the graph, the variables plotted on each axis, and their ranges.

Technique F6.3
Provide an audio equivalent to graphs.

Through an innovative use of audio, software can provide interactive access to graphs using tones or text-to-speech. Since exploring values on static graphs and creating dynamic graphs is a real-time experience for other students, it should ideally be so for blind students as well. Creating audio graphs is not a fully developed field, but there are some examples to consider. The DOS Triangle tool from the Science Access Project at Oregon State University is one example of how to provide audio access to graphs and tables. Also see the Audio Graphing Calculator from ViewPlus Technologies, Inc.

Below are other options for creating useful audio graphs.

Technique F6.3.1
Use tones to present an audio graph.

Use an audio tone to illustrate rise and fall of a graph or the relative values of a variable in a pie chart. If a task requires that more than one variable must be tracked simultaneously or individually, each variable should be assigned a distinct voice, so that the rise and fall of the pitch indicates the change in value. Note that this option will not be useful for deaf-blind users.

Technique F6.3.2
Provide text output of a visual graph.

Use text to deliver the numeric values in a graph interactively. The values can be delivered via text on screen to be read by a screen reader or through direct text-to-speech. More than one variable can be tracked in speech by including the variable name before each value and using different voices or pitches for text-to-speech. This option will meet the needs of deaf-blind users if the text is displayed on screen or provided programmatically for compatibility with a screen reader.

Technique F6.3.3
Implement navigation features to allow users to explore data points while listening to a graph.

Allow users to move through a graph at their own pace, using keyboard commands for navigation. At each increment, provide current graph values using text or tones or both. Allow students to play back the audio or text graph continuously, then pause at a keystroke to confirm a numeric value for a particular point. Provide options to allow users to configure this audio browsing experience for their needs.

Technique F6.4
Provide a haptic or haptic and audible means of obtaining information conveyed in a graph.

Haptic technology allows one to experience a graph or 3D image tactilely through force feedback. Vision is the "highest-bandwidth sense," so replacing the amount of information that can be perceived through vision with touch may require a multimodal approach. Combining haptics with audio can create this richer sensory experience. Methods for providing haptic interfaces to scientific information are still undergoing research, however. For more information, consult these sources:

• The University of Delaware's Information Access Laboratory
• The University of Toronto's Adaptive Technology Resource Centre

Guideline G
Provide access to scientific and mathematical expressions for all users with disabilities.

Current interfaces to scientific and mathematical expressions in Web sites and educational software pose two sets of problems: first, users who are blind cannot read these expressions (and users with low vision may have trouble reading them at small sizes), and second, both users with visual impairments and those with physical disabilities have difficulty using expression input-and-editing interfaces that require use of a mouse.

Checkpoint G1
Allow all expressions to be enlarged on screen.

A zooming or scaling feature, similar to one common in word processors, will improve access for users with low vision by allowing them to enlarge expressions for better viewing. Ensure that characters are smooth and legible at the enlarged size. Users may also wish to print out materials at the enlarged size.

A completely different approach to some types of images (e.g., graphs) is to consider the use of Scalable Vector Graphics (SVG), 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 graphics 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 1.1 Specification
• Accessibility Features in SVG

Checkpoint G2
Ensure that users with visual impairments can read scientific and mathematical expressions and that users with visual impairments and with physical impairments can write expressions.

In order to interact effectively with scientific and mathematical expressions, users need to read, write and edit them. Users must be able to enter all characters needed to create an expression whether they use the keyboard or the mouse. They must know what they have written and where the insertion point is so they can add or delete characters.

Understanding longer or more complex expressions requires navigating within the expression to hear different parts separately. Expressions provided in educational content that cannot be changed by the reader are referred to here as static expressions. Expressions that can be edited or written by the user are referred to as dynamic expressions.

Software developers may use a range of means to read static expressions to users, including direct approaches (providing prerecorded audio files) and compatible approaches (making expressions accessible to screen readers). A direct approach such as pre-recorded files would provide access for blind and low-vision students, though not for those who are deaf-blind. The audio must include sufficient information about the structure of the expression to avoid confusing the listener. Unstructured communication is only adequate in cases of very simple mathematics. For example, nested fractions such as (x+2)(3/5) are difficult to convey accurately in speech without a structured way of speaking. See Appendix 4, for resources.

Software that allows users to write new material including expressions must provide a way to access any user-created text. The best solution is to use a standardized markup language that assistive technologies can interpret. The best choice is Math Markup Language, or MathML, defined by the World Wide Web Consortium. Interpretation of MathML by screen readers is improving, and widespread use of MathML by software developers will hasten the creation of solutions for users of assistive technology. Other tools offer browser-specific approaches to using MathML. Design Science's MathPlayer, for example, is a plug-in for Internet Explorer that will display native MathML. Popular screen readers, such as JAWS, Window-Eyes and HAL work with MathPlayer to provide improved screen-reader output of MathML. MathPlayer also comes with a math-to-speech function as well as a zoom feature to enlarge equations.

A second possible markup language for scientific or mathematical expression display is LaTeX. Tools do exist for converting LaTeX to Nemeth braille for blind users. These tools are designed to convert entire documents rather than for use with interactive software, but this does permit some access to instructional materials.

Technique G2.1
Use MathML to provide access to scientific and mathematical expressions

MathML is the best choice for a markup language for expressing math. The advantage of MathML is it provides mathematical information in an open, standard format that can be exploited by a wide range of assistive technologies.

Math-capable assistive technologies that interact with mainstream Web browsers, such as Design Science's MathPlayer, will receive wider acceptance as MathML becomes a more common means of publishing electronic math content. For maximum accessibility, software that includes content written in MathML and HTML should allow users to use a browser that provides the functions they need. If MathML is the protocol used to deliver math content but the product is not HTML-based, the MathML content should be available as part of an operating system accessibility API or in an accessibility mode allowing access by assistive technology.

Once software programmatically exposes the MathML markup used to display math on the screen, assistive technologies will give users interactive control of reading and writing scientific and mathematical expressions. Note that MathML itself is not intended to be human-readable; tools will interpret the markup and create a useful representation in speech or braille.

Technique G2.2
Use LaTeX to provide access to scientific and mathematical expressions.

LaTeX is a math typesetting language used frequently in academic settings. Tools are currently available that can convert LaTeX files to Nemeth code (math braille). Teachers can use tools to create brailled math for homework assignments, tests, and handouts without knowing any Nemeth code themselves, and students can write their responses in Nemeth code, then produce printed math to submit to their teachers. The current tools convert entire documents rather than allowing for use with interactive software, but they do provide some access by allowing instructional materials to be printed for blind users. The Texas School for the Blind and Visually Impaired (TSVBI) maintains a list of Nemeth translation software.

Technique G2.3
Use prerecorded audio to read static scientific and mathematical expressions

A human narrator can prerecord all text including static expressions. This audio file allows the user to hear entire expressions on command, as well as smaller chunks. Use of the DAISY talking book specification provides a synchronized and controlled audio presentation. This technique, unfortunately, does not provide access for all users, such as deaf-blind students. Consider using audio files as a supplement to one of the other techniques to ensure that your content is universally accessible. See Appendix 4 for resources.

A project at the WGBH National Center for Accessible Media (NCAM) is currently studying the development of a standardized approach to describing mathematical or scientific tables, illustrations and other visual material. See the Effective Practices for Describing Science Content project for complete information.

Technique G2.4
Use concatenated speech strings for simple scientific and mathematical expressions.

For simple expressions, such as those in elementary-level math software, a satisfactory interface can be created by concatenating (stringing together) segments of prerecorded speech. However, the software must provide all commands needed for interacting with the expressions. Furthermore, this approach quickly loses effectiveness as expressions become more complicated and students need more structural information to interact efficiently with the content.

gh LLC is currently developing a method for rendering specialized math markup, such as MathML and MathSpeak, using the ghPlayer. See the MathSpeak Initiative for full details.

Technique G2.5
Create scientific and mathematical expressions scripts using guidelines for spoken mathematics.

If other techniques are not possible, software must deliver expressions in an alternative form through carefully scripted text. Software can spell out expressions on the screen in words, for example "2 x squared plus the fraction 3 over 4," which can then be read by an assistive technology.

Another interim solution is to send scientific and mathematical expression information directly to a text-to-speech engine. To use this technique, the software must provide a mode where the entire text of the expression is read, as well as provide commands for reading specific sections of the expression. The software must also allow the user to move through the text in shorter chunks, such as parts of expressions. Mechanisms for internal navigation of scientific and mathematical expressions may be required to allow the user to read specific elements and determine their position and relationship to other elements within the expression. See Appendix 4 for resources.

Additional resources for math and science notation include:

• The Network for Inclusive Distance Education
• NCAM's Effective Practices for Describing Science Content
• gh's MathSpeak Initiative

Guideline H
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.

Creating Accessible Multimedia

There are two markup formats that support the inclusion of audio descriptions and/or closed captions in digital multimedia presentations-Synchronized Multimedia Integration Language (SMIL) and Synchronized Accessible Media Interchange (SAMI). SMIL is played by the QuickTime Player, RealPlayer, the Oratrix GRiNS Player and the Ambulant Player. SAMI is played solely by the Windows Media Player. A free utility, the Media Access Generator (MAGpie), can be used to create captions and audio descriptions for SMIL presentations, and captions only for SAMI and Macromedia Flash presentations.

Authors of e-books and digital talking books can integrate accessible multimedia into these materials. Some e-book formats, such as PDF, allow multimedia to be embedded directly into the book, while others, such as Microsoft's LIT format, permit linking to multimedia. DTBs can accommodate accessible in-line audio clips, and at least one software DTB device supports embedded video. See Guideline I and Guideline J for complete information on adding accessible multimedia to electronic texts.

SMIL

SMIL was developed by the World Wide Web Consortium (W3C), an international industry consortium that publishes protocols for the Web. SMIL 2.1 is the latest version of the specification, published in 2005. 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 a local file system via hard drive, CD or DVD. Visit the W3C's Synchronized Multimedia page for complete information about SMIL and related activities at the W3C.

When authored correctly, SMIL allows users to turn captions and descriptions on and off via a player interface. The QuickTime Player, GRiNS Player, Ambulant 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.

(See Guideline H2.3 for details on adding controls to QuickTime presentations.)

Take note that different SMIL players provide varying levels of implementation-- in other words, some players implement the entire specification, and some use only parts of it. Also, not all of SMIL's accessibility features are supported by all SMIL players. In these cases, we offer workaround solutions that will work with existing players.

SAMI

SAMI is a Microsoft public specification that allows closed captions to be played in the Windows Media Player on the Windows OS only. 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., now part of Adobe Systems, 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 Center.

One way to create captions for Flash movies is to use NCAM's CCFlash MX. CCFlash MX is a Flash MX extension that allows Flash developers to easily incorporate closed captions on the Flash timeline. It supports MAGpie input files and can be used on both native timelines as well as Flash video timelines via cuePoints. Developers can set various text attributes, including font face, font size, foreground color, text box size, opacity and background color. All text components generated by CCFlash MX are placed on a separate layer for easy management. Additionally, sample components are generated for toggling the captions on and off.

Another application, HiSoftware's Hi-Caption Studio, also allows users to create captions for Flash movies.

Checkpoint H1
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 should 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.

Technique H1.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. You may also use any sound-editing program, such as SoundForge or Audacity, 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.

Complete information on using MAGpie to create and synchronize audio descriptions may be found in the MAGpie on-line documentation.

Technique H1.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. The RealPlayer, GRiNS Player, Ambulant Player and the QuickTime Player all use SMIL to integrate audio descriptions into a multimedia presentation. In addition, SMIL provides test attributes that can be used to programmatically determine, among other things, the viewer's player preferences for captions and descriptions. The RealPlayer and Ambulant Player, for example, support the SMIL test attributes for captions (systemCaptions) and descriptions (systemAudioDesc), while the Quicktime Player does not.

You can use MAGpie to author accessible SMIL presentations, as described in Technique H1.1, but if you wish to write SMIL code yourself, details are provided here. The RealPlayer and Ambulant Player provide reliable support for the current SMIL recommendation. Support for SMIL in the QuickTime Player is selective, so test your presentation thoroughly before making it available publicly. Also read about QuickTime's support for SMIL at Apple's Developer Connection site.

SMIL 2.x and audio descriptions

When creating a described presentation for a SMIL player, you 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 is a picture of the RealPlayer's accessibility preference settings, showing choices for both audio descriptions and captions.

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, the "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 and the QuickTime Player for programmatically inserting extended audio descriptions was not complete (Ambulant Player's implementation of SMIL 2.1 does include support for this feature, however). 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 the target multimedia player supports SMIL 2.x's extended audio description capabilities.

Technique H1.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 is selective, so not all features are available. Test your presentation thoroughly before making it available publicly, and read about QuickTime's support for SMIL at Apple's Developer Connection site. In cases where SMIL is not appropriate or reliable, 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 Show Movie Properties from the Window menu, or press Command-J on Macintosh, or Ctrl-J in Windows.
2. Using any sound-recording software (such as SoundForge or Audacity), 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. Press the O key to place the Out selection marker at that point.
4. Move the slider backwards until you reach the beginning of this pause. Press the I key to place the In selection marker at that point. This selects the segment of the movie clip that will receive the audio description.
5. Open the Edit menu and choose Add to Movie. This adds the description to the movie as a new sound track. In the track listing at the top of the Show Movie Properties window, you will see that "Sound Track 2" is now one of the menu choices.
6. Play the clip to hear the narration you've just inserted.
7. 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. The process described below simulates a pause in the movie by playing a still-frame for the duration of an extended description.

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. Using the sound-recording software of your choice, record and edit the first description you want to incorporate into the movie clip.
6. Open a new QuickTime Player window and then open the file you created in step 4.
7. Choose Select All from the Edit menu, and then choose Copy from the Edit menu.
8. Open a new QuickTime Player window, and open the audio-description you recorded in step 5.
9. Choose Select All from the Edit menu.
10. Select Add To Selection and Scale 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 1-13 as needed for other extended audio descriptions.
16. Save your work frequently, always saving the movie as a self-contained file.

Technique H1.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 H2
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, since 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, 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.

Technique H2.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 Player 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). Read complete information on using MAGpie to create and synchronize captions on the MAGpie Web site.

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 yet supported in multimedia players.) Therefore, representing anything beyond simple mathematical expressions in captions can only be accomplished via text.

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 integrated into a multimedia player. 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. 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.

Complete instructions for creating SVG captions, as well as a sample SVG-captioned movie, may be found at NCAM's Rich Media Resource Center.

Research and development efforts will eventually simplify the creation and display of scientific and mathematical expressions in captions. The W3C is currently defining a standard timed-text format that could eventually be adopted by 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.

Technique H2.2
Embed captions in QuickTime movies

Some authors may prefer to embed captions directly into a QuickTime movie rather than use SMIL. Doing so will increase the size of the movie somewhat (how much so will depend on how many captions are in the presentation), which may increase download times, but it will guarantee that the caption track is delivered to the user.

To embed captions, first author the caption track in MAGpie as described in Technique H2.1. Output the presentation as SMIL for QuickTime and then follow the procedure outlined below.

1. Open the QuickTime Player.
2. Open the File/Open Movie in New Player dialog box (Ctrl+O in Windows, Apple+O on Macintosh). Browse to the caption file created during the MAGpie export process, named projectname.qt.txt. The caption file will open in QuickTime as a caption track, as shown below.

   

3. Select the entire movie track by choosing Edit/Select All, or by pressing Ctrl+A (Command+A on Macintosh).
4. Copy the entire track by choosing Edit/Copy, or by pressing Ctrl+C (Command+C on Macintosh).
5. From the File/Open dialog, open the original (uncaptioned) video file.
6. Place the slider at the beginning of the movie track, then choose Edit/Add to Movie. The caption track will be added to the movie, but will be placed at the top of the video region, as shown below.

   

7. Reposition the caption track: From the Window menu, choose Show Movie Properties (or press Ctrl+J (Command-J on Macintosh)), choose Text Track. Select the Visual Settings tab. In the Offset area, type in the new position. The first entry is the X (width) position; the second entry is the Y (height) position. Position the caption region so the top edge of the caption track just touches the bottom edge of the video track.

   

8. Once the track is properly positioned, close the Show Movie Properties dialog.
9. Choose File/Save As..., and save the file as a self-contained movie.

Technique H2.3
Add audio-description and caption controls to QuickTime multimedia presentations.

While the QuickTime Player allows users to toggle all embedded movie tracks on and off via the Show Movie Properties dialog, this feature is only available to users who purchase an upgrade to the "pro" version of the player (approximately $30). However, authors can add buttons to the player interface for easier toggling of tracks. These buttons are available to all users, whether they purchased the upgrade or not. Such a feature is crucial when embedding a player into a Web page, and can also provide control of accessibility tracks in movies embedded into some e-books. Below is a picture of caption and description buttons integrated into the QuickTime Player interface.

To add control elements to a QuickTime movie, you will need the following:

• QuickTime Pro
• Control elements; download from the NCAM site or make your own using LiveStage from Totally Hip software.
• A QuickTime movie with captions and/or audio descriptions

For simplicity, this example assumes the use of two of NCAM's caption-control elements: captions-buttons and captions-labels. Follow the steps below to add these control elements to your QuickTime movie.

1. Open the QuickTime movie.
2. Open Window/Show Movie Properties, or press Ctrl+J (Command-J on Macintosh). From the track list at the top of the window, double-click on "Text Track," and rename it to "captions." Special note: QuickTime 7 for Windows introduced a bug that prevents users from renaming tracks (this bug is not present in QuickTime 7 for the Macintosh). NCAM has created a free utility, QTracker, that circumvents this bug and provides a mechanism for renaming tracks.
3. Choose File/Open Movie in New Player (Ctrl+O in Windows, Apple+O on Macintosh) and open the element named captions-buttons.
4. Copy the entire track by choosing Edit/Select All, or by pressing Ctrl+A (Command+A on Macintosh). Copy the track by choosing Edit/Copy or by pressing Ctrl+C Command+C on Macintosh).
5. Click once on the window containing the captioned or described movie.
6. Make sure the slider is positioned at the beginning of the clip. Choose Edit/Add to Selection and Scale.
7. Repeat steps 3-6 for the element named captions-labels.
8. Reposition the elements: in Windows/Show Movie Properties, click once on the captions-buttons track from the track list at the top of the window. Select the Visual Settings tab. In the Offset area, type in the new position. The first entry is the X (width) position; the second entry is the Y (height) position.
9. Repeat step 7 for the captions-labels button.

Technique H2.4
Integrate captions into multimedia presentations using SMIL.

RealPlayer, the QuickTime Player, the Ambulant 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 can be used to programmatically determine, among other things, the viewer's preferences for 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 (see Technique H2.1). If you need to author a captioned SMIL presentation in some other way, such as with a text editor, create a file using the code samples below as a guide.

The first example shows the <layout> section of a SMIL file.

In this example, information between the <layout> tags instructs the player to draw two regions, one for video (<videoregion>) and one for text (<textregion>). Height and width are sized in pixels. Note that the top edge of the text region (top="214") is positioned so that it nearly touches the bottom edge of the video region (height="212"). This will place the captions in a box directly below the video region.

Below is some sample code showing the body of the SMIL file, where the player is given instructions on how and when to play the video and captions.

The information between the parallel (<par>) tags states that the two source files (one for video and one for captions) should be started at exactly the same time and be played in parallel, thus synchronizing the captions with the program audio. Since no start time is specified, SMIL assumes all elements will begin playing at time 0:00:00.0 (timecodes are represented as hours:minutes:seconds.frames, although other units may also be used). The systemCaptions test attribute is used to determine whether or not to actually play the captions, based on the multimedia player's preferences settings. If the user has set the player's preferences to play captions, those captions will be played at the intervals stated in the text 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.

Here are pictures of a movie with and without closed captions.

The caption file contains the actual captions and timecodes for the multimedia presentation, as shown below.

Note: This example shows a RealText file for use with the RealPlayer and the GRiNS Player. The QuickTime text format, QText, playable only with the QuickTime Player, looks slightly different:

When managing SMIL and caption files, some authors find it convenient to save the caption file in the same directory as the SMIL and video files. However, if you want to save them in separate locations, ensure that the paths specified in the SMIL file reflect the correct locations of the video and text elements. You can change the path information at any time by opening the SMIL file in a text editor and adding the new paths to the src attributes of the video or textstream elements. To test, open the SMIL file in the RealPlayer.

Technique H2.4.1
Integrate transparent- or translucent-background captions using SMIL in RealPlayer.

Instead of placing the caption region below the video region, as illustrated above, it is possible to display captions directly over the video region using a transparent background. RealPlayer supports both transparent-background displays (as does QuickTime; see Technique H2.4.2).

Displaying transparent-background captions in the RealPlayer is accomplished through the use of SMIL in combination with extensions unique to RealPlayer. The steps below outline the procedure.

1. Create captions with MAGpie, and choose Export/RealPlayer when finished.
2. Open the project's SMIL file (filename.real.smi) in a text editor. Replace the <SMIL> declaration with the following:

   <smil xmlns=http://www.w3.org/2000/SMIL20/CR/Language xmlns:rn="http://features.real.com/2001/SMIL20/Extensions/alphaControl">

3. Add the following to the <textstream> declaration in the <body>: rn:backgroundOpacity="0%". This will make the text region transparent.
4. Specify the text region's dimensions by altering the height and width in the <textregion> area of <layout>. For example:

   <region id="videoregion" height="300" width="400" background-color="black" left="5" top="5"/> <region id="textregion" height="70" width="400" left="5" top="230"/>

   In this code sample, <videoregion> has a height of 300 pixels and a width of 400 pixels. <textregion> has a height of 70 pixels and a width of 400 pixels.
5. Specify the location of the caption region within the player window by altering the coordinates in <textregion>. In the code shown in step 4, top="230" places the top edge of the caption region 230 pixels from the top edge of the player, and left="5" refers to the five-pixel indent from the left edge of the player. (Captions look best when there is a small amount of padding between the left edge of the caption region and left edge of the player.) Since the entire video region has a height of 300 pixels (height="300"), the caption region will occupy the lower 70 pixels of the video area.
6. Specify the text color. Open the RealText caption file (filename.real.rt) using any text editor. In the header, alter font color="#RRGGBB" to represent the color you want, where RRGGBB represents red/green/blue hexadecimal values.

Below is an image illustrating transparent-background captions as they appear in the RealPlayer.

If legibility is a problem, use a translucent region rather than a transparent one. To do so, specify a background color in the RealText caption file (filename.real.rt) file by adding background="color" to the header, where "color" represents the background color you want (e.g., background="black"). In the SMIL file, change the value in rn:backgroundOpacity="X%" to a percentage that represents the degree of opacity. The image below illustrates a black background with 25% opacity (rn:backgroundOpacity="25%").

When managing SMIL and caption files, some authors find it convenient to save the caption file in the same directory as the SMIL and video files. However, if you want to save them in separate locations, ensure that the paths specified in the SMIL file reflect the correct locations of the video and text elements. You can change the path information at any time by opening the SMIL file in a text editor and adding the new paths to the src attributes of the video or textstream elements. To test, open the SMIL file in the RealPlayer.

Complete documentation for adding effects to RealText captions can be found in the RealNetworks Production Guide.

Technique H2.4.2
Integrate transparent- or translucent-background captions into multimedia presentations for the QuickTime Player.

Displaying transparent-background captions in the QuickTime Player is accomplished through the use of embedded tracks or SMIL in combination with extensions unique to QuickTime. The steps for both approaches are outlined below.

Embedded transparent-background caption tracks in QuickTime

1. Create captions with MAGpie. Choose Export/QuickTime when you're finished.
2. Open the caption file (projectname.qt.txt) in a text editor.
3. In the header, add {keyedText:on}. This will create the transparent caption region.
4. To improve legibility of the text, add a drop shadow to the captions by adding {dropShadow:on} to the header. To adjust the characteristics of the drop shadow, use {dropShadowOffset:X,Y}, where X specifies the number of pixels to offset the shadow to the right, and Y specifies the number of pixels to offset the shadow downward. Values of 1,1 are often sufficient. Finally, you may want to use {dropShadowTransparency:X}, which specifies the intensity of the drop shadow. X can be any value from 0-255.
5. Adjust the height of the caption region by adding {height=X} to the header, where X represents the height of the region in pixels.
6. Specify the color of the text by adding {textColor:R,G,B} to the header, where R=red, G=green and B=blue. Each value can range from 0-65535.
7. If you find that the text edges look ragged, you can smooth them by adding {anti-alias:on} to the header.
8. Embed the track as described in Technique H2.2. When positioning the caption region in its new location (step 7 in H2.2), be sure to align the bottom edge of the region with the bottom edge of the video region, as shown below.

   

To learn more about QuickTime's text-track features, read the complete documentation about text descriptors at the Apple site.

Transparent-background caption tracks with SMIL in QuickTime

When possible, integrate transparent-background captions with SMIL. To do so, follow steps 1-7 for embedding transparent-background captions in QuickTime. Rather then embedding the caption track manually, however, SMIL will overlay it in the presentation on the fly.

After generating the SMIL file in Magpie, open the SMIL file (filename.qt.smil) in a text editor and adjust the textregion top value to place the transparent text region over the video, rather than below it (which is MAGpie's default). For example:

<region id="videoregion" height="300" width="400" top="5" left="5" background-color="black" />

<region id="textregion" height="60" width="400" top="240" left="5" background-color="black" />

Here, the entire videoregion has a height of 300 pixels. The top edge of the textregion is placed 240 pixels from the top of the presentation, and has a height of 60 pixels. Because {keyedText:on} has been added to the QText file, however, the background of the 60-pixel region will be rendered transparent, and the caption text will appear in this region directly over the video.

When managing SMIL and caption files, some authors find it convenient to save the caption file in the same directory as the SMIL and video files. However, if you want to save them in separate locations, ensure that the paths specified in the SMIL file reflect the correct locations of the video and text elements. You can change the path information at any time by opening the SMIL file in a text editor and adding the new paths to the src attributes of the video or textstream elements. To test, open the SMIL file in the QuickTime Player.

Embedded translucent-background caption tracks in QuickTime

1. Follow steps 1-8 for creating embedded transparent-background captions.
2. Open a text editor and create a caption-background track by entering the following text:

   {QTtext}{timescale:100}{width:400}{height:57}

   [00:00:00.00]

   [00:00:36.20]

   Note that the last timecode shown above ([00:00:36.20]) should be altered to represent the entire length of the movie. Do not enter caption text, or any other text, in this file. Save the file with the extension .TXT (e.g., mask.txt).
3. Open the file you created in step 2 in the QuickTime Player. Copy and embed the background track as described in steps 3-7 of Technique H2.2. Note that the background track will appear solid black in color.
4. Open the Windows/Show Movie Properties dialog and click once on the background track from the track list at the top of the window. Choose the Visual Settings tab.
5. From the Transparency menu, choose Blend. Move the slider to the right or left to adjust the transparency of the background. Below is an image showing a 50% setting.

   

6. Reposition the caption track: in the Offset area, type in the new position. The first entry is the X (width) position; the second entry is the Y (height) position. Position the caption region so the bottom edge of the caption track just touches the bottom edge of the video track.
7. Close the Show Movie Properties dialog.
8. Choose File/Save As..., and save the file as a self-contained movie.
9. Open the movie in the QuickTime Player. If you find that the background needs to be adjusted, open the Show Movie Properties dialog again and change the setting as described in step 5, above.

Translucent-background caption tracks with SMIL in QuickTime

When possible, integrate translucent-background captions with SMIL. QuickTime's implementation of SMIL is selective, so test your presentation thoroughly before making it available publicly. Read about QuickTime's support for SMIL at Apple's Developer Connection site.

Translucent-background captions with SMIL is accomplished through the use of unique QuickTime attributes, as described below.

1. Create captions with MAGpie. Choose Export/QuickTime when you're finished.
2. Open a text editor and create a caption-background track by entering the following text:
   

   {QTtext}{timescale:100}{width:400}{height:57}

   [00:00:00.00]

   [00:00:36.20]

   Note that the last timecode shown above ([00:00:36.20]) should be altered to represent the entire length of the movie. Do not enter caption text, or any other text, in this file.
3. Save the file with the extension .TXT (e.g., mask.txt) in the same directory as the existing text track, movie and SMIL file.
4. Open the project's SMIL file (projectname.qt.smil) in a text editor. In the <par> element, add the following line of code above the existing <textstream> declaration:

   <textstream region="textregion" src="mask.txt" qt:composite-mode="blend;X%"/>

   qt:composite-mode="blend;X%" represents the level of opacity of the background. Adjust the X value as necessary (e.g., "blend;40%") and save the file.
5. Open the SMIL file in the QuickTime Player. If the level of opacity is too dark or light, adjust it in the SMIL file as necessary.

When managing the video and text files, some authors find it convenient to save the caption file(s) in the same directory as the SMIL and video files. If you want to save them in separate locations, ensure that the paths specified in the SMIL file reflect the correct locations of the video and text elements. You can change the path information at any time by opening the SMIL file in a text editor and adding the new paths to the src attributes of the video or textstream elements. To test, open the SMIL file in the QuickTime Player.

Technique H2.5
Integrate captions into multimedia presentations using SAMI.

SAMI (Synchronized Accessible Multimedia Interchange) is a format from Microsoft used to display captions in Windows Media Player on the Windows OS only. Because it is HTML-based, it can take advantage of flexible display properties of that format.

As with SMIL, SAMI caption files can be created with MAGpie. Below is an excerpt from a SAMI file. Note that the formatting information is held in the <STYLE> section of the file, and the captions plus timing information are held in the <BODY>.

After exporting the SAMI file, ensure that the source media file and the caption file have identical root filenames (i.e., mymovie.wmv and mymovie.smi), and copy these files into the same directory. To launch the captioned presentation, open or link to the source media, not the SAMI file. However, for ideal file maintenance and to ensure that all Windows Media-compatible source material will play the associated SAMI file, store the video and SAMI files in separate directories and coordinate their playback using an ASX file. An ASX file contains the paths for the video and SAMI files (and other optional parameters), as shown below.

Note that the video and SAMI sources are contained in a single HREF, separated only by a question mark (?) without spaces. Be sure to link to the ASX file, not the source media, to launch the captioned presentation in Windows Media Player. If you are embedding a Windows Media presentation in a Web page using <object>, be sure to point to the ASX file in the FileName parameter, not the base media.

Read more about other elements that can be used in an ASX file in the Windows Media Library.

SAMI is playable on Windows Media Player for Windows. Microsoft announced in early 2006 that it would no longer support Windows Media Player for the Macintosh, and is now distributing Windows Media Components for QuickTime with Flip4Mac. To play Windows Media files in the QuickTime Player, users must download and install the free Flip4Mac software. SAMI files are not currently supported by Flip4Mac, however.

Guideline I
Provide accessible multimedia in e-books.

Most e-book formats can accommodate multimedia in some manner, either by embedding the elements directly into the e-book, or by linking to them externally. Some formats and readers are more accessible to users with disabilities than others: Adobe Reader (PDF format) offers reasonable access to screen readers, provided the author has taken care to create an accessible document; the Microsoft Reader (LIT format) comes with a text-to-speech engine that provides reasonable accessibility even though Reader itself is inaccessible to screen-reading software; and the OpenBerg Reader (OEBPS format) offers some accessibility to screen readers. However, even the most carefully authored documents may not provide a 100% accessible e-book due to limitations in the format itself or in the software used to read the book.

Before incorporating multimedia into any e-book, always be sure to add captions and audio descriptions to that multimedia. See Guideline H for details.

The information in this section describes procedures for adding multimedia — video or audio clips — to e-books in PDF, LIT, PRC and OEBPS formats on various hardware devices, such as desktop/laptop or handheld. Note that while the multimedia elements themselves may be accessible, the e-book readers for these formats offer varying degrees of accessibility. In the case of handheld devices, accessibility for deaf users is generally not a problem, but blind and visually impaired users may find it very difficult to use handheld devices to read e-books (see Checkpoint D3). See the comparison chart of e-book readers at NCAM's Beyond the Text project for more information. Also see Guideline D for more discussion about e-book accessibility.

Checkpoint I.1
Integrate accessible multimedia into PDF e-books

PDF e-books support both embedded and linked multimedia. Embedded clips, for example, are convenient: the user need only download and open a single document, and no Internet connection is necessary to view the clips. However, depending on the size of the e-book and the number of embedded clips, the document size can become rather unwieldy. Linked multimedia, on the other hand, is comparatively easy to integrate, takes up minimal space in the book and is launched in an external player appropriate to the clip's format. However, the user must have an Internet connection to play the movies if they are server-based, or must download and install the movies if they are linked locally.

Technique I1.1
Embed multimedia into PDF e-books.

Once captions and/or audio descriptions have been added to the multimedia, create a visible space in the e-book source to display the multimedia clip. If the book was authored in HTML, for example, use a <div> of appropriate dimensions to make room for the clip. The CSS float property can also be used to create the space as well as to flow text around it. When the document is converted to PDF it will then contain a visible area into which the multimedia may be embedded.

Convert the source document to PDF, then open it in Adobe Acrobat Professional. Choose Movie Tool from the Tools/Advanced Editing menu, then double-click in the blank area you created on the page where the clip will be embedded. Browse to the clip, choose a poster option and select OK.

When the media clip appears in the file, drag it or use the arrow keys to position it (or right-click or use the context-menu key to make use of the Center option). Next, double-click on the movie to open the Multimedia Properties dialog (or right-click to open the context menu and choose Properties). In the Settings tab, enter alt text to describe the clip. Some users will find it helpful if you provide brief instructions on how to operate the clip, as illustrated in the image below. A screen reader will read this alt text back to the user when the clip has focus.

Now press the Edit Rendition... button and add alt text to the Rendition Alternate Text area in the Media Settings tab.

Next, choose the Playback Settings tab, as shown below.

Select the player settings you want, ensuring that the "Show player controls" checkbox is checked. Press the Add... button and specify which player(s) you want to use, as shown below. For example, if you're embedding a self-contained QuickTime (.MOV) movie, choose the QuickTime Player from the list.

If you are embedding a SMIL presentation, remember that SMIL created for QuickTime will work only on the QuickTime Player, and that SMIL created for Real will work only on the RealPlayer. (Support for SMIL in the QuickTime Player is selective, so test your presentation thoroughly before making it available publicly. Read about QuickTime's support for SMIL at Apple's Developer Connection site.) Because the QuickTime Player and RealPlayer both claim the .SMIL extension, specifying which player to use will avoid a player-fight when the user starts the movie. Also note that while various Windows Media formats are supported in PDF, those captioned with SAMI currently are not.

Press OK to return to the Multimedia Properties window, then select the Appearance tab. Choose the border options you want, then select the Actions tab. For maximum flexibility, select Mouse Up as the trigger, which allows activation using either the mouse or keyboard, and set the Select Action menu to Play Media. Click once on the rendition in the Actions menu, and then press the Edit button. Choose "Play" and then press OK. Press the Close button to save your choices and close the dialog.

Below is an image of an embedded QuickTime movie in a PDF e-book. Note the visible captions.

When embedding multimedia in a PDF e-book, ensure that the clips can be controlled by all users. Making the player controls visible, for example, allows mouse users to easily manipulate the clip (users can also just click anywhere on the clip to play or pause it). By default, keyboard users can control a clip by tabbing to it to bring it into focus, then pressing P to pause/play, S to stop and rewind completely, and the right and left arrow keys to move forward and backward, respectively. These commands are the same regardless of the multimedia format used.

Depending on the multimedia format, authors can also add controls directly to the movie. QuickTime, for example, can accommodate buttons directly on the user interface which can be programmed to toggle captions and audio descriptions on and off, as illustrated in the image below.

See Technique H2.3 for instructions on adding buttons to QuickTime movies. Once the controls have been added to the movie, it can be embedded into the PDF e-book as with any other clip, described above.

Informing the user about keyboard controls via a page of access instructions or even through alt text (both of which are included in the e-book and DTB samples available at the Beyond the Text Web site) will aid screen-reader users or anyone who prefers to use the keyboard rather than a mouse. Consider placing a link to the instructions from the title page as well as the table of contents so users will find them immediately upon opening the book.

Be aware that some screen readers, such as JAWS, may make use of keyboard commands that conflict with some of Adobe Reader's keyboard shortcuts. For example, if JAWS is in use when a multimedia clip is playing, the P, S, left and right arrow keys cannot be used to control the clip. Instead, the user must first invoke JAWS' pass-through mode (Ins+3) before pressing the appropriate player-control key. (Window-Eyes, another popular screen reader, does not require users to invoke pass-through mode when controlling embedded clips in PDF e-books.) It is therefore imperative that you test the e-book for conflicts with screen readers before publication.

Technique I1.2
Link to multimedia from a PDF e-book

Relative to the embedding process, linking to multimedia clips is simple: just create the links to the clips when preparing the source documents for the e-book. When the source is converted to PDF, the links will remain intact. However, it's always a good idea to check Acrobat's work: open the document in Acrobat, choose the Link tool from the Tools/Advanced Editing menu and then double-click the link text to open the Link Properties dialog box. You can also right click on the link and choose Properties from the context menu. Select the Actions tab and verify that "Open a Web link" appears in the Actions list (and that the URL is correct), as shown here.

If Acrobat has specified an incorrect action, select the action in the list and press the Delete button. Open the Add an Action drop-down menu, choose "Open a Web link" and press the Add... button. Type the URL into the edit field that appears, as seen here:

Press the OK button, and then press the Close button to close the Link Properties dialog box. Now, when the user selects the link, the clip will be launched in the appropriate player.

Choosing this method of integrating multimedia will make for a smaller document if the clips are to be played from a server, but will require the user have access to the Internet while reading the e-book. A safer alternative may be to deliver the multimedia with the e-book (in a ZIP archive, for example), linking to the clips stored on the user's computer.

In addition to keeping the e-book's size to a minimum, externally linked multimedia has accessibility advantages. Some screen-reader users may prefer to control a multimedia clip in its native environment, rather than using the unfamiliar commands necessary with an embedded clip. Additionally, authors can take advantage of the caption or audio-description support found in QuickTime, Real and Windows Media players, as well as the sophisticated layout and timing advantages of languages like SMIL.

As with embedded movies, consider adding caption or audio-description controls to the movies you're linking to. This process is described in Technique H2.3.

Technique I1.3
Link to embedded multimedia in a PDF e-book

A hybrid option combines both linked and embedded multimedia: the movie appears to be embedded in the e-book but is actually linked from another location. Rather than creating a text link to launch a clip in a separate player, follow the steps for creating embedded multimedia, with one exception: when choosing the media source, type a URL into the Locations edit field in the Add Movie dialog box, as shown in the image below.

When the clip is played by the user, it will appear to be embedded when in fact it is playing from a server. The clip can be controlled with a mouse or with the same keyboard shortcuts used for embedded multimedia. A distinct advantage to this approach is that the e-book experience is contained within a single document while keeping the document as small as possible. And as long as the multimedia is properly tagged and clearly identified, it can be located and activated by the user.

Technique I1.4
Make multimedia in a PDF e-book locatable

Just as important as providing accessible multimedia is providing a method for locating the clips. One way to help users is to create a table of contents containing links directly to each clip. This may be done within the body of the source document, so that when the conversion to PDF takes place the table of contents is created along with the rest of the e-book. Another method is to create a table of contents using Acrobat's bookmarking capabilities, as described below.

1. Open the document in Acrobat and choose View/Navigation Tabs/Bookmarks, or press F6 to open the navigation pane.
2. Choose the Bookmarks tab.
3. In the document pane, move to the first location where you want to place a bookmark, then press Ctrl+B or, from the Options menu in the navigation pane, choose New Bookmark.
4. In the navigation pane, give the bookmark a name and press <Enter>.

Below is a picture of an e-book showing bookmarked embedded multimedia.

For easy identification, identify the multimedia as such in the bookmark: for example, "Movie: 'Oh, No, It's Broken'". When the user selects the bookmark, the focus in the document pane will shift to the bookmarked point. Selecting a bookmarked movie will also invoke the default action associated with the clip, so if you have selected "play" as the trigger (as described earlier), the clip will begin playing when chosen from the bookmarks list.

When identifying linked multimedia, screen-reader users will find it helpful if the link text states that the clip will open in an external player. For example, "Play the movie 'Oh, No, It's Broken' (opens in Windows Media Player)" is more informative than "Play the movie."

Checkpoint I.2
Integrate accessible multimedia into LIT e-books

Microsoft Reader does not support embedded multimedia (although it does support embedded images). To give users access to video or audio clips, you must link to the multimedia instead. The multimedia cannot be local (resident on the user's computer); instead, it must be accessed via http, meaning it will be located on a remote server. Linked multimedia takes up minimal space in the document (resulting in smaller e-books) and is launched in an external player appropriate to the clip's format. However, the user must have an Internet connection to play the movies.

Technique I2.1
Link to multimedia from a LIT e-book

Creating links in the LIT format to external multimedia is no different than creating links to other resources, such as Web pages: simply insert the link when you are creating the source document. If HTML is your source, use the a element as you normally would:

If Word is your source, use Word's Insert Hyperlink function (Ctrl+K or Insert/Hyperlink menu). When you convert the Word file into the LIT format the hyperlink will be converted as well. See Guideline D2.2 for information on applications used for creating e-books compatible with the Microsoft Reader.

Microsoft Reader only links to http sites, which will not cause problems when launching Windows Media Player or the RealPlayer. However, you may have a problem when linking to QuickTime movies. QuickTime will automatically open a linked movie in a browser using the QuickTime plug-in, not the stand-alone player. Because screen-reader control of an embedded movie player is inadequate, authors should specify that the movie be opened using the QuickTime Player. This is accomplished via the use of the QTL extension. A QTL (QuickTime link) file is simply a text file that points to the actual QuickTime movie. Its advantage is that the extension forces the movie to open in the QuickTime Player.

To create a QTL file, open a blank document in a text editor and enter the following information, replacing mymovie.mov with the name of the source file:

Save this text file with the extension .qtl. In the above example, the autoplay="true" instruction forces the movie to begin playing when the player launches. If you do not want the movie to automatically play, set the value to "false" or omit this parameter altogether. Read the full list of QTL parameters to learn more about controlling the movie's behavior.

When identifying linked multimedia, users will find it helpful if the link text states that the clip will open in an external player. For example, "Play the movie 'Oh, No, It's Broken' (opens in the QuickTime Player)" is more informative than "Play the movie."

To help readers become familiar with the accessibility features you have included in the e-book, provide a set of access instructions at the beginning of the book. Within these instructions you can tell users about navigational structure as well as information about multimedia clips (how to control them, for example, or how they are indicated in the book). Also ensure that the access instructions are available from the table of contents. Consider placing a link to the instructions from the title page, too, so users will find them immediately upon opening the book. You can see an example of access- instruction links embedded in a LIT e-book in the images below, or you can download one of the LIT e-books from the Beyond the Text site.

Checkpoint I.3
Integrate accessible multimedia into OEBPS-format e-books

OEBPS-formatted materials can be read by any reading system that supports the format. There are at least three native OEBPS-format e-book readers — Mentoract Reader (still in beta), eMonocle and the OpenBerg Reader (still in beta) —, meaning they render native OEBPS publications, just as a Web browser reads HTML files directly. A number of distilled formats also exist, such as Microsoft's LIT, MobiPocket's PRC, and eBook Technologies' IMP. These are optionally DRM-restricted e-books created directly from OEBPS source files. These reading systems will not, however, read native OEBPS files themselves.

Although OEBPS itself can embed multimedia using the <object> element, most available OEBPS reading systems do not actually support embedded video or audio clips yet. However, authors can link to multimedia presentations outside the book, either locally or remotely. Linked multimedia takes up minimal space in the document (resulting in smaller e-books) and is launched in an external player appropriate to the clip's format. However, the user must have an Internet connection to play the movies if they are server-based, or must download and install the movies before reading the book if they are linked locally. Keep in mind that QuickTime movie links should refer to a QTL file, not the MOV file directly. See Technique I2.1 for more information about creating QTL files.

Technique I3.1
Link to multimedia from OEBPS e-books

Creating links in an OEBPS publication to external multimedia is no different than creating links to other resources, such as Web pages: simply insert the link when you are creating the source document:

Here are images of linked multimedia inserted into two native OEBPS readers, OpenBerg Reader and Mentoract Reader.

You can see an example of links embedded in an OEBPS e-book by downloading one of the OEBPS e-books from the Beyond the Text site.

When identifying linked multimedia, users will find it helpful if the link text states that the clip will open in an external player. For example, "Play the movie 'Oh, No, It's Broken' (opens in the QuickTime Player)" is more informative than, "Play the movie."

To help readers become familiar with the accessibility features you have included in the e-book, provide a set of access instructions at the beginning of the book. Within these instructions you can tell users about navigational structure as well as information about multimedia clips (how to control them, for example, or how they are indicated in the book). Also ensure that the access instructions are available from the table of contents. Consider placing a link to the instructions from the title page, too, so users will find them immediately upon opening the book.

Checkpoint I.4
Integrate accessible multimedia into handheld e-books

There is currently no handheld e-book software that supports embedded video or audio. Therefore, authors who wish to include multimedia in handheld e-books must rely on linking. There are several e-book readers for both Palm and Windows Pocket PC/Mobile OSes, but their support for linking is not always consistent from one OS to another, and some permit internal linking only, not external linking. Below is a table illustrating the multimedia support in three popular handheld e-book reading applications. There is no native OEBPS reader for either the Palm or Windows Mobile OS.

Summary of three handheld software e-book readers and their multimedia support.

	OS	Multimedia support	Comments
Adobe Reader	Palm, Windows Mobile	Palm: none Windows Mobile: linked	Multimedia must be downloaded first
Microsoft Reader	Windows Mobile	Palm: n/a Windows Mobile: none	Multimedia can be linked via http only
MobiPocket Reader	Palm, Windows Mobile	Palm: linked Windows Mobile: none	Multimedia must be downloaded first

Note that the Adobe Reader for Pocket PC can link directly to a multimedia clips without the user having to manually open a separate player, but the user must download the multimedia files to the device prior to opening the book. Installation of the multimedia files can be done while synchronizing the e-book from a desktop machine to the handheld device.

Authors wishing to integrate multimedia into Palm e-books can use the MobiPocket Reader. While MobiPocket will permit external hyperlinking to multimedia, the process of playing a movie requires manual intervention: when the user taps the link the device will download the clip, but then the user must manually open a multimedia player and then open the clip from within the player itself.

Technique I4.1
Integrate multimedia into Palm e-books

Integration of multimedia into Palm e-books can be accomplished using the MobiPocket Reader in conjunction with a Palm-compatible media player, such as the Kinoma Player. Kinoma-format movies can be created using the Kinoma Producer. Kinoma Producer requires the use of QuickTime Player, so the source media must be compatible with QuickTime. Formats include, but are not limited to, MOV, MP4, MP3 and AVI. Keep in mind that the target device must have the Kinoma Player installed ($19.99, although older versions are free).

No Palm-compatible multimedia player has provisions for toggling on and off caption or description tracks, so the only method for providing accessible movies is to supply open-captioned and/or open-described clips. In the Beyond the Text project, staff created a sample Palm-OS e-book with integrated multimedia in the MobiPocket (PRC) format, linking to Kinoma movies.

To create multimedia for use on a Palm device, first install the Kinoma Producer. Create the source media in a QuickTime-compatible format, such as MOV, and use MAGpie to add captions or audio descriptions to the video clip.

After authoring captions and descriptions in MAGpie as described in Technique H2.1, export the presentation as SMIL for QuickTime. Then follow the procedure described in Guideline H for embedding caption and description tracks into QuickTime movies. Save the movie as self-contained, making sure that the caption track and audio-description track (if you created one) are on before you save the file. After saving the file, open the Kinoma Producer and convert the movie to the Kinoma format, specifying the target handheld device(s), then upload the clip to a server.

Because e-books in the MobiPocket format (PRC) are essentially OEBPS-format documents that are protected by DRM, you can author your source material in formats such as HTML, Word or text before converting them to PRC, where software will create the OPF file for you. (See Checkpoint D2 for discussion about OPF files.) Insert hyperlinks to movies where appropriate, with the URL being the Kinoma-format movie on your server.

To convert the source materials to PRC, use MobiPocket Creator Publisher Edition ($149), a full-featured application for converting and distributing content. You can also use MobiPocket Creator Home Edition ($29.95), which is best suited for personal use.

After converting the source, test the e-book by transferring it to a Palm device. The image below shows a page from a PRC e-book for MobiPocket Reader, with a hyperlink to a movie.

When the user taps on the link, the Palm device will download the movie and place it into the Kinoma Player's library, as shown in the image below.

The user must now open the Kinoma Player and choose the movie from the library. Below is an image showing the Kinoma Player playing an open-captioned video.

Download a sample PRC e-book with accessible multimedia to see a working example of this type of e-book and accessible multimedia.

Technique I4.2
Integrate multimedia into Windows Pocket PC e-books

As with Palm-OS devices, Windows Pocket PC/Mobile devices can display e-books that integrate linked multimedia. However, this OS makes it somewhat more convenient to link to and play media files. The Beyond the Text project created several sample e-books that demonstrate how a PDF e-book (opened with the Adobe Reader) can link to multimedia on a handheld device. PDF was chosen because Reader will link to local as well as remote multimedia. Handheld e-book software such as Microsoft Reader and MobiPocket Reader do not support external hyperlinking nor will they launch multimedia players or files.

There are several multimedia players available for Windows Pocket PC/Mobile, including (but not limited to) Windows Media Player, RealPlayer, and PocketTV. Because no handheld player currently offers the ability to toggle caption or audio-description tracks on and off, multimedia integrated into mobile e-books must be open captioned or described.

Two applications are required to create accessible multimedia for a Windows Pocket PC/Mobile device: QuickTime Player and Windows Media Encoder. For illustrative purposes, this example assumes an eventual target of Windows Media (WMV).

Because Windows Media Player for Windows Pocket PC/Mobile doesn't play SAMI captions or audio descriptions, you must first author the captions and descriptions in a format that can embed these accessibility features. You must then save the entire movie with open captions and descriptions before converting the presentation to WMV. QuickTime-supported formats (MOV and MP4, for example) work well as source files because QuickTime allows the embedding of caption or description tracks.

Start by adding captions and audio descriptions to the MOV source with MAGpie as described in Guideline H. Export the presentation as SMIL for QuickTime and then follow the procedure described in Checkpoint H2 for embedding tracks in QuickTime movies. When you're finished embedding the tracks, save the movie as self-contained, making sure that both the caption track and audio-description track (if you created one) are turned on before you save the file.

Next, export the entire presentation to an AVI clip:

1. Open the accessible movie in the QuickTime Player.
2. Choose File/Export, then Movie to AVI from the Export drop-down list, as shown below.

   

3. Accept QuickTime's default settings, or press the Options button to set your own parameters.
4. Press the Save button. QuickTime will convert the movie to the AVI format, complete with open captions and descriptions.

Next, open Windows Media Encoder and follow the steps described below.

1. Choose File/New.../Convert a file. Using the Wizard, browse to the AVI you exported in the QuickTime Player and then browse to the output folder where you want the WMV movie saved.
2. In the next dialog, choose the target device. For this example, the target is Pocket PC, as shown below.

   

   After selecting a target, press Next.
3. Choose whether you want to encode the movie as standard or wide-screen video, and choose CD- or voice-quality audio. Press Next.
4. Enter optional display information (title, author, etc.) and press Next.
5. Review the settings in the summary window. If you need to make changes, press the Back button. Otherwise, press Finish to begin the encoding session.

Once the session is done, transfer the movie to your mobile device and test it with Windows Media Player. If you find that the movie is too small or too large, you can re-encode it with custom dimensions: go back to Windows Media Encoder, choose View/Properties Panel from the menu bar, then select the Video Size tab. In the Resize area, select Custom from the Method list and specify the dimensions, as shown below.

Close the dialog when you're finished and press the Start Encoding button to re-encode the video. Transfer and test the movie again; repeat as necessary until you are satisfied with the size.

After you're done encoding all the movies, create the e-book for use on a handheld device, such as Acrobat Reader for Pocket PC which provides support for linked multimedia. (Neither Microsoft Reader and MobiPocket Reader support external linking on this OS.) See Technique D2.1 for details on creating accessible PDF documents, and also read about adding linked multimedia to a PDF e-book. It is especially important that you place the multimedia to which you are linking in the same directory as the PDF file. Convert the text to PDF using Adobe Acrobat as described in Technique I1.2, then transfer the document and the movies, all in a single directory, to a handheld device for testing.

Open the e-book using Acrobat Reader for Pocket PC. Test a movie by tapping on the link. You may be asked to confirm that you want to open a movie. Choose Yes (or Yes to All), then the movie will open in Windows Media Player.

Guideline J
Provide accessible multimedia in Digital Talking Books (DTBs).

Strictly speaking, a digital talking book (DTB) is a multimedia representation of a print publication that provides access to the text through digitally recorded human voice or synthetic text-to-speech technology. DTBs are largely aimed at blind or visually impaired users, but are also used to help improve reading and comprehension skills in students with learning disabilities. They provide various levels of navigation, from partial to complete, and can be read on dedicated hardware devices or on software players that run on Windows or Macintosh computers. There is also at least one DTB player for Windows Pocket PC/Mobile devices. See the comparison chart at NCAM's Beyond the Text site for a listing of available devices.

There are six types of DTBs, defined in the current DAISY/NISO Standard:

1. Audio with title element only: DTB without structure. This is the simplest class of DTB and is used for books where structure will not be applied.
2. Audio with NCX (an XML file that defines the structure of the DTB) only: DTB with structure. The NCX, if present, contains only the structure of the book and may contain links to features such as narrated footnotes, etc. This is the most common form of DTB and is ideal for stand-alone players.
3. Audio with NCX and partial text: DTB with structure and some additional text. The XML textual-content file contains only the structure of the book and the text of components where keyword searching and direct access to the text would be beneficial, e.g., index, glossary, etc.
4. Audio and full text: DTB with structure and complete text and audio. This form of a DTB is the most complex but provides the greatest level of access. The XML textual-content file contains the structure and the full text of the book. The audio and the text are synchronized.
5. Full text and some audio: DTB with structure, complete text and limited audio. The XML textual content file contains the structure and the text of the book. The audio files contain recordings of parts of the text. This type of DTB could be used for a dictionary where only pronunciations were provided in audio form.
6. Text and no audio: E-text with structure. The XML textual-content file contains the structure and text of the book. There are no audio files.

While accessible in-line audio clips can be used in any player capable of playing recorded speech, players that support external linking (that is, hyperlinks leading to external sources such as audio or video clips) can, in theory, integrate either audio or video by launching the media in a stand-alone player. Not all reading devices support linking, however, so authors must be sure to provide a fallback for devices that lack this capability. And when it comes to embedding video elements into DTBs, there are currently only two software DTB players that support this feature: Dolphin's EaseReader and Aequus Technologies' AspireReader.

A question that often arises is whether to provide human-recorded or synthetic speech (i.e., text-to-speech) in a DTB. The most sophisticated DTB-creation software allows the author to incorporate either or both, whereas some applications may only accommodate text-to-speech integration. Human speech sounds the best to most human ears, but is time-consuming and expensive to create: narrators must spend hours carefully reading and recording text, ideally in soundproof rooms. The recordings must then edited and carefully checked for accuracy before being integrated into the DTB. In the case of a Type 4 DTB, text and audio must also be synchronized, which adds to the workload. The result, however, is a completely natural-sounding, easy-to-listen-to audio book.

Synthetic speech, on the other hand, can be created in a fraction of the time it takes to record, edit and process human speech. Some DTB-creation software can import the text of the book, automatically generate structured, searchable text with synchronized speech in a matter of minutes compared to the many hours it takes to do the same with human speech. Many DTB players can read text using built-in text-to-speech software, so the author of the book need not even include audio files in the package (Type 6 DTB), simplifying the process even further.

In recent years, synthetic speech technology has undergone improvements leading to voices that sound less robotic and artificial. It is generally believed that these improvements make them easier to listen to for long periods of time. There has been little formal research thus far to determine user preferences of human vs. synthetic speech, but the National Library for the Blind (NLB) has conducted one survey investigating the acceptance of leisure-reading material using synthetic audio synchronized with full text and navigational structure. Their findings, as well as anecdotal evidence, suggest that human speech is generally preferred over synthetic, and that human speech may be best for leisure reading (e.g., novels or magazines) whereas synthetic speech may be sufficient for all other materials (such as textbooks, technical documents, bank statements, medical records, etc.). Objective research to explore the efficacy of synthetic vs. natural speech will be necessary to definitively prove this, however.

There are several applications available for creating DTBs, ranging in price from free to several hundred dollars. Visit the Daisy Consortium's Production Tools page for more information. At one end of the spectrum is the free application DTBMaker, available in a simple on-line version that imports text and generates a DTB containing structured text and synthetic speech. (Downloadable versions are available as well.) The user need only follow basic markup instructions before uploading the file. When DTBMaker is finished creating the book, the user is notified via e-mail that the materials can be downloaded in a ZIP archive. The DTB can then be opened in any DAISY-compatible player. If the source files contain links to external multimedia, DTBMaker will keep those links intact when it performs the DTB conversion.

At the other end of the spectrum is the Dolphin's EasePublisher, a sophisticated DTB-creation package. EasePublisher can record, edit, synchronize and process human speech, create synchronized text-to-speech DTBs, edit text, create different styles and perform a multitude of other functions. NCAM's Beyond the Text project created a number of sample DTBs containing accessible multimedia using this software.

Note: the checkpoints below describe the bare basics for recording and synchronizing human speech, or generating and synchronizing synthetic speech, using EasePublisher 1.02. For complete, step-by-step details about recording and processing audio, see the Help files that are associated with EasePublisher.

Also note that this guideline does not provide anything beyond a very basic summary about the creation and structuring of DTBs themselves. Rather, the information here is focused on the integration of multimedia into DTBs. For complete information about DTB markup and structure, authors are encouraged to read the following two resources:

• DAISY/NISO Structure Guidelines
• The DAISY/NISO Standard

Checkpoint J1
Add in-line multimedia to DTBs

All DTBs that contain audio can accommodate described, in-line audio clips (that is, those that are pre-recorded and then inserted directly into the structure of the book). For example, a DTB that is created with recorded speech will treat accessible audio clips as just another audio element in the book, and when the book is played back with recorded speech the described clip will be played automatically by the DTB reader as with any other audio element.

Technique J1.1
Integrate in-line multimedia in DTBs

After the source files (e.g., HTML or plain text) of the book have been prepared, use EasePublisher 1.02 to convert the text to a DTB. You may synchronize the text with human-recorded speech or convert the text to synthetic speech. Both processes are briefly summarized below (for full details, see the Help files that are associated with EasePublisher).

To create and synchronize human speech:

1. Click on the first sentence of the text.
2. Press Right-Ctrl+F5 to launch the recorder, then begin speaking the text into a microphone.
3. After you complete the first sentence, immediately press Ctrl+Enter to move the on-screen focus to the next phrase. Speak the text into the microphone.
4. Repeat this process until the entire book has been recorded.
5. Press Spacebar or F5 to stop the recording at any time.

To create and synchronize synthetic speech:

1. Click on the first sentence of the text.
2. From the Tools menu, choose TTS Encode
3. Choose Settings..., then select the voices you want to use for differentiating headings from body text. Adjust the voice settings as desired, choose an audio format, then press OK.
4. Open Tools/TTS Encode again, then choose Whole Project to convert the entire book to synthetic speech, or choose Current Chapter to convert just the current chapter.
5. After the conversion is complete, test it by pressing the spacebar to start and stop the playback of audio. To re-record, delete the audio from the waveform area and repeat the steps above.

Regardless of which approach you choose, the end result will be a project that looks similar to the one shown below, with both the book text and audio waveforms visible on the screen.

To add an in-line described audio clip, first record and edit the audio clip in a separate application such as NCAM's MAGpie, Audacity or Sony's Sound Forge. Save the file as MP3 or WAV (the former provides the most compact file size), then follow the steps below.

1. In EasePublisher, click once on the text of the phrase that occurs immediately prior to the insertion point of the described audio clip.
2. Press the spacebar to play the audio to the end of this phrase. Press the spacebar to stop the playback at the end of the phrase. Use the right and left arrow keys to precisely position the cursor at the end of the waveform, if necessary.
3. From the Project menu, choose Import/Import audio file(s)...
4. Browse to the audio file you want to insert. Select the file and press Open.
5. In the Import Audio dialog, double click on the audio file.
6. From the Audio File Import Settings dialog, choose "insert at pos". Press OK.
7. Press the Start Import Audio button. The clip will be imported and inserted into the timeline at the cursor position.
8. Click again on the text of the phrase that precedes the described audio clip, and press the spacebar to listen to your work. If the insertion was not successful, delete the described clip and re-import.
9. Repeat these steps for subsequent described audio clips.

Once you have finished preparing the DTB (cleaning up and formatting all text, importing audio files, etc.), prepare the book for playback on all devices (note: these instructions describe a simplified process for building a project. For full details, see the Help files that are associated with EasePublisher):

1. Press F9 to open the Build Options dialog.
2. Choose Full Text from the "Build distribution as..." list at the bottom of the window if you want the book to contain full text as well as audio (ideal for software readers that display text); choose NCC Only if you only want the NCC file (similar to a table of contents) plus audio (sufficient for hardware players that do not display text).
3. Choose +build/encode from the Build Options list at the bottom of the window. (This will clean up any extraneous audio files in addition to encoding the book for distribution.)
4. Select the options you want from the other tabs, being sure to specify a folder target in the Folders tab.
5. Press the Start button.
6. Test the presentation by opening the .NCC file in a software player, or by copying the distribution files onto a CD for playback on a hardware player.

Technique J1.2
Integrate linked multimedia into DTBs

Before creating a DTB that contains links to external or local multimedia, take care to note that not all DTB players (e.g., hardware players) support linking. See the chart at NCAM's Beyond the Text site for a listing of available devices and their linking capabilities. If you want to provide a DTB with links, it may also be a good idea to provide the same book with in-line, accessible audio clips as an alternative for those readers who do not have a player capable of activating links.

To create a book with links, code the links in the source documents as any HTML hyperlink: i.e., <a href="http://mywebsite.org/mymovie.qtl">Movie: How to Build a Doghouse</a>. You can point to video or audio files stored on a remote server, bearing in mind that the user will have to have access to the Internet in order to access remote multimedia, or to files stored on the reader's local hard drive, which are delivered as part of the DTB package downloaded by the user (e.g., in a .zip archive).

Next, follow the instructions for converting source files to a DTB. Add human-recorded or synthetic speech, and then build the project for distribution. Always test the book by opening it in a DTB reader that supports linking.

Technique J1.3
Integrate embedded, accessible multimedia into DTBs

A DTB with embedded, accessible multimedia represents perhaps the most flexible type of digital talking book. Authors may create structured, searchable text and can integrate audio or even video right into the book.

The irony of embedding video into a DTB must be acknowledged, yet it is not an unreasonable proposition given that a) it can be done today, and b) it will serve a useful purpose as DTBs enter the mainstream. Students could, for example, read a biology text and watch (or listen to) a movie describing cell division, all without having to open an external application to play the multimedia. And embedded movies can be captioned as well as described, something useful for deaf or hard-of-hearing users with or without learning disabilities. Embedding movies can eliminate the need for an Internet connection — the movies are downloaded and installed with the rest of the DTB — and keeps the book portable and easy to use.

One obstacle to embedding multimedia (video or audio) directly into a DTB is support: no hardware DTB player currently on the market has any accommodation for embedded multimedia, let alone visual display. There are, however, two software players that support the integration of embedded audio or video clips with captions and audio descriptions: Dolphin's EaseReader and Aequus Technologies' AspireReader. Both players can play embedded multimedia in QuickTime, Windows Media and Real formats; all three of these formats can accommodate captions, and two (Real and QuickTime) can accommodate descriptions. SMIL (Synchronized Multimedia Integration Language) presentations for both QuickTime and Real can even be embedded into DTBs. The usability of embedded clips may be limited at this point, however — these players do not yet support convenient control of the embedded multimedia players for blind or keyboard-only users — but future versions of DTB players may offer improved support.

Multimedia in each of the three major formats (Real, QuickTime and Windows Media) can be embedded in a DTB through the use of the <object> element, as described in the following three techniques.

Authors embedding video clips should be sure to include the <prodnote>, or producer's note, element. <prodnote> contains language commonly used to provide verbal descriptions of visual elements (e.g., charts, graphs or videos), to supply operating instructions, or describe what the video is showing for users who cannot play the video. A <prodnote> could, for example, provide a one- or two-sentence summary of the video embedded in the DTB as well as an alternative URL for the user to access the presentation via a browser or multimedia player. The <prodnote> can be displayed visually and/or rendered in audio. See the DAISY/NISO Structure Guidelines for more information about using <prodnote>. <prodnote> is shown in the examples below.

Technique J1.3.1
Embed accessible QuickTime multimedia into DTBs

First, add captions or audio descriptions to your QuickTime presentation and embed them or create a SMIL presentation. You may even add control toggles for the captions and audio descriptions.

To embed the QuickTime clip, add <object> to the HTML source documents, as shown below.

classid and codebase are mandatory; enter them exactly as shown above. You must also enter the height and width of the movie. QuickTime supports many different parameters for controlling the behavior and appearance of embedded movies. Three are illustrated in the sample above and are explained below.

• src (required): defines what media to play
• autoplay: defines whether or not the media will play upon loading. It is recommended to set autoplay to a value of false so the movie doesn't begin playing when the book is loaded.
• controller: defines whether or not the player's controls are visible. It is recommend to set this value to true. Note that you must add 16 pixels to the height attribute to accommodate the controller.

<prodnote> is used to illustrate how to describe the embedded video for users who do not have a DTB reader that supports this type of multimedia. Including the URL in the <prodnote> instructs users how to access the movie in an alternative setting, such as a stand-alone multimedia player.

Next, follow the instructions for converting source files to a DTB. Add human or synthetic speech, and then build the project for distribution. Finally, test the book by opening it in a DTB reader that supports embedded multimedia.

Technique J1.3.2
Embed accessible Real media into DTBs

First, add captions or audio descriptions to your Real presentation and create a SMIL presentation. To embed the Real clip, add <object> to the HTML source documents, as shown below.

classid is mandatory; enter it exactly as shown above. You must also enter the height and width of the movie. Note that the controller and the movie itself are two separate elements. RealPlayer supports many different parameters for controlling the behavior and appearance of embedded movies. Three are illustrated in the sample above and are explained below.

• console: specifies whether multiple controls should be linked together
• controls: embeds the RealPlayer's controls in the page
• autostart: defines whether or not the media will play upon loading. It is recommended to set autoplay to a value of false so the movie doesn't begin playing when the book is loaded.

<prodnote> is used to illustrate how to describe the embedded video for users who do not have a DTB reader that supports this type of multimedia. Including the URL in the <prodnote> instructs users how to access the movie in an alternative setting, such as a stand-alone multimedia player.

Next, follow the instructions for converting source files to a DTB. Add human-recorded or synthetic speech, and then build the project for distribution. Finally, test the book by opening it in a DTB reader that supports embedded multimedia.

Technique J1.3.3
Embed accessible Windows Media multimedia into DTBs

First, add captions to your Windows Media presentation and create a SAMI presentation. Note that Windows Media does not accommodate an additional audio-description track. If you wish to add audio descriptions to a Windows Media presentation you must create an additional audio track and encode it with the video and program audio, or create a program audio track that also contains integrated descriptions.

To embed the Windows Media clip, add <object> to the HTML source documents, as shown below.

classid is mandatory; enter it exactly as shown above. You must also enter the height and width of the movie. Windows Media Player supports many different parameters for controlling the behavior and appearance of embedded movies. Four are illustrated in the sample above and are explained below.

• FileName (required): defines what media to play.
• AutoStart: defines whether or not the media will play upon loading. It is recommended to set AutoPlay to a value of false so the movie doesn't begin playing when the book is loaded.
• ShowControls: defines whether or not the player's controls are visible. It is recommended to set this value to true.
• CaptioningID: determines the location of the captions. In this example, they are to be placed in <div id="captext">, which has a width of 320 pixels and a height of 60 pixels.

<prodnote> is used to illustrate how to describe the embedded video for users who do not have a DTB reader that supports this type of multimedia. Including the URL in the <prodnote> instructs users how to access the movie in an alternative setting, such as a stand-alone multimedia player.

For ideal file maintenance, and to ensure that Windows Media-compatible will always play the associated SAMI file, store the video and SAMI files in separate directories and coordinate their playback using an ASX file. The ASX file contains the paths (and other optional parameters) for the video and SAMI files, as shown below.

Read more about other elements that can be used in an ASX file in the Windows Media Library.

Note that the video and SAMI sources are contained in a single HREF, separated only by a question mark (?) without spaces. When entering the value of the FileName parameter in <object>, be sure to point to the ASX file, not the base media.

Next, follow the instructions for converting source files to a DTB. Add human-recorded or synthetic speech, and then build the project for distribution. Finally, test the book by opening it in a DTB reader that supports embedded multimedia.

Appendix 1:
Braille and Tactile Graphics Production Resources

Duxbury Systems
Provides software for braille publishers, as well as a world-wide directory of braille producers.

Other selected braille and tactile graphics production resources:

American Printing House for the Blind
Designated by Congress as the official source of educational texts (primary through secondary level) for students who are visually impaired in the United States and its possessions. It also maintains the Central Catalog, which is a listing of textbooks and other instructional materials available in large print, braille, recorded format, or tactile graphics that are produced by APH, by volunteers, and by commercial companies.

Contact:
American Printing House for the Blind
1839 Frankfort Ave.
P.O. Box 6085
Louisville, KY 40206-0085
Phone: (502) 895-2405
Toll-free: (800) 223-1839
Fax: (502) 895-1509
e-mail: info@aph.org

National Braille Press
Produces high-quality braille and tactile graphics and braille textbooks. Experienced in redesigning visual images to maximize comprehension for the tactile reader.

Contact:
National Braille Press
88 St. Stephen St.
Boston, MA 02115
Phone: (617) 266-6160
Toll-free: (800) 548-7323
Fax: (617) 437-0456

gh LLC
Produces many types of accessible documents for blind people and creates tactile graphics using its LaserLine technology.

Contact:
gh LLC
3000 Kent Ave., Suite E2-201
West Lafayette, IN 47906
Phone: (765) 775-4534
e-mail: ghinfo@ghbraille.com

PRISM
Uses Rapid Prototyping or Layered Manufacturing technology to make 3D models to improve understanding for blind students, scientists, and researchers using tactile feedback.

Contact:
PRISM: Partnership for Research in Spatial Modeling
PO Box 878609
Arizona State University
Tempe, AZ 85287
Phone: (480) 965-0483
Fax: (480) 965-9522
e-mail: prism@asu.edu

Appendix 2:
Closed Captioning and Audio Description Resources

A directory of captioning service providers is available from the Closed Captioning Web.

Major captioning service providers include:

Media Access Group at WGBH
WGBH Educational Foundation
125 Western Avenue
Boston, Ma 02134
Voice/TTY: (617) 300-3600
Fax: (617) 300-1020
e-mail: access@wgbh.org

National Captioning Institute
1900 Gallows Rd., Suite 3000
Vienna, VA 22182
Voice/TTY: (703) 917-7600
Fax: (713) 917-9878
e-mail: koconnor@ncicap.org

VITAC
101 Hillpointe Dr.
Canonsburg, PA 15317-9503
Phone: (800) 278-4822
info@vitac.com
http://www.vitac.com

Audio description service providers include:

Media Access Group at WGBH
WGBH Educational Foundation
125 Western Avenue
Boston, Ma 02134
Voice/TTY: (617) 300-3600
Fax: (617) 300-1020
e-mail: access@wgbh.org

Metropolitan Washington Ear, Inc.
35 University Blvd. East
Silver Spring, MD 20901
Phone: (301) 681-6636
Fax: (301) 681-5227
e-mail: information@washear.org

Narrative Television Network
5840 South Memorial Dr., Suite 312
Tulsa, OK 74145-9082
Phone: (918) 627-1000
Fax: (918) 627-4101
e-mail: webmaster@narrativetv.com

Appendix 3:
General Captioning Conventions

The Caption Center provides basic captioning guidelines. The brief guidelines below add specifics for digital captions (e.g., for Web- or CD-based multimedia players) and may be considered addenda to The Caption Center's general guidelines.

Additional captioning guidelines are also available from these resources:

• Closed Captioning Standards and Protocol for Canadian English Language Broadcasters
• Captioned Media Program Captioning Key

General Conventions

1. Captions should be a verbatim representation of what is being said, although you may edit out unnecessary speech (um..., ah..., er..., etc.).
2. Each caption should be composed of one or two rows and should be positioned in the bottom center of the caption region. Avoid using three-row captions except when using a speaker identification.
3. If you can fit a caption on a single row rather than two, do so.
4. Caption what is spoken: if the speaker says "string" when he meant to say "spring", for example, caption it as such.
5. Don't correct grammar-if you hear it, caption it.
6. End punctuation (period, exclamation point, question mark) indicates the end of a caption, and the next sentence starts with a new caption. For example:
   
   Preferred:
I have a weight.

The weight hangs from a rope
which is two feet long.

The rope is attached to a hook
in the ceiling.

To be avoided:
I have a weight. The weight
hangs from a rope

which is two feet long. The rope
is attached to a hook in the ceiling.


   There are occasional exceptions to this rule. For example:

   Acceptable:
Ready? Go!
 
7. Points (...) may be used to indicate a pause, an interruption or a suspension within the caption, or as end punctuation. For example:
   
   Preferred:
Now we stretch the string... no, sorry,
I mean the spring.

Preferred:
I will start the clock
and count the oscillations.

One...

two...

three...

four.
 
8. When using two-row captions, avoid formatting them so that one line is substantially longer than the other.
   
   Preferred:
We have a car, and the car
is moving at a constant speed.

Acceptable:
We have a car,
and the car is moving with a constant speed.

To be avoided:
We have a car, and the car is moving with a constant
speed.
 

Math notation

1. Generally, numbers one through ten are written as words. Anything over ten is written numerically.
   
   Preferred:
I have here six coconuts.

Preferred:
I will count 12 oscillations
once the clock is running.
 
2. Decimals should always be rendered numerically.
   
   Preferred:
The answer is 2.6.

To be avoided:
The answer is two point six.

Preferred:
The distance is 0.3 meters.

To be avoided:
The distance is zero point three meters.
 
3. Avoid mixing words and numbers in equations.
   
   Preferred:
2 + 12 = 14

To be avoided:
Two plus 12 = 14

Also to be avoided:
Two + 12 equals 14

   On the other hand, for the sake of clarity, in some cases it may be best to mix numbers and words. For example:
   
   Preferred:
The square root of (2 + 3 x 10).

To be avoided:
The square root of two plus three times ten.

4. Simple equations should be rendered with signs and numerals when possible, with spaces between characters.
   
   
   • 2x + 15y = z
   • (a + b) - c = d
   • 2 x 3 = 6
5. Because support for math notation in captions is currently very limited, anything other than simple notation must be written out in words:
   
   
   • two times the square root of five
   • R equals delta T
   • six squared
   • 15 to the sixth power
      
6. Always notate upper/lowercases in the captions as the speaker says or writes them. If an uppercase P is used in an equation, for example, use an uppercase P in the captions.

Timing conventions

1. Generally speaking, for readability and aesthetic purposes captions should be timed to change precisely with shot changes. However, a caption may cross a shot change if the caption itself doesn't change within a second of the shot change.
2. Time the captions to appear as the corresponding words are spoken. If the speaker is speaking quickly, the captions should change quickly. If he is speaking slowly to emphasize a point, time the captions accordingly.
3. If necessary, in order to increase reading time, a caption may be timed to appear slightly before the corresponding audio begins, and/or to erase after the audio has ended.
4. If there is a pause of approximately two seconds or more where nothing is being said, you may erase the caption display.

Appendix 4:
Guides to Spoken Mathematics

MathSpeak

Handbook of Spoken Mathematics: Larry's Speakeasy
Lawrence Livermore National Laboratory
P.O. Box 808
Livermore, CA 94551

National Braille Association Tape Recording Manual
Volunteer Tape Recording Manual
National Library Service for the Blind & Physically Handicapped
Library of Congress
Washington, DC 20542

Appendix 5:
General Audio Description Guidelines

No general guidelines are publicly available for writing audio descriptions. The information below relates specifically to audio descriptions written for the Access to PIVoT project and is presented as an example of how description writing was approached for on-line physics lectures and tutorials. It is not intended to be a complete tutorial on writing audio descriptions.

1. Watch the entire presentation before writing any audio descriptions. This will help you determine where descriptions are necessary, how much information must be added to the original presentation, and if extended descriptions will be necessary.
2. You will also find it helpful to watch the presentation with the monitor turned off, or with your eyes closed, listening carefully to the audio. If you can't understand something the speaker is talking about, neither will a blind or visually impaired student.
3. Identify the points in the presentation that need audio descriptions. If the speaker speaks aloud what he is writing on the board, or if he sufficiently describes a picture he has drawn, an audio description may not be necessary. However, if he fails to speak written information fully or describe a drawing completely, or if he makes a reference to location (e.g., "up here," "over there," "look at this," etc.), you must supply a description.
4. When writing descriptions, first determine if the additional information can be written to fit within an appropriate natural pause in the program's sound track. If no such pause exists, you must insert an extended description at that point. Extended descriptions may be of any length, but keep them as concise as possible while still conveying all necessary information. You may find it helpful to first write a full description and then edit it to an appropriate length, rather than writing and editing simultaneously.
5. Use vocabulary appropriate to the subject matter and to the audience.
6. When writing descriptions for a young audience, use age-appropriate descriptive language. Include complex concepts or vocabulary several times, within context, throughout the description. Write in short sentences for better comprehension.
7. Insert each description, extended or not, at a natural point in the movie's timeline. Don't cut off the speaker in mid-word; instead, take advantage of any brief pause. Even a pause between words or sentences will suffice as long as the description is not out of context at its insertion point. You may "predescribe" (that is, insert the description slightly before the action occurs on screen) if it clarifies the situation.
8. Use a specialized descriptive language, such as MathSpeak, for scientific and mathematical expressions.
9. Use MAGpie, a free application available from NCAM, to write, edit, time and record descriptions for digital video. Be sure to record the descriptions in a quiet room, speaking naturally and clearly into the microphone.

Acknowledgements

We are indebted to the members of our advisory board who provided valuable input throughout the project. They are:

James Alexander, Director of E-books, Adobe Systems Incorporated

Margaret Bausch, Research Assistant Professor; Project Director, National Assistive Technology Research Institute; President, Technology and Media Division of CEC, University of Kentucky

Robert Brink, Program Manager for Accessibility, eMerging Technologies Division, Microsoft Corporation

Norman Coombs, CEO, Equal Access to Software and Information (EASI)

Steve Dreisler, Executive Director, American Association of Publishers, Inc., School Division

William M. Jolley, Secretary General, DAISY Consortium

Bob Regan, Accessibility Product Manager, Macromedia, Inc.

Mary Anne Siller, National Program Associate in Education, Textbooks and Instructional Materials Solutions Forum, American Foundation for the Blind

Jonathan Simeone, President, National Alliance of Blind Students

Claude Stout, Executive Director, Telecommunications for the Deaf, Inc.

Barbara J. Wagreich, software engineer

We would also like to thank the following people for their assistance and advice:

Nick Bogaty, Executive Director, International Digital Publishing Forum (IDPF)

Garth Conboy, President, eBook Technologies, Inc.

Mark Hakkinen, University of Jyväskylä, Finland; Independent Consultant, Lawrenceville, NJ

Jon Noring, OpenReader Consortium

Finally, NCAM would like to thank the many dozens of people who volunteered to test and comment upon the sample e-books and DTBs created for the Beyond the Text project.