IMS Guidelines for Developing Accessible Learning Applications Version 1.0 White Paper

Short Table of Contents

An extended Table of Contents, with a full listing of sub-categories within each section, is provided below the Short Table of Contents.
1. Introduction

2. Primer on Accessibility

3. Principles for Accessibility in Online Distributed Learning

4. Using XML for Accessibility

5. Guidelines for Accessible Delivery of Text, Audio, Images, and Multimedia

6. Guidelines for Developing Accessible Asynchronous Communication and Collaboration Tools

7. Guidelines for Developing Accessible Synchronous Communication and Collaboration Tools

8. Guidelines for Developing Accessible Interfaces and Interactive Environments

9. Guidelines for Testing and Assessment

10. Guidelines for Developing Accessible Authoring Tools

11. Guidelines for Topic Specific Accessibility

Appendix A - Legal Issues for Accessible Distance Learning

Appendix B - Resources

About This Document

Revision History

Index

Table of Contents

1. Introduction

The evolution of the Internet and other technologies has led to tremendous growth in opportunities to teach and learn outside of the traditional classroom. Over the past decade, the Internet has brought learning "online" and offers many advantages: it is convenient, available at any time of the day, and can be accessed nearly anywhere in the world. Clearly, online or distributed learning, offers tremendous potential to increase the availability and convenience of education. And if the technologies behind distributed learning are made universally accessible, it will also have the potential to reach a significant percentage of those with disabilities.

As with many types of products and technologies, including those used in online distributed learning, people with disabilities may be inadvertently excluded if accessibility is not considered and incorporated into products and technologies. If steps are not taken to incorporate accessibility into distributed learning, people with disabilities may be excluded from the many benefits offered by online technologies. However, accessibility is not only of concern to those with disabilities. The potential for online distributed learning expands when developers embrace the widest possible range of individual learning styles, preferences, and abilities.

Accessible design grants a wider range of learners more options and greater flexibility in learning. Inclusive design strategies, also known as "universal design," can help meet the varying needs and limitations of end users, including limitations created by available computer power and bandwidth. Universal design can make stand-alone courseware, Web-based e-learning systems, and other content more accessible to a larger population, including people with disabilities. Presenting educational material in a variety of formats will also provide benefits to those with differing learning styles (visual, auditory, tactile) and will allow people to learn in their preferred learning style.

The guidelines developed by the IMS Accessibility Project Group and presented in this document, will provide a framework for the distributed learning community. This framework will highlight existing solutions, discuss the opportunities and strategies for their implementation and will identify areas where further development and innovation are required to ensure education that is truly accessible to anyone, anytime, anywhere.

Other standards and guidelines currently exist; however, the IMS Accessibility Guidelines are targeted at the distributed learning community and specifically address the challenges that exist in online education. The IMS Accessibility Guidelines are not meant to replace existing standards and guidelines, but instead to references those resources and provide additional information and solutions compatible with existing recommendations. That said, some topics addressed in this document, such as mathematics, scientific, and musical notation guidelines, do not yet have mainstreamed or widely adopted solutions. In these cases, this document offers suggestions and indicates the direction of current research.

1.1 Roles and Responsibilities

There are existing policies and laws that govern accessibility for people with disabilities. But they vary greatly from country to country, state-to-state, province-to-province, and even from one educational institution to another. Even the motives behind the desire to address accessibility concerns vary from person-to-person and from company-to- company. Yet in order to make learning technologies accessible to everyone, all parties must share responsibility.

The stakeholders include:

• courseware and software vendors
• educational publishers
• authoring tool developers/vendors
• authors/content developers
• educational institutions (including administrators)
• educators/instructors
• administrative staff
• students

Each setting is unique, requiring its own mix of roles and responsibilities. Consider the challenge of achieving accessibility in a university that delivers online education.

To begin, the manufacturer of courseware development tools must make the authoring environment itself accessible. Vendors must also provide tools within that environment to help educators and other courseware authors to meet universal design criteria.

Even if a vendor has made all features of an authoring environment accessible, and has provided the tools that support creating accessible courseware, there is no guarantee that an authoring professor will take advantage of them, and students with disabilities may still be excluded. Therefore, responsibility falls heavily on educators as well.

Educational institutions are responsible for following their own government's regulations. Educational institutions can go further and create their own accessibility policies in support of students, faculty, administrators, and staff with disabilities. These policies might include timeframes that establish the amount of advance notice a student must give that institution in order for the institution to be able to provide accessible materials. Polices can also establish just who must be informed of these needs and the procedures that students must follow in making their needs known.

Finally, students should also be considered a crucial part of this process. They must take responsibility for informing professors and school administrators about their particular needs and preferences and to do so in a timely manner. The school may establish limits within which students must communicate their accessibility needs and the student may be expected to work within those limits.

Making each constituent aware of their role is a responsibility shared by all. Creating courseware is a collaborative process and not all participants recognize that their contribution may have an impact on accessibility. By fostering an environment where accessibility is openly supported and discussed, institutions can help to ensure that all participants fulfill their individual obligations with accessibility in mind.

This document is targeted at the online distributed learning community, which includes software developers, courseware vendors, educational publishers, content developers, administrators, educators/instructors, and students. It is intended to be useful to a wide audience, including readers with varying levels of technical expertise.

1.2 Issues with Learning Technologies for People with Disabilities

Teaching and learning materials are delivered in many forms: paper, audio, and videotape, CD-ROM, television, and over the Internet. However, online education has become the preferred means of retrieving up-to-date information. With its characteristic speed and flexibility, online learning takes advantage of a variety of technologies to facilitate learning and interaction between participants.

Online education technologies include:

• synchronous and asynchronous communication and collaboration tools such as e-mail, listservs, bulletin boards, whiteboards, chat rooms, videoconferencing, and teleconferencing.
• interactive environments, such as simulations, immersive experiences, and games.
• testing and evaluation tools, including self-assessment and multiple-choice testing.

