ACCLIP Briefing

Back to Accessibility Topic Front Page.

This is the HTML version of the IMS Accessibility for Learner Information Package (ACCLIP) Specification Briefing Paper (Word Format) - 66Kb.

What is the ACCLIP Specification? The IMS ACCLIP Specification provides a means of describing preferences so that learners can interact with an e-learning system regardless of disability, hardware or   environment. These preferences are based on those parts of a computer system (hardware and software) that can be adjusted to improve accessibility, rather than on type of disability. It    concentrates on the display, control and selection of learning content, so that learners with alternative content or interface requirements can be supported.

The name of root element - &lt;accessForAll&gt; - shows that it goes beyond addressing preferences for learners with disabilities to ensure that all learners can define preferences. For example, learners with a hearing impairment, without a soundcard, or studying in a library may all have similar requirements, perhaps preferring captions instead of an audio track. It also allows learners to specify different sets of preferences (contexts) for different situations.

Some preferences can be listed hierarchically. For example, one type of assistive technology can be specified alongside optional alternatives if the preferred choice is not available - a learner might prefer to use the JAWS screen reader, but will optionally use the WindowEyes screen reader, if JAWS is not available. The ACCLIP Specification consists of five documents:   ACCLIP Information Model - defines the actual elements and data structures for representing accessibility preferences.  ACCLIP XML (eXtensible Mark-up Language) Schema Binding - describes how these elements are represented in XML.  ACCLIP Best Practice and Implementation Guide - gives examples and suggestions for best practice.  ACCLIP Conformance Specification - provides information for developing ACCLIP test plans.  ACCLIP Access for All Use Cases - contains use cases and examples of usage.

It is available free of charge from http://www.imsglobal.org/accessibility/#acclip.

Back to Top of Page

Why is it useful? Implementing the ACCLIP Specification ensures that learners can control how they interact with e-learning resources, regardless of the computer interface or environment around them. It also enables e-learning systems to locate and present resources appropriate to the learner's needs, such as captions or audio descriptions for video. The ability to modify the display, control and content is useful for many different types of learners, such as those:  With disabilities; With low-bandwidth;</li> Using mobile devices, such as PDAs (Personal Digital Assistants), 'phones, handheld computers, etc;</li> With older or slower hardware;</li> Without or unable to use certain pieces of hardware (e.g. speakers, soundcard, mouse, keyboard, etc);</li> In noisy environments (such as a mine) or quiet environments (such as a library).</li></ul>

Back to Top of Page

Related IMS Specifications The ACCLIP Specification is part of the IMS LIP (Learner Information Package) Specification, which enables information about a learner's history, goals, and    accomplishments to be recorded and managed. The ACCLIP &lt;accessForAll&gt; element is a component of the LIP &lt;accessibility&gt; element, whilst the ACCLIP &lt;accommodation&gt; element is a component of the LIP &lt;eligibility&gt; element. Other relevant specifications    include:

<ul>  Access For All Metadata 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>  Content Packaging Specification - for identifying and accessing alternative forms of content. Accessibility preferences should be packaged in a Content      Package.</li>  Learning Design Specification - selection of alternative content and sequencing may impact on the actual learning design.</li>  QTI (Question and Test Interoperability) Specification - accessibility preferences may affect how assessments are delivered.</li>  Simple Sequencing Specification - describes how content can be sequenced. The selection of alternative content may have an effect on the sequencing of learning activities.</li></ul>

Back to Top of Page

How does it work? The ACCLIP Specification defines the &lt;accessForAll&gt; root element. This element contains the &lt;context&gt; element, which itself contains the three elements that represent learner  preferences - &lt;display&gt;, &lt;control&gt; and &lt;content&gt;. The &lt;accommodation&gt; element describes what a learner may use in a test situation.

&lt;context&gt; This is the top set of elements, under the &lt;accessForAll&gt; root, and contains the elements which describe a learner's preferences: &lt;display&gt;, &lt;control&gt; and    &lt;content&gt;. Different contexts can be created, which define different sets of preferences for different situations, depending on, for example, the time of day, study environment or hardware environment. The first context is always considered as the default.

&lt;display&gt; This element has a number of sub-elements that define how the interface and content should be presented to the learner. It covers:

<ul> Speech synthesizers (e.g. screen readers) and screen enhancement (e.g. screen magnifiers);</li> Text highlighting;</li> Braille displays and tactile displays;</li> Visual alternatives to audio alerts; and</li> Content structure settings (e.g. how windows should be displayed).</li></ul>

The following XML example shows some of the preferences that could be set for a screen reader. In this case, the screen reader would read out any links, and would "speak" at 180 words a    minute.

&lt;control&gt; The sub-elements under &lt;contro&gt; define how the learner interacts with the technology. It covers:

<ul> Accessibility enhancements for a standard keyboard, virtual (onscreen) keyboards, and alternative keyboards;</li> Mouse emulators (e.g. non-pointing devices) and alternative pointing devices;</li> <li>Voice recognition settings for spoken commands and dictation;</li> <li>Coded input (control methods that use a code to select the desired input);</li> <li>Prediction (e.g. word prediction); and</li> <li>Navigation through the content (e.g. use of a table of contents for navigation). </li></ul>

