Accessibility Guidelines Briefing

Back to Accessibility Topic Front Page.

This is the HTML version of the IMS Guidelines for Developing Accessible Learning Applications Briefing Paper (Word Format) - 65Kb.

What are the Accessibility Guidelines? The Accessibility Guidelines provide a set of accessibility resources and recommendations for the e-learning community, so that online learning can be made    accessible to everyone. They address the different (software) components of e-learning and provide information about how these components can be made accessible. The Accessibility    Guidelines are not intended as a replacement for existing guidelines, specifications or standards but act as a resource bank for each of those components. There is a section for each    component describing common accessibility problems, best practices, and resources. The Accessibility Guidelines are aimed at everyone in the e-learning community - i.e. software developers, vendors, educational publishers, content developers, administrators, educators, and students - regardless of technical expertise. They are available free of charge from: http://www.imsglobal.org/accessibility/#accguide.

Back to Top of Page

Why Are They Useful? Using the resources and recommendations described in the Accessibility Guidelines will help to ensure that all learners will be able to benefit from e-learning as much as    possible, regardless of disability, learning style, preferences, technology, or bandwidth. Accessible design gives learners more options and greater flexibility in how they    interact with an e-learning environment and it should, therefore, provide a more enjoyable and rewarding experience. Back to Top of Page

Related IMS Specifications The Accessibility Guidelines are relevant to the majority of IMS specifications, as not only must the e-learning content be accessible, but the e-learning systems that render the content must also be accessible and able to interoperate with assistive technologies.

Guidelines developed by the W3C WAI (World Wide Web Consortium Web Accessibility Initiative) are particularly important across the IMS specifications and include:

 ATAG (Authoring Tool Accessibility Guidelines) - provide assistance for developers designing authoring tools that produce accessible Web content, and assist in creating an accessible authoring interface. Available free of charge from: http://www.w3c.org/TR/ATAG20/. 

UAAG (User Agent Accessibility Guidelines) - provide guidelines for designing user agents, such as HTML (HyperText Mark-up Language)browsers and other types of software that retrieve and render Web content. Available free of charge from: http://www.w3c.org/TR/UAAG10/. 

WCAG (Web Content Accessibility Guidelines) - outline the design principles for creating accessible Web content, so that it can be made accessible to a variety of Web-enabled devices, such as 'phones, handheld devices, kiosks, etc. Available free of charge from: http://www.w3c.org/TR/WCAG20/.  XAG (XML Accessibility Guidelines) - for designing accessible XML (eXtensible Mark-up Language) Applications. Available free of charge from: http://www.w3c.org/TR/xag.

Back to Top of Page

How do they work? The Accessibility Guidelines are split into different sections, which relate to different components that could be used in an e-learning environment. A set of six common accessibility   principles are described, followed by accessibility recommendations for e-learning components, assessment and specialist topics, such as maths.

Six Principles for Accessibility It is recommended that developers, content providers and educators include these principles from the start of the design process, as attempting to retrofit accessibility can be      expensive and time-consuming. The six principles, which apply to each of the following e-learning components, are:

  Allow for customisation based on user preference - customisable elements include:  Font - style, colour, and size; Cursor - size, style, and blink rate;</li> Size of text and images (including video);</li> Screen layout, colours, and backgrounds;</li> Timing of events (dialog boxes and alerts should stay on screen until cleared by the user);</li> Keyboard settings.</li></ul> </li>

 Provide equivalent access to auditory and visual content based on user preference:  Caption auditory content;</li> Provide text transcriptions for auditory content;</li> Provide audio descriptions (describe visual aspects of the content) for multimedia;</li> Add text descriptions (&lt;alt&gt; text) to static images;</li> Use the &lt;longdesc&gt; attribute.</li></ul> </li>

 Provide compatibility with assistive technologies and include keyboard access. </li>  Provide context and orientation information:  Teach users how to navigate;</li> Provide information on document length;</li> <li>Use "skip page" and navigation links;</li> <li>Maintain a consistent layout between pages;</li> <li>Provide an alert if a new browser window opens.</li></ul> </li>

<li> Follow IMS and other relevant guidelines, specifications and standards - to improve interoperability. </li> <li> Consider the use of XML - to improve interoperability and flexibility of content presentation.</li></ol>

Guidelines for Accessible Delivery of Text, Audio, Images and Multimedia This section provides accessibility information for text, audio, images and multimedia. For example:

<ul> <li> Text - accessibility can be enhanced by structuring it correctly (e.g. marking up headings, etc) and using style sheets. </li> <li> Audio - accessibility can be improved by providing volume controls and visual equivalents to audio alerts. </li> <li> Images are generally not accessible without the support of text, but can also be made accessible by providing a zoom feature and using SVG (Scalable Vector       Graphics). </li> <li> Multimedia (combination of text, graphics, video, animation, and sound) - alternatives should be available for each media type.</li></ul>

Guidelines for Developing Accessible Asynchronous Communication and Collaboration Tools Accessibility recommendations - such as providing help files and ensuring that the name of the thread, message, document or event accurately reflects its contents - are given for the    following asynchronous communication and collaboration tools:

<ul> <li> Threaded message boards - e.g. discussion forums, bulletin boards, etc;</li> <li> E-mail and listserv messaging; <li> Document repositories; </li> <li> Organisers, schedulers, and calendars. </li></ul>