Today, online content is varied and can include: text on a website, digital audio, digital video, animated images, and virtual reality environments. This content can be created in a variety of ways, utilizing a variety of authoring tools.

As technology advances, accessibility questions proliferate. Video is everywhere, yet are all videos captioned for deaf and hard-of-hearing viewers? Do all videos carry an audio component that describes visual images for blind and low-vision users? Do all software applications offer keyboard equivalents appropriate for users with mobility restrictions or vision impairments. Do all images on websites have labels (alt-text) for users who access content with the help of screen reading software? How can blind students access mathematical equations presented as graphics, which cannot be read by screen readers? Are testing protocols flexible enough? Are administrative matters such as course listings and course registration accessible?

Not all of these questions have answers based in existing technologies. But we need to examine all accessibility issues in order to ensure access to online education for everyone. This document will lay out guidelines for accessible learning. These guidelines include:

• common accessibility problems associated with each technology.
• practices that learning system developers can implement to enhance accessibility for all users.
• practices that content creators and/or educators can implement to enhance accessibility for all users.
• resources that provide best practices and solutions in use.

1.3 Acknowledgements

This project is supported by a grant awarded to the CPB/WGBH National Center for Accessible Media from the Learning Anytime Anywhere Partnerships (LAAP), a program administered by the Fund for the Improvement of Postsecondary Education (FIPSE), U.S. Department of Education (http://www.ed.gov/offices/OPE/FIPSE/LAAP/).

Additional support is provided through participation and contributions from the following organizations:

Blackboard	USA	http://www.blackboard.com/
CETIS (Centre for Educational Technology Interoperability Standards)	UK	http://www.cetis.ac.uk/
DEST (Department of Education, Science, and Training)	Australia	http://www.dest.gov.au/
ETS (Educational Testing Service)	USA	http://www.ets.org/
IMS Global Learning Consortium	USA	http://www.imsglobal.org/
Industry Canada	Canada	http://www.ic.gc.ca/
NCAM (The CPB/WGBH National Center for Accessible Media)	USA	http://ncam.wgbh.org/
The Open University	UK	http://www.open.ac.uk/
Sheffield Hallam University	UK	http://www.shu.ac.uk/
UK eUniversities Worldwide	UK	http://www.ukeu.com/
University of Toronto ATRC (Adaptive Technology Research Centre)	Canada	http://www.utoronto.ca/atrc/

1.4 Nomenclature

ASL	American Sign Language
ATRC	Adaptive Technology Research Centre, University of Toronto, Canada
AT	Assistive Technology
CETIS	Centre for Educational Technology Interoperability Standards (UK)
DEST	Department of Education, Science, and Training (Australia)
DTD	Document Type Definition
ETS	Educational Testing Service
NCAM	The CPB/WGBH National Center for Accessible Media
SVG	Scalable Vector Graphics
TTY	Text Telephone
W3C	World Wide Web Consortium
WAI	Web Accessibility Initiative of the W3C
WGBH	Boston, Massachusetts public broadcaster

2. Primer on Accessibility

2.1 Disabilities, Functional Limitations, and Accessibility Tips

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

Resources:

See the Trace Center Accessible Software Guidelines for a comprehensive guide to creating accessible software at: http://www.trace.wisc.edu/world/computer_access/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 and published at: http://trace.wisc.edu/docs/software_guidelines/toc.htm

2.1.1 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 they possess.

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.

Application software 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. Do not create single graphics containing multiple objects. By keeping tools and other objects 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. Try instead to lock the "help" balloon in place so that the user can move the cursor and continue to read the balloon.
• use single column text whenever possible.
• provide keyboard equivalents for all tools, menus, and dialog boxes.

Since screen readers can only read text (or give names to separately identifiable icons or tools), it is a good idea to:

• avoid assigning unlabeled "hot spots" to pictures for use as controls, unless they are redundant with menu selections.
• avoid non-text menu items when possible or at least incorporate visible or invisible text cues to accompany these items. Screen readers can see text even if that text is written to the screen invisibly.
• avoid non-redundant graphic tool bars. Make any tool bar command available in a menu.

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

• documentation and online 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.

2.1.2 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 sensitivity to glare, night blindness, or reduced contrast.

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 to or magnify portions of the screen.

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

2.1.3 For People with Color Blindness

To make it easier for color blind users to access their software, 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.

2.1.4 For People Who Are Hard-of-Hearing or Deaf

Many users with hearing impairments need to have some method for adjusting the volume or for coupling audio output more 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 impairments 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.
• 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 ShowSounds feature that allows a user to assign a visual and caption for each audio event.

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

2.1.5 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. 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 can only be solved 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 interfere with the interactive experience by preventing users from easily manipulating the interface.

To increase the accessibility of software to 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 StickyKeys, SlowKeys, Key Repeating.

2.1.6 For People with Language or Cognitive Disabilities

Language and cognitive disabilities are very difficult for developers to address, partly because of the diversity of 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 range of impairment within each of these categories can vary 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 the 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 subsection 2.1.1 For People Who Are Blind.)

Dyslexia is one of the most common learning disabilities. Affecting between 4 and 15 percent of the population, this neurological disorder interferes with the acquisition and processing of written language. Dyslexia is associated with difficulties in both receiving and expressing language, including phonological processing, in reading, writing, spelling, handwriting, and sometimes in mathematical reasoning. Dyslexic students can benefit from many of the solutions developed to help users with other disabilities.

To improve accessibility for people with dyslexia, developers can:

• give users the ability to select their preferred font.
• make their products compatible with screen reading software and voice recognition software.
• use consistent layouts and formats.
• use plain, uncomplicated backgrounds behind text.
• avoid flashing, moving, or animated text.
• List hyperlinks at the end of the relevant paragraph or section instead of within the general text.
• Describe the type of information or website pointed to by a link, before inserting the link into the text.

Resources:

U.S National Institute of Neurological Disorders and Stroke resource on dyslexia: http://www.ninds.nih.gov/health_and_medical/disorders/dyslexia_doc.htm

Learning Disabilities Resource Community: http://www.ldrc.ca

