1 Introduction

1.1 AccessForAll

The AfA Specification is intended to promote an inclusive user experience by enabling the matching of the characteristics of resources to the needs and preferences of individual users. The AfA specification consists of a common language for describing:

• A learner's needs and preferences with respect to how the learner can best interact with digital resources, including configuration of assistive technologies. This is represented using the 1EdTech AccessForAll Personal Needs and Preferences (PNP) v3.0 [AfAPNP, 12] specification;
• Digital learning resources. This is represented using the 1EdTech AccessForAll Digital Resource Description (DRD) v3.0 specification [AfADRD, 12].

The AfA DRD specification is intended for use in combination with the 1EdTech AfA PNP specification v3.0 [AfAPNP, 12], which provides a means to describe how a user desires to access online learning content and related applications. This part of the AfA Specification is intended to describe aspects of digital resources or a computer system (including networked systems) that can be adjusted to improve accessibility. They are not intended to address non-digital systems that can include physical location, other people, external processes, etc.

The AfA PNP specification is intended to meet the needs of learners with disabilities and of anyone in a disabling context. The purpose of the AfA PNP Specification is to provide a machine-readable method of stating user needs and preferences with respect to digitally based education or learning. The AfA PNP specification can be used independently, for example to deliver the required or desired user interface to the user, or in combination with the AccessForAll Specification Digital Resource Description [AfADRD, 12] to deliver digital resources that meet a user's needs and preferences.

1.2 Structure of this Document

The structure of this document is:

2. Design of AccessForAll 3.0

A brief review of the underlying design principles for AfA 3.0;

3. Previous Versions of the AccessForAll Standards

The historic perspective for AfA 3.0;

4. Use Cases

The set of use cases used to define the scope of the AFA 3.0 specification definition;

5. AccessForAll Document Set

An overview of the documentation set released as the AfA 3.0 specification.

1.3 Nomenclature

AccLIP

Learner Information Package Accessibility for LIP

AccMD

AccessForAll Meta-data

AfA

AccessForAll

AfA DRD

AccessForAll Digital Resource Description

AfA PNP

AccessForAll Personal Needs & Preferences

DRD

Digital Resource Description

1EdTech

1EdTech Consortium Inc.

LMS

Learning Management System

ISO

International Standards Organization

PNP

Personal Needs & Preferences

UML

Unified Modeling Language

W3C

World Wide Web Consortium

WAI

Web Accessibility Initiative

WCAG

Web Content Accessibility Guidelines

 

1.4 References

[AfABPIG, 12] 1EdTech AccessForAll Best Practices & Implementation Guide v1.0, R.Schwerdtfeger, M.Rothberg and C.Smythe, Public Draft, 1EdTech Inc., September 2012.

[AfADES, 12] 1EdTech AccessForAll v3.0 Data Element Specification v1.0, R.Schwerdtfeger, M.Rothberg and C.Smythe, Public Draft, 1EdTech Inc., September 2012.

[AfAPNP, 12] 1EdTech AccessForAll Personal Needs & Preferences v3.0 Information Model v1.0, R.Schwerdtfeger, M.Rothberg and C.Smythe, Public Draft, 1EdTech Inc., September 2012.

2 Design of AccessForAll 3.0

2.1 Guiding Themes

The themes that guided the development of AfA 3.0 are described here.

• Simplicity and ease of understanding are crucial to adoption;
• Easy modifiability will support changing requirements and the needs of organizations that require some parts of the model but not all, or require some parts of the model but use a different set of properties for other parts of it. Here, the work takes a knowledge-oriented approach, which will in future versions support Semantic Web technologies, as further explained in the Best Practices and Implementation Guide;
• Easy integration with other metadata should be possible;
• Integration with standards for device properties will, in future versions, permit matching to device properties as well as user requirements.
• The standard should properly relate user agents, accessibility APIs and producer-oriented accessibility standards;
• Widespread adoption within accepted accessibility frameworks and tools will promote wider impact.

The long-term goal of 1EdTech AfAv3 is to produce a sustainable, general and effective model integrated with the other standards efforts. It has to work across environments, device contexts and organizations; it is not limited to the educational domain. It aims to support accessibility through an "architecture" for personalization. It needs to be recognized, however, that at this point, the work is prototypical and intended to support progression towards such a model.

