1                  Introduction

1.1            AccessForAll Overview

The AccessForAll Specification (AfA) 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, 12a] specification;
• Digital learning resources. This is represented using the 1EdTech AccessForAll Digital Resource Description (DRD) v3.0 [AfADRD, 12a] specification.

To facilitate industry adoption of AccessForAll, Core Profiles for the DRD and PNP have been identified.  Mainstream implementations, such as web mash-ups, may choose to only support the Core Profiles, whereas a learning management system may choose to support the full specifications.  All systems must support at least the DRD and/or PNP Core Profile.  This document contains the definition of the AfA Core Profiles.

1.2            Scope and Context

This document must be read in conjunction with the AfA v3.0 DRD [AfADRD, 12a] [AfADRD, 12b] and AfA v3.0 PNP [AfAPNP, 12a] [AfAPNP, 12b] specification documents.  Those documents contain the details of the various attributes and classes.  This document identifies the components of the Core Profile and the differences to the full specification only.

1.3            Structure of this Document

The structure of this document is:

2.     Profiling AccessForAll	An overview of the Core Profiles defined for AfA v3.0;
3.     Digital Resource Description Core Profile	The AfA v3.0 DRD Core Profile;
4.     Personal Needs & Preferences Core Profile	The AfA v3.0 PNP Core Profile;
5.     Bindings of the Core Profile	Describes the mapping of the information model descriptions to the XSD bindings;
6.     Best Practices	Best practice recommendations for the use of the Core Profiles;
7.     Conformance & Compliance	How systems and instances claim conformance to the DRD and PNP parts of the AfA Core Profile.

1.4            Nomenclature

AfA                        AccessForAll

AfA DRD              AccessForAll Digital Resource Description

AfA PNP               AccessForAll Personal Needs & Preferences

API                         Application Programming Interface

DRD                       Digital Resource Description

1EdTech            1EdTech Consortium Inc.

ISO                         International Standards Organization

PNP                        Personal Needs & Preferences

W3C                       World Wide Web Consortium

WAI                       Web Accessibility Initiative

WCAG                   Web Content Accessibility Guidelines

XML                       Extensible Mark-up Language

XSD                        XML Schema Definition

1.5            References

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

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

[AfADRD, 12a]             1EdTech AccessForAll Digital Resource Description (DRD) Information Model v3.0, R.Schwerdtfeger, M.Rothberg and C.Smythe, Public Draft Release, 1EdTech Inc., September 2012.

[AfADRD, 12b]            1EdTech AccessForAll Digital Resource Description (DRD) XSD Binding v3.0, R.Schwerdtfeger, M.Rothberg and C.Smythe, Public Draft, 1EdTech Inc., September 2012.

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

[AfAPNP, 12b]             1EdTech AccessForAll Personal Needs & Preferences (PNP) XSD Binding v3.0, R.Schwerdtfeger, M.Rothberg and C.Smythe, Public Draft, 1EdTech Inc., September 2012.

 

2                  Profiling AccessForAll

This is the Core Profiles definition for the 1EdTech AccessForAll v3.0 specification.  The aim of the Core Profiles is to define the simplest subset of the full AfA specification that is required to support the exchange of key DRD and PNP information. The Core Profiles consists of two profiles: one of the DRD and one of the PNP.  The two profiles are described in Section 3.  The Profiles have been produced by:

1. Identifying the common set of data model features that every implementation must support;
2. Refining the vocabularies supported in the data models.

The key for the colour coding and special symbols in the Table 3.1 and 3.2 is:

• White – the original feature of the specification is adopted and unchanged (the ID column contains only a number);
• Red – a feature in the base specification is now prohibited i.e. an instance must NOT use it (the ID column has dashes before and after the number);
• Yellow – a feature in the base specification has been further constrained (the ID column has parenthesis around the number).

Conformance to the Core Profiles is described in Section 7.

3                  Digital Resource Description Core Profile

The Core Profile of the 1EdTech AfA DRD v3.0 specification is defined in Table 3.1.

Table 3.1 Core Profile for an AfA DRD v3.0 instance.