Trace Center resources on Learning Disabilities: http://trace.wisc.edu/docs/quick_sheets/qs17.html

2.1.7 General Accessibility Improvements

To increase overall accessibility, developers can:

• make documentation available in electronic form, accessible by screen reading software, thus making it easier to use for people who cannot handle or read printed materials.
• make product support staff aware of disability access issues and that people with disabilities routinely depend on their software products.
• establish a protocol to forward accessibility and compatibility problems from product support staff to product designers. Keep the trigger-level for such referrals low.

Finally, all properly trained support staff should be able to handle routine product use questions from users who have disabilities. Ideally, some individual should also seek to specialize, to learn how to resolve specific incompatibility issues between software and technologies designed to assist those with disabilities. In this way, developers and support staff can create pools of expertise to deal with the widest possible range of problems and suggestions brought forward by users.

2.2 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 online education, AT refers to hardware and software technologies that enable people with disabilities to use a computer more effectively. The following is a brief overview of the main categories of these assistive technologies.

2.2.1 Screen Readers

Screen readers are software products designed for blind users. Screen readers are also useful to users with learning disabilities.

Screen readers locate information on the computer screen and vocalize it for the user using text-to-speech audio hardware and software. 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 by some disabled students.

2.2.2 Refreshable Braille Displays

Refreshable Braille displays are tactile devices that move small pins up and down to create Braille letters. These Braille displays are the primary means of access to computers for users who are deaf-blind.

2.2.3 Screen Magnifiers

Screen magnifiers are software solutions for users 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. For example, reversing the colors and blacks of the video signal can make the text more readable for some users.

Compatibility between screen magnifiers and software can be an issue 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.

2.2.4 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 an AT 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.

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

2.2.6 Single Switches

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

Resources:

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

2.3 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 using a different modality. 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. That said, 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 by The Open University, UK for disabled students, proved better able to achieve key learning objectives than its mainstream counterpart and it came to be used by all students.

2.4 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 the aid of an AT. For example, to be accessible to users with low-vision, directly accessible applications, software, or websites 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 website. 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 ATs. For this reason, it is particularly important to provide direct access in products targeted at elementary and middle school students.

Direct access brings many benefits. Most importantly, the user is able to access educational material without needing special assistive hardware and software. In this way, direct access helps to reduce cost for schools and individuals,\ and eliminates the technical difficulties associated with using AT. 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 website. These are the content experts and 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 website is an application designed with AT in mind. This level of access assumes that the user has a preferred AT package installed and is relatively competent and comfortable with the AT they are using. 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 such as adapted keyboards or single switches. These "hooks" are provided by developers using software engineering tools such as Microsoft Active Accessibility (MSAA) and the Java Accessibility API from Sun Microsystems (discussed in more detail in Section 8.7 Accessibility Information for Operating Systems and Development Platforms). Developers of compatibly accessible applications should also remember to always expose the cursor, use standard controls and fonts, and follow the operating system's human interface guidelines.

Compatible access offers some advantages. It provides consistency of operation between applications for users who already know how to navigate with their AT or who can become competent doing so. In some cases it may be less expensive to develop applications, software, and websites in this way. Relying on the AT package for text-to-speech capability, rather than adding it into the product itself, for instance, can save on disk space. 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 websites to be compatible with ATs 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.

3. Principles for Accessibility in Online Distributed Learning

The following principles present best practices for producing accessible software applications and accessible content for online distributed learning. Developers, content providers, and educators involved in the creation of learning products should adhere to these guidelines from the outset of the design process, since retrofitting an inaccessible product is almost always significantly more difficult, labor-intensive, and expensive.

We offer six principles that address accessibility for people who have sensory or mobility disabilities. These principles also address accessibility issues faced by people with cognitive disabilities, though often to a lesser extent.

1. allow for customization based on user preference.
2. provide equivalent access to auditory and visual content based on user preference.
3. provide compatibility with assistive technologies and include complete keyboard access.
4. provide context and orientation information.
5. follow IMS specifications and other relevant specifications, standards, and/or guidelines.
6. consider the use of XML.

3.1 Allow for Customization Based on User Preference

When applications make it possible to present information in a versatile manner, content becomes more accessible, reaching a wider variety of users. Some examples of items that should be customizable by the users fall into two categories:

Customizable display elements include:

• font, font style, font color, and font size
• cursors size, style, and blink rate
• size of text and images, including video
• screen layout, colors, and backgrounds

Customizable interface features include:

• timing of events
• keyboard settings

Allowing the user to customize elements of the application and its content is essential for accessibility. Hard-coding presentation elements such as fonts, may make access impossible for some users. Depending on a user's abilities and preferences, they may seek to change settings for presentation style, size, or timing. For example, a user with low-vision may want to change the style of a font and enlarge the size of text.

The user should also be able to change other application features, such as the timing of events. For example, dialog boxes and alerts should remain on the screen until they are cleared by the user. Programmed activities that require several actions to be taken within a fixed time limit can create problems for users whose ATs provide less efficient ways of interacting with the software. Those timing requirements should be customizable by the user.

3.2 Provide Equivalent Access to Auditory and Visual Content Based on User Preference

To be fully accessible to deaf or hearing-impaired users, applications should provide equivalent access to all auditory aspects of learning technologies and content.

To make applications accessible to those with hearing impairments, developers can:

• caption all auditory content.
• provide a text transcription of auditory content.

For blind or visually impaired users, applications should provide equivalent access to all visual aspects of learning technologies and content. Specifically, developers should:

• add text descriptions (alternative text or alt-text) to all static images (e.g., pictures, logos, charts, links, other graphics) so the text can then be read by a screen reader or output to a Braille display.
• utilize the "longdesc" attribute for images that have useful content and require more lengthy descriptions.
• provide audio description tracks for multimedia, describing visual aspects of the content.

For users who are deaf, hearing-impaired, blind, visually impaired, or deaf-blind, applications should combine equivalent access, as detailed above, for all auditory and visual aspects of learning technologies and content. Deaf-blind users in particular, need text equivalents for all audio and visual material.

