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 mis