The following XML example shows some of the preferences that could be set for an alternative pointing device, such as a trackball, joystick, stylus, etc. In this case, the learner prefers to use the device with the right hand, with an average double click speed.

&lt;content&gt; The &lt;content&gt; sub-elements, which could be paired with metadata to facilitate searches for content with accessibility support, define the auxiliary, alternative or equivalent content requirements, such as:

<ul> <li>Alternatives to visual content (e.g. audio descriptions, colour avoidance);</li> <li>Alternatives to text (e.g. graphics or sign language);</li> <li>Alternatives to audio content (e.g. captions or sign language);</li> <li>A learner scaffold (place to carry common tools, such as a dictionary, calculator, spell checker etc);</li> <li>Links to personal style sheets; and</li> <li>Requests for extra time. </li></ul>

The following XML example shows the preferences that could be set for alternatives to text if a learner has difficulties hearing sound or reading text. In this case, the learner prefers to   have graphic alternatives displayed and British Sign Language, if available.

&lt;accommodation&gt; This element has a number of sub-elements, which specify the preferences a learner is allowed when interacting with particular learning objects, such as tests, to ensure    that these preferences do not stop the learning object from fulfilling its intended purpose; for example, allowing the use of a spell checker during a spelling test. This element includes:

<ul> <li>Description of the learning object (e.g. test);</li> <li>The learner's request for the accommodation;</li> <li>The actual accommodations that are allowed;</li> <li>Who authorized the accommodation;</li> <li>When it was authorized and when it expires. </li></ul>

These accommodations are generally approved in advance of a test and any number of &lt;accommodation&gt; element sets can be defined.

Back to Top of Page

What is required? In order to present content according to the learner's preferences, the learner must first specify those preferences. Therefore, an interface needs to be developed to anonymously collect and store the learner's preferences. This interface should allow the learner to create, edit and modify preferences. A possible interface could take the form of a   wizard or interactive form, which takes the learner through preference choices. Learners should also be able to change their preferences on-the-fly, with an option to save them at the time of change or at the end of the session. It is recommended that a learner's preferences are not associated with their identity, although some form of authentication may be required. An  interface may also need to be designed to capture information relating to the &lt;accommodation&gt; element.

The architecture of the ACCLIP implementation also needs to be designed. The ACCLIP Specification does not specify an architecture, as it simply defines accessibility   preferences, which could be included as part of a learner profile. However, as a possible example, an ACCLIP Manager could be designed as part of a larger Learner Profile Manager. Although ACCLIP preferences can be implemented and used in isolation, both an ACCLIP repository (for creating, storing and managing ACCLIP data) and an ACCLIP   application (allows the relevant parts of the computer system to interact with the preferences file and present the content as the learner has specified) are required. An   ACCLIP repository could consist of, for example: a smartcard, a Web-based repository, or a locally based repository associated with an MLE (Managed Learning Environment).

It is beyond the scope of the ACCLIP Specification to actually define how the content presented to the learner should be designed or sequenced. However, it is assumed that that it complies with the W3C WCAG (World Wide Web Consortium Web Content Accessibility Guidelines) - available free of charge from http://www.w3.org/TR/WAI-WEBCONTENT/.

Back to Top of Page

Example Use Cases and Implementations Mining Environment Use Case Two mining engineering students, one of whom is colour-blind, wearing protective goggles and gloves are using a computer underground in a noisy mine. Each student has their own set of preferences (context) set up on the computer and there is also a set of preferences for when the students work together. When the students work together, text is displayed as yellow on a black background, so that both the students can read the text. A joy-stick mouse and onscreen keyboard is used to control the computer as it would be difficult to use a standard computer keyboard when wearing protective clothing. The actual content is presented as text and graphics and alternatives to sound are automatically selected by the system based on the information supplied from the current context.

Web-4-All Project - http://www.web4all.ca/ The Web-4-All Project enables users of public access internet terminals in Canada to define their preferences and so that they can use any other public access terminal without having to set them up again. It uses a combination of hardware and software to record and store a user's preferences as an encrypted, compressed XML string, which the user carries around on a smartcard. A wizard guides users through the initial configuration process. Users then need only insert their smartcard into the public access terminal in order for their preferences to be displayed. Once the user leavers the terminal, the system automatically sets the preferences back to a default setting. These preferences can also be adjusted at any time depending on the user's needs.

BarrierFree - http://www.barrierfree.ca/ The BarrierFree Project has created media-rich learning content that transforms in response to the needs of the learner. Tools were developed, including authoring tools, a player/browser, a   preference wizard, and a dynamic learning object repository that implements the &lt;accessForAll&gt; element. Video content was digitized and tagged using verbatim captions (a text transcription of the sound track) synchronized to the video through time code. These captions were used to mark up the structure of the video so that the learner could navigate through the video and search for specific segments. The captions were also used to link to auxiliary materials such as definitions, exercises illustrating a concept, and Web material. Alternative captions for more basic reading levels and audio descriptions (spoken descriptions of the visual content) were also created.

Back to Top of Page

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

<ul> <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>

<li>Briefing: IMS Guidelines for Developing Accessible Learning Applications (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.</li></ul>

Information for this briefing has been taken from the IMS Accessibility for Learner Information Package (ACCLIP) Specification.

End of Briefing: Back to Top of Page