3.3 Provide Compatibility with Assistive Technologies and Complete Keyboard Access

Applications, software, and content must be compatible with all types of ATs including: screen readers, screen magnifiers, adaptive keyboards, voice recognition software, and single switches.

Developers should provide complete keyboard access to all elements of an application and its content, including menus, help directories, toolbars, and dialog boxes. Never assume that all users can operate a mouse.

3.4 Provide Context and Orientation Information

Applications and software are made more usable when developers provide context and orientation information to users. They should design their products to:

• teach users how to navigate.
• inform the user of the length of the document. For example, page numbers can be expressed as: "Page X of Y pages".
• provide a way for users to skip standard page headers and navigation links. Users who are already familiar with the page layout should be able to skip directly to the primary content.
• maintain a consistent layout between pages. Content becomes more accessible when users can depend on consistency of presentation.
• provide alerts/text warning whenever a new browser window will be automatically opened.

Applications that implement these features will help users of screen reading software work more efficiently, saving time. They will be able to listen to content rather than rely on graphics or visual aids to navigate through content. In addition, these features benefit all users by increasing usability and minimizing the learning curve. And adhering to a consistent design between pages makes information generally easier to find for all users.

3.5 Follow IMS Specifications and Other Relevant Specifications, Standards, and/or Guidelines

Developers who follow relevant specifications and guidelines increase accessibility in two ways. Obviously, guidelines that provide information on how to implement accessibility within applications offer useful techniques and suggestions to programmers. But because accessibility often relies on interoperability between learning applications, software, content, and ATs, following other relevant industry specifications will also lead to improved access. These broad guidelines help ensure that applications, software, and content conform to standard operating system protocols, and thus make it more likely that ATs will be able to operate with them.

Developers within the online distributed learning community who seek to promote more fully interoperable technologies should fully adopt IMS Global Learning Consortium specifications.

Through the work of the IMS Accessibility Project Group, in conjunction with other IMS Project Groups, these specifications will continue to evolve and will include additional, specific sections intended to improve accessibility of online distributed learning technologies.

Many IMS specifications are currently available:

• The IMS Profiles and Enterprise System Specification organizes learner information and specifies interfaces for exchanging student, course, and administrative data. They make learning systems more responsive to the specific needs of each user, as well as better integrated with administrative software systems.
• The IMS Content Packaging Specification makes interchange of content possible between different learning systems.
• The IMS Question & Test Interoperability Specification allows institutions to share test items and other assessment tools across different systems.
• The IMS Learning Resources Meta-Data Specification creates a uniform way for describing learning resources.

Several IMS specifications are currently in development (at time of publication of this document):

• The IMS Accessibility Project Group is currently working on producing additions to the Learner Information Profile (LIP) Specification and including provisions for accessibility in the Meta-Data Specification.
• The IMS Learning Design Project Group is producing an information model that will extend IMS Content Packaging to describe a learning experience and the activities that contribute to it.
• The IMS Digital Repositories Project Group is producing an information model that specifies a means to perform searches, gather information, and set up alerts across different kinds of repositories.
• The IMS Simple Sequencing Project Group is working towards a final specification which provides a a rule-based method for ordering and presenting learning objects to a user.

Throughout this document there are references to additional industry specifications, standards, and guidelines, which are also listed in Appendix B of this document.

Resources:

IMS specifications are available to the public, free of charge, at: http://www.imsglobal.org/specifications.html

3.6 Consider the Use of XML

XML (Extensible Mark-up Language) has been selected by the IMS Global Learning Consortium as the basis for all of its specifications. XML provides a widely accepted method for defining abstract data structures that can be easily parsed, used, and validated. All of the major computer platforms support XML, making it ideal for solving interoperability problems.

XML lends itself to accessibility for these and other related reasons. An AT often requires interoperability between the application delivering the actual course content or services and the specialized application, used by a learner with a disability, to access that content.

Materials authored in XML also offer the following benefits:

• Transformable and flexible: XML encourages separation of content and presentation. It allows user agents to transform the presentation of content to meet users' individual needs, even if the author didn't consider those transformations.
• Structured and validated: XML encourages use of consistent nested structures, which make it easier to navigate complex learning materials. Also, XML documents can be validated to ensure they use mark-up appropriately.
• Text based: XML documents are likely to contain reusable text content since they are created as text documents. Providing text improves accessibility as described in Section 5 Guidelines for Accessible Delivery of Text, Audio, Images, and Multimedia.

XML does not guarantee accessibility. To avoid creating accessibility problems, developers should follow guidelines accompanying any published XML language (see the WAI for information on W3C languages). Also, developers should use existing XML languages whenever possible, especially if they have built-in accessibility features, such as those from the W3C (see Section 4 for more details). When designing a new XML language, developers should follow the W3C's recommendations to ensure that the new language is as accessible as possible.

For more information, see the W3C's XML accessibility guidelines at: http://www.w3.org/TR/xmlgl

4. Using XML for Accessibility

As mentioned in Section 3, XML can facilitate accessibility through transformable, structured, text-based content. XML allows a range of flexible stylesheet transformations. It allows simple changes to font size and color as well as the use of complex translation grammars used to translate a presentation into entirely different modalities. Because all content in an XML document is declared and labeled, authors can create content that later can be re-styled in ways that the author never imagined.

4.1 XML is Customizable and Flexible

XML is the W3C recommended metalanguage for the Web. Using XML, authors can develop content that is controlled by languages of their choice and even of their own making. For the purposes of these Guidelines, authors are advised to use XML-based languages in preference to plain HTML. In addition, they should seek to confine their selection of special-purpose XML languages to those already in general use, especially those languages designed with accessibility provisions.

XML has significantly fewer limitations than HTML. While the tags and attributes within HTML are restricted to a pre-defined set, XML offers expert developers the capability to employ author-defined tags. This flexibility makes XML more fully customizable.