2.2 Mechanisms in AccessForAll 3.0

The AfA 3.0 information model includes both properties and refinements of properties. These refinements are described in the Best Practices and Implementation Guide and will be modeled in future versions for other technologies, such as Semantic Web-oriented technologies.

In designing AfA3.0, the working group has made a number of changes, including the following:

• Essential properties that should meet the needs of most mainstream accessibility use cases have been included in the Core Profile;
• The vocabulary for Access Mode has been simplified to the bare minimum for the Core profile, with additional terms in the full information model;
• Some relationships between terms and properties have been expressed using refinement, requiring some restructuring of the model. For example, see the treatment of textOnImage in the Best Practice and Implementation Guide document;
  • A new vocabulary for adaptationMediaType simplifies matching between the user profiles and content metadata; see Appendix B of the Best Practices and Implementation Guide document for more information and for questions on which the group seeks your feedback;
• Two new properties support declaration of assistive technology interoperability through conformance, both at the content level and at the accessibility API level;
  • A new property called accessModeRequired supports the use case of seeking a resource with a specific access mode without specifying the type of adaptation;

· All vocabularies across PNP and DRD have been restructured so that the same set of terms is used for matching properties. Each term and vocabulary is defined only once but used in as many places as needed.

3 Previous Versions of the AccessForAll Standards

3.1 1EdTech AccLIP and AccMD 1.0

The 1EdTech Learner Information Package Accessibility for LIP (AccLIP) and the 1EdTech AfA Meta-data Specification (AccMD) 1.0 (available from http://www.imsglobal.org/accessibility/, June 2003) were developed to work together so that metadata descriptions of content in AccMD were associated with descriptions in AccLIP of user preferences to allow learning content to be delivered to meet the needs of the user.

The ideas and technological approaches of AfA were originally formulated as part of the Web-4-All project (http://web4all.atrc.utoronto.ca/), which began in 2002. Web-4-All provided a way of describing a user's technical needs so that a computer could be automatically configured to their preferences and then re-configured for another user. The development and testing of the Web-4-All system informed the development of AccLIP and AccMD, and when the Web-4-All project ended in 2006, it was fully 1EdTech-compliant.

The development of AccLIP and AccMD expanded upon the ideas of Web-4-All to include the control, content and display characteristics of a digital resource. This approach became known as the AccessForAll (AfA) approach to accessibility.

AccLIP 1.0 was a comprehensive specification for description preferences relating to a) the type of content, b) the way it is rendered (displayed), and c) how it is controlled (interacted with). Representation was in hierarchically-structured XML and was intended to augment the 1EdTech specification of Learner Information called the Learner Information Package (LIP), hence the name 'Accessibility for LIP'. The LIP specification described a format for user information required mainly by the Enterprise parts of educational organizations.

