IMS Learner Information Package Accessibility for LIP Conformance Specification
Version 1.0 Final Specification
Copyright © 2003 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Learner Information Package Accessibility for LIP Conformance Specification
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.
IMS 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 IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.
Copyright © 2003 IMS Global Learning 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 IMS found on the IMS website: http://www.imsglobal.org/license.html.
The limited permissions granted above are perpetual and will not be revoked by IMS 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.
1.2 Scope and Context
2. The Conformance Architecture
2.1 Use Case Coverage
2.2 The System Architecture
2.3 The Specification Classes
2.3.1 <accessForAll> Specification Classes
2.3.2 <accommodation> Specification Classes
2.4 Conformance Test Architecture
3. accessForAll Test Specification
3.1 <accessForAll> Class
3.1.1 Class Overview
3.1.2 XML Behavior Specification
3.1.3 Object Behavior Specification
3.1.4 Path Behavior Specification
3.2 <context> Class
3.2.1 Class Overview
3.2.2 XML Behavior Specification
3.2.3 Object Behavior Specification
3.2.4 Path Behavior Specification
3.3 <display> Class
3.3.1 Class Overview
3.3.2 XML Behavior Specification
3.3.3 Object Behavior Specification
3.3.4 Path Behavior Specification
3.4 <control> Class
3.4.1 Class Overview
3.4.2 XML Behavior Specification
3.4.3 Object Behavior Specification
3.4.4 Path Behavior Specification
3.5 <content> Class
3.5.1 Class Overview
3.5.2 XML Behavior Specification
3.5.3 Object Behavior Specification
3.5.4 Path Behavior Specification
4. Conformance Categories
4.1 Manager Level Conformance
4.1.1 Baseline Conformance Classification
4.1.2 Strict Conformance Classification
4.1.3 Profiled Conformance Classification
4.2 Application Level Conformance
4.2.1 Baseline Conformance Classification
4.2.2 Strict Conformance Classification
4.2.3 Profiled Conformance Classification
Appendix A - Glossary of Terms
Appendix B - Baseline Vocabularies
Appendix C - Conformance for Extensions
About This Document
List of Contributors
This conformance plan is, by necessity, a high level abstract plan, since actual conformance testing must be done within the context of an application profile. As such, this document can be viewed as source material for developing specific ACCLIP test plans tightly associated with an application profile.
This document draws heavily on the ACCLIP Information Model and ACCLIP Object Model. The reader is referred to those documents for the definitive specification of data elements, methods, and class definitions.
A general conformance plan is described for the <accessForAll> and <accommodation> elements as defined by the ACCLIP Information Model. Object model tests are described for each of the major classes defined by the ACCLIP Object Model. These objects do not go all the way to specific preferences, since they are implementation dependent.
|ACCLIP||Accessibility for Learner Information Package|
|LIP||Learner Information Package|
|XML||Extensible Mark-up Language|
|[ACCLIP 1a,b,c,d]||IMS Learner Information Package Accessibility for LIP Information Model, Binding, Best Practice Guide, and Use Cases|
|[LIP 1a,b,c]||IMS Learner Information Package Information Model, Binding, and Best Practice Guide|
The IMS Accessibility for LIP Use Cases, v1.0 describes several likely use cases for accessibility preferences. Several of these use cases describe actual distance learning environments that utilize accessibility preferences. All of the use cases described refer to preferences and accommodations that can be represented using an ACCLIP structure.
The ACCLIP specification does not presume a particular architecture beyond that specified in the IMS Abstract Framework. Since ACCLIP is intended to provide accessibility preferences in a comprehensive learner profile, it is likely that an ACCLIP manager is part of a larger Learner Profile Manager. This is not, however, a requirement. The ACCLIP preferences can be implemented and used in isolation and do not have dependencies on the Learner Information Package beyond those stated in the ACCLIP Information Model.
Regardless of how ACCLIP is implemented, two classes of systems are identified which must interact with ACCLIP data: ACCLIP repositories and ACCLIP applications. ACCLIP repositories are responsible for creating, storing, and managing ACCLIP data. ACCLIP applications allow preferences to be utilized. In some cases, an ACCLIP application may alter or add new preferences (a volume change, for example). In such cases, the application supplies new information to a central manager for storage. These two classes of systems are reflected in two distinct conformance classifications: manager and application.
Two root classes are defined in the ACCLIP Information Model: <accessForAll> and <accommodation>. Both are name spaced extensions of elements previously defined in the IMS Learner Information Package.
|Class||Manager Implementation||Application Implementation|
- preference aggregation using XML
- preference aggregation using objects
- specific preference references using path descriptions
Each of these are binding dependent and will require separate test methods to measure conformance. In addition to the above, LIP data may be aggregated into an IMS Content Package and, by extension, ACCLIP data as well.
The read() method associated with this class returns an XML string formatted according to an accessForAll XML schema binding. Similarly, the write() method allows aggregated preferences to be saved all at once.
The <context> class provides a method to group preferences according to need, environment, and alternative use. Each <context> is identified with a identifier unique to this system. The <context> class serves as a container for the <display>, <control>, and <content> objects.
The read() method associated with this class returns an XML string formatted according to an accessForAll XML schema binding for this context. Similarly, the write() method allows aggregated preferences to be saved all at once in the specified context.
The <context> class contains three sub-objects and provides get and set methods for each of them. These include getDisplay(), setDisplay(), getControl(), setControl(), getContent(), and setContent(). In addition, two methods are provided to getLang() and setLang(), which is the default language associated with this context.
The <display> class contains learner preferences that determine how information displayed or delivered to the learner. This class serves as a container for the screenReader, screenEnhance, textReadingHighlight, braille, tactile, visualAlert, and structurePresentation objects.
The read() method associated with this class returns an XML string formatted according to an accessForAll XML schema binding for the display preferences in this context. Similarly, the write() method allows aggregated display preferences to be saved all at once.
The <display> class contains seven sub-objects and provides get and set methods for each of them. These include getScreenReader(), setScreenReader(), getScreenEnhance(), setScreenEnhance(), getTextReadingHighlight(), setTextReadingHighlight(), getBraille(), setBraille(), getTactile(), setTactile(), getVisualAlert(), setVisualAlert(), getStructurePresentation(), and setStructuralPresentation(). The actual implementations of these sub-objects is dependent on an application profile suitable for its use.
The getViaPath(path) method resolves a path specification to a specific display preference and returns it. The setViaPath(path, value) method resolves a path specification and changes the value associated with it.
The <control> class contains learner preferences that determine learners interact with an eLearningsystem. This class serves as a container for the <keyboardEnhanced>, <onscreenKeyboard>, <alternativeKeyboard>, <mouseEmulation>, <alternativePointer>, <voiceRecognition>, <structuralNavigation>, and <codedInput> objects.
The read() method associated with this class returns an XML string formatted according to an accessForAll XML schema binding for the control preferences in this context. Similarly, the write() method allows aggregated control preferences to be saved all at once.
The <display> class contains seven sub-objects and provides get and set methods for each of them. These include getKeyboardEnhanced(), setKeyboardEnhanced(), getOnscreenKeyboard(), setOnscreenKeyboard(), getAlternativeKeyboard(), setAlternativeKeybaord(), getMouseEmulation(), setMouseEmulation(), getAlternativePointer(), setAlternativePointer(), getVoiceRecognition(), setVoiceRecognition(), getStructuralNavigation(), setStructuralNavigation(), getCodedInput(), and setCodedInput(). The actual implementations of these sub-objects is dependent on an application profile suitable for its use.
The getViaPath(path) method resolves a path specification to a specific control preference and returns it. The setViaPath(path, value) method resolves a path specification and changes the value associated with it.
The <content> class contains learner preferences that define the learner's preferences in content. This class serves as a container for the <alternativesToVisual>, <alternativesToText>, <visualText>, <alternativesToAuditory>, <learnerScaffold>, <personalStylesheet>, and <extraTime> objects.
The read() method associated with this class returns an XML string formatted according to an accessForAll XML schema binding for the content preferences in this context. Similarly, the write() method allows aggregated content preferences to be saved all at once.
The display class contains seven sub-objects and provides get and set methods for each of them. These include getAlternativesToVisual(), setAlternativesToVisual(), getAlternativesToText(), setAlternativesToText(), getVisualText(), setVisualText(), getAlternativesToAuditory(), setAlternativesToAuditory(), getLearnerScaffold(), setLearnerScaffold(), getPersonalStylesheet(), setPersonalStylesheet(), getExtraTime(), and setExtraTime. The actual implementations of these sub-objects is dependent on an application profile suitable for its use.
The getViaPath(path) method resolves a path specification to a specific content preference and returns it. The setViaPath(path, value) method resolves a path specification and changes the value associated with it.
The ACCLIP Conformance strategy defines two levels of conformance: Manager and Application. Generally speaking, repositories that manage ACCLIP information are required to implement all ACCLIP structures. Applications are required to implement the root element, context, and at least one set of technology preferences.
Applications that use some or all ACCLIP preferences and accommodations are not required to implement all such preferences. They are required to implement the root elements (<accessForAll> and <accommodation>), the <context> element, and at least one set of technology preferences in <display>, <control>, or <content>.
A quick example illustrates why all preferences are optional under this conformance strategy. Screen readers are applications that convert textual information into speech. Several preferences are provided in <screenReader> for speech rate, pitch, volume, etc. Since these preferences are specific to the application, there is not need for the application to implement other preferences, such as braille, etc.
Application Level Conformance requires at a minimum to implement root elements (<accessForAll> and <accommodation>), <context>, and at least one set of technology elements in <display>, <control>, or <content>.
Since some applications may be more general than a screen reader (using the example above), groups of technology preferences can be collected into profiles. Three profiles are initially defined: display, control, and content. Applications choosing to conform to the display, control, or content profiles are required to implement all of the technology preferences associated with them. Other mixed profiles may also be defined.
|Title||IMS Learner Information Package Accessibility for LIP Conformance Specification|
|Team Co-Lead||Jutta Treviranus|
|Version Date||18 June 2003|
|Summary||This document describes the ACCLIP Conformance.|
|Revision Information||18 June 2003|
|Purpose||Defines conformance measures for the ACCLIP specification.|
|Version No.||Release Date||Comments|
|Final v1.0||18 June 2003||The first public release of the document.|
Abstract Framework 1
Content Package 1
level C 1
IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Learner Information Package Accessibility for LIP Conformance Specification ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
IMS makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.
The Specification is at all times subject to change and revision without notice.
It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.
IMS would appreciate receiving your comments and suggestions.
Please contact IMS through our website at http://www.imsglobal.org
Please refer to Document Name: IMS Learner Information Package Accessibility for LIP Conformance Specification Revision: 18 June 2003