Headers and paragraph tags can be made more descriptive. Instead of the standard header and paragraph tags found in HTML, XML allows the developer to define tags, making them more intelligent and intelligible. Thus it is possible for an author to tailor data files to meaningfully describe the type of data in any particular set of tags in a data file.

This flexibility also allows the author to mark up data files with tags that clearly differentiate content intended for different users with different needs. For example, a single data file can contain content designed both for blind or visually impaired users and sighted users. Subsection 4.3.2 provides an example of how this can be achieved using XML and stylesheets. These flexible tags also support the editing process by permitting authors to use a different 'editing' view than they intend to display for their readers. A visually impaired author, for example, could use a large print view but publish in a smaller print.

Another important difference between HTML and XML lies in the way that the two languages handle the structure and display of data. HTML combines structure and display data. XML separates structure information from display information. The XML metalanguage can create languages that describe and manage the structure of data or that format data. The semantics of an XML document are, therefore, defined by the applications that process them and/or by stylesheets (Extensible Stylesheet Language Transformations, XSLT). Stylesheets render the content of the XML file appropriately for differing output formats.

4.2 XML Allows for Standardization for Accessibility, Validation, and Well-Formedness

XML-based mark-up languages, including those created by authors, depend upon online DTDs or schemas that provide rules for their interpretation. This means that the tags, including those in XHTML, must be well-formed and validated. This additional strictness, not required by HTML, imposes a discipline on content developers, but it is not burdensome. There are code validators available from W3C, and both the content files and the associated stylesheets can be validated for correct code. As described in the principles on standards, validity and well-formedness generally contribute to accessibility.

Resource:

For information on accessible use of XML, consult the resources from the W3C at: http://www.w3.org/TR/xmlgl

4.3 Recommended XML-Based Languages

The following subsection considers some of the XML-based languages used in online education.

4.3.1 XHTML

XHTML offers persuasive advantages over HTML for the production of accessible online media.

Well-formed HTML can be translated easily into XHTML, which then refers the user agent to standardized, online interpretation specifications. Developers need not fear that XHTML will cause compatibility problems with older browsers. XHTML will default to HTML when it encounters non-XHTML browsers. This back-up feature comes at a small cost to the author but it offers important support for user agents that are designed to increase accessibility using XML.

To use XHTML is to use a mark-up language that is future-proofed. Developers do not have to make significant changes to existing resources and activities; they need only follow the rules for producing correct HTML 4.1 and then add an extra line to their resource that identifies it as being accessible to XML-using agents. This added line also includes instructions for finding online, machine-readable information for interpreting the XML version in use. XHTML is particularly useful to user agents that have work to do: to find alternative resources, to synchronize files such as caption and video files, or to transform the content in some way to make it more accessible.

4.3.2 XML Mark-up and Stylesheets

Cascading Stylesheets (CSS), as used with HTML, are able to alter the display and formatting of all or part of the contents of the HTML file to which they apply. Thus, for example, <H1> tags in the HTML file can be designed to appear as bold, 15 point, and blue. But a different CSS can instead render them as 30 point for a low-vision learner. CSS are, however, capable of altering the formatting and display of selected aspects of the entire contents of the HTML file. The browser will display the whole HTML file to every user.

Extensible Stylesheet Language Transformations (XSLT) are a more powerful tool. They allow the selection and formatting of particular parts of an XML file. They also allow the addition (within the XSLT file itself) of other elements such as images, text, or video not included in the default presentation. Thus, authors need only write data files once but can specify a variety of presentations to suit different needs. For example, using HTML to create multi-language websites requires separate files for each language for each page. XSLTs allow the stylesheet to select each language's text from the contents of a single file for the page and display it together with any language-specific images, audio, or video.

Besides handling multiple languages, XML can be used to differentiate content that is intended for a variety of users including blind learners, visually impaired learners, and sighted learners, all within a single data file.

Here is an example from a biological sciences course:

<A_robustus_intro>
	<audio description> This page contains information relating to the fossils of Australopithecus robustus. It shows an image of a skull specimen discovered in 1950 by Robert Broom showing a slight sagittal crest and large zygomatic arches that project forwards, hiding the sunken nasal area.</audio description>
	<large print> The above image shows the skull of Australopithecus robustus, discovered in 1950 by Robert Broom. Look at the distinctive features and note them. </large print>
	<standard> The above image shows the skull of Australopithecus robustus, discovered in 1950 by Robert Broom. Look at the distinctive features and note them. </standard>
</A_robustus_intro>

The various versions about A. Robustus can be added to the learner's view of the lesson via XSLT, perhaps in response to a preference setting where the user can indicate the need for large print and/or audio description. This brief example illustrates the capacity of XML to include author-tailored tags that increase both the flexibility and readability of the file.

4.3.3 Scalable Vector Graphics (SVG)

Scalable Vector Graphics language (SVG) is a vector graphics language recommended and supported by W3C, and is thus used by many of the W3C member companies who develop relevant authoring and user agent software.

Vector graphics differ from raster graphics. Raster, or bit-mapped graphics store images as a simple collection of bits, making manipulation of those images difficult. Vector graphics, however, define images descriptively. For example, a vector image of a cube is defined by a mathematical description of its shape. In that way, the cube can be enlarged, reduced, or rotated on the screen. The description of the object can be interpreted by other output devices, such as a haptic display. In the case of technical drawings, the displayed image is often derived from a database of information. That information can be reproduced graphically, but also as a table or even represented by sound.

The data that defines a vector image can also include a detailed description of the data itself. Thus both the ALT text and the LONGDESC can be part of the 'image' object. In addition, SVG supports meta-data about the object so that an image object can point to an alternative description of the object located elsewhere.

Anywhere images are constructed from other image elements, the individual objects retain their own descriptions. In an engineering diagram, for example, items included in a flowchart can each be described separately. In this way, the content producer is able to group sets of objects to create a more complex graphical object. If the graphical elements can be described and their relationship described, then even the user who cannot use a graphical interface still has a good chance of being able to decode the image.

