 |
1EdTech Learner Information Package Accessibility for LIP Best Practice and Implementation Guide Version 1.0 Final Specification |
Copyright © 2003 1EdTech Consortium, Inc. All Rights Reserved.
The 1EdTech Logo is a trademark of 1EdTech Consortium, Inc.
Document Name: 1EdTech Learner Information Package Accessibility for LIP Best Practice and Implementation Guide
Revision: 18 June 2003
IPR and Distribution Notices
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.
1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.
Copyright © 2003 1EdTech Consortium. All Rights Reserved.
Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.
Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/license.html.
The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.
THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.
Table of Contents
1. Introduction
1.1 Overview
1.2 Scope and Context
1.3 Structure of this Document
1.4 Nomenclature
1.5 References
2. Relationship to Other Specifications
2.1 1EdTech Specifications
2.1.1 1EdTech Learner Information Package
2.1.2 1EdTech Content Packaging
2.1.3 1EdTech Simple Sequencing
2.1.4 1EdTech Question and Test Interoperability
2.2 Related Specifications
2.2.1 IEEE Learning Object Metadata
2.3 1EdTech Specification Development Process
3. Conceptual Overview
3.1 Accessibility Preferences
3.1.1 Accessibility Preferences for People with Disabilities
3.1.2 Accessibility Preferences for People with Other Types of Access Challenges
3.1.3 Accommodation Eligibility
3.2 Intended Uses
4. Examples
4.1 Basic Examples - Generic
4.1.1 Examples of Display Preferences
4.1.2 Examples of Control Preferences
4.1.3 Examples of Content Preferences
4.2 Basic Examples - Application Specific
4.2.1 Screen Reader - HomePageReader
4.2.2 On Screen Keyboard - VDK
4.2.3 Text Reader - CAST eReader
4.2.4 Screen Reader - JAWS
4.3 Basic Examples - Accommodation Eligibility
4.4 Advanced Examples
4.4.1 Multiple Contexts
4.4.2 Morning vs. Night Example
4.5 Special Examples
4.5.1 Externally Define Contexts and Shared Profiles
5. Run-Time Implementation
5.1 Recommended Implementation Guidelines
5.1.1 Specification of Preferences
5.1.2 Communication of the <accessForAll> Instance
5.1.3 Response to the Specified Preferences
5.2 Web-4-All
5.2.1 The Web-4-All Implementation
5.2.2 The Web-4-All Preference Wizard
5.3 BarrierFree
5.4 Mapping Generic Preferences to Actual Applications
6. Best Practice Recommendations
6.1 Context Identifiers
6.2 Dynamic Preferences
6.3 Privacy
6.4 Stand-Alone Use
Appendix A - List of Example Files
About This Document
List of Contributors
Revision History
Index
1. Introduction
1.1 Overview
The 1EdTech Learner Information Package, Accessibility for LIP (ACCLIP) specification adds a new element under <accessibility> to allow learner accessibility preferences to be defined. Rather than being a description of the learner's abilities, it allows him or her to explain how they interface and use a computer mediated learning system. A learner may have one or more defined preference sets, called a context. It also adds a new element under <eligibility> to allow recording of requests for and authorization of accessibility accommodations for testing or assessment.
Preferences are grouped into <display>, <control>, and <content> elements. Display preferences describe how the user prefers to have information displayed or presented. Control preferences describe how a user prefers to control the device. Finally, content preferences describe what enhanced, alternative or equivalent content the learner requires. This document describes best practices related to the <accessForAll> preferences and accommodation.eligibility elements. It includes recommendations on how to implement this specification in a learning environment. Examples of the preference elements are included to give a better understanding of how they are represented and grouped. General practices are included to explain special or technical points.
1.2 Scope and Context
This document is the final version of the 1EdTech ACCLIP Best Practice and Implementation Guide As such it should be used in conjunction with:
- 1EdTech Learner Information Package Accessibility for LIP Information Model v1.0 [ACCLIP 1a]
- 1EdTech Learner Information Package Accessibility for LIP XML Binding v1.0 [ACCLIP 1b]
1.3 Structure of this Document
The structure of this document is:
1.4 Nomenclature
The following abbreviations and acronyms are used in this document.
1.5 References
The following document references are identified:
| [ACCLIP 1a,b,d,e] | 1EdTech Learner Information Package Accessibility for LIP Information Model, Binding, Use Cases, and Conformance Specification |
| [LIP 1a,b,c] | 1EdTech Learner Information Package Information Model, Binding, and Best Practice Guide |
| [SS 1a,b] | 1EdTech Simple Sequencing Information Model, Binding Guide |
| [CP 1a,b,c] | 1EdTech Content Packaging Information Model, Binding, Best Practice Guide |
| [QTI 1a,b,c] | 1EdTech Question and Test Interoperability Information Model, Binding, Best Practice Guide |
| [RDCEO 1a,b,c] | 1EdTech Reusable Definition of Competency or Educational Objective Information Model, Binding, Best Practice Guide |
| [LD 1a,b,c] | 1EdTech Learning Design Information Model, Binding, Best Practice Guide |
| [RFC 1766] | http://ds.internic.net/rfc/rfc1766.txt (xml:lang) |
| [SCORM] | http://www.adlnet.org (ADL SCORM) |
2. Relationship to Other Specifications
2.1 1EdTech Specifications
Version 1.0 of the 1EdTech ACCLIP specification is made up of four documents:
- 1EdTech Learner Information Package Accessibility for LIP Information Model - Version 1.0. This document describes the data structures that are used to provide interoperability between learning management systems that sequence learning activities;
- 1EdTech Learner Information Package Accessibility for LIP XML Binding - Version 1.0. This document describes how to encode the sequencing objects in XML and provides the corresponding XML schema;
- 1EdTech Learner Information Package Accessibility for LIP Best Practice and Implementation Guide - Version 1.0. This document provides an overview and describes how the Learner Information Package Access for All Information Model and XML Binding can be applied to specific interoperability scenarios.
- 1EdTech Learner Information Package Accessibility for LIP Use Cases - Version 1.0. Collected use cases that were used to determine the requirements of the Accessibility for LIP work.
The ACCLIP specification is related to other 1EdTech specifications, both complete and in-progress.
2.1.1 1EdTech Learner Information Package
The 1EdTech Learner Information Package [LIP 1a,b,c] specification describes a means to represent various characteristics associated with a learner that are needed for the purpose of recording history, goals, and accomplishments; engaging a learner in a learning experience. The LIP has twelve parts, bound by separate XML schemas: content type, identification, goals, qualifications and licenses, activity, interest, competency, accessibility, transcript, affiliation, security, and relationships.
The <accessibility> elements grouped into: language, eligibility, preference, and disability. The ACCLIP specification expands these definitions by adding a new element called <accessForAll> and deprecating the <disability> element. The new element was added to describe accessibility needs other than those just for people with physical disabilities. In addition, Accessibility for LIP extends the <eligibility> element by adding an <accommodation> element that allows one to specify accommodations for which a learner is eligible when using a particular learning object, such as a test.
2.1.2 1EdTech Content Packaging
The 1EdTech Learner Information Package Best Practice Guide [LIP 1c] indicates that the 1EdTech Content Packaging specification [CP 1a,b,c] is to be used for the packaging of a LIP XML instance. It will do this for a single learner instance and the aggregation of several instances for a single learner or for multiple learners.
By extension, the accessibility preferences defined by <accessForAll> and <accommodation> should be packaged in a Content Package using the techniques previously described.
2.1.3 1EdTech Simple Sequencing
The 1EdTech Simple Sequencing specification describes how content can be sequenced using information added to a Content Package manifest file. This specification has a very limited capability of accessing information outside of its state model. The Learning Objectives referred to in Simple Sequencing correspond to the kind of competency descriptions that can be included in a learner profile.
It is anticipated that future versions of Simple Sequencing will include the ability to test for accessibility preferences, such as those described in Accessibility for LIP. By including this ability, the sequencing engine will be able to adapt content or user choices based on individual accessibility preferences and alternative forms of content, where available.
2.1.4 1EdTech Question and Test Interoperability
Currently, the 1EdTech Question and Test Interoperability v1.2 Specification does not refer to accessibility needs. The ACCLIP specification has some support for accessibility needs during assessment situations (<learnerScaffold>, <extraTime>, etc.). The <accessibility> element under <eligibility> also relates to assessment. Future versions of QTI should consider how these preferences and eligibility impact the delivery of online assessment.
2.2 Related Specifications
2.2.1 IEEE Learning Object Metadata
The IEEE has defined a meta-data system for describing learning objects (LOM). This standard, IEEE p1484, was based in part on the 1EdTech Meta-Data specification.
At the time of this writing, 1EdTech specifications provide there is very little support for descriptive meta-data used for supporting accessibility. A project has been proposed within 1EdTech to develop a set of meta-data elements that would allow content to be described in a manner which corresponds to the accessibility preferences described by ACCLIP.
2.3 1EdTech Specification Development Process
The development lifecycle for 1EdTech specifications has been established as:
- Month 0 - Set up of the team including identification of the team and key collaborating groups and organizations. Team and scope/requirements development as an approved charter by the 1EdTech Technical Board;
- Month 1 - Initial internal team documents developed;
- Months 2 & 3 - Base Document development and vote. Approval of the Base Documents by the Technical Board;
- Months 4 & 5 - Document improvement. Open issues are identified and solutions developed. Companies are encouraged to develop code against the base documents. Further document improvement and feedback from organizations involved in implementations;
- Month 6 - Completion of the Public Draft Specification and approval by the 1EdTech Technical Board;
- Months 7 & 8 - Accept feedback from organizations working to the Public Draft Specification. Resolve any issues raised;
- Month 9 - Completion of the Final Specification and approval by the 1EdTech Technical Board. This is the combination of the Public Draft Specification plus resolutions due to experience gained in working with it.
The term 'Base Document' is used for draft specifications that have reached a relatively high level of stability based on input from the team and the Technical Board. Base Documents represent the stage in the specification process of final development and refinement. It is Base Documents that are presented in their final forms to the 1EdTech Technical Board for vote. If approved, the document becomes a 'Public Draft Specification' and is listed as such on the 1EdTech Public Website. If not approved, the team works through whatever adjustments and recommendations the Technical Board provides, and then resubmits the document. After three months the Public Draft Specification should be adopted as a 'Final Specification'.
After a Final Specification is released, the team develops the scope document for any subsequent work. New requirements and features dropped from the previous specification often constitute the scope of the next effort.
3. Conceptual Overview
The 1EdTech LIP 1.0 Specification allows information about learners to be captured for the purposes of recording and managing learning-related history, goals, and accomplishments; engaging a learner in a learning experience. The specification supports the exchange of learner information among learning management systems, human resource systems, student information systems, enterprise learning systems, knowledge management systems, resume repositories, and other systems used in the learning process.
When the 1EdTech LIP v1.0 Specification was published in March 2001, a placeholder was left for capturing information about users with disabilities. The ACCLIP model fills out this placeholder and provides the structure for information regarding the needs and preferences of learners with disabilities as well as the alternative preferences of other learners. It does not describe disabilities but rather preferences for the display, control, or selection of learning content.
The ACCLIP model provides a significant means of supporting learners with disabilities and non-disabled learners with alternative content or interface preferences. The Information Model expresses accessibility needs and will enable learning systems to locate and present learning material with support for those needs. The ACCLIP Information Model also defines ways that users interface with a learning system, including by keyboard only, by mouse only, or through assistive technology such as an on-screen keyboard. The Information Model allows users to specify the kinds of materials appropriate to their needs, such as captions or audio description for streaming media. These modifications to the 1EdTech specification avoid many problems for users with disabilities, permitting learning systems to adapt their display, control, and content selection features to match the user's needs and preferences.
This document also defines an <accommodation> element that allows one to specify accommodations for which a learner is eligible when using a particular learning object, such as a test.
In designing the <accessForAll> element and sub-elements it is assumed that content to be presented to the learner is compliant with basic accessibility specifications delineated in the World Wide Web Consortium Web Accessibility Guidelines (W3C WCAG). Compliance with W3C WCAG priority 1 and 2 would insure that the presentation and control of text is transformable. This would negate the need to provide multiple static presentations of textual material to accommodate the varying needs of learners.
3.1 Accessibility Preferences
There are three groups of accessibility choices for learners defined within <accessForAll>:
- display (how the user interface and content should be presented)
- control (alternative ways of controlling a device)
- content (specification of auxiliary, alternative or equivalent content requirements).
Having the ability to modify the display, control, and content is relevant not only for people with disabilities, but also for people with other types of access challenges, such as low-bandwidth users or those using mobile devices.
3.1.1 Accessibility Preferences for People with Disabilities
The accessibility preferences provided by the accessForAll model will serve people with many types of disabilities, including disabilities such as:
- Visual (e.g., blind, low-vision or colorblindness)
- Hearing (e.g., Deaf or hard-or-hearing)
- Physical
- Cognitive (e.g., learning disabilities)
3.1.2 Accessibility Preferences for People with Other Types of Access Challenges
The accessibility preferences provided by the accessForAll model will serve people with many types of access challenges. These types are varied, but may include:
- low bandwidth
- older/slower hardware
- lack of hardware (i.e., no speakers)
- users of PDAs or other mobile devices (phone, handheld computer)
- people in noisy environments (such as a train station) or quiet environments (such as a library)
- multi-tasking (listening to a conference call & reading the transcript of a video containing relevant information instead of watching the video)
3.1.3 Accommodation Eligibility
Under the <eligibility> element this document defines an <accommodation> element that allows one to specify accommodations for which a learner is eligible when using a particular learning object, such as a test. The accommodation.eligibility element is likely to be particularly important in certain high stake testing situations, where considerable rigor is necessary to ensure that accommodations do not prevent the test from measuring what it is intended to measure. For example, to allow a student to use a spell checker as an accommodation during a spelling test would likely prevent the test from fulfilling its intended purpose. The <accommodation> element provides an interoperable means for educational institutions to record authorized accommodations.
3.1.3.1 Accommodation Use Case
Pat is a blind 17-year old who has relied on four accommodations during the last year:
- private room,
- having content read aloud via synthesized speech,
- refreshable Braille display, and
- extra testing time (1.25 times the regular time).
Pat's teacher submits a request for all four accommodations for the upcoming reading test, accompanied by reference to supporting documentation. A description of the request is recorded as part of the <requestForAccommodations> sub-element of the accommodation.eligibility element. This information is typed into the system. For example, for "request for accommodations," the teacher types the following.
The request for Pat for the XYZ Reading Test (3rd Edition) is: private room; having content read aloud via Brand Y screen reader; refreshable Braille display; and extra testing time (1.25 times the regular time). See case #2312 for supporting documentation.
The text entered into this <requestForAccommodations> attribute might consist of one or more of (a) a reference or pointer to the request and its supporting documentation (e.g., a case number) or (b) a description of the request, with or without supporting documentation. In this instance, the text consists of a short description of the request, plus a case number that points to the full documentation. Note that in this example, the inclusion of a "case number" might facilitate access to documentation supporting the request. Specifications for such documentation is beyond the current scope of the 1EdTech specifications.
The accommodation needs assessor determines that the requests for a private room, refreshable Braille display, and extra time are approved and but that having the test content read aloud by a speech synthesizer is not allowed. (Note that in many instances, the accommodations needs assessor may be a representative of a group charged with making such determinations.) One factor in this decision is that the test is intended to measure decoding (the ability to form words from characters) and allowing a speech synthesizer to read aloud the test would have exempted Pat from demonstrating that skill. The use of the speech synthesizer might have been appropriate for another reading test or perhaps even for the same test for a different purpose.
The accommodation needs assessor writes a description of the authorized package of accommodations:
Pat may take the reading test in a private room using a refreshable Braille display and extra testing time (1.25 times the regular amount of time). He may not use text-to-speech technology (such as a screen reader) to have test content read to him, though he may use it (with the volume off) if it is necessary to drive the refreshable Braille display.
Note that in describing the package of accommodations, the accommodation needs assessor acknowledges that use of a refreshable Braille display might involve using a screen reader, but that if that occurs, the volume must be turned off. Finally, the accommodation needs assessor enters the date of the authorization and the date of expiration for the authorization.
3.2 Intended Uses
Implementations of the ACCLIP Information Model may vary. It is expected that learning software will use the information model to improve functionality in the following way: a preference file will be created using information gathered from a learner, perhaps in the form of an online questionnaire or at registration time. Learners will be asked to specify their preferences regarding the user interface including the assistive technology they use, the format they require for different types of information, and any auxiliary or alternative content they need. The preference file can then be used to tailor the user interface and the retrieval and presentation of different types of content to suit the learner's needs. Once the preference file has been created it can be transferred to other compliant learning environments.
- A student working at a public workstation could set <systemSounds> to "desktop, required" in order to receive visual alternatives (desktop flashes) in place of audio system alert sounds.
- A student with a learning disability could set the <contentDensity> to "bigPicture", in order to avoid an overload of information from a content-rich lesson.
4. Examples
4.1 Basic Examples - Generic
The following examples illustrate how the various preference elements are expressed using an XML binding. They are individual examples of the preferences, which can be combined into larger collections under <display>, <control>, and <content>.
4.1.1 Examples of Display Preferences
4.1.1.1 Generic screenReader Preferences
When screen readers are used, text on the screen is read aloud using speech synthesis.
<screenReaderGeneric>
<link usage="required" value="speakLink"/>
<speechRate usage="preferred" value="180"/>
<pitch usage="optionallyUse" value="0.5"/>
<volume usage="required" value="0.5"/>
</screenReaderGeneric>
In this example, the screen reader would be required to read any links it encounters. The preferred speak rate is 180 words per minute. An optional pitch setting is set to the normal (default) value. This example requires a slightly higher than average volume setting.
4.1.1.2 Generic screenEnhance Preferences
Regular computer displays can be enhanced using the screenEnhance preferences.
<screenEnhanceGeneric>
<fontFace>
<fontName usage="preferred" value="String"/>
<genericFace usage="preferred" value="sansSerif"/>
</fontFace>
<fontSize usage="required" value="2"/>
<foregroundColor usage="required" value="ff000000"/>
<backgroundColor usage="required" value="ffffffff"/>
<highlightColor usage="required" value="ffff0000"/>
<invertedColorChoice usage="required" value="false"/>
<cursorSize usage="preferred" value="0.5"/>
<cursorColor usage="preferred" value="ffffffff"/>
<cursorTrails usage="required" value="0.5"/>
<tracking>
<mouse usage="required" value="true"/>
<caret usage="required" value="true"/>
<focus usage="required" value="true"/>
</tracking>
<magnification usage="preferred" value="1"/>
</screenEnhanceGeneric>
In this example, a serif font is preferred. The required font size is 18pt. On fine pitch displays, normal font sizes (10 or 12) are often unreadable. The learner has indicated that the foreground color should be black, and requires that the background color be white, which usually provides good contrast. A cursor size of 0.5 is preferred, which is the default cursor size. However, the learner requires that the cursor color be blue, perhaps making it easier to find it on the screen. When using a screen magnifier or similar function, the user indicates that mouse tracking, caret tracking, and focus tracking is required.
4.1.1.3 Generic screenTextReadingHighlight Preferences
Computers equipped with text to speech software have the capability of reading text aloud. These preferences control how the spoken text is presented to the learner.
<textReadingHighlightGeneric>
<speechRate usage="preferred" value="180"/>
<pitch usage="optionallyUse" value="0.5"/>
<volume usage="notUse" value="0.5"/>
<highlight usage="preferred" value="word"/>
<speakAltText usage="optionallyUse" value="true"/>
<speakWhenTabbing usage="optionallyUse" value="true"/>
<readingUnit usage="preferred" value="word"/>
</textReadingHighlightGeneric>
This user prefers a speech rate of 180 words per minute, which is a typical rate easily understood by most people. The pitch and volume are set to normal levels, though the user would rather not use the volume preference (perhaps setting it manually instead). As the text is spoken, each word is highlighted. The learner wants both speaking altText and speaking when tabbing to be optional.
4.1.1.4 Generic Braille Preferences
Some people who are blind prefer to use a Braille display. This display consists of a set of cells with dots that can be raised or lowered. Some displays allow text characteristics to be marked using extra dots in what is called uncontracted Braille.
<brailleGeneric>
<grade usage="required" value="1"/>
<numDots usage="preferred" value="8"/>
<numCells usage="preferred" value="80"/>
<markHighlight usage="optionallyUse" value="true"/>
<markBold usage=" optionallyUse " value="true"/>
<markUnderline usage=" optionallyUse " value="true"/>
<markItalic usage=" optionallyUse " value="true"/>
<markStrikeout usage=" optionallyUse " value="true"/>
<markColor usage=" optionallyUse " value="true"/>
<dotPressure usage="preferred" value="0.5"/>
<statusCell usage="preferred" value="left"/>
</brailleGeneric>
In this example, the learner requires uncontracted Braille. Each cell has 8 dots, and her display has 80 cells in a row. The learner prefers to know about text characteristics, so has optionally indicated the display of highlighting, bold, underline, italic, strikeout, and color. She has a preferred dot pressure of 0.5, which is an average pressure setting. Finally, she prefers to use a Braille Status Cell, which is an extra cell used for showing system status, etc.
4.1.1.5 Generic visualAlert Preferences
Under certain circumstances, regular auditory alerts (system beeps) cannot be heard by the learner (in a noisy environment or if the learner has a hearing loss, for example). The visualAlert preference allows the learner to specify a visual alert to be used instead of the audible alert.
<visualAlertGeneric>
<systemSounds usage="preferred" value="desktop"/>
<captions usage="required" value="true"/>
</visualAlertGeneric>
In this example, the learner prefers to have the desktop flashed to indicate an alert. There is also a requirement for captions to be displayed for the text of system audio messages. Note that this setting is not for captions for content-related audio and video, which are specified within the <content> element.
4.1.1.6 Generic structuralPresentation Preferences
The structural presentation preferences give the user control over some aspects of how content is presented. These are often used when screen space is very limited (such as a digital assistant), but may also be used by some learners with cognitive disabilities.
<structuralPresentation>
<contentDensity usage="preferred" value="collapsed"/>
<contentViews usage="notUse" value="imageIntensive"/>
<showLinks usage=" preferred " value="true"/>
<showTranscript usage=" preferred " value="false"/>
<showNotes usage=" preferred " value="flast"/>
<windowLayout usage=" preferred " value="frontMost"/>
</structuralPresentation>
When structured content is presented, this learner prefers to collapse any hierarchic views. Content views are not used. If there are links present, the user prefers to see them, but would rather not see a transcript or notes. If multiple windows are present, the windows should fill the screen and the current window should be the front most window.
4.1.1.7 Future Technology
Future technology is an element that allows new display preferences to be added to <accessForAll>.
<futureTechnology>
<application name="Optic Nerve Interface" priority="1">
<param name="sensitivity" value="0.5"/>
</application>
</futureTechnology>
In this example, a hypothetical Optic Nerve display has a parameter named "Sensitivity", whose value is 0.5, a nominal setting.
4.1.1.8 Repository Searches
A repository search for a learner who requires captions might only offer search results where any included video or audio provides captions. (It is strongly advised that search tools offer a convenient way to expand the search results to ignore this requirement on user request. This would in effect change the preference for that search to "preferred.")
A repository search for a learner who prefers captions might give resources that have video or audio without captions lower rank in the search results than those with captions or those with no video or audio.
A repository search for a learner who optionally uses captions or does not use captions would be unaffected, assuming that the video presentation method allows captions to be turned off; when the resource is displayed, the learner for whom captions are optional would see them if available, while the learner who does not use them would never see them.
In this example, one user specifies three preferred caption types.
<?xml version="1.0"?>
<accessForAll
xmlns="http://www.imsglobal.org/xsd/acclip"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.imsglobal.org/xsd/acclip
AccessForAllv1p0d27.xsd">
<context identifier="x-LMS">
<content>
<alternativesToAuditory>
<captionType xml:lang="en" usage="required">
<reducedReadingLevel value="false"/>
<reducedSpeed value="false"/>
<enhancedCaption value="true"/>
</captionType>
<captionType xml:lang="fr" usage="preferred">
<reducedReadingLevel value="false"/>
<reducedSpeed value="true">
<captionRate value="25"/>
</reducedSpeed>
<enhancedCaption value="false"/>
</captionType>
<captionType xml:lang="de" usage="optionallyUse">
<reducedReadingLevel value="true"/>
<reducedSpeed value="true">
<captionRate value="20"/>
</reducedSpeed>
<enhancedCaption value="false"/>
</captionType>
</alternativesToAuditory>
</content>
</context>
</accessForAll>
4.1.2 Examples of Control Preferences
4.1.2.1 Generic keyboardEnhanced Preferences
The keyboardEnhanced preferences provide an additional degree of control over how keys function to allow a learner to enhance a hardware keyboard.
<keyboardEnhancedGeneric>
<layout>
<alphaLayoutExternal value="keyboard.xml"/>
</layout>
<stickyKeys usage="required" value="false">
<playSound usage="required" value="false"/>
</stickyKeys>
<repeatKeys usage="required" value="false">
<autoRepeatDelay usage="required" value="0.5"/>
<autoRepeatRate usage="required" value="0.5"/>
</repeatKeys>
<slowKeys usage="required" value="true">
<slowKeysInterval usage="required" value="0.2"/>
</slowKeys>
<debounce usage="required" value="true">
<debounceInterval usage="required" value="0.5"/>
</debounce>
</keyboardEnhancedGeneric>
The learner prefers to use an external keyboard layout in a file called keyboard.xml. He prefers not to use sticky keys, which leaves a shift or control key depressed until the next key is pressed. He prefers not have a key repeat if it is held down, so the automatic delay and rate of repeats is a normal default value. He prefers to use a slow keys rate of 0.2, which is also typical for that function. This user may have shaky hands causing him to strike a key multiple times unintentionally. As such, he requires de-bouncing the keys and prefers a de-bouncing interval of 0.5, which is an average rate.
4.1.2.2 Generic onScreenKeyboard Preferences
In some cases, physical manipulation of a regular computer keyboard can be difficult or may not be possible. In such cases, an on-screen keyboard may be presented to the learner to allow him or her to enter characters by selecting them from the on-screen keyboard using a pointing device or switches.
<onscreenKeyboardGeneric>
<layout>
<alphaLayoutExternal value="onscreen.xml"/>
</layout>
<keyHeight usage="preferred" value="0.12"/>
<keyWidth usage="preferred" value="0.12"/>
<keySpacing usage="preferred" value="0.12"/>
<sound usage="preferred" value="true"/>
</onscreenKeyboardGeneric>
This learner prefers to use an external keyboard layout when an on-screen keyboard is needed. Key width, height, and spacing have common values. Use of sound feedback is preferred.
4.1.2.3 Generic alternativeKeyboard Preferences
Sometimes, specially designed alternative keyboards are created for particular applications. A telephone keypad is one example. Another is a dynamically defined membrane switch keyboard.
<alternativeKeyboardGeneric>
<layout>
<alphaLayoutExternal usage="preferred" value="layout.xml"/>
</layout>
<stickyKeys usage=" preferred " value="true">
<playSound usage=" preferred " value="false"/>
</stickyKeys>
<repeatKeys usage="required" value="false">
<autoRepeatDelay usage=" preferred " value="0.5"/>
<autoRepeatRate usage=" preferred " value="0.5"/>
</repeatKeys>
<slowKeys usage=" preferred " value="true">
<slowKeysInterval usage="required" value="0.2"/>
</slowKeys>
<debounce usage=" preferred " value="false">
<debounceInterval usage=" preferred " value="0.5"/>
</debounce>
<resizableKeys value="true">
<keyHeight usage=" preferred " value="10"/>
<keyWidth usage=" preferred " value="10"/>
<keySpacing usage=" preferred " value="0"/>
</resizableKeys>
</alternativeKeyboardGeneric>
This particular learner is using a keyboard layout defined by an external file called "layout.xml." The file name reference is abbreviated here. Normally, it would be a full URL. Repeat keys is turned off. Auto delay and auto rate have normal values, as does slow keys. De-bouncing is turned on and has a typical de-bounce interval. The keyboard has re-sizable keys and the height, width, and spacing are set to nominal values.
4.1.2.4 Generic mouseEmulation Preferences
When a user cannot control a mouse or alternative pointing device, he may wish to emulate the function of the mouse using another strategy that allows him to move the mouse pointer to a desired location. These strategies can include a set of directional keys, a voice command system, or a switch with a scanning program.
<mouseEmulationGeneric>
<speed usage="preferred" value="0.5"/>
<acceleration usage="preferred" value="0.5"/>
<device usage="preferred" value="keypad"/>
</mouseEmulationGeneric>
In this case, a keypad is being used to emulate a computer mouse. Both speed and acceleration are set to typical values.
4.1.2.5 Generic alternativePointing Preferences
A mouse is not the only device used for pointing. These controls define preferences for alternative pointing devices, which might include a trackball, joystick, stylus and tablet, etc.
<alternativePointingGeneric>
<handedness usage="preferred" value="right"/>
<doubleClickSpeed usage="preferred" value="0.4"/>
<buttonAssignmentExternal usage="preferred" value="http://www.altova.com"/>
</alternativePointingGeneric>
This user prefers a relative pointing style (as opposed to absolute). Speed and acceleration are set to average values. This user prefers to use it left-handed and uses a moderate double click speed. Button assignments (if present) are defined in an external file called "buttons.xml."
4.1.2.6 Generic voiceRecognition Preferences
Suitably equipped computers or systems are capable of recognizing spoken speech. These elements provide preferences for voice recognition.
<voiceRecognition>
<voiceRecognitionGeneric>
<microphoneGain usage="preferred" value="0.5"/>
<controlsWindow usage="preferred" value="true"/>
<dictation>
<voiceProfileExternal usage="preferred" value="profile.xml"/>
</dictation>
<commandControl>
<vocabulary usage="preferred" value="natural"/>
<feedback usage="preferred" value="true"/>
<mouse usage="preferred" value="false"/>
</commandControl>
</voiceRecognitionGeneric>
The microphone gain controls how sensitive the microphone is to speech. In this case, the gain is set to an average value. This learner prefers a control window to be visible on the screen. Voice recognition is better when trained to a particular learner. This training is saved in a dictation profile, which in this case is saved in an external file called, "profile.xml." When speaking commands, the learner prefers to use a natural vocabulary, and get feedback from the system. The learner prefers not to use speech commands to control a pointer.
4.1.2.7 structuralNavigation Preference
These preferences can be provided to a learner when learning content is organized in a hierarchical fashion.
<structuralNavigation>
<navigationDepth usage="preferred" value="depthFirst"/>
<useTableOfContents usage="preferred" value="true"/>
</structuralNavigation>
The learner has expressed a preference to navigate through content in a depth-first order, and to use a table of contents.
4.1.2.8 codedInput Preferences
Coded inputs are used when response to a computer request is limited to special devices or ones with restricted input capabilities for use by people with limited motor.
<codedInput>
<code usage="preferred" value="quartering"/>
<codeSwitchNumber usage="preferred" value="2"/>
<codeTermination value="timed">
<codeRate usage="preferred" value="3.0"/>
</codeTermination>
<codeSelect usage="preferred" value="pointAndClick"/>
<switchType usage="preferred" value="mouse"/>
<codeExternal usage="preferred" value="input.xml"/>
</codedInput>
In this case, the learner is used a 'quartering' approach to coding inputs. Other methods are also available, such as Morse code. Two switches are used as the input, with timed entry, limited to three seconds. In this case, the method is represented externally in a file called "input.xml", and a point and click approach is defined.
4.1.2.9 Future Technology Preferences
Future technology is an element that allows new control preferences to be added to <accessForAll>.
<futureTechnology>
<application name="Alpha Wave Pointing" version="1.0" priority="1">
<param usage="preferred" name="sensitivity" value="0.5"/>
</application>
</futureTechnology>
In this case, a hypothetical "alpha wave pointing" device is referenced. It has a use priority of 1 and includes a single parameter called sensitivity, which has a value of 0.5.
4.1.3 Examples of Content Preferences
4.1.3.1 alternativesToVisual Preferences
Often content is made available in several different forms to provide the learner with choices. Alternatives to Visual provides preferences for non-visual presentation of learning content that is originally presented visually.
<alternativesToVisual>
<audioDescription usage="required" lang="en" type="expanded"/>
<altTextLang usage="required" lang="en-us"/>
<longDescriptionLang usage="required" lang="en-us"/>
<colorAvoidance>
<avoidBlueYellow usage="required" value="false"/>
<avoidGreenYellow usage="required" value="false"/>
<avoidOrange usage="required" value="false"/>
<avoidPurpleGray usage="required" value="false"/>
<avoidRed usage="required" value="false"/>
<avoidRedBlack usage="required" value="false"/>
<avoidRedGreen usage="required" value="true"/>
<useMaximumContrastMonochrome usage="required" value="false"/>
</colorAvoidance>
</alternativesToVisual>
This learner prefers to use an English audio description with expanded information, if available. Red / Green color combinations are to be avoided.
4.1.3.2 alternativesToText Preferences
In certain cases, the learner may prefer alternatives to text which are not auditory in nature.
<alternativesToText>
<graphicAlternative usage="required" value=true/>
<signLanguage usage="prefers" value="American-ASL"/>
</alternativesToText>
Here, the learner has required than any graphic alternatives available be displayed, and he prefers American Sign Language.
4.1.3.3 alternativesToAudio Preferences
Alternatives to Audio are useful when the learner cannot hear audio material. This might be due to a hearing impairment, or the computer system may not be equipped to reproduce sound. It may also be that the person needs to be quiet, for example on an airplane.
<alternativesToAuditory>
<captionType lang="en">
<reducedSpeed usage="required" value="false">
<captionRate usage="required" value="120"/>
</reducedSpeed>
<enhancedCaption usage="required" value="false"/>
</captionType>
<signLanguage usage="required" value="American-ASL"/>
</alternativesToAuditory>
In this case, the learner requires verbatim captioning in English. They can also benefit from Russian Sign Language, if it is available. They would like to see a text equivalent of any system audio.
4.1.3.4 learnerScaffold Preferences
Scaffolding refers to learner support tools such as a calculator, dictionary, note taking application, etc. While these are taken for granted by most of us, in some cases they are essential for learning. These elements allow a learner to specify preferences identifying which scaffolding types should be available during a learning session.
<learnerScaffold>
<scaffoldType usage="required" value="dictionary"/>
</learnerScaffold>
For this particular learner, dictionary is required. No other scaffolding applications are needed.
4.1.3.5 personalStylesheet Preferences
Style sheets give a user a lot of personal control over how content is presented. Using a personal style sheet, preferences for font sizes, colors, even layout can be defined and controlled.
<personalStylesheet usage="preferred" value="sheet.css"/>
The style sheet is referenced by a URL abbreviated to "sheet.css", in this case.
4.1.3.6 futureTechnology
The <futureTechnology> provides a means for adding new kinds of controls for working with content. The particular parameter names and value would be specific to the new content type.
<futureTechnology>
<param usage="preferred" name="New-Content-Param-1" value="0.5"/>
<param usage="preferred" name="New-Content-Param-2" value="true"/>
</newContentControl>
4.2 Basic Examples - Application Specific
In addition to the generic preferences above, the following examples illustrate how parameters associated with applications are saved as preferences.
4.2.1 Screen Reader - HomePageReader
<screenReader>
<application name="HomePageReader">
<!-- Fast forward control speed, [1,18] -->
<param name="fastForward" value="8"/>
<!-- Feedback for typing characters into text fields -->
<param name="echoTypedWords" value="true"/>
<param name="echoTypedCharacters" value="false"/>
<!-- Use HTML as the document model -->
<param name="convertPDF2HTML" value="true"/>
<!-- Presentation of tables -- speak headers -->
<param name="speakColumnHeaders" value="true"/>
<param name="speakRowHeaders" value="true"/>
<!-- History: how long to remember visited pages -->
<param name="historyMemory" value="28"/>
</application>
</screenReader>
4.2.2 On Screen Keyboard - VDK
Here is an example of the VDK keyboard parameters.
<onscreenKeyboard>
<application name="VDK">
<!-- Use word prediction -->
<param name="wordPredictor" value="true"/>
<!-- Number of words in prediction set [1,10]. -->
<param name="numPredictions" value="7"/>
<!-- Add new (unknown) words to prediction dictionary. -->
<param name="addWords" value="true"/>
<!-- Allow editing of the dictionary -->
<param name="editDict" value="true"/>
</application>
</onscreenKeyboard>
4.2.3 Text Reader - CAST eReader
This is an example of the CAST reader parameters.
<textReadingHighlight>
...
<application name="eReader">
<param name="speakMenus" value="true"/>
<param name="speakToolTips" value="true"/>
<!-- Talking while typing is one of {letter, letterOrWord, word, chunk, sentence, none } -->
<param name="typeAndTalk" value="letterOrWord"/>
<!-- Screen real estate is either split 50/50, or 66/33 -->
<param name="docLayout" value="fiftyFifty"/>
<!-- What to show on launch: {blankWindow, starterFile, launcherWindow} -->
<param name="onLaunch" value="launcherWindow"/>
</application>
</textReadingHighlight>
4.2.4 Screen Reader - JAWS
This is an example of the JAWS screen reader application parameters.
<screenReader>
...
<application name="JAWS">
<!-- Experienced users generally want less speech output; novices more: {novice, intermediate, experienced} -->
<param name="verbosity" value="experienced"/>
<!-- How numbers are spoken: {synthesizerDecides, singleDigits, pairs, fullNumbers}-->
<param name="numbers" value="fullNumbers"/>
<!-- Speak various text formatting info -->
<param name="speakFontName" value="true"/>
<param name="speakFontSize" value="true"/>
<param name="speakTextColour" value="true"/>
<param name="speakBackgroundColour" value="false"/>
<param name="speakCapitalization" value="true"/>
<param name="speakIndentation" value="true"/>
</application>
</screenReader>
4.3 Basic Examples - Accommodation Eligibility
The follow example of eligibility corresponds to the Legally Blind Use Case.
<accomodationPackage authorizedDate="2001-12-17T09:30:47-05:00" expirationDate="2001-12-17T09:30:47-05:00">
<learningObjectDescription>
XYZ Reading Test (3rd Edition)
</learningObjectDescription>
<requestForAccomodations>
The request for Pat for the XYZ Reading Test (3rd Edition) is: private
room; having content read aloud via Brand Y screen reader; refreshable
Braille display; and extra testing time (1.25 times the regular time).
See case #2312 for supporting documentation.
</requestForAccomodations>
<accomodationDescription>
Pat may take the reading test in a private room using a refreshable Braille display and extra testing time (1.25 times the regular amount of time). He may not use text-to-speech technology (such as a screen reader) to have test content read to him, though he may use it (with the volume off) if it is necessary to drive the refreshable Braille display.
</accomodationDescription>
<authorizedBy>J. Higgins</authorizedBy>
</accomodationPackage>
4.4 Advanced Examples
4.4.1 Multiple Contexts
A student at the Universitè de Montrèal has a hearing impairment. When at home, she increases the volume on her computer speakers, and enhances any audio content with a text caption. On campus, however, some public workstations are not equipped with speakers, and in other cases, she does not wish to disrupt other students. In these cases, the student prefers to enhance audio content with a sign language interpretation, and engage visual alerts. The following example illustrates how these requirements might be encoded in a single <accessForAll> branch using different <context>s.
<accessForAll>
<context identifier="Ecole" language="fr">
<display>
<visualAlert>
<visualAlertGeneric>
<systemSounds value="desktop"/>
<captions value="false"/>
</visualAlertGeneric>
</visualAlert>
</display>
<content>
<alternativesToAuditory>
<visual>
<signLanguage value="Quebec-LSQ"/>
</visual>
</alternativesToAuditory>
</content>
</context>
<context identifier="Maison" language="fr">
<content>
<alternativesToAuditory>
<visual>
<enhancedCaption type="enhancedDescription" xml:lang="fr"/>
</visual>
</alternativesToAuditory>
</content>
</context>
</accessForAll>
4.4.2 Morning vs. Night Example
Outline of difficulty:
Jannika is a twenty-four-year-old and with multiple sclerosis (MS) and experiences has fluctuating energy levels. She is a non-native English-speaker with an accomplished level of English. She is dyslexic and experiences also suffers from some lack of strength and motor control in her hands, which prevents her from using a mouse, meaning that she cannot use a mouse. Her handwriting is very poor, due to the effects of both her dyslexia and MS. She has a poor auditory memory and poor phonological awareness. She therefore requires additional time to read and absorb written information and to listen/view auditory or video clips more than once. She has difficulty organizing her work and with structuring her essays and assignments. She is able to use a keyboard for short periods at certain times of day. Her dyslexia causes her some difficulty tracking when reading. She is doing a chemistry degree part-time and is currently in her fifth and final honors year.
Jannika registered her needs with the university at the time of registration. She has set-up a preference profile that provides her with differing provisions and software settings depending on the variation in her condition. This means that her learning material and other aspects of her course are delivered in a manner suited to her fluctuating condition.
Jannika has one profile for the mornings when her symptoms are less pronounced and another profile called her evening profile as she tends to suffer from fatigue and increased involuntary hand tremors in the evenings. It should be stated, that although the pattern (more energy in the mornings and less in the evenings) is a general model, it does not always hold. Jannika does not always feel less fatigued and tremor less in the mornings and she may sometimes feel more energetic and tremor less in the evenings. She therefore wishes to be able to choose which profile she uses each time she logs onto to the university system, and to make some adjustments to each profile if her needs are slightly different from day to day. In general two main profiles are sufficient for Jannika's needs - morning and evening. This means that she may want to invoke her morning profile in the evening and vice versa - or indeed to invoke it at any time of day. On the whole, though there is a general morning and evening pattern. In addition there may be some aspects of one profile that she may wish to include into the other profile (see BounceKeys below for example).
Reading:
For reading support (tracking and spell checking) Jannika uses TextHelp Gold. For large reading assignments, she uses the scanning facility of TextHelp Gold, scanning in the text and listening to the passages with text highlighting.
General requirements for all profile situations:
Jannika prefers closed captions for video/audio clips that assist with both her understanding of technical chemical vocabulary used in video and audio clips that form part of her course (by allowing her to see the correct spelling of technical words) and also with her general understanding of spoken technical English. In addition this provides the information in more than one modality (audio/video/textual).
<alternativesToAuditory>
<verbatim/>
<captionType lang="en">
<reducedSpeed usage="required" value="false">
<captionRate usage="required" value="120"/>
</reducedSpeed>
<enhancedCaption usage="required" value="false"/>
</captionType>
</alternativesToAuditory>
Morning profile:
When not fatigued (morning profile) Jannika uses TextHelp Gold to type. This supports her spelling and tracking. She uses BounceKeys and slow keys to control the effects of her hand tremors on her key presses which in turn reduces the degree of correction she must do.
Jannika uses "Inspiration" mind-mapping software to help her structure her essays and other written assignments. These diagrams are then exported in text format into TextHelp where she then uses the spellchecker and text-to-speech to check the English and proof-read the sense and structure of her documents.
In general the Jannika has more energy in the mornings and is able to read online in a sustained way for period of up to about 35 minutes.
<context identifier="morning" lang="us-en">
<control>
<keyboardEnhancedGeneric>
<slowKeys usage="required" value="true">
<slowKeysInterval usage="required" value="0.1"/>
</slowKeys>
<debounce usage="required" value="true">
<debounceInterval usage="required" value="0.5"/>
</debounce>
</keyboardEnhancedGeneric>
</control>
</context>
Evening profile:
In general her energy is lower in the evenings and she is able only to read online and to carry our her course activities for periods of up to 15 minutes at a time, requiring at least an hour's recovery prior to her next learning session.
When fatigued (evening profile) She uses speech to text software to dictate her course assignments and e-mails. She uses Dragon Dictate voice recognition software for this. To read back and check her work she copies the Dragonfiles into TextHelp where she can both read with text highlighting and listen to her written work, assisting the identification of errors and adjustment for sense. When fatigued she requires the provision of additional modalities (auditory and visual enhancement via text highlighting) to help her concentrate on the content and structure of her work.
Since she experiences increased involuntary hand movement when fatigued, she requires BounceKeys so that her system does not register each involuntary key press but waits for a certain period of time before registering a key press. The time interval before a second key press on the same key is called the de-bounce time. She requires a longer de-bounce time in the evenings when her hand tremor is worse.
Since her hand tremor is, however, not constant she would like to have the opportunity to change the de-bounce time. When she feels able to type well, a long de-bounce time is frustrating for her as she has to wait for too long before she can type the same key twice. In these cases she edits her settings to decrease the de-bounce time but doesn't save the change in her profile.
<context identifier="evening" lang="us-en">
<display>
<textReadingHighlight>
<textReadingHighlightGeneric>
<speechRate usage="required" value="120"/>
<highlight usage="required" value="word"/>
<speakAltText usage="optionallyUse" value="true"/>
<readingUnit usage="preferred" value="word"/>
</textReadingHighlightGeneric>
</textReadingHighlight>
</display>
<control>
<keyboardEnhancedGeneric>
<slowKeys usage="required" value="true">
<slowKeysInterval usage="required" value="0.1"/>
</slowKeys>
<debounce usage="required" value="true">
<debounceInterval usage="required" value="0.2"/>
</debounce>
</keyboardEnhancedGeneric>
</control>
</context>
SlowKeys and BounceKeys:
Jannika's hand motor control varies throughout the day, with her experiencing on the whole, significantly more hand tremors in the evening than in the mornings. (See example above.)
Evening BounceKeys:
Jannika requires this feature because her hand tremors more pronounced in the evenings, meaning that she has difficulty with single key presses. BounceKeys prevents her making multiple unintentional key presses.
Since SlowKeys and BounceKeys cannot both be active at the same time, she must be able to select this as part of her daily profile. In the evenings Jannika therefore needs both Slow Keys and BounceKeys and in the morning she needs only Bounce Keys.
SlowKeys require the user to hold down the key for a minimum amount of time before it registers. She requires the use of slow keys as well, all the time - as her hand motion is unpredictable and she often hits the wrong key by accident. (See example above.)
Since MS is a progressive illness, it is likely that she will require to use her evening profile more and more often and may need to have the ability to change her evening profile to include more support for her changing condition.
4.5 Special Examples
4.5.1 Externally Define Contexts and Shared Profiles
The U.S. Department of Labor use case describes a scenario in which several learners are acting as a team in two different environments: a classroom and a mineshaft. The following XML document defines two profiles in their own contexts. The first is a group profile for working in a noisy, underground environment. The second is a more typical classroom environment. This document is called "mineProfile.xml".
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 U (http://www.xmlspy.com) by Mark J. Norton (1EdTech Consortium) -->
<!--Sample XML file generated by XMLSPY v5 U (http://www.xmlspy.com)-->
<accessForAll xmlns="http://www.imsglobal.org/xsd/acclip" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.imsglobal.org/xsd/acclip
C:\DOCUME~1\MARKNO~1\MYDOCU~1\1EdTech\_WORKI~1\Accessibility\ACCLIP\Binding\AccessForAllv1p0d14.xsd">
<context identifier="mineshaft" language="en">
<display>
<screenEnhance>
<screenEnhanceGeneric>
<fontFace>
<fontName usage="required" value="Ariel"/>
<genericFace usage="required" value="sansSerif"/>
</fontFace>
<fontSize usage="required" value="1"/>
<foregroundColor usage="required" value="yellow"/>
<backgroundColor usage="required" value="black"/>
<cursorSize usage="required" value="0.5"/>
<cursorColor usage="required" value="white"/>
</screenEnhanceGeneric>
</screenEnhance>
<visualAlert>
<visualAlertGeneric>
<systemSounds usage="required" value="desktop"/>
<captions usage="required" value="false"/>
</visualAlertGeneric>
</visualAlert>
<structuralPresentation>
<windowLayout usage="required" value="tiled"/>
</structuralPresentation>
</display>
<content>
<alternativesToAuditory>
<visual>
<enhancedCaption usage="required" type="speedReduced"/>
</visual>
<audioText>
<verbatimCaptionLang usage="required" xml:lang="en-us"/>
</audioText>
</alternativesToAuditory>
<learnerScaffold>
<scaffoldType usage="required" value="noteTaking"/>
</learnerScaffold>
</content>
</context>
<context identifier="classroom" language="en">
<display>
<screenEnhance>
<screenEnhanceGeneric>
<fontFace>
<fontName value="Ariel" usage="required"/>
<genericFace usage="required" value="sansSerif"/>
</fontFace>
<fontSize usage="required" value="3"/>
<foregroundColor usage="required" value="black"/>
<backgroundColor usage="required" value="white"/>
<cursorSize usage="required" value="0.5"/>
<cursorColor usage="required" value="gray"/>
</screenEnhanceGeneric>
</screenEnhance>
<visualAlert>
<visualAlertGeneric>
<systemSounds usage="required" value="none"/>
<captions usage="required" value="false"/>
</visualAlertGeneric>
</visualAlert>
<structuralPresentation>
<windowLayout usage="required" value="frontMost"/>
</structuralPresentation>
</display>
<content>
<learnerScaffold>
<scaffoldType usage="required" value="noteTaking"/>
</learnerScaffold>
</content>
</context>
</accessForAll>
To use a shared profile set, the 'external' attribute of the <context> element is used. Here is a simple example of a typical student who wants to inherit preferences from the mine profile:
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 U (http://www.xmlspy.com) by Mark J. Norton (1EdTech Consortium) -->
<!--Sample XML file generated by XMLSPY v5 U (http://www.xmlspy.com)-->
<accessForAll xmlns="http://www.imsglobal.org/xsd/acclip" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.imsglobal.org/xsd/acclip
C:\DOCUME~1\MARKNO~1\MYDOCU~1\1EdTech\_WORKI~1\Accessibility\ACCLIP\Binding\AccessForAllv1p0d14.xsd">
<context identifier="mineshaft" external="mineProfile.xml" >
</context>
</accessForAll>
In this particular case, the learner has no preferences that override the mine profile. Take note of the fact that the context identifier here matches the context name in the mine profile. This allows several profiles to be saved in a single shared file.
In the use case, one of the students is red/green colorblind. As such she has special accessibility requirements over and above the ones defined by the mine profile. Overriding and additional preferences can be described by including them in the <display>, <control>, and <content> elements of the external content reference. Here is an example that adds a preference for information to be presented without color dependencies:
<alternativesToVisual>
<colorAvoidance>
<avoidRedGreen usage="required" value="true"/>
</colorAvoidance>
</alternativesToVisual>
5. Run-Time Implementation
Overall run-time implementation guidelines are followed by specific examples of early prototypes including Web-4-All and BarrierFree.
5.1 Recommended Implementation Guidelines
Implementation of the ACCLIP specification requires that several basic functions be performed. These functions can be accomplished in a large number of ways. The basic functions are:
- The specification of preferences for a given learner, or in other words the creation of an <accessForAll> instance for the learner. A learner may have several different contexts within an <accessForAll> instance. This basic function would include the ability to edit or modify the <accessForAll> instance.
- The specification of information about assessment accommodations using the <accommodation> element.
- Communication of the <accessForAll> and <accommodation> instances, which may include storage, retrieval, and identification or authentication functions.
- Response to the preferences specified in the <accessForAll> instance. This includes modification of the display, modification of the method of control and selective content retrieval, for the learner. Note that machine response to the information in the <accommodation> element is not assumed.
5.1.1 Specification of Preferences
<accessForAll> instances can be created in a variety of ways. The most likely means is through a wizard or interactive form that presents a number of questions to the learner and, given responses to the questions, generates the <accessForAll> instance. This application may be integrated into an LMS or offered as a stand-alone application.
5.1.2 Communication of the <accessForAll> Instance
The <accessForAll> instance once created may be stored and communicated using a variety of storage media and communication protocols. A smart card is an example of a mobile device carried by the learner. This method would require a smart card reader or appropriate wireless receiver at the workstation but would reduce the privacy and security concerns associated with other methods of storage and communication because the smart card could carry only the <accessForAll> instance and not the learner's name or other identifying information. An alternative is through a repository that can be accessed using a secure protocol over the Web. Another alternative is in a local repository associated with a LMS. Whether or not information identifying the owner of the <accessForAll> instance is stored with the instance must be determined according to the privacy policies of the implementing agency. Identification and authentication associated with retrieval would also be determined by these privacy policies.
5.1.3 Response to the Specified Preferences
Response to the preferences must happen in 4 classes of technology:
- Operating system (OS) tools governing display and control options,
- Application software preference systems governing display and control options,
- Assistive technology available on the workstation or available as an online service, and
- Repository or LMS functions assigned to retrieve and present learning content to the learner.
5.1.3.1 Operating System Tools Governing Display and Control Options
At present all operating systems have a version of the Equal Access Tools originally developed by the Trace Center or an equivalent. The <accessForAll> element addresses these Equal Access options. A configuration program either associated with the Equal Access Tool or as a separate program must be implemented to adjust the options in the Equal Access Tool according to the specification in the <accessForAll> instance. An example of this program is the Configuration Manager associated with the Web4All program described below.
5.1.3.2 Application Software Preference System Governing Display and Control Options
While some application programs inherit the display and control settings from the OS it is more common that the application software determines how the user interface and content is displayed and controlled within the application itself. Again a configuration program either associated with the application or as a separate program must be implemented to make adjustments to the application preferences or options governing display and control. To implement accessForAll successfully it is assumed that the application program follows the software development guidelines associated with the platform or OS.
5.1.3.3 Assistive Technology (AT)
Implementation of accessForAll is dependent on response by assistive technologies to the accessForAll specification of the learner. The AT must respond to the generic settings and the AT developer must create and distribute a "special settings" extension to accessForAll for settings not covered by the generic specifications. These extensions governing special AT specific settings must be shared with the developers of the configuration programs and the programs that allow learners to specify their preferences. As with the other technology classes a program or function is required to read the accessForAll specification and adjust the preference settings of the AT. This may be integrated into the AT or implemented as a separate program.
5.1.3.4 Content Retrieval
Programs governing content retrieval and presentation to the learner must respond to the request to retrieve either alternative or auxiliary/additional content. The programs must determine what is required (from the <accessForAll> instance) and whether it is available and then determine how it will be displayed (available browsers/players and accessForAll preferences). To accomplish this the content must have appropriate meta-data that correlates to the ACCLIP Information Model.
5.2 Web-4-All
Web-4-All is a system, commissioned by the Web Accessibility Office of Industry Canada that combines hardware and software to quickly configure a public access computer to accommodate the special needs of a user and then reconfigures back to a standard setting for the next user. The user's technology preferences are stored on a smart card, which is a credit card sized object that contains a computer memory chip. Such a card is easily carried on a person; hence the user's preferences are easily transported from place to place.
The Web-4-All preferences are encoded on the smart card according to the ACCLIP specification. By using this standard, the data is recorded in a portable, non-proprietary format. While the cards are currently only used in Web-4-All systems, because a standard format was used, the information could be used by any other system that is compliant with the ACCLIP specification.
5.2.1 The Web-4-All Implementation
Libraries, schools, colleges, universities, government offices, and Internet cafes all provide access to computer workstations that are used by multiple users each with their own personal setup preferences. Depending on the technical support available, users presently make do with the workstation default or spend a great deal of time and effort adjusting the workstation to an approximation of their requirements. Many users with disabilities cannot use these workstations, even when they are "accessible" workstations, because the technology they need is not available or the technical support to set it up the way they need it is absent. In addition institutions offering and maintaining public workstations are often reluctant to include assistive technologies in the setup because the technologies conflict with one another or with other software and hardware on the system. Web-4-All is a system that allows users to carry their desktop preferences with them (including system preferences, browser preferences and assistive technology preferences) and automatically configure public terminals to suit their preferences and access requirements.
Web-4-All is a program developed by the Adaptive Technology Resource Centre for Industry Canada to address the need for accessible Community Access Point sites. Community Access Point sites are Internet workstations dispersed to remote and under-served areas of Canada to encourage citizens to utilize the Web. The CAP sites do not have sufficient resources to provide the technical support and assistive technology expertise needed to support users of alternative access systems. Web-4-All automatically configures public access terminals according to personal setup preferences (for the system, the browser and the assistive technology), as saved onto a smart card or other Open Card compliant device. The personal preferences are saved as an encrypted, compressed XML string and take up less than 2K. They are specified and saved onto the card using a personal preference wizard program. Once on the card, the user can take the card to any public access terminal with Web-4-All software, insert or swipe the card, and cause the system preferences, browser preferences and assistive technology preferences to be set exactly as they have specified. This is achieved through a software program called the Configuration Manager. When the card is removed the workstation reverts back to the default and all assistive technologies are shut down to avoid conflict with other applications.
5.2.2 The Web-4-All Preference Wizard
The Preference Wizard is a component of Web-4-All that is used to create a LIP instance for each individual user. Through a series of plain language questions the wizard guides the user through a series of choices. The responses to these choices are used to create the XML string that forms the LIP instance. The structure of the choices is based on the ACCLIP specification.
The following series of screen shots shows how a user would choose screen enhancement as a preference.
The first choice is the preferred language. As the Web-4-All systems support French and English, the choice is restricted to these two languages.
The second screen offers generic categories of preferences: assistance with "seeing the display", "identifying sounds", "using the keyboard", and/or "using the mouse". The user would choose "seeing the display" and would then be given the choice of "make text and the cursor easier to see," "highlight text and read it to me," "read the screen to me," and/or "let me use a Braille tablet."
Having chosen "make text and cursor easier to see," the user would then specify the point size and fontface preferences; the text color, background color and highlight color; preferences regarding cursor size and color; and, whether the magnifying window tracks the mouse, caret or focus.
The wizard shows the user a preview of his or her choices. In addition to the generic preferences the user is also able to specify a specific preferred technology, four prioritized alternatives and the custom preferences specific to those technologies.
5.3 BarrierFree
The BarrierFree Project, -a multi-partner project lead by Canadian Learning Television and the ATRC, University of Toronto, funded by CANARIE, -has explored the requirements and implications of learner-centric, online education delivery. The team has created and evaluated media-rich learning content that transforms in response to the specified individual needs of the learner. To achieve this the team developed the necessary tools including authoring tools, a player/browser, a preference wizard, and a dynamic learning object repository that implements the <accessForAll> element of the LIP.
Among the content types explored the team chose to target media-rich content such as video, as it presents the greatest challenge. Video content was digitized and tagged using available verbatim captions (a text transcription of the sound track) synchronized to the video through time code. Many existing videos are captioned. The 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 associated web material. Alternative captions for more basic reading levels were also created.
To accommodate learners who are blind and to provide additional commentary on the video, audio descriptions were created- spoken descriptions of the visual content that usually fit into the pauses in the soundtrack.
Thus a student viewing a video of a lecture given by an eminent physicist, for example, would be able to click on terms appearing in captions that they did not understand and view their. To clarify a concept that was discussed, to the student could link to an interactive exercise that illustrates the concept. If the student has difficulty following a demonstration given by the lecturer he or she can turn on audio descriptions that provides a sub-narrative in the audio pauses further describing what is happening. For additional help the student can turn on overlay captions that provide text labels of the objects and processes occurring in the demonstration.
If students feel they have missed necessary background material they could search for video segments on the topic and navigate to the segments for review. Each learning scaffold can be controlled by the learner either by using the Preference Wizard to create an <accessForAll> instance which is applied when the learner logs on, or by changing the preferences during the session. These session specific preferences can be saved to the preference default or used only during the session.
In a successor to the BarrierFree Project called The Inclusive Learning Exchange, the ATRC is investigating the implementation of the specification when using the full range of content media types.
5.4 Mapping Generic Preferences to Actual Applications
In general, the attributes of generic accessibility preferences have been chosen to correspond to widely available characteristics for such devices and technologies. In most cases, direct one-to-one correspondences can be drawn for preference values. For example, the <speechRate> element in <textReadingHighlightGeneric> can be directly mapped to the rate at which text is spoken by reading support system such as E-Reader.
Some situations will call for transformation of values into either more limited ones or specific values. For example, foreground color is given as an RGBa value that could be mapped to the nearest web safe color. Furthermore, many applications will not allow an alpha (transparency) value to be specified directly with the color. It may need to be broken out into a separate value, or discarded in some cases.
Finally, there will be cases where there is no specific setting to correspond to a preference value. In such cases, the preference can only be ignored.
In general, it is up to implementations and third-party applications to make the mapping from generic to specific settings.
6. Best Practice Recommendations
6.1 Context Identifiers
Each <context> element instance is required to have an "identifier" attribute. This identifier is a string with no implied system meaning. Thus, a 'night' identifier doesn't necessarily mean that it is automatically used at night; a learner might choose her night settings at other times of day if those settings best suit the task, ambient conditions, or personal energy level.
For purposes of initialization, the first context defined in a learner's accessibility preference set is considered the default context and should be used unless a specific context is identified.
6.2 Dynamic Preferences
Creating and setting accessibility preferences should not be considered a one-time thing. A means should be provided to allow learners to change their preferences on the fly and to save these changes either at the time of change or at the end of a session.
6.3 Privacy
Information about people should not, in general, be collected, stored, used, or published (even to a single additional person) without the user's explicit permission. Legal requirements demand that all applicable jurisdictions be considered. For example, if checking out reserved readings does not ordinarily require signing a list that shows who has read the material, it may be necessary to provide access to an electronic reading list without collecting the names of learners. However, it will still be necessary to access those learners' preferences in order to transform the materials appropriately. Care should be taken in the design of authentication systems so that a learner's identity can be confirmed differently for these two purposes.
The accessibility preferences have been designed to focus on the preferences rather than the disabilities that are the reasons for them but nevertheless, learners may consider the information in ACCLIP as sensitive or private. Best practice will ensure the privacy of this information. In many cases, there is little need even for high security of this information, as it will not benefit others. In cases when there is a need for strong authentication, this authentication is probably associated with other forms of authentication. An example is offered by the situation in which high-stakes assessment is taking place, and all participants are authenticated with a high-security system that can include the person claiming the preferences at the time. Information about user's preferences does not usually need to be associated with the identity of the person as long as it can be authenticated that the requester is the person with the preferences.
Best practices may also demand that information about an individual with a preference profile not be held in a storage system for longer than it is used, so that when a learner leaves a learning institution (or the learner requests that the data be purged), the data can be deleted from the system. This avoids unscrupulous use of data at a later date and does not rely on the integrity of either the system or those operating the system.
6.4 Stand-Alone Use
For privacy and security reasons, best practice use of the accessibility preferences will not have the preferences being stored with or associated with the identity of the user claiming those preferences. An independent wizard that allows for users to instantaneously vary preferences may be required.
Appendix A - List of Example Files
| Name | Description | Type |
| accessForAll.xml | A full set of preferences. | complete |
| accommodation.xml | A complete accommodation record. | complete |
About This Document
| Title | 1EdTech Learner Information Package Accessibility for LIP Best Practice and Implementation Guide |
| Editor | Mark Norton, Jutta Treviranus |
| Team Co-Lead | Jutta Treviranus |
| Version | 1.0 |
| Version Date | 18 June 2003 |
| Status | Final Specification |
| Summary | This document presents the 1EdTech Learner Information Package Accessibility for LIP Best Practice and Implementation Guide and describes the recommended best practices when adopting the ACCLIP specification. |
| Revision Information | 18 June 2003 |
| Purpose | Defines the 1EdTech Learner Information Package - Accessibility Preferences. |
| Document Location | http://www.imsglobal.org/accessibility/acclipv1p0/imsacclip_bestv1p0.html |
List of Contributors
The following individuals contributed to the development of this document:
Revision History
Index
A
assessment 1, 2, 3, 4
audio 1, 2, 3, 4, 5, 6, 7, 8
C
Content Package 1
E
Elements
accessForAll 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
accommodation 1, 2, 3, 4
content 1, 2, 3, 4
context 1, 2, 3
control 1, 2, 3
display 1, 2, 3
eligibility 1, 2, 3, 4
futureTechnology 1, 2, 3
Extension 1, 2
I
1EdTech Specifications
Accessibility for LIP 1, 2, 3, 4, 5, 6, 7
Content Packaging 1, 2
Learner Information Package 1, 2, 3, 4, 5, 6
Meta-Data 1
Question and Test Interoperability 1, 2
Reusable Definition of Competency or Education Objective 1
P
preferences 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19
S
SCORM 1
Sequencing 1, 2
style sheet 1
V
video 1, 2, 3, 4, 5
visual 1, 2, 3, 4, 5, 6, 7
X
XML 1, 2, 3, 4, 5, 6, 7
XSD 1
1EdTech Consortium, Inc. ("1EdTech") is publishing the information contained in this 1EdTech Learner Information Package Accessibility for LIP Best Practice and Implementation Guide ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
1EdTech 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.
1EdTech would appreciate receiving your comments and suggestions.
Please contact 1EdTech through our website at http://www.imsglobal.org
Please refer to Document Name: 1EdTech Learner Information Package Accessibility for LIP Best Practice and Implementation Guide Revision: 18 June 2003