ID	Element/Attribute Name	Spec Multiplicity	Profile Multiplicity	Profile Commentary
Root	accessForAllResource	1		Each AfA DRD v3.0 instance file will contain one and only one accessForAllResource.
(1)	accessMode	0..*		The following terms are not permitted as a value for ‘accessMode’: itemSize, olfactory, orientation and position.
2	accessModeAdapted	0..*
3	adaptationType	0..*
4	atInteroperable	0..1
5	controlFlexibility	0..*
6	displayTransformability	0..*
7	educationalComplexityOfAdaptation	0..1
8	hasAdaptation	0..*
9	hazard	0..*
10	isAdaptationOf	0..*
11	languageOfAdaptation	0..*
-12-	adaptationDetail	0..*	Prohibited
-13-	adaptationMediaType	0..*	Prohibited
-14-	apiInteroperable	0..*	Prohibited
-15-	educationalLevelOfAdaptation	0..*	Prohibited
-16-	isFullAdaptationOf	0..*	Prohibited
-17-	isPartialAdaptationOf	0..*	Prohibited
-18-	extensions	0..*	Prohibited	Extensions are not supported.

 

4                  Personal Needs & Preferences Core Profile

The Core Profile of the 1EdTech AfA PNP v3.0 specification is defined in Table 4.1.

Table 4.1 Core Profile for an AfA PNP v3.0 instance.

ID	Element/Attribute Name	Spec M’plicity	Profile M’plicity	Profile Commentary
Root	accessForAllUser	1		Each AfA PNP v3.0 instance file will contain one and only one accessForAllUser.
1	accessModeRequired	0..*
(1.1)	existingAccessMode	1		The following vocabulary terms are not permitted: itemSize, olfactory, orientation and position.
(1.2)	adaptationRequest	1
2	adaptationTypeRequired	0..*
(2.1)	existingAccessMode	1		The following vocabulary terms are not permitted: itemSize, olfactory, orientation and position.
2.2	adaptationRequest	1
3	atInteroperable	0..1
4	educationalComplexityOfAdaptation	0..1
5	hazardAvoidance	0..*
6	inputRequirements	0..1
7	languageOfAdaptation	0..*
8	languageOfInterface	0..*
-9-	adaptationDetailRequired	0..*	Prohibited
-9.1-	existingAccessMode	1	Prohibited
-9.2-	adaptationRequest	1	Prohibited
-10-	adaptationMediaRequired	0..*	Prohibited
-10.1-	existingAccessMode	1	Prohibited
-10.2-	adaptationRequest	1	Prohibited
-11-	educationalLevelOfAdaptation	0..*	Prohibited
-12-	extensions	0..*	Prohibited	Extensions not supported.

5                  Bindings of the Core Profiles

The Platform Specific Models (PSM) for the Core Profiles are shown in Figures 5.1 and 5.1.  The Core Profiles XSDs are:

• AfA DRD – imsafadrdv3p0_corev1p0.xsd;
• AfA PNP – imsafapnpv3p0_corev1p0.xsd.

 

Figure 5.1 PSM for the AfA DRD Core Profile.

 

Figure 5.2 PSM for the AfA PNP Core Profile.

6                  Best Practices

The Best Practices for the Core Profiles follow those as per the full specification [AFABPIG, 12].  The differences are:

• The use of extension elements is NOT permitted;
• Extension of the vocabularies is NOT permitted;
• Only the subset of elements in the Core Profiles are available for use.

7                  Conformance & Compliance

Conformance to the Core Profile has the following perspectives:

• Conformance of an XML instance i.e. the file containing the DRD or PNP information – an instance will contain either DRD or PNP information i.e. an instance cannot be a mixture of the DRD and PNP information.  An instance may contain one, some or all of the corresponding elements;
• Conformance of a system that processes an XML instance – a single system may process only DRD or PNP data or it may support both specifications.  A system can:
  • Import an XML instance – read an instance and store the data appropriately;
  • Export an XML instance – write an instance;
  • Round-trip an instance i.e. import and then export or export and then import;
  • Render an instance – use the information to appropriately control the use/display of the relevant information.
• Systems and instances may also be compliant to the Full Specification.  The set of possible levels of compliance are to the:
  • Core Profile – the information detailed in this document for AfA DRD and AfA PNP;
  • Full Specification (without extensions) – support for the full set of elements and vocabularies;
  • Full Specification (with extensions)  – support for the full set of elements and vocabularies plus addition of extension element or changes to the default vocabularies.