Authors need to work carefully with the power of SVG. Complex images can contain many sub-elements and thus accumulate a large number of descriptions associated with the entire image. Authors should organize sub-element information hierarchically so that a user who cannot see the entire image can listen to or read the text, and still be able to create a suitable mental model of the image.

SVG provides a format for images that supports a number of accessibility features. These features include:

• text information for blind or low-vision users.
• scalability that allows high quality zoom functionality. Lines stay sharp when magnified.
• labels on objects. If the objects are also grouped into a hierarchy, the hierarchical relationship between labels will convey more fine-grained detail than a single text description.
• support for stylesheets, DOM2 for customizing presentation and meta-data as well as RDF for efficient cataloguing.
• support for device-independent events allowing ATs and other input devices.

Resources:

Further information about SVG and SVG accessibility is available at: http://www.w3.org/TR/SVG-access/

Also see the W3C's "Accessibility Features of SVG" at: http://www.w3.org/TR/SVG/struct.html#GElement

4.3.4 Synchronized Multimedia Integration Language (SMIL)

Synchronized Multimedia Integration Language (SMIL) is another XML language. SMIL, pronounced "smile", is recommended for the creation of multimedia presentations for the Web and is supported by popular user agents, including RealPlayer and QuickTime Media Player.

Many of the solutions to problems discussed in these Guidelines require the author to provide equivalent alternative formats such as text, sounds, or haptics alongside graphics. The integration and synchronization of these elements can be managed by SMIL. Throughout the text of these guidelines, there is reference to SMIL and there are some examples that show how it can be used, where appropriate.

Resources:

For information on accessibility features of SMIL see the W3C's "Accessibility Features of SMIL" at: http://www.w3.org/TR/SMIL-access/

For an authoring tool for accessible SMIL presentations see the National Center of Accessible Media's MAGpie (Media Access Generator) at: http://ncam.wgbh.org/webaccess/magpie/

4.3.5 XML E-Book Formats

Two major e-book formats are XML based: the Digital Audio-based Information System (DAISY) and the Open eBook Publication Structure.

DAISY's mission is to develop international standard and implementation strategies for the production, exchange, and use of Digital Talking-Books in both developed and developing countries. To ensure access to information for people with print disabilities, DAISY is designed to enhance integration with mainstream technology.

More information is available on the DAISY website at: http://www.daisy.org

The purpose of the Open eBook Publication Structure is to provide a specification for representing the content of electronic books. Specifically:

• the specification is intended to give content providers (e.g., publishers and others who have content to be displayed) and tool providers minimal and common guidelines that ensure fidelity, accuracy, accessibility, and presentation of electronic content across various electronic book platforms.
• the specification seeks to reflect established content format standards.
• the goal of this specification is to provide the purveyors of electronic-book content (publishers, agents, authors, et al.) a format for use in providing content to multiple reading systems.

The Open eBook Publication Structure is based on the premise that in order for electronic-book technology to achieve widespread success in the marketplace, reading systems must have convenient access to a large number of titles across a variety of genres. The specification therefore is based on HTML and XML, the same core languages that define the World Wide Web, and is designed to allow publishers and authors to deliver their material in a single format. This information and more is available from the Open eBook site at: http://www.openebook.org/

4.3.6 Other Mark-up Languages

MathML, ChemML, MusicML, and others are discussed in Section 11 Guidelines for Topic Specific Access. These are mark-up languages, developed in XML format, and they can be mixed and matched with XHTML.

5. Guidelines for Accessible Delivery of Text, Audio, Images, and Multimedia

Every person learns differently. At its best, online learning allows users to interact with lesson material in their preferred way, relying on their individual strengths while discounting as much as possible their weaknesses. The principles of excellent software design call on developers to work in full knowledge of the range of human skills and limitations. Software designers of teaching materials and activities, in particular, must strive to achieve this high standard.

When a user has a disability, access to learning software may depend entirely on how flexibly that product can deliver its content. Some users may need only to modify the parameters in which media is presented; other users may require entirely different media. Developers who achieve the kind of flexibility that diversity requires will enhance the accessibility of their product.

At a minimum, developers should provide text representations for all media types. This baseline will help address access for many users. It is important to note that users with learning disabilities benefit from graphical presentations. For this reason, the practice of providing text-only content as an alternative to inaccessible multimedia content may not be an effective solution for users with cognitive disabilities.

A number of resources that address flexible media delivery are currently available. The W3C's Web Accessibility Initiative provides accessibility guidelines for W3C technologies such as HTML, XML, SMIL, CSS, and SVG. It also provides more general guidelines for Web content accessibility, authoring tool accessibility, and user agent accessibility. More information links are available in the appendix. Two other comprehensive guides are referenced here.

The National Center for the Dissemination of Disability Research publication, "User-Friendly Materials and Alternate Formats" provides information on implementing several formats and modes including:

• large print
• audiotape
• Braille
• diskette
• CD-ROM/DVD
• video and descriptive video
• captions
• Internet/World Wide Web

Visit the National Center for the Dissemination of Disability Research online at: http://www.ncddr.org/du/products/ufm/ufm.html

The California Community Colleges have produced a comprehensive set of guidelines that offers alternative formats for presenting printed materials. Their document, "Guidelines for Producing Instructional and Other Printed Materials in Alternate Media for Persons with Disabilities" can be found at: http://www.htctu.fhda.edu/amguidelines/am33000.htm

The California Community Colleges document provides a comprehensive resource for producing several types of alternative media including:

• audio
• Braille
• tactile graphics
• large print
• electronic text

5.1 Common Types of Media Delivery and Associated Presentation Formats

5.1.1 Text

When text is correctly structured and formatted, it can be the most flexible way to present content. To make distributed online learning accessible, developers of learning platforms must provide a means to render digital text in alternative formats.

Specifically, it should be possible to render text as:

• Visual information. Text can be displayed on computer screens or other electronic devices (e.g., personal digital assistants, cell phones, e-book readers).
• Audio information. Text can be translated into speech using recordings or via synthesized speech provided by a computer.
• Tactile information. Text can be displayed on refreshable Braille displays or printed using a Braille embosser.