Guidelines for Developing Accessible Synchronous Communication and Collaboration Tools Both the user interface of synchronous communication and collaboration tools, as well as the real-time communication, should be accessible. For example, it is recommended that a     real-time text transcript should be provided as well as mechanisms for learners who communicate slowly. This section covers: <ul> <li> Synchronous text chat; </li> <li> Audio-conferencing; </li> <li> Video-conferencing; </li> <li> Whiteboards; </li> <li> MOOs (Multi-user domain Object Oriented environments) - whereby users control "avatars" that move through the virtual world, interacting and communicating via     speech generated from user-typed instructions.</li></ul>

Guidelines for Developing Accessible Interfaces and Interactive Environments Accessibility recommendations for interfaces and interactive environments include, for example, ensuring that the tab order of forms makes sense and that colour is not relied on for highlighting information. This section covers:

<ul> <li> Interface controls - including buttons, text fields, text field labels, menus, etc;</li> <li> Interface navigation; </li> <li> Forms; <li> Interactive exercises - drag-and-drop exercises, simulations and timed tests;</li> <li> Interactive tutorials; </li> <li> DVDs, consumer electronics and handheld devices - i.e. accessible kiosks and DVD, set-top box and touch screen accessibility;</li> <li> Accessibility information for operating systems and development platforms - such Microsoft's Windows, Apple's Macintosh, Java platform, Web accessibility, and other  operating systems.</li></ul>

Guidelines for Testing and Assessment This section describes several guidelines for assessment accessibility and discusses the need to ensure that accessibility accommodations do not invalidate the assessment objective. For example, at a low-stakes assessment level (tests the immediate process of learning); the use of spellchecker during a spelling test might invalidate the objective of testing a learner's      spelling. At high-stakes level (may have an impact on a learner's life); accessibility accommodations may need to be rigorously controlled. Equivalent content formats (see "What is required?" section below) should be used where possible and alternative formats should be used with caution, particularly at high-stakes level. These guidelines include:

<ul> <li> Consider accessibility from the earliest stage; </li> <li> Follow standards for testing and assessment that promote test validity - accessibility features need to be examined for any impact on the validity of the assessment;</li> <li> Build a coherent rationale for the assessment; </li> <li> Develop a reuse strategy that includes test content, designs, etc. </li></ul>

Guidelines for Developing Accessible Authoring Tools Authoring tools should support the creation of accessible content and should also be accessible to authors with disabilities.

Guidelines for Topic Specific Accessibility This section covers:

<ul> <li> Mathematics - e.g. use SVG and MathML (an XML mark-up language for maths);</li> <li> Physics and chemistry - e.g. use SVG and ChemML;</li> <li> Simulations and immersion; </li> <li> Robots and telepresence; </li> <li> Charts, diagrams and tables - can be made accessible by providing the information in other formats, such as interactive audio descriptions, text descriptions, tactile images, haptics or 3D models;</li> <li> Geography and maps - Maps produced from textual information held in databases can be printed to a haptic printer. Generally, all data-driven graphics, including maps, should be rendered as SVG;</li> <li> Music; </li> <li> Languages - Catering for the variety of alphabets and character representations can be difficult, although the use of Unicode (a more complex set of characters than the ASCII character set), SVG, SMIL (Synchronised Multimedia Integration Language), and style sheets may help.</li></ul>

Back to Top of Page

What Is Required? There are no special requirements for implementing the recommendations described in the Accessibility Guidelines. However, implementing accessibility guidelines may impact on the format of e-learning content. For example, if the original content, despite being made as accessible as possible, is not suitable, then depending on the learner's preferences and    requirements, it can be presented as:

<ol> <li> Equivalent content - the original content is presented in a different format; for example, providing a printed textbook in Braille, on audio tape, or digitally;     or  </li>

<li> Alternative content - presents content that is different to the original, but which is designed to achieve the same learning objectives. For example, a multiple choice test might be given to learners, who are unable to use a mouse or graphical interface, instead of a drag-and-drop exercise. Alternative content should only be provided if it is not possible to provide equivalent content.</li></ol>

Back to Top of Page

Example Implementations Digital Frog has produced a "Digital Fieldtrip to the Rainforest" e-learning resource, which is accessible to assistive technology users. It is available from: http://www.digitalfrog.com/products/rainforest.html. It can be used by learners with different learning styles and disabilities and has full keyboard accessibility and closed captioning.

NCAM (National Centre for Accessible Media) has produced an accessible maths game, called "How the West was One + Three x Four", available from: http://ncam.wgbh.org/cdrom/guideline2000/west.html. It has keyboard accessibility, audio instructions and on-screen information.

Back to Top of Page

Other Briefings Other briefings in this series are available and include:

<ul> <li>Briefing: IMS Accessibility for Learner Information Package (ACCLIP) Specification - This specification provides a means of describing preferences so that learners can interact with an e-learning system regardless of disability, hardware or environment. </li>

<li>Briefing: IMS AccessForAll Meta-data (ACCMD) Specification - The ACCMD Specification defines the meta-data that can be used to describe a learning resource's accessibility and its ability to match a learner's preferences.</li></ul>

Information for this briefing has been taken from the IMS Guidelines for Developing Accessible Learning Applications (Accessibility Guidelines).

End of Briefing: Back to Top of Page