Introduction
The development of a match set of resource metadata and student functional profiles was recognised in the late 1990s as the best way of achieving automated personalisation for accessibility in any Web based system but particularly an Virtual Learning Environment (VLE) or Learning Management System (LMS). In 2000 and accessibility working group was established within IMS Global Inc. to work on this. I was a member of that group and have continued to be associated with this work. In September 2013 IMS published a public draft of the specification of AccessForAll 3.0 stating:
“The Accessibility project group has released a public draft of IMS Access for All v3.0. The public draft is provided so that implementors have the opportunity to begin work and provide comments before production of the final specification.”
This blog post outlines the specification of part of this, the part that relates to user profiles known in IMS as PNP (Personal Needs and Preferences). Note – no details are given here of the corresponding resource metadata specification known as the DRD (Digital Resource Description). For authoritative details please refer to the IMS publications available at:
http://www.imsglobal.org/accessibility/
Overview of the IMS AccessForAll 3.0 PNP Specification
To quote from the primer to the specification:
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 IMS AfA3.0 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.
The Data Elements
The specification is for a “core” specification, but this is designed to be extensible where this is needed for specific implementations. Using extensions to the core will impact on interoperability with other system components or external systems; thus it is an important design decision.
The Core Profile of the IMS Global AfA PNP v3.0 specification is defined in Table 4.1. [Taken from IMS Global Access for All (AfA) Core Profiles, Version 3.0 Specification, Public Draft 1.0]
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. |
Figure 1: data elements in AccessForAll 3.0 PNP Core Profile
AfA3.0 Statements – a functional model of disability
Now in the existing data at the OU we can use in Learning Analytics we have , which is a binary that just indicates that the student has, or has not, declared a disability. Then there is . There are 12 categories of disability used to collect data for national reporting to the Higher Education Statistical Agency (HESA) which constitute the values of ; these are:
- Sight
- Hearing
- Mobility
- Manual skills
- Speech
- Specific learning difficulty e.g. dyslexia
- Mental health
- Personal care
- Fatigue/pain
- Other
- Unseen disability e.g. diabetes, epilepsy, asthma
- Autistic Spectrum Disorder
The AccessForAll 3.0 specification by contrast allows machine-readable statements like the following to be stored in a user profile database:
- Student ‘x’ has a Access Mode Requirement of textual alternatives to graphics;
[c.f. has a sight impairment as would be stated in the above categorisation]
In other words AccessForAll 3.0 allows a functional model rather than a medical model of disabilities to be constructed. This is very important for the Accessibility use case for Learning Analytics and will enable refinements in the Support use case.
Applications in Learning Analytics
Previous blog posts on Learning Analytics form a useful introduction to this section – see:
- https://martyncooper.wordpress.com/2012/10/12/use-case-scenarios-learning-analytics-disabled-students-accessibility/
- https://martyncooper.wordpress.com/2012/10/16/la4stem-project-descriptio/
- https://martyncooper.wordpress.com/2013/01/09/learning-analytics-for-supporting-disabled-students-and-identifying-accessibility-deficits/
- https://martyncooper.wordpress.com/2014/01/22/perspectives-on-the-student-as-e-learner/
- https://martyncooper.wordpress.com/2014/02/17/ethics-learning-analytics-and-disability/
- https://martyncooper.wordpress.com/2014/03/14/internal-project-proposal-learning-analytics-for-disabled-students-in-stem-subjects/
- https://martyncooper.wordpress.com/2014/03/16/jisc-digital-festival-2014-notes-day1-cont/
What is desirable in the envisaged Learning Analytics applications is a user profile that can describe how each individual user interacts with their computer (or other device) and the Web environment. This will enable the Accessibility use case to be implemented meaningfully. This follows from the fact that if users with similar profiles encounter access problems with the same learning activity (object) then there is a high degree of probability that it has accessibility deficits.
It will also be of benefit in the Support use case as users with similar needs can be targeted with specific support for them. E.g. before screen reader users undertake a particular activity they could be directed towards a help page.
Now is AccessForAll 3.0, in its core specification sufficient for this? Probably not, extensions will be required to give the level of detailed information sort but these extensions are allowed in the specification. However, the specification allows for such extensions and their devising although application specific could be fed back into later versions of AccessForAll as recognised extensions that other applications could use and thus be interoperable.
UML Diagram of a Learning Analytics System Deploying AccessForAll
Figure 2: UML diagram of a future e-learning system incorporating Learning Analytics and Personalisation.
The above UML diagram shows a future system integrating a Virtual Learning Environment (VLE), Analytics Engine, Personalisation Engine. The functional user database at the bottom of the diagram could be based on a data model itself based on AccessForAll 3.0 (with or without extensions).
In summary, when a student requests a learning resource from the VLE the Personalisation Engine determines what format of the resource best suits that user based on the data stored in the functional user database. The Analytics Engine records all the student’s interactions with the VLE and the resultant system responses. In fact the only elements on the above systems diagram not already in place are the Personalisation Engine and the Functional User Database towards the bottom of the diagram.
Conclusions
So AccessForAll 3.0 holds enormous promise for being able to implement Learning Analytics approaches, for both Support and Accessibility use cases, that incorporate detailed user profiles and has many advantaged over the medical model based classification . Now it is time to do some implementation and validate the approach with end users and other stakeholders.
— end —