1EdTech Logo

1EdTech AccessForAll Meta-data Overview

Version 1.0 Final Specification

Copyright © 2004 1EdTech Consortium, Inc. All Rights Reserved.
The 1EdTech Logo is a trademark of 1EdTech Consortium, Inc.
Document Name: 1EdTech AccessForAll Meta-data Overview
Revision: 12 July 2004


 
Date Issued: 12 July 2004

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 © 2004 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 Documents in this Specification
1.2 Other Related Specifications
1.2.1 IEEE LOM
1.2.2 Dublin Core Metadata Element Set
1.2.3 ACCLIP Specification and Content Accessibility Guidelines
1.3 Nomenclature
1.4 References

2. Overview of Accessibility and Meta-data

3. Primary and Equivalent Alternative Resources
3.1 Primary Resource Meta-data
3.1.1 Access Modality
3.1.2 Adaptability
3.1.3 Equivalent
3.2 Equivalent Alternative
3.2.1 Equivalent Alternative Resource Meta-data

4. The Importance of Interoperability for Accessibility

5. Scenarios
5.1 Scenario 1: Discovery and Retrieval of Alternate Training Content
5.2 Scenario 2: Customization of Information about a Prescription
5.3 Scenario 3: Extreme Instructional Environments

About This Document
List of Contributors

Revision History

Index


1. Introduction

1.1 Documents in this Specification

This document includes or refers to the following:

AccessForAll Meta-data Overview (this document)

This Overview is designed to explain the role and purpose of the specification. It also explains the relationship between this specification and other standards and specifications.

Information Model

The Information Model fully and formally describes the information that is considered important for the specification. It shows the relationship between the various pieces of information involved in the model. It is a human-readable document that specifies what must be encoded in the machine-readable documents to conform to this specification.

The information model describes the core aspects of the specification and contains parts that are normative for any binding claiming to conform to this specification. It contains details of semantics, structure, data types, value spaces, multiplicity, and obligation (i.e., whether mandatory or optional).

XML Binding

The XML binding is a formal document describing the Information Model and its binding to an XML Schema. It is normative for any XML instance document that claims to employ this specification, whether by reference or by declaration of the namespace reserved for this specification. In cases of error or omission, the Information Model takes precedence. The XML Binding is released with an XML Schema Definition file.

Conformance issues are addressed in the binding document, as the binding document will be used to judge conformance.

XML Schema Definition

The XML Schema Definition defines, in a machine-readable format, the required syntax and structure of valid XML instance documents conforming to this specification. The XML Schema is to be used in system implementations.

Best Practice and Implementation Guide

The Best Practice and Implementation Guide provides guidance in implementing the specifications and responds to common questions expected from implementers. The Best Practices Guide also gives examples of how the specification is related to other specifications, most notably the AccessForAll LIP specification.

1.2 Other Related Specifications

1.2.1 IEEE LOM

