1 Introduction
1.1 Access For All Overview
The Access For All 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 IMS Global Access For All Personal Needs and Preferences (PNP) v3.0 [AfAPNP, 12a] specification;
- Digital learning resources. This is represented using the IMS Global Access For All Digital Resource Description (DRD) v3.0 [AfADRD, 12a] specification.
To facilitate industry adoption of Access for All, 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 Access for All |
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 Access For All
AfA DRD Access for All Digital Resource Description
AfA PNP Access for All Personal Needs & Preferences
API Application Programming Interface
DRD Digital Resource Description
IMS Global IMS Global Learning 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] IMS Global Access For All Best Practices & Implementation Guide v3.0, R.Schwerdtfeger, M.Rothberg and C.Smythe, Public Draft, IMS Global Inc., September 2012.
[AfADES, 12] IMS Global Access For All Data Element Specification v3.0, R.Schwerdtfeger, M.Rothberg and C.Smythe, Public Draft, IMS Global Inc., September 2012.
[AfADRD, 12a] IMS Global Access For All Digital Resource Description (DRD) Information Model v3.0, R.Schwerdtfeger, M.Rothberg and C.Smythe, Public Draft Release, IMS Global Inc., September 2012.
[AfADRD, 12b] IMS Global Access For All Digital Resource Description (DRD) XSD Binding v3.0, R.Schwerdtfeger, M.Rothberg and C.Smythe, Public Draft, IMS Global Inc., September 2012.
[AfAPNP, 12a] IMS Global Access For All Personal Needs & Preferences (PNP) Information Model v3.0, R.Schwerdtfeger, M.Rothberg and C.Smythe, Public Draft, IMS Global Inc., September 2012.
[AfAPNP, 12b] IMS Global Access For All Personal Needs & Preferences (PNP) XSD Binding v3.0, R.Schwerdtfeger, M.Rothberg and C.Smythe, Public Draft, IMS Global Inc., September 2012.
2 Profiling Access for All
This is the Core Profiles definition for the IMS Global Access for All 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:
- Identifying the common set of data model features that every implementation must support;
- 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 IMS Global AfA DRD v3.0 specification is defined in Table 3.1.
|
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 IMS Global AfA PNP v3.0 specification is defined in Table 4.1.
|
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 IMS 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 IMS 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
IMS Access for All 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 Access for All 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 IMS, 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 IMS 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 Access for All 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
IMS 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 IMS 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 Access for All 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. ]]