Even though no large-scale AfA implementation was built, some small implementations demonstrated the value of the approach of supporting the delivery of a personalized, accessible learning experience (compared to a one-size-fits-all solution), resulting in a more user-centered, inclusive learning experience for all users. One example is The Inclusive Learning Exchange (TILE, http://inclusivelearning.ca/ ), which began in 2003. TILE implemented AccLIP and AccMD as part of its prototype learning object repository, allowing users to customize the selection and delivery of content. The project was completed in 2006.

3.2 ISO PNP and DRD and AccessForAll 2.0

ISO/IEC JTC1 SC 36[1] adopted the 1EdTech accessibility work and developed a multi-part standard that includes 1EdTech AccLIP 1.0 as the Personal Needs and Preferences standard (PNP) and 1EdTech AccMD 1.0 as the Digital Resources Description standard (DRD). The ISO AfA standard is known as ISO/IEC 24751:2008 Individualized Adaptability and Accessibility in E-learning, Education and Training. The first three parts are:

• Part 1, a framework for definitions and rules within other parts, including the idea that parts should be in pairs, with one part for description of the relevant user needs and preferences and the other part for matched resource descriptions;
• Part 2, the AccessForAll Personal Needs and Preferences (PNP) - originally 1EdTech AccLIP;
• Part 3, the AccessForAll Digital Resource Description (DRD) - originally 1EdTech AccMD.

In developing the ISO/IEC framework, the 1EdTech specifications were improved and extended, including the following changes:

• The preferences were made to stand-alone from 1EdTech LIP;
• The system was made more symmetrical in its treatment of resources and adaptations for them. The fact that an entity could be both a resource and an adaptation was made more explicit. This meant the dynamic structure of instances as they relate to resources would be different from that in AccLIP and AccMD;
• The structure of many elements was improved. For example, what in AccLIP/AccMD was represented as individual color combinations to avoid became in PNP/DRD a single boolean property representing that content depended on information coded only in terms of color (or a personal requirement for independence from that);
• The structure was flattened to remove deep branches, though it still uses a container-based structuring mechanism;
• Many definitions were improved.
• The ISO/IEC standard provides significant improvements for AccessForAll. 1EdTech released AccessForAll 2.0 [2], which adopts the changes recommended by the ISO editors, in late 2009 and early 2010.

4 Use Cases

The following use cases were included in the Charter document that established the AfA working group that has created version 3.0. Notes indicate whether each use case is supported by this draft, deferred for support in later drafts, or rejected as no longer appropriate to the aims of the working group. The names AccLIP and AccMD have been updated to PNP and DRD to match the current version's terminology.

Table 4.1 Discover and rank DRD-labeled resources Use Case

Use Case Title:	Discover and rank DRD-labeled resources
Status:	Supported
Use Case Local ID:	AccessForAllv2-UC1
Brief Description:	A search for resources that have some degree of match with a PNP instance produces multiple results. Each result is assigned a "degree of match" metric; how this is determined is implementation specific.
Level:	Summary
Actors:	Primary: LMS OR Resource Discovery engine communicating between LMS and Repository Service
	Secondary: PNP Service, DRD Service, Repository, LMS
Stakeholders & Interest:	Stakeholder: Learner, Training or Educational Delivery Service
	Interest: Selection of a resource to deliver
Notes:	Matching resources to a PNP instance can produce multiple matches with different degrees of imperfect match: some required features may match perfectly while others do not or are partially successful. Some preferredfeatures may also be present or not. A learner might in some scenarios select a resource to use from an indicated ranking of the matching. In other scenarios, an LMS may do that selection.

 

Table 4.2: Discover and rank resources labeled with a DRD in their suitability for delivery in a device context Use Case

Use Case Title:	Discover and rank resources labeled with a DRD in their suitability for delivery in a device context
Status	Partially supported; partially deferred
Use Case Local ID:	AccessForAllv2-UC2
Brief Description:	A search for resources that have some degree of match with a PNP instance AND some degree of match with a device context produces multiple results. Each result is assigned a "degree of match" metric; how this is determined is implementation specific.
Level:	Summary
Actors:	Primary: LMS OR Resource Discovery engine communicating between LMS and Repository Service.
	Secondary: PNP Service, DRD Service, Repository, LMS
Stakeholders & Interest:	Stakeholder: Learner, Training or Educational Delivery Service.
	Interest: Selection of a resource to deliver.
Notes:	Matching resources to a PNP instance and device context can produce multiple matches with different degrees of imperfect match: some required features may match perfectly while others do not or are partially successful. Some preferred features may also be present or not. A learner might in some scenarios select a resource to use from an indicated ranking of the matching. In other scenarios, an LMS may do that selection.

 

Table 4.3 Discovery and retrieval of alternate training content Use Case

Use Case Title:	Discovery and retrieval of alternate training content
Status:	Supported
Use Case Local ID:	AccessForAllv2-UC3
Brief Description:	A student is enrolled in a course where the final exam requires the completion of 3 out of 5 exercises. Learner logs into the VLE and requests the exercises. System compares the learner's PNP file with DRD data associated with the exercises. System reports that 4 of the 5 exercises are available in the requested alternate format, text only. Learner chooses 3 from the 4 accessible exercises and completes the exam using her requested format.
Level:	Summary
Actors:	Primary: Learner, VLE
	Secondary: Tool, PNP server
Stakeholders & Interest:	Stakeholder: Learner, Educational institution
	Interest: Learner: Completing assignments and progressing in school. Institution: providing quality education
Notes:	Relevant also to digital libraries, which may wish to present information to each user about what resources are accessible to them.

 

Table 4.4 Customization of information about a prescription Use Case

Use Case Title:	Customization of information about a prescription
Status:	Supported
Use Case Local ID:	AccessForAllv2-UC4
Brief Description:	A patient is diagnosed with a medical condition, such as diabetes. The patient is a non-English speaker and has a visual impairment. 1) Nurse prepares a prescription package, including information to manage the diagnosed condition. 2) Nurse creates a PNP profile for the patient specifying language (Tamil) and print requirement (large text). 3) Patient accesses the hospital IS; system retrieves her profile. 4) System prints the information in the requested language and large print format.
Level:	Summary
Actors:	Primary: Nurse, Patient
	Secondary: IS, PNP server