Common text accessibility problems include:

• hard-coded fonts that prevent users from changing style, size, or color.
• text presented with background images or poor contrast colors that hinder readability.
• text presented in an image format that screen readers and Braille displays cannot transform.
• multi-column formats (including some tables) that screen readers cannot process in the correct order.

Learning system developers may enhance the accessibility of text for all users by following these practices:

• offer features that allow the user to customize fonts and backgrounds.
• allow ATs to have access to the source code.
• use validated XHTML.

Content creators or educators may enhance the accessibility of text for all users by following these practices:

• choose text formats that offer the most accessibility (e.g., XHTML, plain text).
• use true text and not graphical representations of text.
• structure the text appropriately, identifying headings and other structural elements.
• use styles or stylesheets to provide a flexible display.

5.1.2 Audio

Audio elements can add to the general appeal of online learning materials while making them more accessible to those who are print-impaired learners, such as those with visual impairments or dyslexia. However, developers should provide alternatives to ensure that learners who are deaf or hard-of-hearing are not disadvantaged.

Common audio accessibility problems include:

• lack of captions and/or transcripts.
• poor sound quality.
• inability to control volume.

Learning system developers may enhance the accessibility of audio for all users by following these practices:

• provide a means to include captions and/or transcripts.
• provide volume controls.
• provide visual equivalents to audio alerts (e.g., show a text alert on the screen whenever an error beep is played).

Content creators or educators may enhance the accessibility of audio for all users by following these practices:

• provide transcripts or captions for all essential audio.
• consider providing other forms such as ASL or captions with images.

Resources:

An authoring tool to add captions, subtitles, and audio descriptions to digital media is available free-of-charge for content creators and educators. This tool, MAGpie (Media Access Generator), is available from the National Center for Accessible Media (NCAM) at: http://ncam.wgbh.org/webaccess/magpie/

CAST (the Center for Applied Special Technology) offers "Tips on Presenting Alternatives to Sound" at: http://www.cast.org/udl/index.cfm?i=352#tips

Proprietary software exists that allows authors to add sign language displayed using animated characters. One company developing this software is Vcom3D. They have created "SigningAvatars" that are able to render content in Signed English and Pidgin Signed English (and possibly ASL in the future). More information is available at: http://www.signingavatar.com

5.1.3 Images

Images can provide essential information. But without text support, images are not accessible for users who are blind or have low-vision. Developers must provide users with a way to access visual information. Providing text identification, or alternative text, will also benefit users of text-only browsers, such as mobile phones. Developers should ensure that images are scalable so that users can enlarge them for better clarity.

Common image accessibility problems include:

• failure to provide alternate text.
• poor image resolution that restricts the ability of low-vision users to enlarge images.

Learning system developers may enhance the accessibility of images for all users by following these practices:

• provide a means to include text alternatives of images.
• provide a zoom feature.

Content creators or educators may enhance the accessibility of images for all users by following these practices:

• provide text alternatives for images.
• use SVG features that improve accessibility (see subsection 4.3.3).
• use the highest practical resolution for bit-mapped graphics when use of SVG is not possible (e.g., photographs).

Resources:

The University of Toronto's Special Needs Opportunity Windows (SNOW) on making images accessible at: http://snow.utoronto.ca/access/higher/images.html

The W3C WAI Techniques for Web Content Accessibility Guidelines 1.0 section 2.1.1 for providing alternatives to auditory and visual content at: http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#images

The Web Design Group's article on use of alt-text in HTML at: http://www.htmlhelp.com/feature/art3.htm

WebAIM's tutorial, including code examples, illustrating the W3C Web Content Accessibility Guidelines 1.0 recommendation checkpoint for providing "equivalent alternatives to auditory and visual content" at: http://www.webaim.org/tutorials/alt

SVG is a language used in XML to describe two-dimensional graphics. SVG 1.0 is recommended by W3C and is available from the W3C website at: http://www.w3.org/TR/SVG/

Accessibility features of SVG are described at: http://www.w3.org/TR/SVG-access/

5.1.4 Multimedia

Multimedia is the combination of text, graphics, video, animation, and sound. Thus, a given piece of multimedia content combines the access needs of each media type represented. Multimedia can be useful for many groups of learners, since a multi-modal presentation of information can be easier to understand. In general, users benefit when alternatives are available for each media type.

Common multimedia accessibility problems include:

• digital videos without captions, transcripts, or audio descriptions.

Learning system developers may enhance the accessibility of multimedia for all users by following these practices:

• provide the means to include accessibility features, such as captions, transcripts, and audio descriptions, within the multimedia format provided by the application.

Content creators or educators may enhance the accessibility of multimedia for all users by following these practices:

• follow all relevant suggestions for enhancing accessibility for text, audio, and images, since multimedia can combine all of these elements.
• provide audio description describing essential visual elements for video content.
• consider the importance of the timing of media delivery when planning access features. For example, a "talking head" video may need only a stand-alone transcript of the audio, but a documentary including graphics and other important visuals may require captions in order to maintain the link between visuals and narration.

Resources:

The WGBH National Center for Accessible Media's "Rich Media Accessibility" website (http://ncam.wgbh.org/richmedia/) provides information of a wide range of digital media formats, including:

• A tutorial on Creating Audio Descriptions for Rich Media at: http://ncam.wgbh.org/richmedia/audiodesc.html
• A tutorial on Creating Captions for Rich Media at: http://ncam.wgbh.org/richmedia/captioning.html

6. Guidelines for Developing Accessible Asynchronous Communication and Collaboration Tools

This section covers the development of asynchronous communication and collaboration tools, including:

• threaded message boards
• e-mail and listserv messaging
• document repositories
• organizers, schedulers, and calendars
• presentation tools

