Please note: original is available at http://www.imsproject.org/accessibility/index.html
Copyright © 2001 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: 19 October 2001
The following paper was published by IMS for the education world and is therefore directed to that audience. It is, nevertheless, a most comprehensive document and considered worthy of reading by anyone. The authors of the document were drawn from a number of leading web content accessibility communities. The field was researched extensively before the paper was written. This paper is Version 0.6 and will be undergoing continuous improvement in the future.
An extended Table of Contents, with a full listing of sub-categories within each section, is provided below the Short Table of Contents.
3. Principles for Accessibility in Online Distributed Learning
4. Guidelines for Flexible Media Delivery of Text, Audio, Images, and Multimedia
5. Guidelines for Developing Asynchronous Communication and Collaboration Tools
6. Guidelines for Developing Synchronous Communication and Collaboration Tools
7. Guidelines for Developing Accessible Interfaces and Interactive Environments
8. Guidelines for Testing and Assessment
9. Guidelines for Developing Accessible Authoring Tools
10. Guidelines for Topic Specific Access
Appendix B - List of Contributors
Appendix C - About This Document
1. Introduction
1.1 Roles and Responsibilities
1.2 Issues with Learning Technologies for People with
Disabilities
1.3 Additional Resources
1.4 Acknowledgements
1.5 Nomenclature
2. Primer on Accessibility
2.1 Disabilities, Functional Limitations, and Accessibility
Tips
2.1.1 For People Who Are Blind
2.1.2 For People with Low-Vision
2.1.3 For People with Color Blindness
2.1.4 For People Who Are Hard-of-Hearing or Deaf
2.1.5 For People with Physical Disabilities
2.1.6 For People with Language or Cognitive
Disabilities
2.1.7 For People in General
2.2 Tools for Access - Types of Assistive
Technologies
2.3 Equivalent Access Versus Alternative Access
2.4 Direct Access Versus Compatible Access
3. Principles for Accessibility in Online Distributed
Learning
3.1 Allow for Customization Based on User
Preference
3.2 Provide Equivalent Access to Auditory and Visual
Content Based on User Preference
3.3 Provide Compatibility with Assistive Technologies and
Complete Keyboard Access
3.4 Provide Context and Orientation Information
3.5 Follow IMS Specifications and Other Relevant
Specifications, Standards, and/or Guidelines
3.6 Consider the Use of XML (Extensible Mark-up
Language)
4. Guidelines for Flexible Media Delivery of Text, Audio,
Images, and Multimedia
4.1 Common Types of Media Delivery and Associated
Presentation
Formats
4.1.1 Text
4.1.2 Audio
4.1.3 Images
4.1.4 Multimedia
5. Guidelines for Developing Asynchronous Communication and
Collaboration Tools
5.1 Introduction
5.2 Threaded Message Boards
5.3 E-mail Messaging
5.4 Document Repositories
5.5 Organizers, Schedulers, and Calendars
6. Guidelines for Developing Synchronous Communication and
Collaboration Tools
6.1 Introduction
6.2 Synchronous Text Chat
6.3 Audio-Conferencing
6.4 Video-Conferencing
6.5 Whiteboards
6.6 Multi-User Domain Object Oriented Environments
(MOOs)
7. Guidelines for Developing Accessible Interfaces and
Interactive Environments
7.1 Interface Controls
7.2 Navigating the Interface
7.3 Forms
7.4 Interactive Exercises: Drag-and-Drop Exercises,
Simulations, and Timed Tests
7.5 Interactive Tutorials
7.6 DVDs, Consumer Electronics, and Handheld Devices
8. Guidelines for Testing and Assessment
8.1 Testing and Assessment Challenges
8.2 Principles and Guidelines - General
8.2.1 Low-Stakes Assessment
8.2.2 High-Stakes Assessment
8.2.3 Accommodations
8.2.4 Use Existing Standards
8.3 Delivery and Authoring Tool Principles
8.4 Content Development Principles
8.4.1 Provide Information about Purpose
8.4.2 Provide Information about Accessibility of Content at
Varying Levels
8.5 Bibliography/References
9. Guidelines for Developing Accessible Authoring Tools
10. Guidelines for Topic Specific Access
10.1 Introduction
10.2 SMIL, SVG, and Other Accessibility Tools
10.2.1 Scalable Vector Graphics (SVG)
10.2.2 Synchronized Multimedia Integration Language
(SMIL)
10.3 Mathematics
10.3.1 The Problem
10.3.2 Chunking or Simplified Reading of Mathematical
Expressions
10.3.3 Inaccessible Mathematical Notation
10.3.4 Encoding Mathematical Expressions
10.3.5 Localized Applications for Mathematical
Accessibility
10.3.6 Accessible Mathematical Applications and
Devices
10.4 Science
10.4.1 Chemistry
10.4.2 Accessible Science Devices and Applications
10.5 Simulations and Immersion
10.6 Robots and Telepresence
10.7 Charts, Diagrams, and Tables
10.7.1 Current Techniques for Making Graphics Information
Accessible
10.7.2 Haptic Perception
10.7.3 Haptic Image Sources
10.7.4 Other Devices for Accessible Charts, Diagrams, and
Tables
10.8 Microsoft PowerPoint®
10.8.1 The Problem
10.8.2 Alternatives: WimpyPoint
10.9 Geography and Maps
10.9.1 The Problem
10.10 Music
10.10.1 The Problem
10.10.2 Some Solutions for Music Accessibility
10.11 Languages
10.11.1 The Problem
10.11.2 Some Solutions for Language Accessibility
Appendix B - List of Contributors
Appendix C - About This Document
Distributed methods of education have been utilized throughout modern history, yet the popularity of these methods has grown significantly in the past several years. The evolution of the Internet and other technologies throughout the 1990s, combined with the fast-paced lifestyle that many people lead, has led to the tremendous growth of teaching and learning outside of the traditional classroom over the past decade, and has brought learning "online". Online distributed learning has many advantages: it is convenient, available at any time of the day, and can be available nearly anywhere in the world. Online distributed learning has tremendous potential to increase the availability and convenience of education, and if the technologies utilized in distributed education are accessible, these forms of education also have a tremendous potential to include a significant percentage of people with disabilities.
As with many types of products and technologies, people with disabilities may be inadvertently excluded from their use if accessibility is not considered and incorporated into products and technologies, including those used in online distributed learning. The accessibility of these educational technologies is not an issue that only affects people with disabilities. Many other factors, which include a person's abilities, learning style and learning preferences, and the other technologies that they utilize, may inhibit a person's access to learning technologies. The potential for online distributed learning broadens exponentially by accommodating a wide range of learners, such as those with different learning styles or preferences, those with different abilities, and those utilizing different types of technologies and methods of Internet access.
There are many significant benefits to designing distributed learning technologies for accessibility, since accessible design will allow a wider range of learners to have more options and flexibility in their learning experience. Utilizing inclusive design, also known as "universal design", will help to meet these varied needs, styles, preferences, abilities, and technologies. Through universal design web-based e-learning systems, non-web courseware, and content, resulting products will be more fully accessible by a larger population, including people with disabilities. Presenting educational material in a variety of formats will also provide benefits to people with differing learning styles (visual, auditory, tactile) and will allow people to learn in their preferred learning style.
The subsequent set of guidelines developed by the IMS Accessibility Working Group and presented in the upcoming sections of this document, will provide a framework for the distributed learning community. This framework will set the stage for what solutions currently exist, what the opportunities and possibilities are for implementing them, and the areas where more development and innovation are still needed in educational technologies to ensure education that is truly accessible to anyone, anytime, anywhere.
There are other standards and guidelines that currently exist (see the Appendix), however the IMS Accessibility Guidelines are specifically targeted at the distributed learning community, and challenges that exist in an online education environment. The IMS Accessibility Guidelines will not replace these other standards and guidelines, but will provide references to those resources and additional information and solutions that will be compatible with the information that exists. Some issues that will be addressed in this documentation, including complex math and science notation, music notation, and others may not yet have any mainstreamed, or widely adopted solutions, and may still have significant challenges related to accessibility.
In many instances, there are policies or laws that govern accessibility for people with disabilities. These policies and laws vary greatly in different countries, states, provinces, and even from one educational institution to the next. Individuals and companies have varying reasons to be concerned about accessibility, yet to truly work, the responsibility for making learning technologies accessible to everyone is something that must be shared by many constituents, including:
The roles that these people have may differ in different settings and different situations, and these roles and responsibilities are determined and communicated by governments, educational institutions, and companies. As an example, consider a courseware system being utilized by a university for its online learning courses.
The courseware vendor would first have to make the courseware accessible so users would have access to all features, including authoring and viewing content. The vendor of any additional authoring tools used to add content to a course would then have to ensure their interfaces were accessible and also that their tools supported educators in creating accessible content.
Even if a vendor has worked to make all of the various features of a system accessible, and the authoring tools allow or support creating accessible assignments, if a professor fails to take advantage of these features and posts a course assignment in an inaccessible format (possibly because they have not been properly trained), the end result is the student is still excluded from accessing the assignment.
Students should also be considered a crucial part of this process. Their role is to inform the appropriate people (such as professors and school administrators) about their particular needs and preferences, and to provide that information in advance to allow adequate time for those needs to be accommodated. If their needs are not known, then the educational institution, administration, and educators cannot effectively address those needs.
Educational institutions have a responsibility to be aware of and to follow governmental regulations pertaining to their country. Educational institutions may also create their own internal policies regarding accessibility regulations for their students, educators, administrators, and staff with disabilities. These policies might include timeframes of how much notice must be provided by a student who requires materials in an accessible format, who needs to be informed, and what other procedures the student may need to follow.
Informing people about their role, or roles, is a responsibility that is applicable throughout the different group of constituents. Some people may not be aware of the role that they play in this cycle of accessibility, and can therefore not respond effectively. For example, anyone who creates templates can be considered an authoring tool developer. They may not identify themselves as a member of the content production community even though they are acting as an authoring tool developer.
This document is targeted towards the online distributed learning community including software developers, courseware vendors, educational publishers, content developers, administrators, educators/instructors, and students. It is intended to be useful to a wide range of audiences, with varying levels of technical ability.
Teaching and learning materials can be presented in many forms, such as paper, audio and videotapes, CD-ROM, television, and over the Internet. In the new millennium however, online delivery has become the most prevalent way of getting the most up-to-date information to students in the quickest and most flexible and innovative ways possible. Learning courses can utilize a variety of technologies to facilitate learning and interaction between participants: asynchronous and synchronous communication and collaboration tools (such as e-mail, listservs, bulletin boards, whiteboards, chat rooms, videoconferencing, teleconferencing), interactive elements (such as simulations, immersive environments, and games), and various testing and evaluation methods (such as self-assessment, multiple choice testing, etc.). Online educational content can be presented in many media: text on a website, multimedia such as 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.
There are many issues that affect the accessibility of all of these various technologies for learners with disabilities. Are all videos captioned so deaf and hard-of-hearing users can access the content? Is description of visual elements in videos (audio description) provided for blind and low-vision users? Can users with limited mobility utilize keyboard control throughout an application? Have all images on a website been labeled with alternative text (alt-text) for users listening to the content of a site through screen reading software? How will blind students access mathematical equations presented as graphics, which cannot be read by screen readers? What are the challenges of certain types of testing? Are administrative aspects of the online learning process accessible, such as course listings and course registration?
Although not all of these questions have solutions, attention needs to be given to these and other accessibility issues to ensure access to online education for everyone. These issues will be more fully explored in the guidelines sections of this document.
The guideline sections of the document will address:
For additional resources, see the Appendix section at the end of this document.
This project is supported by a grant from the Learning Anytime Anywhere Partnerships (LAAP), a program administered by the Fund for the Improvement of Postsecondary Education (FIPSE), U.S. Department of Education (http://www.ed.gov/offices/OPE/FIPSE/LAAP/)
Additional support is provided through participation and contributions from the following organizations:
| Blackboard | http://www.blackboard.com/ |
| CETIS | http://www.cetis.ac.uk/ |
| DETYA | http://www.deetya.gov.au/ |
| ETS | http://www.ets.org/ |
| IMS | http://www.imsglobal.org/ |
| Industry Canada | http://www.ic.gc.ca/ |
| NCAM | http://ncam.wgbh.org/ |
| The Open University (UK) | http://www.open.ac.uk/ |
| University of Toronto ATRC | http://www.utoronto.ca/atrc/ |
| WebCT | http://www.webct.com/ |
This section provides an introduction to several types of disabilities and the functional limitations they cause for computer users. The following contain accessibility tips describing general strategies for meeting the needs of these users. See the Trace Center Accessible Software Guidelines http://www.trace.wisc.edu/world/computer_access/software for a comprehensive guide to creating accessible software.
This section is adapted with permission from a previous publication of the Trace R&D Center, the Trace Application Software Design Guidelines written in 1994 and published at: http://www.trace.wisc.edu/docs/software_guidelines/software.pcs/cover.htm.
Many people who are legally blind have some residual vision. This may vary from an ability to perceive light to an ability to view things that are magnified. The best design for this group is therefore one that doesn't assume any vision but allows a person to make use of whatever residual vision they may have.
Access by people who are blind is usually accomplished using special screen reading software to access and read the contents of the screen, which is then sent to a text-to-speech synthesizer or refreshable Braille display.
There are a number of things that application software developers can do to make it possible for people using screen readers to detect and figure out what is on the screen. These include:
The compatibility of software can also be increased with screen readers by:
Since screen readers can only read text (or give names to separately identifiable icons or tools), it is a good idea to avoid:
Finally, documentation and training materials can be more accessible when:
For people with low-vision, a common way to access the information on the screen is to enlarge or otherwise enhance the current area of focus. Given this, the direct accessibility of software can increase when the user can adjust the fonts, colors, and cursors in a program to make them more visible.
The accessibility of software can increase when:
Many users with hearing impairments need to have some method for adjusting the volume or for coupling the sounds more directly to their hearing aids. Both of these are hardware considerations and can be met with systems having volume controls and headphone or audio jacks. Users who have more severe hearing impairments may also use a combination of these techniques, as well as techniques for people who are deaf. Such techniques generally involve the visual display of auditory information.
Therefore, the accessibility of software to users with hearing impairments can increase when:
In addition, product support people must be reachable via text telephones (TTYs).
People with physical disabilities can have a wide range of abilities and limitations. Some people may have complete paralysis below the waist but may have no disability at all in their upper body. Others may have weakness overall. Some may have very limited range of motion, but may have very fine movement control within that range. Others may have little control of any of their limbs, or may have uncontrolled, sporadic movements which accompany their purposeful movements. Some with arthritis may find that hand and other joint movement is both physically limited and limited by pain. A physical disability, by itself, does not usually affect a person's ability to perceive information displayed on the computer screen. Access is generally dependent on being able to manipulate the interface.
Therefore, accessibility of software can increase (both directly and through compatibility with assistive technologies) when timed responses (less than 5-8 seconds) are avoided, or when the response time can be changed.
This is perhaps one of the most difficult areas to address. Part of the difficulty lies in the tremendous diversity that this category represents. It includes individuals with general processing difficulties (mental retardation, brain injury, etc.), people with very specific types of deficits (short term memory, inability to remember proper names, etc.), learning disabilities, language delays, and more. In addition, the range of impairment within each of the categories can (like all disabilities) vary from minimal to severe, with all points in between. In general, software that is designed to be very user friendly can facilitate access to people with language or cognitive impairments.
Somewhat more specifically, the accessibility of software can increase when:
In addition, because print disabilities are more common among people with language and cognitive impairments, accessibility of software increases when it is compatible with screen reading software. (See the section titled "For People Who Are Blind".)
Finally, the overall accessibility of software increases when:
Screen readers: software for blind users that finds information on the computer screen and communicates it to the user either with text-to-speech software or hardware or a refreshable Braille display. Screen readers are generally designed to get information using the standards of the operating system for which they are created; applications and software that adhere to those standards will be most accessible, whereas applications and software that ignore them may be impossible to access. Refreshable Braille displays use pins that move up and down to spell out words in Braille and are the fundamental means of access to computers for users who are deaf-blind. Screen Readers are often very useful for users with learning disabilities.
Screen magnifiers: software for low-vision users that allows the user to customize the size of the images and text on the screen, by enlarging images on the screen to many times their original size. Screen magnifiers may also permit the user to change the default colors of the display, for example, by using reverse video if that provides better contrast. Screen magnifiers track the cursor or the active region of the screen in order to automatically enlarge the portion of the screen the user needs to see. Therefore, applications and software that use a custom cursor may pose a challenge for accessibility since the wrong portion of the screen may be magnified.
Adaptive keyboards: a variety of keyboard options for users with physical disabilities who cannot use a standard keyboard. Keyboards may be smaller for users with little range of motion or larger for users without fine motor control; they may offer fewer choices for users who benefit from structured choices or provide a way to type with one hand for users who cannot use both hands. In some cases, software can be used to simulate a keyboard on the user's monitor. Such on-screen keyboards allow those who cannot use other keyboards to type by pointing with a mouse (or an AT that emulates a mouse). Applications and software that use the operating system's standard methods of reading input from the keyboard should be compatible with adaptive keyboards; those that depend upon reading keystrokes directly from the keyboard, rather than through the operating system, are not likely to be accessible.
Voice recognition software: allows the user to input data or control the computer by speaking. This is beneficial to users who have difficulty typing. Generally, applications and software that allow full access through keyboard commands will be well suited for use with voice recognition software.
Single switches: hardware for some users with physical disabilities who can only control the computer with one or two specific movements. Switches are used with software that scans through options on the screen allowing the user to trigger the switch when the option they wish to choose is highlighted. Single switches can be used in conjunction with on-screen keyboards and word prediction software. The scanning software can be used to create customized screen layouts for use with a variety of software. However, every clickable spot in the layout must be identified manually in advance.
When considering the accessibility of applications and software for learning, education, and training, it is important to understand the differences between two types of access: equivalent and alternative.
Equivalent Access provides the learner with the same learning activity but it is mediated in a different modality. Providing a course textbook in Braille format, on audio tape, or in digital format are examples of equivalent accessibility. Alternative Access provides the learner with a different learning activity but one that is designed to achieve the same learning objectives. An example of alternative accessibility might be having a mobility-impaired student conduct science experiments in a virtual laboratory, where the same levels of dexterity, strength, and physical access are not required as in a physical laboratory.
Equivalent access should be provided as the first option to learners, and alternative access provided only if equivalent access is not possible.
Education accessibility solutions fall into two categories: direct access and compatible access. A "directly accessible" product is designed so that a person with a disability can operate all on-screen controls and access the 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 to enlarge all controls and on-screen text and are designed with high contrast colors or provide features that allow users to choose appropriate colors. To be accessible to blind users, a directly accessible product should have a keyboard interface with audio output. Such a keyboard interface will also provide access for many 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 get limited training with ATs. For this reason, direct access is most crucial in products targeted for the elementary and middle school level.
Direct access has many benefits. The greatest is that the user is able to access educational material without needing special assistive hardware and software. This keeps costs down for schools and individuals, and reduces common technical difficulties associated with using AT. It also allows a student with a disability to utilize any computer rather than being restricted to an adapted workstation. Finally, having the accessible interface designed by the people creating the application, software, or website creates a better interface since the designers understand the educational intent and user interface model. An AT can only interpret the information available to it.
A "compatibly accessible" application, software, or website is designed with AT in mind. This level of access assumes the user has a preferred AT package installed and is relatively competent and comfortable with it. A compatibly accessible product is designed with "hooks" to facilitate ease of use with a screen reader, screen magnifier, or alternative input devices such as adapted keyboards or single switches. These hooks can be implemented by developers with tools such as Microsoft Active Accessibility (MSAA) and the Java Accessibility API from Sun Microsystems (discussed in more detail in the section on Major Vendor Guidelines). Exposing the system cursor, using standard controls and fonts, and following the operating system's human interface guidelines can help make a product compatibly accessible.
Compatible access has some advantages. It provides consistency of operation between applications since users already know how to navigate with their AT or continually gain competency in 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, in place of adding audio to a product, for instance, can save on disk space for larger applications. Compatibly accessible products may be the only means of access for some users, i.e., deaf-blind Braille users depending on screen readers to interact with computers. Building applications, software, and websites to be compatible with ATs should use a single set of programming techniques to create software that works well with the range of screen readers, alternative input devices (switches, on-screen keyboards, voice recognition), and any other input or output device that is not part of a standard computer. Deaf-blind students generally require compatible interfaces. These students cannot use directly accessible technologies and rely on compatibly accessible materials from a young age.
The following principles represent best practices for producing accessible software applications and content for online distributed learning. These principles primarily address accessibility for people who have sensory or mobility disabilities, and to a lesser extent on the wide array of accessibility issues faced by people with cognitive disabilities. Many of these principles will also be beneficial to users with cognitive disabilities, such as a learning disability, however comprehensive solutions for these users goes beyond the scope of this document. Attention should be given to implementing these practices from the beginning of the design/development process, since retrofitting a product or content for accessibility is almost always significantly more labor-intensive and more costly than incorporating it from the start.
Allowing for versatility in the way information is presented makes applications, software, and content more fully accessible to a wider variety of users. Some examples of items that should be customizable by the users include:
Changes to the display and characteristics of elements, such as:
Allowing for customization of various elements in software applications and content is essential for accessibility. Hard-coding elements such as fonts, may make access impossible for some users. Depending on a user's abilities and preferences, they may want or need to make changes to 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 the text.
Changes to features, such as the timing of events, is another element that should be controlled by the user. For example, dialog boxes and alerts should stay on the screen until they are cleared by the user, to ensure that they have been recognized, and activities that require several actions to be taken within a certain amount of time should have an option for removing that time limit for users whose ATs provide less efficient ways of interacting.
For users who are deaf or hearing-impaired, equivalent access to all auditory aspects of learning technologies and learning content should be provided. Accessibility solutions include:
For users who are blind or visually impaired, equivalent access to all visual aspects of learning technologies and learning content should be provided. Accessibility solutions include:
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.
Provide keyboard-only access to all elements of an application or of content, including menus, help directories, toolbars, and dialog boxes, and do not assume that a user can use a mouse.
Providing context and orientation information is vital to making applications and software more usable. Context and orientation information can be provided in the following ways:
For people utilizing screen-reading software to listen to content rather than using graphics or visual aids to navigate, these features will save a considerable amount of time. These features will benefit all users by minimizing the learning curve, and consistency between pages will make information easier to find.
Following relevant specifications and guidelines improves accessibility in two ways. Most obviously, guidelines that provide information on how to implement accessibility offer useful techniques and suggestions. But because accessibility often relies on interoperability between the learning applications, software, or content and the user's AT, following other relevant industry specifications is likely to improve access by ensuring that the applications, software, or content behave as the AT is expecting them to behave.
Adoption of IMS Global Leaning Consortium specifications in the online distributed learning industry will promote more fully interoperable technologies. All IMS specifications are openly available to the public and available free of charge at: http://www.imsglobal.org/specifications.html. Through the work of the IMS Accessibility Working Group, in conjunction with other IMS Working Groups, these specifications will increasingly include specific sections intended to improve accessibility of online distributed learning technologies.
IMS specifications available at the time of publication of this version of this white paper include:
IMS specifications currently in development include:
Other industry specifications, standards, and/or guidelines are referenced in the Appendix section of this document.
As the popularity of the Web and the complexity of what is presented over the Web has grown, the limitations of HTML for presenting have become more complex. XML, or Extensible Mark-up Language was developed by the XML Working Group of the W3C, and the W3C Recommendation for XML 1.0 was published in February 1998 as the next generation mark-up language. XML accessibility guidelines are currently being developed by the W3C. XML differs from other mark-up languages, such as HTML (Hypertext Mark-up Language) or HTML's predecessor SGML (Standard Generalized Mark-up Language) as it is much less complicated than SGML, and much more flexible than HTML.
XML is more than a mark-up language. It is ametalanguage, which is a language (or a set of syntax rules and guidelines) used to define and create new markup languages. XML does not have the same limitations as HTML, since XML does not utilize any pre-defined tag semantics or tag sets. With XML, a language can be created that is unique and meaningful to the particular elements of an application or domain. Another primary difference between HTML and XML is that HTML is used for formatting and displaying data, combining structure and display of a document. The meta-language XML is used to create languages that describe and structure data or that format data. Therefore, XML separates structure and display, and the semantics of an XML document are defined by the applications that process them or by stylesheets.
There are many other advantages to using XML, including:
A public working draft of the WC3 XML Accessibility Guidelines is available at: http://www.w3.org/TR/xmlgl.
[One easy way to think about this is to use XHTML, first endocing using HTML and then converting to XHTML using HTMLTidy.]
The flexibility of media delivery is essential to meeting the needs of a wide variety of users. The standard types of media delivery and associated presentation formats may not meet the needs of all users. Depending on individual needs and preferences, users may want to select how to render learning sites or materials, including options that may differ from the generic or standard presentation format. Designing and allowing for flexibility and providing users options enhances the accessibility for the user and may greatly enhance their learning experience. At a minimum, providing a text representation of all types of media provides a baseline that addresses access needs for many users.
A number of resources are currently available addressing flexible media delivery. Information from the W3C's Web Accessibility Initiative on providing accessibility in W3C technologies is available in the Appendix, while two other comprehensive guides are referenced here.
The National Center for the Dissemination of Disability Research publication, "User-Friendly Materials and Alternate Formats" http://www.ncddr.org/du/products/ufm/ufm.html, provides information on implementing several formats and modes including:
The California Community Colleges have produced a comprehensive set of guidelines that offer alternative formats for presenting printed materials. The document, "Guidelines for Producing Instructional and Other Printed Materials in Alternate Media for Persons with Disabilities" http://www.htctu.fhda.edu/amguidelines/am33000.htm, provides a comprehensive resource for producing several types of alternative media including:
Information for creators of authoring tools, which should support the creation of flexible educational media, is in the section of this document on Authoring Tools.
Text, correctly provided, can be the most flexible form of content when it is provided properly. Providing means for alternate rendering of digital text formats is essential to the accessibility of distributed online learning. Users may render text in one of three ways: visual, audio, or tactile. Text content must be accessible through any of these renderings.
Some examples of how text may be rendered in these different ways:
Common accessibility problems include:
Learning system developers may
enhance accessibility for all users by following these
practices:
Content creators or educators
may enhance accessibility for all users by following these
practices:
Including audio in online learning materials can add to their appeal and to their accessibility to some groups. Print-impaired learners, such as those with visual impairments or dyslexia, will benefit from audio materials. However, alternatives should be provided to ensure that learners who are deaf or hard-of-hearing are not excluded.
Common accessibility problems include:
Learning system developers may enhance accessibility for all users by following these practices:
Content creators or educators
may enhance accessibility for all users by following these
practices:
An authoring tool is available free-of-charge for content creators and educators to add captions, subtitles, and audio descriptions to digital media. 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 which allows authors to add signed language through animated characters. One company developing this software is Vcom3D. They have created "SigningAvatars" which 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, however without text identification of images, they are not accessible for users who are blind or low-vision. Users must be provided with a way to access the information presented through the image. Providing text identification, or alternative text, will also be beneficial to users of text-only browsers or browsers with the graphics turned off, as well as those utilizing non-graphical devices such as mobile phone browsers. The quality of images is important for users who will enlarge the size of the image, so that the image is clear even when the size is altered.
Common accessibility problems include:
Learning system developers may
enhance accessibility for all users by following these
practices:
Content creators or educators
may enhance accessibility for all users by following these
practices:
Scalable Vector Graphics (SVG) is a language used in XML to describe two-dimensional graphics. SVG 1.0 is a W3C Recommendation, 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 and thus has all of the access needs of all of those media. Multimedia can be useful for many groups of learners, since a multi-modal presentation of information can be easier to understand. Ensure that alternatives are available for users who cannot access important information in one or more parts of multimedia materials.
Common accessibility problems include:
Learning system developers may enhance accessibility for all users by following these practices:
Content creators or educators
may enhance accessibility for all users by following these
practices:
The CPB/WGBH National Center for Accessible Media's "Rich Media Accessibility" website http://ncam.wgbh.org/richmedia/index.html provides information of a wide range of digital media formats.
This section will cover development of asynchronous communication and collaboration tools including:
Asynchronous communication and collaboration tools such as threaded message boards, e-mail messaging, listservs, document repositories, and calendar systems must be rendered in formats that facilitate the full participation of learners with disabilities in online interactions. The navigation system for this type of utility should allow users of AT to scan items and locate content easily, follow the thread of an ongoing discussion topic, post responses, or add additional information without encountering barriers to any aspect of the functionality.
Users must have flexibility in their choice of browser, input and output modalities, and use of assistive technologies. 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 W3C WAI website: http://www.w3.org/WAI.
For discussion forums, bulletin boards, and other utilities that allow posting of asynchronous text messages, both the navigation system and the content of the messages should be rendered in standard HTML. Requiring use of proprietary client software or non-standard file formats may create barriers by limiting access according to individual user preferences, as described in the introduction.
Common accessibility problems include:
Learning system developers may enhance accessibility for all
users by following these practices:
Content creators or educators may enhance accessibility for all users by following these practices:
Examples are available at the WorldEnable Internet Accessibility Discussion Board at: http://www.worldenable.net/iadiscuss/.
E-mail systems may be used either for one-to-one exchanges, or for listserve distribution of messages. In both cases, proprietary client software may be selected by the user, depending on their needs and compatibility with their preferred AT software and hardware. The user interface for e-mail clients should be compliant with W3C Authoring Tool Accessibility Guidelines 1.0, available from the WAI website: http://www.w3.org/TR/WAI-AUTOOLS/. To ensure e-mail messages can be made accessible, the option to send plain ASCII text should be provided.
Common accessibility problems include:
Learning system developers may enhance accessibility for all
users by following these practices:
Content creators or educators may enhance accessibility for
all users by following these practices:
Document repositories must be designed in such away that the indexing system is accessible to all users, and follows logical document structure. Where possible, documents should be stored in standard HTML format rather than proprietary or non-standard file formats that may create barriers by limiting learner options for access according to their own needs or preferences. Search functions and display options must be accessible to users of AT.
Common accessibility problems include:
Learning system developers may enhance accessibility for all
users by following these practices:
Content creators or educators may enhance accessibility for all users by following these practices:
Examples are available at the W3C WAI Mail Archives: http://lists.w3.org/Archives/Public/w3c-wai-ig/.
Organizers, schedulers, calendars and other utilities that allow posting of shared information require that information be logically structured using standard HTML. Incorrect use of complex tables or scripting languages may create barriers for non-visual users. It is critical that the information linearizes correctly when transformed to audio output, in order to avoid incorrect juxtapositioning of dates and events. As this is particularly difficult to achieve with traditional calendar layouts, an alternative linear output then may be provided.
Common accessibility problems include:
Learning system developers may enhance accessibility for all users by following these practices:
Content creators or educators may enhance accessibility for all users by following these practices:
The Wave accessibility evaluation tool analyzes the linearized reading order of information on a web site: http://www.temple.edu/inst_disabilities/piat/wave/.
This section will cover 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 both the user interface of the tool and the real-time communicative content mediated by the tool are accessible by way of a variety of input and output modalities.
Synchronous text chat tools (such as IRC, ICQ, etc.) allow two or more users to communicate via typed text messages in real-time. In order to be accessible, both the navigation system of the chat tools and the content of the messages they send and receive must be accessible.
Common accessibility problems include:
Learning system developers may
enhance accessibility for all users by following these
practices:
Audio-conferencing (via phone or Internet) allows two or more users to collaborate via real-time speech. In order to be accessible, users with hearing and speech disabilities must be accommodated.
Common accessibility problems include:
Learning system developers may enhance accessibility for all
users by following these practices:
Video-conferencing allows two or more users to collaborate via real-time televised action (video and sound). In order to be accessible, users with visual, hearing, and speech disabilities must be accommodated.
Common accessibility problems include:
Learning system developers may enhance accessibility for all users by following these practices:
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 to be accessible, both the navigation system and the content of the workspace must be accessible.
Common accessibility problems include:
Learning system developers may enhance accessibility for all users by following these practices:
MOOs are multi-user virtual environments in which users 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.
Common accessibility problems include:
Learning system developers may enhance accessibility for all users by following these practices:
Resources that can assist in developing inclusive synchronous communication tools include:
An earlier section in this white paper, "Principles for Accessibility in Online Distributed Learning", presents some general principles to guide accessible development of elearning software, applications, and content. The section on "Guidelines for Flexible Media Delivery of Text, Audio, Images, and Multimedia" presents information on creating accessible multimedia presentations. In this section, more detail is provided about creating accessible interfaces, simulations, interactive exercises, and non-computer technologies, such as DVDs.
Though more detailed than the principles in previous sections, this section will not include technical details about implementing accessibility in specific operating systems and programming languages. Resources for various development environments are listed in the Appendix. A comprehensive guide to Application Software Accessibility is available at: http://trace.wisc.edu/docs/software_guidelines/toc.htm. In addition the CPB/WGBH National Center for Accessible Media's "Making Educational Software Accessible: Design Guidelines Including Math and Science Solutions" are available at: http://ncam.wgbh.org/cdrom/guideline/.
When designing an interface, be sure to use controls and other components that are compatible with assistive technologies used by people with disabilities. Course designers, educators, and learners need to be able to access buttons, text fields, text field labels, menus, and all other components.
Common accessibility problems include:
Learning system developers may enhance accessibility for all users by following these practices:
Moving between pieces of content, menu bars, tables of contents, frames, and other parts of the interface is often problematic for users of AT, particularly when some features can only be accessed with a mouse.
Common access problems include:
Learning system developers may enhance accessibility for all users by following these practices:
Forms must follow the suggestions above for interface controls in general, but additional problems can arise when a large number of interface elements are displayed together in a form.
Common accessibility problems include:
Learning system developers may enhance accessibility for all users by following these practices:
Content creators or educators may enhance accessibility for all users by following these practices:
As interactive activities become more complex, take care that the interfaces are still independent of the input and output methods of different users. For example, drag-and-drop activities should be usable with either mouse or keyboard, and the keyboard commands should be as simple as possible. Consider how information is displayed as well. Simulations can be made accessible with multi-modal output. If a 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 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 AT that slows down their rate of response. Make timing requirements customizable.
Common accessibility problems include:
Learning system developers may enhance accessibility for all
users by following these practices:
Content creators or educators may enhance accessibility for all users by following these practices:
Examples:
Prototypes are available from NCAM that demonstrate a talking math game and a talking science simulation: http://ncam.wgbh.org/cdrom/guideline/download.html.
The Digital Trip to the Rainforest CD from Digital Frog International is available in an "AT Version" that includes an accessible interface, descriptions of each image, and other access features: http://www.digitalfrog.com.
Interactive tutorials are a special type of interactive activity in which images of a software application in action are combined with audio or text narration to create a tutorial. In addition to the previous suggestions, be sure to provide information in multiple modalities to meet the needs of all users and consider that different users will need to know about different ways to operate the software.
Common accessibility problems include:
Learning system developers may
enhance accessibility for all users by following these
practices:
Learning activities that are available on technology that is not a personal computer may have additional accessibility problems. DVDs and other multimedia formats can be made accessible, as can touch screen kiosks. Solutions are in development for set-top boxes such as digital cable boxes. Access techniques for handheld devices or personal digital assistants are still in need of continued research.
Common access problems include:
Technology developers may
enhance accessibility for all users by following these
practices:
Accessible Kiosks and Touch Screen Interfaces:
Alternative Interface Access Protocol:
The V2 committee of the National Committee for Information Technology Standards (NCITS) is charged with developing national standards for Information Technology Access Interfaces that will provide access features for users with disabilities: http://trace.wisc.edu/world/v2/index.htm.
This section presents principles and guidelines that are specific to testing and assessment in distributed online learning. What is presented here has the aim of enabling a higher level of accessibility in tools, systems, and content used for testing and assessment. It includes principles of design and detailed implementation specifics.
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 learning content and its delivery that are described in other sections of this document apply here also. This section addresses how the needs of testing and assessment are different from those of pure content delivery.
The focus in this section is on the use of testing and assessment as it affects the individual rather than its use to guide policy decisions. If accessibility is viewed as describing ways to cater for learners with disabilities then in any specific situation the numbers of candidates with some specific disability may be low. This makes it difficult to use quantitative arguments about validity and wide scale educational policy. Nevertheless, small issues can have large consequences on an individual level, and that is the concentration of this section. Consequences for educational systems on the grand scale are not within the current scope of this document.
This is a need to distinguish two classes of use for assessment because the requirements of each are different.
Low-stakes assessment is assessment driven very closely by the needs of learning, commonly in a very short feedback loop. It can often be closely associated with direct learning feedback and, in some assessment processes, is the same thing. The essential characteristic is the lack of serious consequences contingent on the results. This will often be integrated with learning in such a way that there is immediacy in delivery of results to learner. This is assessment integrated with the process of learning.
High-stakes assessment, on the other hand, is assessment with consequences that may have serious impact on the life-course of the participant. An example might be a university entrance examination. With high stakes assessment there is a requirement for much greater rigor in the development of accessibility solutions.
These are not absolute terms and need evaluation in the particular context. In particular, different stakeholders may take different views about the degree to which an assessment is low or high stakes. Representations and content design need to allow for this and also for different contextual uses of the same material.
This is a fast-changing area with many challenges to current technology and knowledge. For some areas it is difficult to provide precise complete answers to how things should be done at this point since they are likely to progress significantly in the near future. A few of the current accessibility challenges include:
This means providing alternative content modalities where possible and consistent with the purposes of the assessment, providing compatibility with ATs, etc., as described in principles elsewhere in this document. For example, it would be undesirable to label buttons in a form or other interactive controls only with images or to provide for navigation only by mouse. The goal is systems and content as flexible and adaptable to accessible use as possible.
It is important that a high-stakes assessment be fair to all candidates and not treat some more favorably than others. For confidence in assessment validity, it is important that assessment providers are able to control whether particular alternatives are available or not. This is an important consideration in both content design and delivery system design (see recommendations later in this section). The goal is systems as flexible and adaptable as possible as long as assessment validity isn't compromised. It may be that allowing some particular alternatives has no consequences for fairness for that assessment while allowing others does. What is needed is fine control and rigor in its use.
Careful assessment design, system design and tool design including good use of alternative media and appropriate delivery technologies may enable a greater level of individual tailoring of alternatives, more precise and better use of accommodations and easier integration of disabled candidates.
Traditionally, one approach taken to persons for whom the delivery media of an assessment has been unsuitable has been to "accommodate" their needs with some special conditions. Consider a candidate having poor sight and an examination where a candidate needs to read and understand some text but where reading skills are not amongst those skills it is intended to assess. One approach, if the candidate has enough sight, could be to give the candidate a magnifying device, acknowledge that reading the passage this way would take extra time and allow extra time accordingly. If the time taken is relevant to the validity of the examination, then assessment of the results for that candidate may have to be with a different process than that for the rest of the candidates who did not have that accommodation. It may be that for this candidate, with this examination, the use of speech synthesis would provide an equivalent (or even more accessible) alternative not requiring extra time. In particular conditions for this candidate providing this alternative may have less effect on the validity of his or her results even if judged by the same processes as candidates not using that alternative.
The process that ensures a particular candidate's results are dealt with differently from the rest is sometimes known as "flagging". There are many undesirable side-effects of flagging. Good use of XML-based content formats and appropriate assistive devices can enable a closer matching of alternatives, user, and assessment goals and go some way towards reducing the problem and increasing integration of disabled and non-disabled communities in their learning system use.
In addition to standards recommended elsewhere in this document we recommend the use of the following standards, the full details of which are given at the end of this section:
AERA, APA, & NCME. (1999).Standards for Educational and Psychological Testing
BSI BS 7988 A Code of Practice for the use of information technology for the delivery of assessments. IN PREPARATION
Delivery and authoring tools need to support mechanisms for authoring, storing, and using accessible assessment content.
Note: This is for work in a future version, but may be expected to include:
Note: This is for work in a future version, but may be expected to include purpose information which is needed at multiple levels:
Note: This is for work in a future version.
AERA, APA, & NCME. (1999).Standards for Educational and Psychological Testing. Washington DC: American Educational Research Association.
BSI BS 7988 A Code of Practice for the use of information technology for the delivery of assessments. IN PREPARATION
{This provides good information on the relationship between fairness and validity and provides lots of research findings. While much is oriented to gender issues, lots is very relevant to accessibility issues.}
Willingham, W. W., & Cole, N. S. (1997).Gender and fair assessment. Mahwah, New Jersey: Lawrence Erlbaum Associates.
Willingham, W. W., Ragosta, M., Bennett, R. E., Braun, H., Rock, D. A., Powers, D. E. (1988). Testing handicapped people. Needham Heights, Mass.: Allyn and Bacon.
Making the creation of accessible content and learning environments a simple and naturally integrated part of authoring learning material is a critical and far reaching step to ensuring that the learning experience is open to all learners. A goal of these guidelines is that authors who may not have any knowledge of accessible authoring practices nevertheless create accessible material using an authoring tool.
Anauthoring tool is any software tool that can be used to create content that will be displayed in an online learning environment. Authoring tool accessibility should be approached from two perspectives:
The authoring tool supports and encourages the creation of accessible content or learning materials by following several guidelines, delineated in the W3C Authoring Tool Accessibility Guidelines document at: http://www.w3.org/WAI/AU. The Guidelines are accompanied by a techniques document that suggests how the guidelines can be implemented in various tools. In summary, the tool should encourage the author to adopt accessible authoring practices and assist the author in checking and repairing the content as it is being authored. The tool should not only offer mechanisms whereby accessible content can be authored, but these mechanisms should be prominent, and easy to apply. The accessibility supports should be seamlessly integrated into the look and feel of the tool and well documented in the help and documentation of 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 be accessible to educators and learners with disabilities. This is done by following platform-specific user interface accessibility standards, providing supports for accessible navigation of the document and providing flexible presentation of the content to be edited (as discussed in both the W3C Authoring Tool Guidelines and Techniques documents at: http://www.w3.org/WAI/AU).
In a courseware environment, these guidelines need to be applied to the interface for the administrator, the educator or instructor and the learner or student. All three user groups are potential authors. Checking and repair tools should also be provided by the courseware environment to detect and fix access problems in content authored in a third party authoring tool. A powerful means of insuring that learning content is accessible within an educational institution is to provide templates and models that are accessible.
A review of common courseware authoring tool accessibility issues and solutions can be found at: http://snow.utoronto.ca/access/courseware/index.html.
This section is focussed on specific domains of content and how they should be published for the benefit of all.
In all cases, it should be noted that the beneficiaries of accessible content, particularly with respect to the topic areas considered in this section, will be everyone. Currently, mainstream users of the Web rarely get access to "live" mathematics, and many users of content on the Web find it difficult to comprehend, at least the first time. These users will benefit from alternative "views" of the same content. Thus, a good example is provided by the solution to the problem of accessibility to mathematics: everyone, novice and expert, can benefit in some way from being able to access thesame mathematics in both a symbolic and a semantic representational form.
In the context of specific topics, it is worth being aware of the contribution to the solution being offered by the recent developments of W3C standards, especially Scalable Vector Graphics (SVG) and Synchronized Multimedia Integration Language (SMIL).
SVG provides a format for images that supports a number of accessibility features including text information about graphical elements and high-quality zoom functions.
The grouping element of SVG allows the content producer to create a graphical object from a set of objects in a way that makes it possible to identify and thus describe each element separately. If the graphical elements can be described and their relationship described, the user without a graphical interface still has a good chance ofreading the image. Further information about SVG and SVG accessibility is available at: http://www.w3.org/TR/SVG-access/ and http://www.w3.org/TR/SVG/struct.html#GElement.
Many of the problems and solutions discussed below depend upon the provision of equivalent alternative formats, for instance text, sounds, or haptics alongside graphics, and the integration and synchronization of these elements can be managed by SMIL see http://www.w3.org/TR/SMIL-access/.
In general, people working with mathematics on the Web to:
Currently, following the W3C recommended procedures, a user can do the following:
As mathematical writing can be complicated, varying what is visible/available at any time may facilitate the reading of a mathematical argument or text, and indirectly benefit novices and experts. This can be done by "chunking". Both stylesheets and SVG can be used to "chunk" mathematical expressions. As an example, consider the following sentence:
"This formula:makes it possible to predict the result with accuracy."
With an accessible math reader in place, the user would hear the above 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."
(Or for North Americans: "This formula, a cubed plus b cubed equals parentheses, a plus b, parentheses a squared minus ab plus b, squared, makes it possible to predict the result with accuracy.")
Comprehension might be improved by allowing the learner to choose a style sheet which omits formulas:
"This formula makes it possible to predict the results with accuracy."
The learner could then switch to a mathematical style sheet 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. In addition:
Mathematical Mark-up (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 in an accessibility compliant editor and view or access the 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, or a mathematics application (see the W3C lists 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 use it directly by buying a mathematical symbolic editor that understands MathML and is itself accessible. There is a comprehensive list of MathML solutions are available at: http://www.w3.org/Math/.
There are problems with mathematical accessibility, specific to authoring tool developers, including people who make templates for others to use. MathML is not yet widely used and not native to commonly used browsers, and many of the courseware packages that were sold in the past were not accessibility-aware. This is, to a large extent, changing but it is still unlikely that in the short term, courseware developers will be able to adapt fast enough to alleviate the problem. In the meantime, tool makers can help their users solve the problem by presenting best practice information and, where possible, incorporating software that supports good mathematics mark-up.
Visit http://www.mathmlconference.org/Talks/rudisill/ for examples of mathematics notation in Word (Equation Editor), translated it into MathML using WebEQ generator (a shareware translator) and users viewed the notation with graphical browsers augmented with the WebEQ plug-in (free). The W3C Math home page also provides MathML information at: http://www.w3.org/Math/.
The Audio-Accessible Graphing Calculator (http://dots.physics.orst.edu/agc.html) is a self-voicing Windows application that has been under development and testing for some time by the Science Access Project at Oregon State University. It includes the capabilities to:
Braille 'n Speak, a Braille calculator can do standard maths and also can be used to generate tactile graphs (http://www.dinf.org/csun_99/session0113.html). Additional software is available for students needing the power of a financial calculator and graphing calculator functionality is available for the blind using Graphit in conjunction with any Braille embosser.
As with mathematics, the development of a mark-up standard that can be used to encode and decode scientific expressions is very important for accessibility. In addition, branches of science have discipline-specific 2D and 3D representations that need to be rendered on the screen.
The chemistry equivalent to MathML is ChemML. Accessibility is a matter of the development of suitable stylesheets. Like MathML, ChemML needs to be embedded in XML (or XHTML). CML is a version of ChemML, see http://www.xml-cml.org/information/position.html.
ChemML interoperates with other mark-up languages and XML protocols in the following way to make chemistry available:
Participation in live experiments is not always available to all students, including those who use less common devices. Simulations and artificial environments, such as "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 ensured for all users.
From the Practical Experimentation by Accessible Remote Learning (PEARL) website: "Experimental work is a vital component of science and engineering teaching at all levels. The increasing use of multimedia packages or "virtual science" has much to offer in terms of teaching scientific facts and principles, but does not generally focus on teaching the process of scientific enquiry or engineering practice.
"The system being developed in the PEARL project will deliver practical experimentation where students work together over the Internet (or Campus Intranet), much as they would in a teaching laboratory. They will be able to interact with the remote experiment, change parameters and in some cases modify and design experiments. They will discuss their actions and what they anticipate will happen, and observe the results and analyze them.
"The process is real and so has an authenticity and unpredictability that simulations or descriptions cannot replicate."
Information for this section was derived from the Science Access Project's Accessing Object-Oriented Web Graphics site at: http://dots.physics.orst.edu/~gardner/gardner_j_graphics1.htm.
10.7.1Current Techniques for Making Graphics Information Accessible |
|
There are a number of audio
technologies that are useful as substitutes or
enhancements for visual presentation of maps, charts,
diagrams, and other types of object-oriented graphical
information. Many of these technologies rely on
feedback from the computer to identify and display
information about the important objects in the figure.
For example, [Jacobson and Kitchin] reported that blind people can "read" maps rather well by using a touch screen and running their fingers along a road or railroad track, interrogating cross streets as they are encountered, etc. This "map-reading" method requires not only a touch screen but also graphics software that can provide information to the viewer about any major object on the screen. In this case the names of streets, railroads, foot- and bike-paths, etc. This access method relies on the user's ability to assimilate a mental spatial image of the map. A tactile image reduces the mental effort, and this 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. See [Parkes] reference. |
|
Unfortunately, there are no
technologies for displaying refreshable tactile images
online, but it has recently become possible to create a
tactile copy of a computer picture. This figure on a
touch screen or other digitizing tablet permits a blind
user to feel the tactile images, and receive audio
feedback from the computer about those images. The
[TIGER printer] is very convenient for this purpose,
but people who have no TIGER can use [swell paper] to
make tactile copies.
Offline printing is time-consuming and makes it very difficult for a blind person to take advantage of features like zoom views. A number of online haptic technologies are being developed. The purpose of these devices is for use with virtual reality. One such technology, the haptic mouse, has already been introduced or announced for imminent release by several companies including Immersion Corporation (San Jose, CA, USA) and Control Advancements (Kitchener, Ontario, Canada). These devices may soon permit blind people to explore graphics online. [TIGER printer] The TIGER TactIle Graphics EmbosseR was developed by the SAP http://dots.physics.orst.edu/tiger_project.html and is commercially available from ViewPlus Technologies, Inc., 3223 NW McKinley Drive, Corvallis, OR 97330, http://www.viewplustech.com [Swell paper] is a special paper that can be used to make tactile copies by radiant heating that causes black areas to swell http://www.repro-tronics.com |
"Haptic perception" is not the same but is equivalent to "visual perception" for images. Those who see images learn to "read" the images and their perspective. Cultural differences account for different ways of representing the third, and other, dimensions. For images in the western tradition, "perspective points" determine the form of representation. For people who feel, rather than see 3D representations (the objects get folded out, e.g., a Coke can might have its flat side but also its two ends). An interesting paper on this issue is Rendering Drawings for Interactive Haptic Perception at: http://www.inf.fu-berlin.de/~kurze/publications/chi_97/mk-hapt.htm. It points out that, for example, 3Dness is not represented in perspective, as for sighted people, but rather in relativity, as suggested by the haptic perception image below.
The above drawings show "two equivalent solutions for
flattening a long table. The upper one is chosen if the table
is surrounded by other objects, the lower one if objects
stand on the tabletop."
At http://www.corda.com/examples/example-s.cfm there are some examples of interactive data-driven graphics. Available for purchase is Corda's software to produce Section 508 compliant accessible charts and graphing solutions at: http://www.corda.com/508/.
The success of PowerPoint is probably due to the ease with which users can create what look like "professional" presentations. PowerPoint allows users to mix and match, to drag and drop, and all sorts of objects can end up on a PowerPoint slide with no external information about how they came together, what relationship they have, and so on. Such slides may have no more than a simple set of text outline statements that can be accessed by someone with vision impairments. It may be worse, it is possible that none of the slides end up being accessible.
Converting PowerPoint slides to web pages can also be problematic since the screen presentation of the PowerPoint display is converted into a single graphic image and is connected by links from one screen to another. All information is lost.
What was gained when lecturers learned to use PowerPoint, and at last had good clear font to work with, was gained at a cost to those with special needs or different devices. Two possible alternatives are suggested below: one involves a system that is designed to make sharing of slides easier, including sharing of them exclusively with a particular person, and the other works by making it easy for slide authors to create single web pages, using a good WYSIWYG editor, and then converting their single page into a set of consecutive web pages.
Arsdigita at http://www.arsdigita.com/acs-repository/one-version?version_id=1114 offers an open source alternative to PowerPoint, called "WimpyPoint".
The following description is located on the Arsdigita website (http://www.arsdigita.com/help/for-one-page?url=%2Fwp%2Findex.tcl):
"You can build a slide presentation in WimpyPoint from any Web browser anywhere in the world. WimpyPoint will hold onto your presentation in a professionally maintained and backed-up relational database management system (Oracle 8). You can forget your laptop. You can drop your laptop. You will still be able to give your presentation anywhere in the world that you can find a Web browser.
"More interestingly, WimpyPoint lets you work with colleagues. From your desk at MIT, you can authorize a friend at Stanford to edit your presentation, the two of you can work together until you're satisfied, and then you can both go into a conference room at Hewlett-Packard Laboratories and give your talk from our server."
From the author, Philip Greenspun:
"You can visit http://wimpy.arsdigita.com and see the ancient version (of Wimpypoint) or http://www.arsdigita.com/wp/ to see the modern (version of Wimpypoint). One way in which WimpyPoint is accessible is that the old version uses very simple HTML. The new version uses the same simple stuff but also a cascading style sheet. So any dressing up won't affect people who've told their browsers to ignore publisher style sheets.
I don't think setting up a full ACS installation of the OpenACS (Open ArsDigita Community System) toolkit from http://www.openacs.org would be too tough for most organizations. It doesn't take longer than one morning, including Postgres install."
The W3C Slidemaker Tool converts a single long HTML page into a set of slides. It makes it easy to separate text from presentation, which it handles by way of stylesheets. It also encourages good use of metadata and helps presenters ensure that their presentation will be accessible to alternative devices. See http://dev.w3.org/cvsweb/slidemaker/
The representation of spatial information, particularly 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, etc.
In the past, Braille music could only be produced manually by a small number of specialists. For example, a blind flutist wishing to participate in the school band would need to send copies of the musical score to a transcriber. Braille transcriptions were not returned for weeks or even months, since the ratio of specialists to demand is high. With a translator, transcriptions can be produced locally in a few hours by sighted copyists with no special training in music Braille.
Internationalization of the Web is a major goal for many. The problem is that the use of many different alphabets involves more than changes of font. With some alphabets it is not easy to allow for the wide variety of alphabets and character representations that make up written languages, let alone have "texts" that run from left to right integrated with those that run from right to left, or top to bottom. In addition, many languages are not written using alphabets at all.
The most effective approach towards a solution to these problems has been the work around the use of Unicode, coupled with SVG and SMIL, and stylesheets. Unicode is a more complex matrix set than the original ASCII character set developed in the early days of computing by Americans, for whom it mostly "did the job". With the involvement of so many languages on the Web, Unicode provides a way for new character sets to be developed for languages that have not been used on computers. This does not happen without a cost, however. Most legacy software does not understand Unicode, and only a few new browsers, etc. can cope with it. So there will be a transition period in which it will need to be specifically indicated and promoted, and plug-ins may be needed.
The layout options are no longer a problem, and the use of Unicode is becoming far more widespread in terms of authoring and access packages.
Basic accessibility requirements expect the change of language within a document to be flagged by tags indicating the language of what follows. For more information about internationalization, see: 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 aspects of working with foreign languages (i.e., several languages within a single web resource), or working with non-English language, can be difficult, it is recommended that users consult the W3C help pages at http://www.w3.org/International/O-help.html.
Ruby is the term used for 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. Ruby is also used in China, especially in schoolbooks. Ruby may prove very useful for accessibility.
"Sometimes more than one ruby text is associated with the same base text. A typical example is to indicate both meaning as well as reading for the same base text. In such cases, ruby texts may appear on both sides of the base text. Ruby text before the base text is often used to indicate reading; ruby text after the base text is often used to indicate meaning.
"[The following is] an example of base text with two ruby texts, giving reading using hiragana and Latin letters." Below is a representation of "ruby texts applied to the same base text."
For more information about Ruby mark-up, see http://www.w3.org/TR/ruby/#simple-parenthesis
The W3C Ruby specification defines Ruby markup to be usable with XHTML, so that ruby text is available on the Web without using special workarounds or graphics. See http://www.w3.org/TR/ruby/
W3C Ruby accessibility techniques from http://www.w3.org/TR/ruby/#non-visual:
Documents containing ruby markup may in some cases 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:
The W3C WAI Web Content Accessibility Guidelines 1.0 provide information that is relevant to eLearning content for the Web. They are available on the Web at: http://www.w3.org/TR/WCAG10/
The W3C WAI User Agent Accessibility Guidelines 1.0 provide information about
features that should
be included in tools used to read eLearning content. They are available
on the Web at: http://www.w3.org/TR/2001/WD-UAAG10-20010622/
Accessibility
techniques for specific development environments are available on the Web
at: http://www.w3.org/TR/ATAG10-TECHS/#check-use-system-conventions
Assistive technologies: A reference on types of ATs and a list of vendors for
each are provided in the Technical Glossary
of the Adaptive Technology Resource Centre at the University of Toronto
are available on the Web at: http://www.utoronto.ca/atrc/reference/tech/techgloss.html
The CPB/WGBH National Center for
Accessible Media's "Making Educational Software Accessible: Design Guidelines
Including Math and Science Solutions" are available at the Web at: http://ncam.wgbh.org/cdrom/guideline/
The following individuals contributed to the development of this document:
| Title | IMS Guidelines for Developing Accessible Learning Applications |
|---|---|
| Editors | Cathleen Barstow, Liddy Nevile, Madeleine Rothberg, Mark McKell |
| Version | 0.6 |
| Version Date | 19 October 2001 |
| Status | White Paper |
| Summary | This document presents the IMS Guidelines for Developing Accessible Learning Applications. |
| Revision Information | 19 October 2001 |
| Purpose | Describes the guidelines for creating or retrofitting learning applications to meet the demands of accessibility. |
| Document Location | http://www.imsglobal.org/accessibility/accwpv0p6/imsacc_wpv0p6.html |
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 ApplicationsRevision: 19 October 2001