• Key conformance conditions are:
  • A compliant XML instance may contain some or all of the elements defined in the Core Profile, and must comply with the multiplicity and vocabulary requirements (an instance MUST contain at least one AfA object for compliance i.e. a null file cannot be compliant).  The 1EdTech AfA Online Validator will determine whether or not an instance is compliant;
  • Any compliant system MUST support the full Core Profile of the relevant specifications i.e. it must process, appropriately, an instance that contains all of the elements defined in the Core Profile.  Furthermore, multiplicity and vocabulary requirements must be upheld and 1EdTech will supply a set of reference test instances that will be used to help determine if a system is appropriately compliant (other manual and observation-based testing will also be undertaken);
  • To “process appropriately” means that conformant systems which do not support some of the capabilities described by the specification are not required to respond to those elements or values they do not support; however they must preserve those elements and values when importing, editing, and exporting instances.

7.1            Conformance Test Process

1EdTech AccessForAll conformance enables interoperability of the accessibility information. As the use of AfA grows in use, the need to both broaden and narrow the scope of the specification's functionality will arise. The AccessForAll Accredited Profile Management Group (AfA-APMG) will take responsibility for the maintenance and revision of the specification.

While the specification’s original developers decided on what they believed to be a minimum set of criteria that would enable interoperability between systems, new experience of adoption may require changes in these criteria.   As more vendors and individuals use AfA and as new tools are developed that use AfA, these tools may not require all of AfA functionality.  In 1EdTech, our goal is to enable interoperability and allow the broadest use of our standards while still maintaining the integrity of the specification and the use of 1EdTech standards at the core of tools. 

The AfA-AMPG is responsible for defining the criteria needed to achieve AfA conformance.  There are different processes and/or tests to achieve AccessForAll Compliance for different types of tools:

• AfA instances;
• Read Tools – these are tools that read in instances;
• Write Tools – these are tools that export or create instances.

Up-to-date material on conformance can be found at: http://www.imsglobal.org/developers/alliance/conformance.cfm.

 

 

[[ ED NOTE: The AfA APMG will be established at Final Release. ]]

 

 

7.2            AfA System Conformance

From a tool perspective, the AfA specification defines:

• The syntax for AfA instances which a platform must be able to successfully import;
• A set of features that the tool must be capable of supporting at runtime.

The criteria for system compliance are:

• Successful import of compliant AfA instances without error;
• Correct runtime delivery of the content and features dependent on the settings supplied in an AfA instance.

No runtime model is defined for AfA, this is left as an issue for the implementer and therefore runtime usage will differ across platforms.

A test data set of AfA instances has been constructed for evaluating system compliance as is described below.  System vendors are required to assess compliance by self-inspection using the available test data set corresponding to the version of AfA that they have implemented.

7.3            AfA Instance Compliance

To be deemed to comply with the AfA specification, an instance file must:

• Successfully validate against the AfA online validator;
• Satisfy all of the additional mandatory constraints.

7.3.1           Testing Process for AfA Instances

Access the online validator (http://validator.imsglobal.org/afa/) if you are testing an AfA instance.  Choose which Core Profile you would like to test against i.e. DRD or PNP.  Upload your file and the test will run.  A report on any detected errors will be supplied.

7.3.2           Scope of AfA File Tests

1EdTech provides an online AfA Instance validation tool.  The tool is located at: http://validator.imsglobal.org/afa/.  This test system is made available free-of-charge so that you can perform your own testing of AfA files for conformance with the 1EdTech AfA v3.0 specification.  The validator will:

• Do XML validation of all XML files;
• Do Schematron validation of the instance to enforce additional constraints not enforced through XML Schema validation alone.

7.3.3           Limitations of Instance Testing

The testing tool will not apply run-time tests to the AfA file content.

7.4            Test Data Set

A test data set of cartridges is available to members of the AccessForAll Alliance to enable self-testing of systems for AfA compliance. The test data set is comprised of four sets of example instances:

• Valid AfA DRD instances (containing only features in the Core Profile) to exercise the scope of the features supported in the AfA DRD;
• AfA DRD instances with known errors to provide coverage of errors liable to occur in instances;
• Valid AfA PNP instances (containing only features in the Core Profile) to exercise the scope of the features supported in the AfA PNP;
• AfA PNP instances with known errors to provide coverage of errors liable to occur in instances.

 

[[ ED NOTE: This test set will be produced before Final Release. ]]