Asynchronous communication and collaboration tools such as threaded message boards, e-mail messaging, listservs, document repositories, calendar systems, and presentation tools must be rendered in formats that facilitate the full participation of learners with disabilities in online interactions. The navigation system for these utilities should allow users of ATs to operate without encountering barriers to any aspect of the functionality. Specifically, the software should allow them to:

• scan items and locate content easily.
• follow the thread of an ongoing discussion topic.
• post responses, or add additional information.

Users must have flexibility in their choice of browser, input and output modalities, and be able to use ATs. All Web-based components of asynchronous communication and collaboration tools should be compliant with the W3C Web Content Accessibility Guidelines 1.0, available from the WAI website: http://www.w3.org/TR/WCAG10/

6.1 Threaded Message Boards

For discussion forums, bulletin boards, and other utilities that allow posting of text messages, content providers should render both the navigation system and the content of the messages in standard XHTML. Requiring use of proprietary client software or non-standard file formats may create barriers by preventing users from establishing individual preferences, as described in the introduction.

Common threaded message board accessibility problems include:

• navigation systems using complex framesets that fail to include title or name attributes.
• lack of ALT text on buttons that function with JavaScript to expand or contract threaded discussions (i.e., blue triangles are commonly used).
• form fields that do not accommodate keyboard navigation.
• illogical tab sequence when moving between elements on the page.

Learning system developers may enhance the accessibility of threaded message board applications for all users by following these practices:

• ensure that all actions can be completed using the keyboard.
• provide easy-to-use features that allow users to configure the interface according to individual preferences.
• provide help files, including an orientation to the interface and its functionality.
• use text instead of images of text for navigation links or buttons.
• use stylesheet attributes and text to create attractive form buttons instead of using images.
• provide bypass links or some other method to allow users to skip repetitive navigation links and go directly to the main content of the page.

Content creators or educators may enhance the accessibility of threaded message board applications for all users by following these practices:

• provide informative names to identify discussion threads and message subject lines.

Resource:

Examples of accessible threaded message boards are available on the Internet Accessibility Discussion at: http://www.worldenable.net/iadiscuss/

6.2 E-Mail Messaging

E-mail systems may be used either for one-to-one exchanges, or used to distribute and receive messages to a larger user group via a listserv. To use an e-mail system, users select proprietary client software according to their individual needs and according to the compatibility needs of their preferred AT hardware and software. To ensure accessibility, developers should make the interface of their e-mail clients compliant with the latest Authoring Tool Accessibility Guidelines, available from the W3C's WAI website at: http://www.w3.org/TR/WAI-AUTOOLS/

To further ensure that e-mail messages are accessible, users must always have the option to send plain ASCII text.

Common e-mail accessibility problems include:

• non-plain text components within the body of the e-mail, including XHTML mark-up code for fonts, colors, and bold formatting.
• inclusion of background images that obscure text for users who are low-vision.
• attachment of non-standard file formats that cannot be accessed by the recipient of the e-mail.

Learning system developers may enhance the accessibility of e-mail applications for all users by following these practices:

• ensure that e-mail clients allow e-mail content in a plain text format that does not allow fonts, colors, bold formatting, background images, and so on.
• provide easy-to-use features that allow the users to configure the interface according to their individual preferences (e.g., a simple or expert option).
• provide help files that include an orientation to the interface and its functionality.
• follow the latest version of the WAI Authoring Tool Accessibility Guidelines.

Content creators or educators may enhance the accessibility of e-mail applications for all users by following these practices:

• ensure that the subject line accurately reflects the content of the message.
• do not attach files to listserv messages. Some recipients may not be able to access the content.
• use a signature file or Vcard to provide information about the sender's name, title, and address.

6.3 Document Repositories

Designers of document repositories must ensure that the indexing system is accessible to all users and that it follows logical document structure. Where possible, store documents in standard XHTML format. Using proprietary or non-standard file formats may create barriers. Other formats are less accessible and might limit the user's ability to access information according to individual needs or preferences. Search functions and display options must be accessible to users of ATs.

Common document repository accessibility problems include:

• indexing or navigation systems use complex frames that do not include the title or name attributes.
• form fields in search utilities do not accommodate keyboard navigation.
• display options are hard to locate or are not accessible via the keyboard.

Learning system developers may enhance the accessibility of document repository applications for all users by following these practices:

• ensure that all actions can be completed from the keyboard.
• provide easy-to-use features that allow users to configure the interface according to individual preferences.
• provide help files and include an orientation to the interface and its functionality.

Content creators or educators may enhance the accessibility of document repository applications for all users by following these practices:

• ensure that document titles accurately reflect the content of the document.
• provide documents in standard XHTML format. Avoid the use of proprietary or non-standard file formats.

Resource:

Examples of accessible document repositories are available at WAI Mail Archives at: http://lists.w3.org/Archives/Public/w3c-wai-ig/

6.4 Organizers, Schedulers, and Calendars

Some applications, such as organizers, schedulers, and calendars allow users to post shared information. To make these utilities accessible, developers and content providers should seek to structure posted information in a logical manner, encoded using standard XHTML. Non-visual users are at a disadvantage when confronting complex tables or scripting languages. For these and other users, information must linearize correctly in order to be translated accurately into other forms, such as audio output. When providers fail to properly format structured data, dates and events can become improperly juxtaposed. Traditional calendar layouts are particularly susceptible to this sort of error, so content providers ought to include alternative linear output whenever possible.

Common organizer, schedule, and calendar accessibility problems include:

• scripts that use event handlers that are device-dependent (i.e., require a mouse).
• the use of incorrect mark-up that inhibits the user's ability to navigate among table cells and access headers and other cell information.
• table cells whose content does not linearize correctly.

Learning system developers may enhance the accessibility of organizers, schedules, and calendars for all users by following these practices:

• ensure that tools are usable even when scripts are not supported.
• provide equivalent information on an alternative accessible page.
• for data tables, identify row and column headers. Use abbreviations for header labels and identify structural groups of rows or columns.
• test table content to ensure it linearizes correctly. If it does not, provide a linear alternative.

Content creators or educators may enhance the accessibility of organizers, schedules, and calen