IMS Guidelines for Developing Accessible Learning Applications
Version 1.0 White Paper
Copyright © 2002 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Guidelines for Developing Accessible Learning Applications
Revision: 27 June 2002
IPR and Distribution Notices
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.
IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.
Copyright © IMS Global Learning Consortium 2006. All Rights Reserved.
If you wish to distribute this document or use this document to implement a product or service, you must complete a valid license registration with IMS and receive an email from IMS granting the license. To register, follow the instructions on the IMS website: http://www.imsglobal.org/specificationdownload.cfm.
This document may be copied and furnished to others by Licensee organizations registered on the IMS website provided that the above copyright notice and this paragraph are included on all such copies. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to IMS, except as needed for the purpose of developing IMS specifications, under the auspices of a chartered IMS work group.
Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/accessibility/accessiblevers/accguidev1p0speclicense.html.
The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.
THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.
An extended Table of Contents, with a full listing of sub-categories
within each section, is provided below the Short Table of Contents.
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
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.
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:
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.
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:
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:
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:
| CETIS (Centre for Educational Technology Interoperability Standards)
| DEST (Department of Education, Science, and Training)
| ETS (Educational Testing Service)
| IMS Global Learning Consortium
| Industry Canada
| NCAM (The CPB/WGBH National Center for Accessible Media)
| The Open University
| Sheffield Hallam University
| UK eUniversities Worldwide
| University of Toronto ATRC (Adaptive Technology Research Centre)
|| American Sign Language
|| Adaptive Technology Research Centre, University of Toronto, Canada
|| Assistive Technology
|| Centre for Educational Technology Interoperability Standards (UK)
|| Department of Education, Science, and Training (Australia)
|| Document Type Definition
|| Educational Testing Service
|| The CPB/WGBH National Center for Accessible Media
|| Scalable Vector Graphics
|| Text Telephone
|| World Wide Web Consortium
|| Web Accessibility Initiative of the W3C
|| Boston, Massachusetts public broadcaster
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.
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
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.
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.
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.
Finally, telephone support staff should also have text telephone (TTY) available in order to be able to assist deaf or hard-of-hearing customers.
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.
Language and cognitive disabilities are very difficult for developers to address, partly because of the diversity of the category. The group includes individuals with:
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.
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.
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
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.
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.
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.
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.
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.
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.
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 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.
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
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.
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.
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.
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:
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.
To be fully accessible to deaf or hearing-impaired users, applications should provide equivalent access to all auditory aspects of learning technologies and 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.
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.
Applications and software are made more usable when developers provide context and orientation information to users. They should design their products to:
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.
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.
Throughout this document there are references to additional industry specifications, standards, and guidelines, which are also listed in Appendix B of this document.
IMS specifications are available to the public, free of charge, at: http://www.imsglobal.org/specifications.html
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:
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
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.
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.
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.
For information on accessible use of XML, consult the resources from the W3C at: http://www.w3.org/TR/xmlgl
The following subsection considers some of the XML-based languages used in online education.
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.
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:
<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>
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.
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:
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
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.
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/
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 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/
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.
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:
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:
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:
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.
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
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.
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/
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.
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:
This section covers the development of asynchronous communication and collaboration tools, including:
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:
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/
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.
Examples of accessible threaded message boards are available on the Internet Accessibility Discussion at: http://www.worldenable.net/iadiscuss/
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.
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.
Examples of accessible document repositories are available at WAI Mail Archives at: http://lists.w3.org/Archives/Public/w3c-wai-ig/
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.
The Wave is an accessibility evaluation tool that analyzes the linearized reading order. It is available at the Web address: http://www.temple.edu/inst_disabilities/piat/wave/
Microsoft PowerPoint has been widely adopted because it is easy to use. With a little practice, most authors can easily create presentations that look "professional". One of its strengths is the fact that Microsoft PowerPoint allows users to mix and match, to drag and drop all sorts of objects into their presentations. The resulting collection of elements often contain no reference to their origins, how they came to be included, what relationship they have to each other and so on. That is a problem for those who require accessibility. It is certainly possible that a presentation slide contains only a set of text outline statements that are easily accessed by a person with vision impairments. But in fact it's all too likely that a given slide will include many inaccessible objects.
This same problem makes converting Microsoft PowerPoint slides to Web pages difficult. If the screen presentation of the Microsoft PowerPoint display is simply converted into a single graphic image and is then connected by links from one screen to another, all embedded information is lost. Often it is just this information that those with disabilities depend on.
For these reasons, the gains made by presenters using Microsoft PowerPoint that allow them to present their material visually often come at a cost to those with special needs or who rely on alternative access technologies.
Below are three possible alternative approaches. Accessibility Wizard, which provides a way to convert Microsoft PowerPoint slides into accessible HTML. The second, W3C Slidemaker, which converts HTML into slides, and finally WimpyPoint, a tool that replaces Microsoft PowerPoint.
Accessibility Wizard software was created at the University of Illinois. It provides an alternative to Microsoft PowerPoint's built-in Web Publishing feature.
Using Microsoft PowerPoint's Web Publishing feature creates content that can only be viewed using Microsoft's Internet Explorer. Even if non-XML options are selected, users cannot easily add information that is required for accessibility. Accessibility Wizard simplifies the task of converting Microsoft PowerPoint presentations into text pure HTML.
Accessibility Wizard is available free-of-charge from The University of Illinois at: http://www.rehab.uiuc.edu/ppt/
Slidemaker converts a single long HTML or XHTML page into a set of slides. It makes it easy for the author to separate text from presentation, which it handles using stylesheets. Slidemaker's ease of use also encourages good use of meta-data and helps presenters ensure that their presentation will be accessible to alternative devices. For more information visit the slidemaker website at: http://dev.w3.org/cvsweb/slidemaker/
ArsDigita has created an open source alternative to Microsoft PowerPoint called WimpyPoint.
WimpyPoint replaces Microsoft PowerPoint and allows users to build a slide presentation using their preferred browser. Presentations are stored remotely and can be accessed from anywhere. WimpyPoint allows multiple users, even when separated geographically, to share presentations and to collaborate in their creation.
WimpyPoint is ideal for creating accessible presentations since it is based on HTML and supports cascading stylesheets.
WimpyPoint is available at the ArsDigita website at: http://www.arsdigita.com/acs-repository/one-version?version_id=1114
This section covers guidelines for the development of synchronous communication and collaboration tools, including:
Synchronous communication and collaboration tools, such as synchronous text chat, audio-conferencing, video-conferencing, and whiteboards, are increasingly important components of online learning. In order to ensure the full participation of learners with disabilities, these synchronous tools must be made accessible to them. In general, this means ensuring that the user interface of the tool, as well as the real-time communication managed by the tool, are both accessible, for input and output equally.
Synchronous text chat tools (such as Internet relay chat (IRC), ICQ, and others) allow two or more users to communicate via typed text messages in real-time. For a chat tool to be accessible, both the navigation system and the messages themselves must be accessible.
Audio-conferencing (via phone or Internet) allows two or more users to collaborate via real-time speech. In order to have access, users with hearing and speech disabilities must be accommodated by the system.
Video-conferencing allows two or more users to collaborate via real-time interaction that includes both video and sound. In order to be accessible, users with visual, hearing, and/or speech disabilities must be accommodated.
Whiteboards are the graphical equivalent of synchronous chat tools. They allow multiple users to work on collaborative drawings in real-time. They often include functionality for drawing, painting, and importing existing graphic files. In order for the system be accessible, both the navigation system and the content of the workspace must be accessible.
MOOs are multi-user virtual environments in which users often control "avatars" (computer-generated actors) that move through the virtual world, interacting and communicating via speech generated from user-typed instructions. In order to be accessible, both the environment navigation system and the communicative exchanges between avatars must be accessible.
Interactivity in online learning is the real power behind the medium. Compared to a passive text, a well-designed and highly interactive online lesson offers clear advantages in flexible content delivery as well as assessment.
Developers who create accessible interfaces, simulation, and interactive exercises for mainstream computer environments face considerable challenges in making their applications accessible.
The following section offers accessibility guidelines for developers of applications delivered via the Web, as well on platforms for AT is not available, such as DVDs and kiosks.
Section 3 Principles for Accessibility in Online Distributed Learning, presents some general principles to guide developers when creating accessible e-learning software, applications, and content.
Section 5 Guidelines for Accessible Delivery of Text, Audio, Images, and Multimedia, presents guidelines for creating accessible multimedia presentations.
This section provides additional information beyond that supplied in Section 3. However, it does not address specific accessibility issues of operating systems or programming languages. Subsection 8.7 lists resources that support specific development environments.
A comprehensive guide to application software accessibility is available from the Trace Center at: http://trace.wisc.edu/docs/software_guidelines/toc.htm
When designing an interface, developers should consider compatibility. It is important to understand how people with disabilities actually use their ATs and how those technologies integrate with software and underlying operating systems. Course designers, educators, and students all need to use the interface of a learning application, including buttons, text fields, text field labels, menus, and other components.
Many users of ATs encounter difficulty trying to use features normally accessed only by a mouse. Making the interface overly mouse dependant will surely cause difficulties for AT users, especially when navigating through content and other elements such as menu bars, tables of contents, and frames.
Forms must follow interface control guidelines in general. But when a large number of interface elements are displayed together in a single form, problems can arise that require other solutions.
When designing complex interactive activities, developers should take care that interfaces remain independent of the input and output requirements of different users. For example, drag-and-drop activities should be usable with either mouse or keyboard, and keyboard commands should be made as easy to execute as possible.
Also consider the manner in which information is displayed. Simulations can be made accessible by allowing for multi-modal output. For example, a computer-simulated chemistry experiment shows its results by changing the color of the liquid in an image from colorless to blue, be sure that the same information is available in text presented nearby or in a text tag associated with the image. Finally, remember that some users may respond more slowly than average to on-screen prompts, or may use an AT that slows down their rate of response. To accommodate this difference, always allow the user to customize timing requirements.
NCAM prototypes that demonstrate a talking math game and a talking science simulation at: http://ncam.wgbh.org/cdrom/guideline/download.html
The Digital Field Trip to the Rainforest CD from Digital Frog International "AT Version" with an accessible interface, descriptions of each image, and other access features at: http://www.digitalfrog.com/products/rainforest.html
Interactive tutorials present images of a software application in action are combined with audio or text narration, in order to teach users how to use that software. While adhering to interface guidelines, developers must also be sure to provide information in multiple modalities in order to meet the needs of all users. It is also important to remember that different users will need to know how to operate the software in different ways, depending on their accessibility needs.
Learning tools not available on computers may also present accessibility issues. Other solutions, for set-top boxes such as digital cable, are in development. Access techniques for devices such as handheld devices or personal digital assistants, require research. Accessibility techniques for these devices will inevitably be different from those provided for mainstream computer applications, since AT is not currently available on these platforms.
Some techniques for creating accessible software are specific to the development environment or operating system (OS). This section provides resources for developers working on the Windows OS and Macintosh OS, for Web developers, and for Java developers.
Microsoft provides detailed information on building accessible software for the Windows platform. The Microsoft Accessibility and Disabilities Group has created tools, documents, and APIs that offer ways to take advantage of access features in the OS. These tools also suggest other ways to make software more accessible. The Microsoft Windows Guidelines for Accessible Software Design provides comprehensive guidelines for creating accessible software.
In particular, the Microsoft Active Accessibility API (MSAA) uses programmatic means to help software communicate with ATs. MSAA exposes elements of the screen and presents their current state. It also exposes the focus, the active area of the screen. Using MSAA, software developers can use entirely custom graphical interfaces while still making each element known to an AT that has been programmed to read this information and convey it to the user.
All Macintosh computers ship with several accessibility features already installed. These features support users with sensory or physical disabilities. Developers may want to test their products with these features activated in order to determine whether their software is operable by users requiring AT. Some of these pre-installed accessibility features include:
In addition to the built-in accessibility features for the Macintosh, Apple maintains a list of Mac-based ATs available from vendors outside of Apple. OutSPOKEN is the only screen reader developed for the Macintosh platform. To ensure product compatibility on the Macintosh platform, developers should test their products using outSPOKEN. Macintosh users who are blind will not be able to use educational software if the product is not compatible with this screen reader.
Apple maintains a developer website that offers an array of resources including the Macintosh Human Interface Guidelines. This document provides "authoritative information on the theory behind the Macintosh 'look and feel' and guidelines for using individual interface components. This book includes many examples of good design and explains why one implementation is superior to another."
The definitive source for information on accessibility in Web technologies is the Web Access Initiative at the World Wide Web Consortium (the W3C WAI). The WAI provides recommendations for achieving accessibility using W3C technologies for Web content, authoring tools, and user agents such as browsers and media players. Information is available on W3C technologies including, XML, HTML, SMIL, CSS, and SVG.
The Java platform is an attractive development environment for creating accessible educational software. Java's strongest feature is the accessibility support that is built into Java's core structure. Its Swing user interface components support accessibility. They include an effective keyboard interface. The Java accessibility API, a standard extension in the Java 2 platform, enables Java-based ATs 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 ATs. The Java accessibility API also contains several properties that enable developers to fine-tune the manner in which assistive technologies present their interfaces.
A longer list of accessibility techniques for additional development environments is available at: http://www.w3.org/TR/ATAG10-TECHS/#check-use-system-conventions
The guidelines in this section are intended to promote access to tests and assessments by people with disabilities. We use the terms "assessment" and "test" virtually interchangeably, though "assessment" is often considered a more general term that includes tests. While distance learning presents important new opportunities for delivery of tests and assessments, much of this section pertains to almost any computer-based delivery or even non-computer-based delivery methods.
Since online assessment or testing takes place in a context where media is presented, even if that media is just text, most of the principles and guidelines pertaining to content described in other sections of this document also apply here. This section outlines some of the differences between the needs of testing and assessment and those of content-only delivery.
Much work has been done throughout the world to make media accessible to all, including the these very guidelines. Testing and assessment involve a step beyond media because they are more intimately tied-in with processes, activity, and organizations. Many of the central problems in achieving widespread accessibility of online assessment systems are, at this stage, problems needing research to clarify the issues and identify appropriate technological solutions. This section presents the state of current issues and some principles that can be identified to point the way for future work.
This document is addressed to various stakeholders who provide the assessment, including assessment designers, content authors, validation bodies, organizations providing assessment delivery, and so forth. Different stakeholders may be involved in different parts of the process and concerned with very different kinds of assessment with different constraints. For example, a test designed to detect dyslexia in young children and a self test for Computer Science undergraduates to diagnose their own programming skills may need to handle accessibility very differently.
As discussed below, one over-arching consideration is that in high-stakes testing, where the consequences for individuals are great, there needs to be a very careful consideration as to the potential effects of accessibility provisions on the validity of the scores derived from the testing.
There are two broad classes of assessment, and their accessibility requirements differ.
Low-stakes assessment is a form of assessment encompassed by the immediate process of learning, often in a very short feedback loop, such as exercises or quizzes. Sometimes this is called "formative" assessment or even just "feedback". The essential characteristics are immediacy and the lack of serious consequences contingent on performance.
Making low-stakes assessment accessible means providing equivalent content modalities and access mechanisms wherever possible. For example, buttons in a form or other interactive controls should not be labeled only with images and without accompanying text. A good solution would provide the label information in a form that allows for runtime generation of equivalents or alternative renderings. Controls must also be accessible through the keyboard as well as the mouse. The overall goal is to make systems and content as flexible and adaptable as possible. All of the solutions explained elsewhere in this guide apply at this media level. The goals of this kind of assessment are intimately tied up with learning. In general, accessibility requirements can be in conflict with the need to ensure assessments are valid, but here we are chiefly concerned with learning and so this is not a serious issue.
High-stakes assessment has consequences that may have a serious impact on the life-course of the participant. An example might be a university entrance examination.
It is important that a high-stakes assessment be fair to all candidates and not offer advantages to one group over another. The goal is to make systems and content as accessible as possible while adhering to validity requirements. Ideally, for example, an examination candidate should not be excluded from an examination or have performance disadvantaged where the candidate's disability is unrelated to the skills or knowledge being tested.
Assessment providers need to be able to control, in a flexible manner, which alternatives are available in order to protect the validity of inferences made from the test scores. It may be that allowing one set of alternatives has no consequences of fairness for particular candidates for that assessment while allowing others does. What is needed is fine control and rigor in the use of alternatives, and building-in this kind of control can affect design choices for both the content, as well as the delivery system and authoring tools. Taking the images and alternatives problem described above as an example, one delivery system may provide for particular alternatives to be enabled or disabled under system control at runtime, whilst another may not. For some group of candidates and assessments this may or may not be important, but the widest reuse of accessible assessment material for high-stakes assessment can only be obtained with the provision of appropriate mechanism. There are however many other considerations in building-in such a mechanism.
Developers and educators should make good use of alternative media and delivery technologies when designing assessment systems and tools. They will likely need to allow assessors greater control over alternatives as well as better use of accommodations and easier integration of disabled users. Accommodations refer to changes in the content, format, and/or administration procedure for individuals who are unable to take assessments under standard (or default) conditions.
There are several challenges in developing and delivering tests and assessments that can be used by people with disabilities, including:
The following are four principles to help guide the implementation of solutions for ensuring access to testing and assessment by people with disabilities. Developers should:
The relative emphasis among these principles is different for low-stakes than for high-stakes assessment.
From the earliest design stages, test developers consider accessibility standards. For example, they need to consider including text to accompany images, as well as captions and auditory descriptions to accompany video. Such alternative content is usually best created by those individuals who are well acquainted with the original content. Designing alternative content early in the process can help eliminate costly retrofits. Details about such accessibility standards are found throughout other parts of these guidelines.
Validity is a preeminent concern in tests and assessments. The Standards for Educational and Psychological Testing, (hereafter called Standards), published by the American Educational Research Association (AERA), American Psychological Association (APA), and National Council on Measurement in Education (NCME) defines validity as:
The degree to which accumulated evidence and theory support specific interpretations of test scores entailed by proposed uses of a test (Standards, 1999).
According to Willingham and Cole (1997):
Validity is the all-encompassing technical standard for judging the quality of the assessment process. Validity includes, for example, the accuracy with which a test measures what it purports to measure, how well it serves its intended function, other consequences of test use, and comparability of the assessment process for different examinees. (p. 228).
Validity is a major theme in chapter 10 of the Standards, which focuses on testing individuals with disabilities. Standard 10.1 (the first of 12 disability-related standards) is essentially about validity. It states: "In testing individuals with disabilities, test developers, test administrators, and test users should take steps to ensure that the test score inferences accurately reflect the intended construct rather than any disabilities and their associated characteristics extraneous to the intent of the measurement" (Standards, 1999, p. 106).
While accessibility features are essential for overcoming threats to validity, some accessibility features can actually pose threats to validity. Oftentimes, the nature of the threat and the proper solution can be ascertained through basic logical analysis. For example, if a physical disability would prevent a person from recording their responses on a math test when administered with the default response method, then the incompatibility between their disability and the default response format constitutes a major threat to validity. It is fairly obvious that providing an alternative response method such as using an AT or a human scribe to record the answers would likely be a proper accommodation. Providing such an accommodation could improve validity.
But sometimes an accessibility feature can diminish validity. Suppose, for example, that an art test that is intended to measure a student's ability to write descriptions of artwork (such as paintings), and that the questions present visually displayed pictorial images of the artwork as prompts. Standards for accessibility might require that text descriptions of the artwork be made available to the test taker. However, to do so would make it virtually impossible to detect the test taker's proficiency in producing the text descriptions, thereby posing a threat to validity. For a test taker who is blind, a better approach might be to provide a tactile graphic of the artwork rather than the text description. Or alternatively, if the questions with pictorial images constitute only a small portion of the total art test, one might consider not administering such questions to test takers who are blind. Thus, for any given test and test-taker, not every accessibility feature necessarily promotes validity. Accessibility features need to be examined for their impact on validity.
Another example concerns the use of a readaloud accommodation in a test of reading comprehension. The test performance of a person who is blind might benefit from having content read aloud to them by synthesized speech or by prerecorded or live human speech. However, suppose that this test of reading comprehension includes decoding words from letters as part of the construct (intent of measurement). In this case, a readaloud accommodation would essentially prevent student performance from serving as a source of evidence about decoding ability since hearing the words spoken would not require decoding in order to answer questions correctly. This scenario would suggest that providing the readaloud accommodation may invalidate the test and that, therefore, the readaloud accommodation should not be allowed. However, the decision about whether to actually allow a readaloud accommodation might involve additional considerations. For example, one might ask additional questions:
The need to examine many factors in making decisions regarding test takers with disabilities points to the need to be able to call on experts when needed. As suggested earlier, the rigor required for accommodation decisions will tend to be greater in high-stakes than in low-stakes testing. Thus, in many instances, basic logical analysis of what the test is intended to measure will make clear what kinds of accommodations will promote validity; in other cases, a more careful analysis and consultation with experts may be essential.
To the extent possible, one should seek to build a coherent rationale for the claims that one makes about the proficiencies (i.e., knowledge, skills, and abilities) of test takers, including test takers with disabilities. Evidence-centered assessment design (Mislevy, Steinberg, & Almond, in press), a design method that emphasizes explicit evidentiary argument, may help strengthen the technical quality of test or assessment. In the case of individuals with disabilities, this argument must encompass not only claims about student proficiencies, but also about comparability of scores based on different formats or conditions of administration for people with disabilities. Evidence-centered design focuses on developing a coherent argument involving:
Consider, for example, a person who consistently answers test questions incorrectly. Generally, one would claim that the test taker lacks the targeted proficiency. However, an alternative explanation for poor performance would be that the test taker has a disability (e.g., blindness) that prevents the test taker from manifesting their true proficiency level under the default testing conditions (regular-sized visually-displayed text). Addressing such an alternative explanation might involve ensuring that (a) candidates are made aware how they can request testing accommodations, (b) the requests for accommodations are examined by a panel of qualified experts, and (c) if the accommodation is approved, the test taker has adequate opportunity to become familiar with the accommodation before using it in the actual test. Obviously, the efforts to address alternative explanations are all the more important in high-stakes settings. Note that the activities to address alternative explanations are diverse and that they often occur in the pre-assessment phase of testing, before the candidate has answered any questions.
Evidence-centered assessment design, particularly its domain modeling stage, can provide a systematic approach for examining accommodations and their appropriateness. Provision of appropriate accommodations seek to match test-taker background characteristics (e.g., blindness, knowledge of Braille) to task features (e.g., readaloud or Braille versions) that are intended to overcome access hurdles without conflicting with the claims that one wishes to make about test-taker proficiencies. The explicit modeling of proficiencies (both those targeted for measurement and those not targeted) can assist in identifying features of the task performance situation that are likely to result in sound measurement.
Evidence-centered design can also make explicit the constraints on the reporting of test scores. Social policy considerations, for example, can be important constraints on reporting of test results. Reporting information about accommodations might help a test score user interpret scores (Lewis, Patz, Sheinker, & Barton, 2002; Standard 10.11 of Standards, 1999). Yet laws and other rulings designed to address the possibility of discrimination against test takers with disabilities may restrict the inclusion of certain information in reports. Evidence-centered design's support for analyzing, modeling, and representing social policy, legal, and other constraints can promote the cohesion of various parts of an assessment argument.
As in any design process, the quality of the outputs from an evidence-centered assessment design process is dependent on the quality of the inputs. Some information that would be useful as inputs to the design process, such as studies of the impact of accommodations test performance and validity can be difficult to obtain due to factors such as small sample sizes, variability in examinees, and variability in accommodations (NRC, 1997; Standards, 1999; Pitoniak & Royer, 2001). While an evidence-centered approach cannot replace the generation of new knowledge through research and development, it can help leverage the value of existing knowledge through sharing and reuse between and among test developers and stakeholders and across related testing applications.
Reuse of assessments designs and of test content is a fundamental strategy for promoting efficient and valid assessments. Striving for reuse impels one to identify commonalities across assessment settings, audiences, and delivery systems.
One important kind of reuse that deserves careful attention is reuse of test content. For example, one of several goals in the design of an "accessible" test might be that the text portion of the test content could be reused across several presentation formats such as (a) visually displayed text for test takers who are deaf or non-disabled, (b) synthesized speech for test takers who are blind, and (c) Braille for individuals who are deaf-blind or blind. Ideally, there would be nothing peculiar to a specific presentation format that would require a different source text for each of these presentation formats. While complete reuse of test content may be a good design goal, one also needs to be ready for the possibility that content -- text content in this example -- might not be completely reusable across test formats. For example, acronyms that might make sense in print to a sighted test taker may voice improperly in synthesized speech used by a person who is blind. Ensuring proper access by the person who is blind and receiving content via audio might require, for example, that letters be separated by spaces to facilitate proper voicing. In some content areas, different formats may require supplementary media such as tactile (raised-line) drawings of math figures, and the on-screen content may need to alert the user about the availability of such. Specialized directions may be necessary for different formats. These kinds of differences between formats may reduce certain kinds of test content reuse.
It follows that a sensible strategy for reuse should include test content but should also extend further, for example, to include reuse of assessment designs. As suggested earlier, an assessment design that comprises an explicit argument can promote greater reuse. Furthermore, strategies for reuse should not overlook the reuse of personnel and other test development and delivery resources.
Delivery and authoring tools need to support mechanisms for authoring, storing, and using accessible assessment content. Many of these mechanisms are identical to those described throughout this document, but some concerns are specific to the authoring and delivery of assessments.
Note: This is for work in a future version, but may be expected to include:
Enabling flexible, accessible assessment content will require encoding additional information in the meta-data about each assessment item and its alternatives. Other concerns are specific to the development of assessments.
Note: This is for work in a future version, but may be expected to include purpose information which is needed at multiple levels including
Note: This is for work in a future version.
In the effort to open the learning experience to all, it is critically important to make content creation a simple and natural part of the authoring process. One goal of these guidelines is to assist authors who may have limited knowledge of accessible authoring practices. Ideally, authors who may not have any knowledge of accessible authoring practices should still be able to create accessible material using proper authoring tools.
An authoring tool is any software tool that can be used to create content that can be displayed in an online learning environment. Authoring tool accessibility should be approached from two perspectives:
An authoring tool can support and encourages the creation of accessible content or learning materials by following several guidelines delineated in the W3C WAI Authoring Tool Accessibility Guidelines at: http://www.w3.org/TR/WAI-AUTOOLS/
The Guidelines are accompanied by a techniques document that suggests how the guidelines can be implemented using various tools. In summary, an authoring tool should encourage the author to adopt accessible authoring practices and assist the author in checking and repairing content as it is being authored. The tool should not only offer mechanisms for creating accessible content, but should make these mechanisms easy to use. Accessibility supports should be seamlessly integrated into the look and feel of the tool and well documented in the help function and documentation supplied with the tool. Any content automatically generated by the tool or any choices made for the author by the tool, should also support accessibility.
It is critical that the authoring tool itself must be accessible to educators and learners with disabilities. Tool developers must follow platform-specific user interface accessibility standards. They must also provide supports for accessible navigation of the document and provide flexible presentation of the content to be edited (as discussed in both the W3C WAI Authoring Tool Guidelines and Techniques documents at: http://www.w3.org/WAI/AU/)
In a courseware development environment, these guidelines need to be applied equally to the interfaces used by the administrator, the educator or instructor and the learner or student. All three of these user groups are potential authors. The courseware development environment should also provide checking and repair tools to help detect and fix access problems in content authored using third-party authoring tools. A powerful means of ensuring that learning content is accessible within an educational institution is to provide templates and models that are accessible.
This section focuses on specific domains of content that depend heavily on modes of presentation that fall outside of the bounds of pure text.
It should be noted that every learner stands to benefit from content made accessible to those with disabilities, particularly with respect to the specific topic areas under consideration in this section. For example, mainstream users of the Web rarely get access to "live" mathematics, and many users of content on the Web find it difficult to comprehend mathematical content. Many of the support strategies devised to make mathematical content more accessible to those with disabilities also provide support to the larger student population.
Similarly, science students also need to decode mathematical expressions, and they also must have access to laboratory experiments. Online simulations of lab exercises or remote use of real lab equipment are helpful to all students.
Likewise, graphs and diagrams can present a barrier to learning even for students who have no visual impairment. By supporting graphical content with text descriptions and discussions, developers improve the prospects of all learners who use their products.
And finally, students who study material presented in foreign languages or with the use of non-standard codes (e.g., music notation) also stand to benefit from supporting text.
The challenge of presenting alternative "views" of symbolic and semantic content makes up the leading edge of accessibility research today and many problems have yet to be solved. This document presents an overview of approaches currently in development or in use in fields such as:
In general, people use mathematics on the Web to represent ideas and to teach mathematics itself. Mathematical expressions are also used interactively to manipulate data, for both educational and work-related pursuits.
Two main types of problems inhibit accessibility. As with other graphical content, mathematical symbols are inaccessible when presented simply as graphics without supporting text descriptions or discussions. But even when mathematical expressions are expressed as text, they sometimes cannot be interpreted by screen reading software.
This document goes on to examine accessibility problems and their solutions in some detail, but in general, we can summarize the steps that content creators and users should take to improve accessibility.
Mathematical writing can be complex. The ability to choose which parts of an expression to make visible or available helps both novices and experts to read a mathematical argument or text. "Chunking" provided by both stylesheets and SVG organizes the display of mathematical expressions. The following expression provides an example.
"This formula: makes it possible to predict the result with accuracy."
With an accessible math reader in place, the user would hear the above spoken as:
"This formula, a cubed plus b cubed equals brackets, a plus b, brackets, a squared minus ab plus b; squared, makes it possible to predict the result with accuracy."
Learners would better comprehend the formula if they were allowed to choose a stylesheet that omits the formula from the initial reading. In this case, the learner would first hear:
"This formula makes it possible to predict the results with accuracy."
To then hear the formula, the learner could switch to a mathematical stylesheet to read the formula in detail.
If equations are presented as graphics, users who cannot see the graphic have no idea what is on the screen. Other problems include:
Mathematical Mark-up language, or MathML, (from W3C at http://www.w3.org/Math/) is an XML mark-up language for mathematical notation written with universal accessibility as a priority. It offers two formats for representing an expression: presentational tags and semantic/content tags. Users can write expressions using an accessibility-compliant editor and then view or access symbolic representations on the Web with an accessibility and MathML standards-compliant user agent. Usually this requires a MathML-enabled Web editor such as Amaya (freely available from the W3C at http://www.w3.org/Amaya/), or a mathematics application (see the W3C's list of MathML compliant browsers and the list of MathML compliant mathematical software).
If mathematics on the Web is marked up properly in MathML, it may be possible to access it directly by using a mathematical symbolic editor that understands MathML and is itself accessible. A comprehensive list of these is available from the W3C math website at: http://www.w3.org/Math/
Authoring tool developers, including people who make templates for others to use, face accessibility problems, specific to MathML. MathML is not yet widely used, is not native to commonly used browsers, and many of the older courseware packages are not accessibility-aware. The landscape is changing but it is still unlikely that courseware developers will be able alleviate the problem quickly enough. However, there are plug-in solutions that might be useful to courseware developers.
In the meantime, toolmakers can help their users solve this problem by presenting best practice information and, where possible, incorporating software that supports good mathematics mark-up.
Visit the MathType website at http://www.dessci.com/webmath/ to learn how to write mathematics notation in Word (Equation Editor), translate them into MathML using WebEQ generator (a shareware translator) and allow users to view the notation using graphical browsers augmented with the free WebEQ plug-in. The W3C Math home page also provides MathML information at: http://www.w3.org/Math/
The Audio-Accessible Graphing Calculator is a self-voicing Windows application that is under development by the Science Access Project at Oregon State University. It includes the capabilities to:
The Audio-Accessible Graphing Calculator is available at: http://dots.physics.orst.edu/agc.html
Braille 'n' Speak is a Braille note taker that can also serve as a calculator which can do standard math. Additional software is available for students needing the power of a financial calculator. The Braille 'n' Speak can also be used to generate tactile graphs using the graphing calculator software Graphit in conjunction with any Braille embosser.
Information about the Braille 'n' Speak is available at: http://www.freedomscientific.com/fs_products/notetakers_bns.asp
Information about Graphit is available at: http://www.freedomscientific.com/fs_products/notetakers_related.asp#graphit
As with mathematics, it is important to develop a mark-up standard that can be used to encode and decode scientific expressions for accessibility. In addition, many branches of science have discipline-specific 2D and 3D representations that need to be rendered on the screen.
Equations are often presented as graphics to users who cannot see the graphic and have no idea what is on the screen. Also, scientific symbols are often inaccessible to people who are using screen reading software.
The following subsections present solutions to enhance the accessibility of chemistry and physics.
Other fields, such as astronomy, biology, and geology still await the development of appropriate accessibility aids.
A useful resource on accommodating students with disabilities in math and science classes from the University of Washington's DO-IT program can be found at: http://www.washington.edu/doit/MathSci/
The chemistry equivalent to MathML is ChemML. ChemML enhances accessibility by allowing the developer to use suitable stylesheets. Like MathML, ChemML must be embedded within XML (or XHTML). CML is a version of ChemML.
For more information about ChemML visit: http://www.xml-cml.org/information/position.html
To make chemistry accessible, ChemML interoperates with other mark-up languages and XML protocols including:
Accessible science experiments in chemistry and physics are available from Barrier Free Education at: http://barrier-free.arch.gatech.edu/Lab/index.html
The Accessible Periodic Table (ATRC) is a haptic periodic table under construction that will give students a "feel" for the periodic table and the elements. It is a worthy attempt to use haptics to increase the dimensions of data available from the table (e.g., the weight of elements). For more information visit: http://nide.snow.utoronto.ca/hperiodic.htm
"Teaching Chemistry to Students with Disabilities" is available from the American Chemical Society Committee on Chemists with Disabilities at: http://membership.acs.org/C/CWD/teaching/start.htm
"Working Chemists with Disabilities: Expanding Opportunities in Science" from the American Chemical Society Committee on Chemists with Disabilities is available at: http://membership.acs.org/C/CWD/workchem/start.htm
The Access to PIVoT (Physics Interactive Video Tutor) project identifies and addresses the needs of deaf and blind students in the design of user interface and navigation systems. It all supports the presentation of video, text, illustrations, graphs and tables. NCAM is working with MIT to develop and apply methods for improving website layout and navigation, access to complex graphics, illustrations and equations, as well as to create captions and audio descriptions for the multimedia.
PIVoT allows students to interact with a renowned MIT physics professor using streaming digital video over the Internet. The PIVoT website offers online multimedia content for students in MIT's introductory physics course covering classical mechanics.
For more information on PIVoT visit:
Request a PIVoT guest account at:
The American Physical Society provides information on physics and persons with disabilities at: http://www.aps.org/memb/disabilities.html
Students are not always able to participate in live experiments. Either distance or physical disability can stand in the way of a traditional "hands-on" learning experience.
Simulations and artificial environments created by "immersive technologies" can provide equivalent alternatives to real life experiences. Working with one's hands in three dimensions provides alternative opportunities for interaction with content. Access to simulations and immersive experiences should be available for all users. Several technologies currently exist, including:
For students who participate in laboratory work from a distance or who have a physical disability, the inability to physically manipulate objects can interfere with the learning process.
Several technologies that make robots available to students to allow them to manipulate objects are under development.
Because of their visual nature charts, diagrams, and tables present a real problem for learners with visual impairments. But other students also have difficulty interpreting graphical information, including those with learning disabilities. To be accessible charts, diagrams, and tables cannot be allowed to stand on their own. They must be paired by other kinds of information and conform to the needs of interpretive technologies.
Making charts, diagrams, and tables more accessible means presenting the same information via a non-visual sensory channel. Interactive audio descriptions elaborating the graphic elements and guided by the user are a standard tool.
However, a number of technologies that directly translate the graphic into an object that can be touched are in development and they are proving to be powerful learning tools. These include both technologies that create a permanent physical object through a version of printing, as well as technologies that use a refreshable touch display analogous to a computer screen.
Using the sense of touch to comprehend graphical information depends on the user's ability to assimilate a mental spatial image of the material. A tactile image reduces the mental effort, and a combination of touch and audio (or braille) feedback has been found to be very successful in making maps and other graphics accessible to blind users.
Unfortunately, there are no technologies for displaying refreshable tactile images online. However, it is possible to make a tactile copy of a computer picture. With this figure installed on a touch screen or other digitizing tablet a blind user can feel the tactile images, and receive audio feedback from the computer about those images. Tactile copies can be made using swell paper or tactile printers. Swell paper is a special paper that swells when radiant heat is applied to black areas, enabling users to feel images. One source of swell paper and the equipment needed to use it is available from Repro-tronics Inc.: http://www.repro-tronics.com
A commercially available tactile printer is the TIGER printer (TactIle Graphics EmbosseR). It is available from ViewPlus Technologies, Inc. More information is available at: http://www.viewplustech.com
A touch screen that can be used with tactile graphics is the NOMAD Pad. This touch-sensitive pad connects to the user's personal computer and allows the user to place raised-line graphics as an overlay on the pad. Once an appropriate file has been selected, the user can touch various points on the graphic and NOMAD will describe them with synthetic speech. TouchBlaster Software is included with NOMAD pads. It provides digitized sound, a simplified menu option and a stand-alone mode that incorporates a built-in Braille alphabet. More information about NOMAD is at: http://www.rit.edu/~easi/easisem/nomadaph.html
Off-line printing makes it difficult for blind users to take advantage of computer-supported features like zoom views. A number of online haptic technologies are in development and will find use with virtual reality applications. One such technology, the haptic mouse, has already been introduced by several companies including Immersion Corporation (San Jose, CA, USA) and Control Advancements (Kitchener, Ontario, Canada).
Haptic perception allows those with visual impairments to comprehend the representational content of an image in the same way that visual perception allows those who can see to infer three-dimensional images from two-dimensional images.
The exact way in which a person learns to "read" a two-dimensional representation of a three-dimensional object depends on environment. Different cultures represent the third dimension differently. In the western tradition, "perspective points" determine the form of representation.
For people who feel, rather than see 3D representations, the objects become folded out (e.g., a Coke can might be represented as a flat side and two round ends) and perspective is portrayed differently. In this tactile culture, 3Dness is not represented via perspective, as it is for sighted people, but rather via relativity (see the haptic perception image below).
These two haptic versions of a four-legged table are two equivalent solutions for flattening a long table. The upper representation is chosen if the table is surrounded by other objects, the lower one if objects stand on the tabletop.
For an interesting paper that discusses this issue visit: http://www.inf.fu-berlin.de/~kurze/publications/chi_97/mk-hapt.htm
The National Centre for Tactile Diagrams at the University of Hertfordshire, UK, offers guidelines for making haptic maps and images. Those guidelines and a collection of haptic images can be found at: http://www.nctd.org.uk/#diagpro
Another source, the American Printing House for the Blind offers both ready-made graphics covering a variety of subjects and custom-made graphics following user specifications. Visit: http://www.aph.org
Finally, anyone can make tactile graphics using a number of common objects such as puff paint, glue, a hot glue gun, drafting tape, yarn, or similar tools.
Charts, diagrams, and tables can also be represented in text, using similar techniques to those use for equations (ALT attribute and long description, for example). Text can be generated by content authors who summarize the information provided by the graphic and give a detailed listing of any data.
A tool called PopChart Xpress from Corda Technologies can be used to create accessible Web-ready charts from data copied from a spreadsheet. It is best used to represent charts with static data. Corda also offers PopChart, which is a server application for websites that need to make a large number of charts accessible, or to adapt charts that access data in a database. More information is available from Corda at: http://www.corda.com. Examples of interactive, data-driven graphics are available from Corda at: http://www.corda.com/examples/example-s.cfm
Spatial information, particularly represented as maps, creates a number of obvious problems for users who do not have access to the full range of multimedia including graphics, color differentiation, sound, and so on. There are two kinds of maps available online - those stored as data and those stored as graphical images. Maps comprised as data can be more easily made accessible than those stored graphically.
Most maps are produced from textual information that is held in databases. Currently the best means of representing maps for users with impairments is to print them on a haptic printer that can create different tactile representations according to graphic detail. What a visual learner might see as a change color might be a change in texture on a haptic map.
Data-driven graphical representations of all kinds, including maps, should be rendered as SVG, a W3C recommended language. SVG objects are, as the name implies, scalable; they can be enlarged without deterioration. SVG contains meta-data associated with individual objects and in fact be built out of a set of objects. This means that a composed image, such as a map of a school playground, can describe both its composition as well as the objects used in that composition.
Similarly, developers should attach stylesheets to the objects and even to the relationships between them so that audio, haptic, or other representations can be generated from that data. Using SMIL, voice, captions, descriptions, and other representations can thus be attached to the objects.
Work is being done on making images audible. For more information, see The Voice - Vision Technology for the Totally Blind at: http://www.seeingwithsound.com/voice.htm
It should be noted that not all blind people can read Braille and Brailles differ. So sound maps are a good alternative. Sound cues are also useful for dyslexic, illiterate, and foreign language learners. For more information, visit: http://garnet.acns.fsu.edu/~djacobso/haptic/press/press93106.html
For other resources that outline the benefits of using tactile maps when trying to learn spatial concepts and while learning to move about in space visit: http://garnet.acns.fsu.edu/~djacobso/haptic/pub/hapticabstracts.html
And for more information regarding haptic maps and the haptic mouse visit: http://garnet.acns.fsu.edu/~djacobso/haptic/press/pressksby.html
Music notation is a code unto its own and most screen reading software can't translate it to speech.
In the past, only a small number of specialists had the skill to produce Braille music. For example, a blind flutist wishing to participate in the school band would need to send copies of the musical score to a transcriber. Because of the busy schedules of these specialists, it could take weeks or months to translate the score into Braille.
Today, using a computerized translator, transcriptions of sheet music can be produced locally in a few hours by sighted copyists with no special training in music Braille. A number of products are making music notation more accessible to those with visual impairments.
The Web is becoming increasingly internationalized. As it does so, language issues present a considerable barrier to access. Switching alphabets often involves much more than a simple change in font. It is not easy to allow for the wide variety of character representations that make up written languages, let alone integrate "texts" that run from left to right, with those that run from right to left, or top to bottom. In addition, many languages are not written using phonetic alphabets at all.
The most effective answer to these problems so far is a work-around that relies on Unicode, coupled with SVG, SMIL, and stylesheets. Unicode is a more complex matrix set than the original ASCII character set developed in the early days of computing. With the involvement of so many languages on the Web today, Unicode provides a way to develop new character sets for languages that have not traditionally been used in computer interfaces. Using Unicode comes at a price, however. Most legacy software does not understand Unicode, and only a few browsers can cope with it. So there will be a transition period during which Unicode will need specific support and promotion, as well as the development and use of plug-ins.
Layout options are no longer a problem, and the use of Unicode is becoming far more widespread in authoring and access packages.
Basic accessibility requirements expect that a change in the language within a document will be flagged with tags that indicate the name of the language that follows. For more information visit the W3C Internationalization site at: http://www.w3.org/International/
There are a number of new standards and practices that, in combination, make it possible to create interesting multi-lingual pages. Language tagging (i.e., indicating a change of language) is an accessibility requirement. Because some of the challenges that arise when working with foreign languages, (e.g., combining several languages within a single Web resource or working with non-English languages) developers should consult the W3C Internationalization help pages at: http://www.w3.org/International/O-help.html
Ruby annotation, a W3C recommendation, is a run of text that is associated with another run of text, referred to as the base text. Ruby text is used to provide a short annotation of the associated base text. It is most often used to provide a reading (pronunciation guide). Ruby annotations are used frequently in Japan in many kinds of publications, including books and magazines.
In those cases, ruby texts might appear on either side of the base text. The ruby text that appears before the base text is often meant to indicate reading while the lower text is meant to indicate meaning.
The following is such an example: center base text with two ruby texts above and below. The base text is Japanese Kanji pictograms. The upper ruby text offers a phonetic guide in Japanese Hiragana and the lower text offers a phonetic guide in Latin letters.
The W3C Ruby specification defines Ruby mark-up to be usable with XHTML, so that ruby text is available on the Web without using special workarounds or graphics. For more information visit: http://www.w3.org/TR/ruby/
Ruby accessibility techniques are available at: http://www.w3.org/TR/ruby/#non-visual
Documents that contain Ruby mark-up may need to be rendered by non-visual user agents such as voice browsers and braille user agents. For such rendering scenarios, it is important to understand that:
This summary of legal issues in various countries is not intended to be exhaustive or to provide legal guidance. It is instead a resource for finding information about relevant legal requirements in countries where that information is available.
The United Nations has an Overview of International Legal Frameworks for Disability Legislation available at: http://www.un.org/esa/socdev/enable/disolf.htm
A number of countries have established policies on accessibility of government websites. These policies may or may not include requirements for distance learning services delivered by those governments. A list is maintained by the Web Accessibility Initiative at: http://www.w3.org/WAI/Policy/
Several countries have more detailed policies that specifically apply to education as described here:
Australia has a Disability Discrimination Act (1992) which applies to education. Draft disability standards have been developed. For information, see: http://www.hreoc.gov.au/disability_rights/education/education.html
In addition, state-by-state regulations for accessibility of government websites are summarized in: http://www.ozewai.org/presentations/webb-legal.html
Canada has a Charter of Rights and Freedoms that guarantee the basic rights and freedoms important to Canada as a free and democratic society. For more information, see the Guide to the Canadian Charter of Rights and Freedoms: http://www.pch.gc.ca/ddp-hrd/canada/guide/index_e.shtml
The Canadian Government has also established a Common Look and Feel for government websites, which includes accessibility provisions. Details are available at: http://www.cio-dpi.gc.ca/clf-upe/index_e.asp
In addition, some Canadian provinces have separate disabilities legislation. See especially the Ontarians with Disabilities Act: http://www.gov.on.ca/MCZCR/english/about/odaintroduction.htm
The Special Educational Needs and Disability Act takes effect on 1 September 2002. The Act removes the previous exemption of education from the Disability Discrimination Act (1995), ensuring that discrimination against disabled students will be unlawful. Institutions will incur additional responsibilities in 2003, with the final sections of legislation coming into effect in 2005.
A summary article (from which this brief introduction was taken) is available at: http://www.techdis.ac.uk/articles/SENDRE.htm
Codes of Practice developed by the Disabilities Rights Commission are available from: http://www.drc-gb.org/drc/InformationAndLegislation/Page34A.asp
Policies are now in place or under consideration in several markets and jurisdictions in the United States that make accessibility a requirement for distance learning.
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, secondary, and post-secondary educational institutions are regulated under these laws. A useful legal analysis of these requirements is provided in the California Community Colleges' Distance Education Access Guidelines, available at: http://www.htctu.fhda.edu
The U.S. Department of Education Office for Civil Rights enforces these laws. Visit: http://www.ed.gov/ocr/disability.html
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 which 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:
A partial list of U.S. states with accessibility requirements for government Web pages is at: http://www.resna.org/taproject/policy/initiatives/508/atprojects.html
Some states have instituted additional requirements, including the following:
California Higher Education Requirements
The California Community College system has released Distance Education Access Guidelines and Alternate Media Access Guidelines. The Alternate Media Access guidelines serve as a guide for the implementation of California law AB422 requiring publishers to provide textbooks in electronic format to the three systems of higher education in California (the University of California, the California State University, and the California Community Colleges). The Distance Education Access Guidelines include a summary of legal requirements as well as access guidelines for specific modes of distance education instructional delivery. These documents and other resources are available from: http://www.htctu.fhda.edu
Texas K-12 Textbook Adoptions
Texas has for several years been studying the issue of access to electronic books and educational software for students with disabilities. Two reports, one issued in 1997 and one in 1999, provide information on how educational materials can be made accessible. Texas requires publishers to provide electronic files for adopted print materials and is in the process of incorporating the U.S. Federal Section 508 requirements as an optional part of their adoption process for interactive educational software and electronic textbooks. Texas reports on textbook accessibility is available at: http://www.tsbvi.edu/Education/index.htm#Textbooks
The following is compilation of the websites referenced throughout the document, sorted in order by the section in which they appeared.
Learning Anytime Anywhere Partnerships (LAAP)
CETIS (Centre for Educational Technology Interoperability Standards)
DEST (Department of Education, Science, and Training - Australia)
ETS (Educational Testing Service)
IMS Global Learning Consortium
NCAM (National Center for Accessible Media)
The Open University (UK)
Sheffield Hallam University (UK)
University of Toronto ATRC (Adaptive Technology Research Centre)
Accessible Software Guidelines from the Trace R & D Center
Application Software Design Guidelines from the Trace R&D Center
U.S National Institute of Neurological Disorders and Stroke Dyslexia Information page
Learning Disabilities Resource Community
Resources on Computers and Learning Disabilities from the Trace R & D Center
Technical Glossary of Adaptive Technologies from the Adaptive Technology Resource Centre at the University of Toronto
IMS specifications (openly available to the public and available free of charge)
XML Accessibility Guidelines from the W3C
XML Accessibility Guidelines from the W3C
Accessibility Features of SVG from the W3C
SVG Document Structure
Accessibility Features of SMIL from the W3C
Media Access Generator (MAGpie) from NCAM
DAISY (Digital Audio-based Information System)
Open eBook Forum
User-Friendly Materials and Alternate Formats from The National Center for the Dissemination of Disability Research
Guidelines for Producing Instructional and Other Printed Materials in Alternate Media for Persons with Disabilities from the California Community Colleges
Media Access Generator (MAGpie) from NCAM
Tips on Presenting Alternatives to Sound from CAST (Center for Applied Special Technology)
"SigningAvatar" from Vcom3D
Making Images Accessible from SNOW (Special Needs Opportunity Windows)
Techniques for Web Content Accessibility
Guidelines 1.0 from the W3C (section 2.1.1 - techniques for providing
alternatives to auditory and visual content)
Use of ALT texts in IMGS from the Web Design Group
A tutorial from WebAIM, including code examples,
illustrating the W3C Web Content Accessibility Guidelines 1.0
recommendation checkpoint for providing "equivalent alternatives to
auditory and visual content"
Scalable Vector Graphics (SVG) Specification from the W3C
SVG Accessibility Features from the W3C
Rich Media Accessibility Resource Center from NCAM
A tutorial on Creating Audio Descriptions for Rich Media from NCAM
A tutorial on Creating Captions for Rich Media from NCAM
Web Content Accessibility Guidelines from the W3C
Examples of accessible threaded message boards from WorldEnable Internet Accessibility Discussion
Authoring Tool Accessibility Guidelines from the W3C
Examples of accessible document repositories from WAI Mail Archives
WAVE accessibility evaluation tool
The University of Illinois' Microsoft Power Point WWW Publishing Accessibility Wizard
W3C Slidemaker Tool
CAST (Center for Applied Special Technologies)
EASI (Equal Access to Software and Information)
SNOW (Special Needs Opportunity Windows)
University of Washington DO-IT Program (Disabilities, Opportunities, Internetworking, and Technology)
NCAM (The CPB/WGBH National Center for Accessible Media)
Application Software Design Guidelines from the Trace R&D Center
Making Educational Software Accessible: Design Guidelines Including Math and Science Solutions from NCAM
Prototypes of accessible educational software are from NCAM (a talking math game and a talking science simulation)
Digital Field Trip to the Rainforest AT Version from Digital Frog International
Technical details on how to create talking DVD menus from NCAM
Abraham and Mary Lincoln: A House Divided
an accessible DVD, includes talking menus for access to navigation by
blind viewers and access features for the program for both blind and
Set-Top Box Accessibility information and a prototype Electronic Program Guide from NCAM
Information about accessible kiosks and touch screen interfaces from EZ Access at the Trace R & D Center
V2 Support Project at the Trace R & D Center
Microsoft Accessibility Home Page
Microsoft Accessibility Information for Developers
Apple Education Disability Resources
Macintosh Human Interface Guidelines Book
Universal Access section of Macintosh Human Interface Guidelines Book
Human Interface Design Principles section of Macintosh Human Interface Guidelines Book
Alva Access Group (developers of the outSPOKEN
screen reader and inLARGE screen magnifier, Alva's time-based demos of
their products can be downloaded for testing purposes)
W3C Web Access Initiative (WAI)
Sun Microsystems' Accessibility Program - Developer Information
The Java Access Bridge
Java Accessibility Helper (follow the link from the Sun Microsystems Accessibility Program website)
The Java Tutorial - Accessibility Section
IBM Guidelines for Writing Accessible Applications using 100% Pure Java
List of accessibility techniques for specific development environments from the W3C
British Standards Institution (BSI) BS 7988 A
Code of Practice for the use of information technology for the delivery
Authoring Tool Accessibility Guidelines from the W3C
Authoring Tool Accessibility Guidelines Working Group of the W3C
A review of common courseware authoring tool accessibility issues and solutions from SNOW
Description of Mathspeak
PIVoT Web site
W3C's Math Home Page (provides MathML information)
Amaya Web editor
American Scientist article Speaking of Mathematics
EzMath is being upgraded and will soon be open source on SourceForge (a website repository of open source code and applications)
IBM TechExplorer Hypermedia Browser
The Accessible Graphing Calculator from Oregon State University's Science Access Project
Braille 'n' Speak notetaker with calculator
Graphit graphing calculator software for the Braille 'n' Speak
Accommodating Students with Disabilities in Math and Science Classes from the University of Washington's DO-IT program
Chemical Markup Language. A Position Paper
Barrier Free Education's Accessible Science Experiments in Chemistry and Physics
Haptics Periodic Table from NIDE (Network for Inclusive Distance Education)
The American Chemical Society (ACS) Guidelines for "Teaching Chemistry to Students with Disabilities"
The American Chemical Society (ACS) Committee on
Chemists with Disabilities "Working Chemists with Disabilities:
Expanding Opportunities in Science"
PIVoT (Physics Interactive Video Tutor)
American Physical Society: Physics and Persons with Disabilities
Electric Chemistry Set
Immersion Medical simulators
Phantom Haptics device
Barrier Free Education's Biology Simulations
Barrier Free Education's Physics Simulations
Practical Experimentation by Accessible Remote Learning (PEARL)
Repro-Tronics (tactile imaging paper)
NOMAD Talking Touch Pad
Rendering Drawings for Interactive Haptic Perception
National Centre for Tactile Diagrams (information about making haptic maps and images)
American Printing House for the Blind
The Voice - Vision Technology for the Totally Blind
Article from Haptic Soundscapes about auditory maps
A series of papers covering the benefits of using tactile maps when trying to learn spatial concepts and to move about in space
Article: "Finding direction by sound"
Dancing Dots' GOODFEEL Braille Music Translator
Scoresynth: A System for the Synthesis of Music Scores Based on Petri Nets and a Music Algebra
Video demo of Toccata Braille Music Software
Toccata Braille Music Software
W3C Internationalization / Localization website
Help with creating a multilingual site from the W3C Internationalization / Localization website
Ruby Annotation from the W3C
Ruby techniques for non-visual rendering from the W3C
|| IMS Guidelines for Developing Accessible Learning Applications
|| Cathleen Barstow, Mark McKell, Madeleine Rothberg, Chris Schmidt
| Version Date
|| 27 June 2002
|| White Paper
|| This document presents the IMS Guidelines for Developing Accessible Learning Applications.
| Revision Information
|| 27 June 2002
|| Describes the guidelines for creating or retrofitting learning applications to meet the demands of accessibility.
| Document Location
The following individuals contributed to the development of this document:
| Cathleen Barstow
| Reidy Brown
|| Blackboard, Inc.
| Open University
| Martyn Cooper
|| Open University
| Eric Hansen
|| Educational Testing Service
| Andy Heath
|| UK eUniversities Worldwide and Sheffield Hallam University
| Hazel Kennedy
|| Open University
| Liddy Nevile
| Mark Norton
|| IMS Global Learning Consortium, Inc.
| Jan Richards
|| Industry Canada and University of Toronto ATRC
| Madeleine Rothberg
| Jutta Treviranus
|| Industry Canada and University of Toronto ATRC
|Version No.||Release Date||Comments|
|| 12 October 2001
|| 19 October 2001
|| a) Added a section about synchronous communication and collaboration tools.
b) Made many minor edits.
|| 12 February 2002
|| Internal working group draft.
a) Reorganized and expanded some material and made extensive edits.
b) Added new sections about using XML for accessibility and accessibility information for operating systems and platforms.
|| 27 June 2002
Alternative access 1
ASL 1, 2
Audio 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
Blind 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
Braille 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
Cognitive Disabilities 1, 2
Deaf 1, 2, 3, 4, 5, 6
Deaf-blind 1, 2, 3, 4
Email 1, 2
Equivalent access 1, 2
Haptic 1, 2, 3
haptic 1, 2, 3, 4, 5
IMS 1, 2, 3, 4
Internet 1, 2
Keyboards 1, 2, 3, 4
Language 1, 2, 3
Learning Disabilities 1, 2
Low-vision 1, 2, 3, 4, 5, 6, 7
Magnifiers 1, 2
Mathematics 1, 2, 3, 4
MathML 1, 2, 3, 4
Message Boards 1
Music 1, 2
NCAM 1, 2, 3
Physical Disabilities 1, 2, 3, 4
Science 1, 2
Screen readers 1, 2, 3, 4, 5, 6
Single switches 1, 2
SMIL 1, 2, 3
SVG 1, 2, 3, 4, 5, 6, 7
Tactile 1, 2, 3, 4, 5, 6, 7, 8
Trace Center 1, 2
Universal Design 1, 2
Visual 1, 2, 3, 4, 5, 6, 7, 8, 9
Voice recognition 1, 2, 3
W3C 1, 2, 3, 4, 5, 6
WAI 1, 2
XHTML 1, 2, 3
XML 1, 2, 3, 4
IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Guidelines for Developing Accessible Learning Applications ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
IMS makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.
The Specification is at all times subject to change and revision without notice.
It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.
IMS would appreciate receiving your comments and suggestions.
Please contact IMS through our website at http://www.imsglobal.org
Please refer to Document Name: IMS Guidelines for Developing Accessible Learning Applications Revision: 27 June 2002