Stakeholders & Interest:	Stakeholder: Nurse, Patient, Clinic
	Interest: Nurse and Clinic: providing care for patient; Patient: understanding condition and receiving treatment

 

Table 4.5 Extreme instructional environments Use Case

Use Case Title:	Extreme instructional environments
Status:	Supported
Use Case Local ID:	AccessForAllv2-UC5
Brief Description:	An aircraft engine repair crew is learning a new procedure and must work hands-on with an engine in a noisy hanger. 1) Workers log in and indicate the hanger as the context. 2) System selects appropriate presentation format (text captions or alternate video content) based on context. 3) Workers use materials in this format.
Level:	Summary
Actors:	Primary: Aircraft maintenance workers
	Secondary: System, content developers
Stakeholders & Interest:	Stakeholder: Workers, Employer
	Interest: Workers: completing task; Employer: attaining high worker performance level

 

Table 4.6 Using DRD to declare that a resource is not accessible Use Case

Use Case Title:	Using DRD to declare that a resource is not accessible
Status:	Deferred
Use Case Local ID:	AccessForAllv2-UC6
Brief Description:	A distance learning provider is inventorying their educational resources to determine which are accessible in what ways. The staff creates AccMD records that detail whether a resource is known to be accessible or inaccessible.
Level:	Summary
Actors:	Staff member, DRD repository, LMS
Stakeholders & Interest:	Stakeholder: Distance learning provider
	Interest: Accurate information about accessibility of resources
Notes:	It is important to be able to record the results of accessibility checks, whether they are positive or negative. For example, DRD must be able to indicate if a resource has or does not have a flexible font size.

 

Table 4.7 Match DRD-described resources to learner context (PNP) and device context

Use Case Title:	Match DRD-described resources to learner context (PNP) and device context
Status:	Deferred; when implemented will include the entire delivery context: device capabilities, environment, and user preferences
Use Case Local ID:	AccessForAllv2-UC7
Brief Description:	A resource is selected for delivery matched to the PNP instance and matched to the device profile that applies. The matching may be successful, partial, or may fail for some specific resource set and context.
Level:	Summary
Actors:	Primary: LMS or matching engine
	Secondary: PNO Service, DRD Meta-data Service or data, Package Reader
Stakeholders & Interest:	Stakeholder: Learner, Training or Educational Delivery Service
	Interest: Successful matching for learner access to resources
Notes:	Matching resources to context requires that they fulfill the learner's functional requirements as described in their PNP and also that they are suitable for the device delivery context. Device delivery context vocabularies will be defined by third party organizations that target delivery of device-specific content such as the W3C, Open Social, or Open Mobile Alliance. We plan to integrate AfA with device delivery context vocabularies to augment the matching process in delivering context aware applications.

 

Table 4.8 Using DRD to declare that a resource is compliant with one or more accessibility standards to meet policy requirements Use Case

Use Case Title:	Using DRD to declare that a resource is compliant with one or more accessibility standards to meet policy requirements
Status:	Rejected
Use Case Local ID:	AccessForAllv2-UC8
Brief Description:	An administrator for a learning management system wishes to indicate that their educational resources, such as those provided through a web service, are compliant with one or more industry accessibility standards. An administrator provides standards compliance preferences which would be merged with a learner's preferences through PNP requiring that the provider deliver content compliant with required accessibility standards and supportive of the learner's preferences. During the resource discovery process, this information is matched to ensure the learner receives content that meets the standards requirements.
Level:	Summary
Actors:	Primary: Administrator, LMS
	Secondary: PNP service, DRD Service
Stakeholders & Interest:	Stakeholder: Distance learning provider, LMS provider, administrator
	Interest: Successful matching for learner access to resources with accessibility compliance standards