The IEEE LOM (Institute of Electrical and Electronics Engineers' Learning Object Metadata) is a profile for learning object meta-data. It contains a description of semantics, vocabulary, and extensions. An encoding of Accessibility Meta-data that harmonizes with the AccessForAll Meta-data and is suitable for use in an IEEE LOM Application is under construction by CEN-ISSS Learning Technologies Workshop [APLR].

1.2.2 Dublin Core Metadata Element Set

The Simple Dublin Core Metadata Element Set is the ISO 15836 standard for core meta-data. There is also a Qualified Dublin Core Metadata Element Set with additional terms and extensions. Dublin Core meta-data is not domain specific. An encoding of the AccessForAll Meta-data specification will be suitable for use in a Dublin Core Application Profile for accessibility of resources.

1.2.3 ACCLIP Specification and Content Accessibility Guidelines

The Accessibility for LIP Specification (ACCLIP) is the 1EdTech specification for expressing learner accessibility preferences and needs. The 1EdTech Accessibility for LIP together with the AccessForAll Meta-data specification provide the two sides of the match needed to address the needs and preferences of learners. One specifies what the learner needs or prefers and the other labels resources using the same terms. Both specifications, while initiated in the educational community, are suitable for any user in any computer-mediated context.

The AccessForAll Meta-data specification and the ACCLIP share a special relationship in that, in certain parts, they are reflections of the same information. The information the two specifications share is related to content i.e., the ACCLIP describes the content needs and preferences of a user whereas the AccessForAll Meta-data describes the content properties and characteristics of a resource. The set of possible values for this shared content information was defined in the ACCLIP. As a result, the obvious solution, and the one employed in the AccessForAll Meta-data specification, is for ACCLIP and AccessForAll Meta-data to share the definition of the content elements in their own usages. In this way the essential functionality is defined only once. An additional benefit is the ease of maintenance of consistency between the two specifications.

The AccessForAll specifications are intended to address mismatches between resources and user needs caused by any number of circumstances including requirements related to client devices, environments, language proficiency or abilities. They support the matching of users and resources despite short-comings in resources. These profiles allow for finer than usual detail with respect to embedded objects and for the replacement of objects where the originals are not suitable on a case-by-case basis. The AccessForAll specifications are not judgmental but informative; their purpose is not to point out flaws in content objects but to facilitate the discovery and use of the most appropriate content for each user.

The AccessForAll specifications do not describe how to create accessible content; other work has been completed that describes how content and media objects can be made more accessible (e.g., 1EdTech Guidelines for Developing Accessible Learning Applications [ACCGuide, 02] for a summary and W3C/WAI Web Content Accessibility Guidelines [W3CWAI] for details). Systems using the AccessForAll specifications will provide more accessible learning environments to the extent that the content and applications available follow the published accessibility guidelines.

1.3 Nomenclature

 
ACCLIP 1EdTech Learner Information Package Accessibility for LIP
ACCMD 1EdTech AccessForAll Meta-data (this specification)
CP 1EdTech Content Packaging Specification
DCMES DCMI Dublin Core Metadata Element Set
DCMI Dublin Core Metadata Initiative
DRI 1EdTech Digital Repositories Interoperability Specification
EARL W3C Evaluation and Report Language
IEEE Institute of Electronic & Electrical Engineering
LOM Learning Object Metadata (usually used in "IEEE LOM")
MIME Multipurpose Internet Mail Extensions
RDF Resource Description Framework
TILE The Inclusive Learning Exchange
W3C World Wide Web Consortium
XML Extensible Mark-up Language

1.4 References

 
[ACCMD, 04a] 1EdTech AccessForAll Meta-data Information Model v1.0, A.Jackl, 1EdTech Consortium, Inc., July 2004.
[ACCMD, 04b] 1EdTech AccessForAll Meta-data XML Binding v1.0, A.Jackl, 1EdTech Consortium, Inc., July 2004.
[ACCMD, 04c] 1EdTech AccessForAll Meta-data Best Practice and Implementation Guide v1.0, A.Jackl, 1EdTech Consortium, Inc., July 2004.
[ACCGuide, 02] 1EdTech Guidelines for Developing Accessible Learning Applications v1.0, 1EdTech Consortium, Inc., June 2002.
[ACCLIP, 03] 1EdTech Learner Information Package Accessibility for LIP v1.0, M.Norton, J.Treviranus, 1EdTech Consortium, Inc., June 2003
[APLR] CEN-ISSS Learning Technologies Workshop Accessibility Properties for Learning Resources, http://www.cen-aplr.org
[CP, 03] 1EdTech Content Packaging v1.1.3, C.Smythe, 1EdTech Consortium, Inc., June 2003.
[IEEE LOM] IEEE 14.84.12.1 - 2002 Standard for Learning Object Metadata, http://ltsc.ieee.org
[RFC 2119] IETF RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels
[RFC 2396] IETF RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax
[RFC3066] RFC 3066, Tags for the Identification of Languages, http://www.ietf.org/rfc/rfc3066.txt
[UDC] Universal Decimal Classification Scheme, UDC Consortium, http://www.udcc.org/
[ISO 11404] ISO 11404, Language-independent Datatypes, http://www.iso.ch/cate/d19346.html
[W3CWAI] W3C/WAI Web Content Accessibility Guidelines, http://www.w3.org/TR/WAI-WEBCONTENT/

2. Overview of Accessibility and Meta-data

In this document, the term disability has been re-defined as a mismatch between the needs of the learner and the education offered. It is therefore not a personal trait but an artifact of the relationship between the learner and the learning environment or education delivery. Accessibility, given this re-definition, is the ability of the learning environment to adjust to the needs of all learners. Accessibility is determined by the flexibility of the education environment (with respect to presentation, control methods, access modality, and learner supports) and the availability of adequate alternative-but-equivalent content and activities. The needs and preferences of a user may arise from the context or environment the user is in, the tools available (e.g., mobile devices, assistive technologies such as Braille devices, voice recognition systems, or alternative keyboards, etc.), their background, or a disability in the traditional sense. Accessible systems adjust the user interface of the learning environment, locate needed resources and adjust the properties of the resources to match the needs and preferences of the user.

Meta-data can be used for two accessibility related purposes: to record compliance to an accessibility specification or standard (e.g., for adherence to legislated procurement policies) or to enable the delivery of resources that meet a user's needs and preferences. The AccessForAll Meta-data specification addresses the latter purpose. Meta-data to assert compliance to an accessibility specification or standard is not within the scope of this specification.

Current meta-data specifications do not provide adequate support for accessible delivery of educational resources. As a result, it is difficult for current systems to match their resources with specific accessibility requirements. Similarly, current guidelines for rating the accessibility of resources do not provide enough granularity in their ratings to support selecting accessible resources for specific users or contexts. Prior to this specification, 1EdTech released the ACCLIP which is a model for describing and recording user preferences regarding content, display, and control of learning resources. The AccessForAll Meta-data specification (ACCMD) defines accessibility meta-data that is able to express a resource's ability to match the needs and preferences of a user's ACCLIP profile. As a result, systems are able to select the appropriate resource(s), when available, for a user, thereby providing user experiences that adapt to individual needs. Because these specifications offer a modular approach to accessibility, defining each aspect of the user preference or resource characteristic separately, systems can determine to whom each resource is accessible and under what circumstances, with greater specificity than allowed by either previous meta-data specifications or existing accessibility guidelines.

The AccessForAll Meta-data is not merely intended to assist with resource discovery. It also provides an interoperable framework that supports the substitution and augmentation of a resource with an equivalent or supplementary resource as required by the accessibility needs and preferences of a user's ACCLIP profile. For example, a text caption could be added to a video when required by a user with a hearing impairment or in a noisy environment. User needs and preferences of people with disabilities are frequently very particular with little or no room for variance. A slight variation in font size, button size, or background color for example can be the difference between an accessible resource and an unusable one. The process of matching a resource with a user requirement is not a matter of convenience or refinement, but one of utmost importance in ensuring access for users whose choice of access modalities is restricted by a disability. As a result, it is necessary for systems to agree upon well-defined interfaces and for the specification to deter free, non-conformant extension in its usage. This closely-defined approach is taken by the AccessForAll Meta-data specification to support optimum interoperability.

The AccessForAll Meta-data specification provides guidance on how to match accessibility meta-data (i.e. a resource profile) to the properties defined in the ACCLIP specification (i.e., a user profile). It also defines the behavior applications should exhibit in some specific contexts; see the Best Practice Guide [ACCMD, 04c] for more information.

The two AccessForAll specifications-AccessForAll Meta-data and Accessibility for LIP-address several challenges:

  • Initial discovery of material having appropriate accessibility support;
  • Adjustment of control and display of resources to meet user accessibility needs and preferences, and
  • Discovery of appropriate alternative or augmentative representations of desired learning resources.

Users of alternative access systems need to know whether a resource is compatible with their required access method, e.g., a user who is blind may need audible access to a resource as opposed to visual access. Used in combination, the AccessForAll specifications offer a significant foundation for providing support to users in expressing their accessibility needs and preferences and conversely to resource providers for declaring the suitability of resources to specific user needs. This allows users to specify how content should be displayed and controlled, what alternative but equivalent resources are needed and what supplementary user supports are needed and for systems to locate and provide resources which support the needs and preferences of users. Other work has been completed that describes how content and media objects can be made more accessible (e.g., 1EdTech Guidelines for Developing Accessible Learning Applications [ACCGuide, 02] for a summary and W3C/WAI Web Content Accessibility Guidelines [W3CWAI] for details).

The AccessForAll specifications are intended to be applied in computer-mediated delivery of educational resources. The specifications capitalize on the capability of the computer to translate or transform user interfaces and resource delivery. The first approach to meeting the specific needs and preferences of a learner would be to transform the resource through alternative styling or through the provision of alternative control methods (e.g., keyboard shortcuts). If a resource cannot be adequately transformed an equivalent alternative is sought that addresses the needs or preferences of the learner.

3. Primary and Equivalent Alternative Resources

The AccessForAll Meta-data specification groups resources into two possible categories: primary resources and equivalent alternative resources. The primary resource is the initial or default resource. Most existing resources would be considered primary resources. An equivalent alternative resource provides equivalent semantic and behavioral functionality and addresses the same learning objective as the referenced primary resource but in an alternative form.

Since the authors of most primary resources are unlikely to be informed about accessibility considerations and may not be motivated to create additional meta-data, the meta-data on the primary resources is kept to a minimum. Meta-data regarding a primary resource simply describes what sensory modality is needed to use the resource (e.g., visual, auditory, etc.), whether the display and method of control can be transformed and whether there is a known equivalent alternative. The meta-data describing whether a resource is amenable to transformation can be generated using existing accessibility evaluation tools that produce EARL files (W3C Evaluation and Report Language).

On the other hand, it is anticipated that authors of equivalent alternatives are likely to be both motivated and informed about accessibility considerations. The description of the equivalent alternative resource is therefore much more detailed and closely matches the Accessibility for LIP specification.

3.1 Primary Resource Meta-data

Primary resource meta-data describes:

  • Access Modality: Whether the user requires vision, hearing, touch and/or text literacy to access the resource.
  • Adaptability: How amenable the resource is to transformation of the display and whether the method of control is flexible (display transformability and control flexibility).
  • Equivalent: Whether there is a known equivalent alternative.

3.1.1 Access Modality

Often the method of displaying a resource or controlling a resource cannot be transformed or cannot be adequately transformed to meet the needs of a learner. For example, a graphic may be enlarged for someone with a vision impairment but cannot be sufficiently transformed for someone without sight. When this is the case an equivalent alternative resource must be sought. To help determine whether this is the case the access modality of the primary resource must be declared.

The access modality of a resource is not the same as the format of a resource. Often, the format of a resource is represented by a MIME type, while its modality is usually format-independent. The important information, from the viewpoint of a user with specific access needs and preferences, is which sensory modalities are required for accessing the resource's content. The possibilities are based on the human computer interface properties of sight, sound, and touch, with an additional special content property of 'text' to denote the need for text literacy. In ACCLIP the user specifies whether he or she requires alternatives to audio, video, tactile or text. 'Text' shares a special relationship with these sensory modalities for users who have a specific problem with text, for example, if they are visually capable but severely dyslexic. In this case, display flexibility may be inadequate and the user will require an alternative resource.

As many resources are made up of multiple files (i.e., aggregate resources), adding the necessary meta-data in order to deliver resources accessibly may involve a dis-aggregation of the primary or encapsulating resource. Once atomic files are able to be associated with their own modalities (as opposed to being represented in the aggregate modality of the primary resource), they can then be individually matched against a user's access modality requirements. Associating individual atomic files with accessibility meta-data ensures that the entire aggregated resource can be made accessible to the user.

3.1.2 Adaptability

3.1.2.1 Display Transformability

The presentation or display of many resources can be transformed if appropriate formats, markup or software development practices are used to create the educational resources. This implies creating the resource in such a way that the content and content-structure are independent of the presentation of the content. Transformation is further supported by creating a well-structured resource that communicates structure using structural markup and not presentation markup (see W3C guidelines [W3CWAI] and 1EdTech Accessibility Guidelines [ACCGuide, 02]). The display or method of presentation can then be transformed using styling mechanisms (e.g., Cascading Style Sheets, system based display settings, XSLT, etc.). Display transformability specifies whether the display or presentation of a resource (e.g., font color, font size, background color, layout, image size) is amenable to transformation. This can be determined using a number of available Web content evaluation and repair tools. These tools produce an EARL statement (W3C Evaluation and Report Language). This EARL statement is therefore used to declare the display transformability of the resource.

The range of possible display transformations is described in the Accessibility for LIP specification.

3.1.2.2 Control Flexibility

Some resources can only be controlled using a mouse or mouse equivalent. This makes them impossible to control for individuals who do not have a mouse or cannot control a mouse. If the same functions can be controlled using keyboard commands these individuals have access to the functionality by using a keyboard or any number of available keyboard-emulating devices (e.g., scanning systems, coding systems, enlarged keyboards, etc.). Some interfaces require a large number of sequential actions to navigate to a desired control. This can result in inefficient or ineffective control for users in a number of circumstances. Interfaces that allow reconfiguration of the actions required to access specific controls, buttons, links or input fields enable the optimization of the control method for a greater number of users or contexts. Control Flexibility specifies whether the resource supports adequate choices for methods of controlling the resource functions. It is anticipated that this will be determined using available accessibility checking tools that produce reports in W3C EARL.

3.1.3 Equivalent

When the authors of meta-data for primary resources are aware of the existence of equivalent resources, they can record a pointer to the equivalent in the meta-data for the primary resource. However, the description of the equivalent alternative is included with the meta-data for the equivalent alternative itself. Further detail on the equivalent alternative resource meta-data is in the next section.

3.2 Equivalent Alternative

When a primary resource contains an equivalent alternative (such as a video that contains a text caption), the meta-data record for the resource will have both a primary resource description (including a pointer to itself as the equivalent) and an equivalent alternative resource description. Thus both components of the AccessForAll Meta-data record will be completed for the single resource.

3.2.1 Equivalent Alternative Resource Meta-data

Equivalent alternative resources are of two types: supplementary and non-supplementary. A supplementary alternative resource is meant to augment or supplement the primary resource, while a non-supplementary alternative resource is meant to substitute for the primary resource. Although in most cases the primary and equivalent alternative resources will be separate, a primary resource may contain a supplementary alternative resource. For example, a primary video could have text captions included. In this case the resource would be classified as primary containing an equivalent supplement. A primary resource can never contain, within itself, a non-supplementary resource.

Equivalent alternative resources (both supplementary and non-supplementary) need to have additional accessibility information apart from a reference to their primary resource. An equivalent alternative resource must contain information about the nature of the equivalence. For example, it is insufficient to know that a resource is an alternative for a video that contains audio and visual modalities. We must also know whether it is an alternative for the audio (e.g., a caption) or for the visual (e.g. a video description). This extra accessibility information describes the content of the equivalent alternative only in the context of its equivalence to the primary, i.e., it specifies whether or not the resource is a text, visual, or audio alternative of the primary resource, and if so, gives the values of its alternate properties. These content properties are exactly the same as the content preferences defined in the Accessibility for LIP specification, but viewed from a resource perspective rather than from a user perspective. It is in this way that a system is able to match equivalent alternative resources to needs or preferences of a user, because it is processing the same set of information for both the resource and user. In addition, this saves work in the implementation because the structure of the information to be matched is the same.

Primary resources are defined as having zero or more equivalent alternative resources but equivalent alternative resources may, by definition, have only one primary resource. An equivalent alternative resource is never allowed to have or point to another equivalent alternative resource. This prevents circular references from occurring and greatly simplifies the relationship model between primary and equivalent resources. For example, a French version of an English caption for a German film will be marked as an equivalent alternative of the primary resource, the German film. Where it may be of interest to know that the French captions were translated from the English version, the 'source' of the particular alternative can be recorded elsewhere.

4. The Importance of Interoperability for Accessibility

While the AccessForAll specifications support the personalized delivery of resources for all users they are of greatest importance to people with disabilities. Disabilities restrict choice and flexibility making accurate matching of resources to personal needs of utmost importance. The personal access systems used by people with disabilities can be seen as unique external systems that need to interoperate with the system delivering the resource. These personal access systems must interoperate with many different delivery systems. The personal access systems must also adjust frequently to updates or modifications in an array of delivery systems. For these reasons it is important that the delivery systems tightly adhere to a common set of specifications with information relevant to accessibility. To promote interoperability this information should be found in a known consistent place, stated using a consistent vocabulary and structured in a consistent way. To support this critical interoperability the AccessForAll specifications offer less flexibility in implementation than other specifications.

5. Scenarios

These scenarios are informal and introductory only, but are provided to help explain the context and use of the specification.

5.1 Scenario 1: Discovery and Retrieval of Alternate Training Content

Sophia is a participant in a distance training program. She is blind and uses a computer equipped with a screen reader that converts on-screen text into both Braille and synthetic speech. At the start of the program, Sophia uses a "preference wizard" which asks her questions regarding her preferred content settings. She records that she would prefer alternatives to visual content, when available. When finished editing her preferences, the preference wizard produces an ACCLIP file that is saved in the content management system's user database.

For today's assignment, Sophia is required to complete 3 of 5 provided exercises. When she logs in and requests the exercises the system compares her ACCLIP file and the Accessibility Meta-data on the exercises to determine if the exercises are suitable for her needs. The meta-data associated with each exercise indicates that all 5 contain visual content. The system then determines that there are text descriptions available for 4 out of 5 of the resources. Two of the exercises have text descriptions embedded in the primary file, while there are separate text descriptions for the other two exercises. The system informs Sophia that 4 of the 5 exercises should be appropriate for her needs, and she selects the three she wishes to complete, giving a sigh of relief that she is able to skip the least interesting one. As she calls up her chosen exercises, the system automatically transforms each resource by displaying the text description rather than the image, drawing the text either from within the primary file or from the associated separate text descriptions, as indicated by the meta-data.

5.2 Scenario 2: Customization of Information about a Prescription

A patient at a hospital has been diagnosed with diabetes. The clinical nurse prepares a prescription package for the patient containing information necessary for the patient to manage her condition. To create the package, the nurse prepares the patient's profile, which includes the native language, Tamil, and the print requirements (large text) of the patient. When the patient uses the hospital's information system, the system processes the user's profile along with the diagnosis to retrieve information in Tamil about measuring blood glucose levels and exercising. Before being printed, the documents are automatically enlarged.

5.3 Scenario 3: Extreme Instructional Environments

Airline maintenance staff receive regular training sessions, but there is always the possibility of the need for "ad hoc" instruction. Available airplane resource materials include video instructions on aircraft engine maintenance that detail the methods for repairing various engine problems. Usually the use of such material is in a noisy hangar in which workers are required to wear hearing protection. There may also be multiple information systems connected to their ear-phones for safety reasons. In this environment, workers use portable computers to view the reference materials as they carry out the repair exercises.

When workers log in, they indicate the hangar as the context and an alternate profile is selected by the system. This profile requires text transcripts or animated diagrams to replace audio content. When viewing the training videos, the system automatically retrieves the available text captions or alternative visual content and supplements the video with them while synchronizing it to the original audio. As a result, the workers are able to reference videos as they work in the hangar.

About This Document

 
Title 1EdTech AccessForAll Meta-data Overview
Editor Alex Jackl (1EdTech)
Team Co-Leads Jutta Treviranus (Industry Canada), Anthony Roberts (Industry Canada)
Version 1.0
Version Date 12 July 2004
Status Final Specification
Summary This document provides an overview of all this is required for the AccessForAll Meta-data specification; it references the technical documents.
Revision Information 12 July 2004
Purpose This document has been approved by the 1EdTech Technical Board and is made available for adoption.
Document Location http://www.imsglobal.org/accessibility/accmdv1p0/imsaccmd_oviewv1p0.html

 
To register comments or questions about this specification please visit: http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=16

List of Contributors

The following individuals contributed to the development of this document:

 
Name Organization
Anastasia Cheetham ATRC - U. Toronto, Industry Canada
Martyn Cooper Open University, UK
Andy Heath Sheffield Hallam University, CEN-ISSS Learning Technologies Workshop APLR project
Alex Jackl 1EdTech Consortium, Inc.
Eric Hansen Educational Testing Service, USA
Liddy Nevile DEST, La Trobe University Australia
Anthony Roberts Industry Canada
Madeleine Rothberg WGBH National Center for Accessible Media, USA
Jutta Treviranus ATRC - U. Toronto, Industry Canada
David Weinkauf ATRC - U. Toronto, Industry Canada

Revision History

 
Version No. Release Date Comments
Base Document 1.0 02 February 2004 Initial version of the AccessForAll Meta-data Specification.
Public Draft 1.0 20 May 2004 Initial Public Draft version of the AccessForAll Best Practice and Implementation Guide.
a) Subsumed the Best Practice Guide into this document and added extensive content.
Final Specification 1.0 12 July 2004 Final Specification of the 1EdTech AccessForAll Meta-data Overview.

