3. Principles for Accessibility in Online Distributed Learning
The following principles present best practices for producing accessible software applications and accessible content for online distributed learning. Developers, content providers and educators involved in the creation of learning products should adhere to these guidelines from the outset of the design process, since retrofitting an inaccessible product is almost always significantly more difficult, labor-intensive and expensive.
We offer six principles that address accessibility for people who have sensory or mobility disabilities. These principles also address accessibility issues faced by people with cognitive disabilities, though often to a lesser extent.
- Allow for customization based on user preference.
- Provide equivalent access to auditory and visual content based on user preference.
- Provide compatibility with assistive technologies and include complete keyboard access.
- Provide context and orientation information.
- Follow IMS specifications and other relevant specifications, standards, and/or guidelines.
- Consider the use of XML.
3.1 Allow for Customization Based on User Preference
When applications make it possible to present information in a versatile manner, content becomes more accessible, reaching a wider variety of users. Some examples of items that should be customizable by the users fall into two categories:
Customizable display elements include:
- font, font style, font color, and font size.
- cursors size, style, and blink rate.
- size of text and images, including video.
- screen layout, colors, and backgrounds.
Customizable interface features include:
- timing of events.
- keyboard settings.
Allowing the user to customize elements of the application and its content is essential for accessibility. Hard-coding presentation elements such as fonts, may make access impossible for some users. Depending on a user's abilities and preferences, they may seek to change settings for presentation style, size, or timing. For example, a user with low-vision may want to change the style of a font and enlarge the size of text.
The user should also be able to change other application features, such as the timing of events. For example, dialog boxes and alerts should remain on 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 assistive technologies (AT) provide less efficient ways of interacting with the software. Those timing requirements should be customizable by the user.
3.2 Provide Equivalent Access to Auditory and Visual Content Based on User Preference
To be fully accessible to deaf or hearing-impaired users, applications should provide equivalent access to all auditory aspects of learning technologies and content.
To make applications accessible to those with hearing impairments developers can:
- Caption all auditory content.
- Provide a text transcription of auditory content.
For blind or visually impaired users, applications should provide equivalent access to all visual aspects of learning technologies and content. Specifically, developers should:
- Add text descriptions (alternative text or alt-text) to all static images (e.g. pictures, logos, charts, links, other graphics) so the text can then be read by a screen reader or output to a Braille display.
- Utilize the "longdesc" attribute for images that have useful content and require more lengthy descriptions.
- Provide audio description tracks for multimedia, describing visual aspects of the content.
For users who are deaf, hearing-impaired, blind, visually impaired, or deaf-blind, applications should combine equivalent access, as detailed above, for all auditory and visual aspects of learning technologies and content. Deaf-blind users in particular need text equivalents for all audio and visual material.
3.3 Provide Compatibility with Assistive Technologies and Complete Keyboard Access
Applications, software, and content must be compatible with all types of ATs including: screen readers, screen magnifiers, adaptive keyboards, voice recognition software, and single switches.
Developers should provide complete keyboard access to all elements of an application and its content, including menus, help directories, toolbars, and dialog boxes. Never assume that all users can operate a mouse.
3.4 Provide Context and Orientation Information
Applications and software are made more useable when developers provide context and orientation information to users. They should design their products to:
- Teach users how to navigate.
- Inform the user of the length of the document. For example, page numbers can be expressed as "Page X of Y pages".
- Provide a way for users to skip standard page headers and navigation links. Users who are already familiar with the page layout should be able to skip directly to the primary content.
- Maintain a consistent layout between pages.
- Content becomes more accessible when users can depend on consistency of presentation.
- Provide alerts/text warning whenever a new browser window will be automatically opened.
Applications that implement these features will help users of screen-reading software work more efficiently, saving time. They will be able to listen to content rather than rely on graphics or visual aids to navigate through content. In addition, these features benefit all users by increasing usability and minimizing the learning curve. And adhering to a consistent design between pages makes information generally easier to find for all users.
3.5 Follow IMS Specifications and Other Relevant Specifications, Standards, and/or Guidelines
Developers who follow relevant specifications and guidelines increase accessibility in two ways. Obviously, guidelines that provide information on how to implement accessibility within applications offer useful techniques and suggestions to programmers. But because accessibility often relies on interoperability between learning applications, software, content and assistive technologies (AT), 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 making it more likely that ATs will be able to operate with them.
Developers within the online distributed learning industry who seek to promote more fully interoperable technologies should fully adopt IMS Global Learning Consortium specifications.
Through the work of the IMS Accessibility Project Group, in conjunction with other IMS Project Groups, these specifications will continue to evolve and will include additional, specific sections intended to improve accessibility of online distributed learning technologies.
Many IMS specifications are currently available:
- The IMS Profiles Specification and Enterprise System Specification organizes learner information and specify interfaces for exchanging student, course, and administrative data. They make learning systems more responsive to the specific needs of each user, as well as better integrated with administrative software systems.
- The IMS Content Packaging Specification makes interchange of content possible between different learning systems.
- The IMS Question & Test Specification allows institutions to share test items and other assessment tools across different systems.
- The IMS Learning Resources Meta-Data Specification creates a uniform way for describing learning resources.
Several IMS specifications are currently in development (at time of publication of this document):
- The IMS Accessibility Project Group is currently working on producing additions to the Learner Information Profile (LIP) specification and to include provisions for accessibility in the Meta-Data specifications.
- The IMS Learning Design Project Group is finalizing a base-level information model. This model will provide extensions to IMS Content Packaging used to describe a learning experience.
- The IMS Digital Repositories Project Group has finalized a base-level information model that has been submitted for approval by the IMS Technical Board. This model specifies a means to perform searches, gather information, and set up alerts across different kinds of repositories.
- The IMS Simple Sequencing Project Group has finalized a base-level information model. The group will submit their work for approval by the IMS Technical Board. This model describes a rule-based method for ordering and presenting learning objects to a user.
Throughout this document there are references to additional industry specifications, standards and guidelines, which are also listed in Appendix B of this document.
Resource:
- IMS specifications are available for download to the public, free of charge.
3.6 Consider the Use of XML
XML (Extensible Markup 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 assistive technology often requires interoperability between the application delivering the actual course content or services and the specialized application, used by a learner with a disability, to access that content.
Materials authored in XML also offer the following benefits:
- Transformable and flexible: XML encourages separation of content and presentation. It allows user agents to transform the presentation of content to meet users' individual needs, even if the author didn't consider those transformations.
- Structured and validated: XML encourages use of consistent nested structures, which make it easier to navigate complex learning materials. Also, XML documents can be validated to ensure they use mark-up appropriately.
- Text based: XML documents are likely to contain re-usable text content since they are created as text documents. Providing text improves accessibility as described in Section 5, "Guidelines for Accessible Delivery of Text, Audio, Images, and Multimedia". XML does not guarantee accessibility. To avoid creating accessibility problems, developers should follow guidelines accompanying any published XML language (see the WAI for information on W3C languages). Also, developers should use existing XML languages whenever possible, especially if they have built in accessibility features, such as those from the W3C (see Section 4 for more details). When designing a new XML language, developers should follow the W3C's recommendations to ensure that the new language is as accessible as possible.
Resource:
- For more information, see the W3C's XML accessibility guidelines.