Notes:	Matching resources to context requires that they fulfill the learner's functional requirements as described in AccLIP. It is important that we define a standard naming convention for standards.

 

Table 4.9 Using DRD to declare that a resource is interoperabile with asssistive technologies Use Case

Use Case Title:	Using DRD to declare that a resource is interoperabile with asssistive technologies
Status	Replacement for AccessForAllv2-UC8
Use Case Local ID:	AccessForAllv3-UC1
Brief Description:	An administrator for a learning management system wishes to indicate that their educational resources, such as those provided through a web service, are interoperable with assistive technologies, meaning that the educational resources is designed such that the content supports accessibility services used by assistive technologies. A user configures their PNP to state that they want content delivered that supports assistive technologies. During the resource discovery process, this information is matched to ensure the learner receives content that meets this requirement. This preference could also be set globally by a system administrator.
Level:	Summary
Actors:	Primary: PNP, DRD services
	Secondary: Administrator services
Stakeholders & Interest:	Stakeholder: Distance learning provider, LMS provider, administrator
	Interest: Successful matching for learner access to resources with content interoperability compliance standards.
Notes:	Matching resources to context requires that they fulfill the learner's functional requirements as described in PNP. Compliance with a subset of WCAG2 addressing assistive technology interoperability fulfills the requirement for AT interoperability. The relevant WCAG2 checkpoints are: 1.1.1, 1.3.1, 1.3.2, 2.4.4, 3.1.1, 3.1.2, 3.3.2, 4.1.1, and 4.1.2.

5 AccessForAll Document Set

The set of documents that make up AfAv3 are listed in Table 5.1:

Table 5.1 List of AfAv3.0 documents

Document	Description
1EdTech AccessForAll Personal Needs and Preferences (PNP) v3.0 Information Model	Definition of the AfA information model for describing a person's requirements for accessibility.
1EdTech AccessForAll Digital Resource Description (DRD) v3.0 Information Model	Definition of the AfA information Model for describing a resource. This model is used to define meta data about a resource that will be used to match resources to a person's requirements for accessibility.
1EdTech AccessForAll 3.0 XSDs	The set of XSDs, including for the core, used to validate DRD and PNP XML instances.
1EdTech AccessForAll 3.0 Core Profiles	Definition of DRD and PNP Core Profiles for use with AfA.
1EdTech AccessForAll 3.0 Data Element Specification (DES)	Definition of the AfA Data Element Specifications. The DES consists of definitions for AfA Vocabulary data types and the application of the specific values to those data types.
1EdTech AccessForAll v3.0 Overview (this document)	An overview of AfAv3 covering the design goals, a history of previous work, and the document set that defines AfAv3.
1EdTech AccessForAll v3.0 Best Practices and Implementation Guide (BPIG)	Defines best practices for authors looking to apply AfAv3 to resources, preferences systems, and content matching systems. It also provides guidance on how to extend the AfA Model.

About This Document

Title: 1EdTech AccessForAll Specification Primer

Editor: Colin Smythe (1EdTech)

Co-chairs: Madeleine Rothberg (WGBH) and Richard Schwerdtfeger (IBM)

Version: 3.0

Version Date : 13 September 2012

Release : Final 1.0

Status: Public Draft

Summary: This document is a primer for the 1EdTech AccessForAll (AfA) specification. The AfA specification consists of information models for: (a) the common language to describing digital learning resources to facilitate matching of those resources to learners' accessibility needs and preferences; and (b) a description of a learner's functional abilities and the assistive technology or other non-standard technology in use as well as other user preferences.

Revision Information: This version supersedes the 1EdTech AccessForAll v2.0 specification.

Purpose: This document is made available for adoption by the public community at large.

Document Location: http://www.imsglobal.org/accessibility/

List of Contributors

The following individuals contributed to the development of this document:

Anastasia Cheetham OCAD University (Canada)

Andy Heath Axelrod AccessForAll (UK)

JoAnna Hunt Blackboard (USA)

Madeleine Rothberg WGBH (USA)

Richard Schwerdtfeger IBM (USA)

Colin Smythe 1EdTech (UK)

Revision History

Version No.	Release Date	Comments
Public Draft v1.0	13 September 2012	The first formal release of the Public Draft version of this document.

Index