Index

A
AccessForAll 1, 2, 3, 4, 5, 6, 7, 8, 9
Accessibility 1, 2, 3, 4, 5, 6, 7

B
Behavior 1
Binding 1

C
Conformance 1

D
Dublin Core 1, 2

E
Extension 1

I
IEEE 1, 2, 3
1EdTech Specifications
AccessForAll Meta-data 1
Content Packaging 1
Digital Repositories Interoperability 1
Learner Information Package 1, 2, 3, 4, 5, 6
Learner Information Package Accessibility for LIP 1, 2, 3, 4
Interoperability 1, 2
 

L
Learning Object 1, 2
LOM 1, 2, 3

M
Meta-data 1, 2, 3, 4, 5

N
Namespace 1
Normative 1

P
Preferences 1, 2, 3, 4, 5, 6
Profile 1, 2, 3

R
Resource 1, 2, 3, 4, 5, 6, 7, 8
Resources 1, 2, 3, 4, 5, 6, 7, 8, 9
RFC 1

S
Standards 1
Structure 1, 2, 3

U
URI 1

V
Vocabulary 1, 2

W
W3C 1, 2, 3, 4, 5

X
XML 1, 2
XSLT 1

 

 

 

1EdTech Consortium, Inc. ("1EdTech") is publishing the information contained in this 1EdTech AccessForAll Meta-data Overview ("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 AccessForAll Meta-data Overview Revision: 12 July 2004