| Title: | Working Group Term Proposal: Adaptability |
|---|---|
| Creator: | Dublin Core Accessibility Working Group |
| Date Issued: | 2004/8/28 |
| Identifier: | http://www.ozewai.org/prop-reqs-table2.html |
| Replaces: | None |
| Is Replaced By: | None |
| Latest Version: | http://www.ozewai.org/prop-reqs-table2.html |
| Status of Document: | Proposal to DCMI Usage Board |
| Description of Document: | This document presents a proposal from the Dublin Core Accessibility Working Group for a new element named "Adaptability" |
Name: http://purl.org/dc/terms/adaptability Label: Adaptability Definition: A statement describing characteristics of the resource that affect how it can be adapted so it can be perceived, understood or interacted with by users Comment: An Adaptability description might be used to match a (digital or physical) resource to a description of user or user agent needs and preferences.
Examples:
- The following example is extracted from the IMS documentation:
Scenario:
An HTML file contains text and an embedded Flash animation (visual only, no sound). There is also alternative textual content to the animation defined by accessibility meta-data as an equivalentResource containing alternativesToVisual properties. A user profile has a content element with the alternativesToVisual preference set and wishes to interact with the aggregate file. The system applies the matching test on the aggregate HTML resource and sees it has a hasVisual property with a value of true. Subsequently it sees the animation has an equivalentResource with an alternativesToVisual which matches the user's content preferences. At this point the system replaces the animation with the text alternative. The system modifies the aggregate resource by changing its reference to the animation to a reference to text, i.e., the embedded Flash animation's <object> tag is replaced with a <p> tag containing the alternative textual content.
Other examples
Type of term: Element Term qualified: None Why needed: The element will be significant in the case of a user with special needs such as an inability to use particular sensory modalities at the time of delivery, or who uses a particular devie that has limitations such as a mobile device with a very small screen. Some users have detailed requirements such as that they cannot use resources that use redand green to convey informative content. Such users and their agents will find the descriptions in the term useful either to allow them to confirm or reject presentation of the resource or to discover substitute content to replace or augment content that is a problem.
Note that sometimes what is inaccessible is only a small part of what might be thought of as a composite object, such as an image in a web page. This object in its original form is known as a primary object and may within itself contain other forms of the same object, known as alternative objects. Where there is an alternative object that is not part of the primary object, it is associated with the primary object as an equivalent object but has separate metadata as it is a separate object.
There can be little doubt that metadata that allows a user to find a resource that is accessible to them is always a high priority. The values of the proposed element can be critical to a user's access to a resource as it wil enable the adaptability of the resource to their needs or the needs of their access devices.
Working Group/community support: The proposed element has been developed over several years. The range of problems that a resource may have for users was first analysed and described. This process was widely advertised and subjected to public debate and comment by the collaborating group, the IMS Global Learning Consortium. Dublin Core Accessibility Working Group members were kept informed of this process and invited to comment on the developments and drafts, and they did. Discussion took place on a number of discussion lists, primarily the IMS coments list. All comments sent to IMS were formally processed. The proposed element is now undergoing more scrutiny in the ISO JTC1 process where it has reached the fisrst draft stage.
To review the discussion archives of the Accessibility Working Group, see http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A0=dc-accessibility.
The proposed element is a reflection of the user profile noted above. It also has been developed by an international collaborative team containing many DC Working Group members and in full knowledge of its development being posted regularly to the DC Accessibility Working Group. IMS again managed the process of advertising the profile, soliciting and managing comments and issues that were raised.
Proposed status: Recommended Related DCMI terms: The possibility of capturing and recording necessary metadata relevant to adaptability to support accessibility has been considered over several years. Although the DCMES has a number of elements and element refinements that individually might be suitable for inclusion of the information being proposed, this approach was considered by the Working Group and relevant communities and rejected.
Related non-DCMI terms: IMS AccLIP and AccMD (AccessibilityForAll User Profile and Accessibility Metadata)
These two specifications are those worked on by DC Accessibility WG members as well as IMS participants. They provide the information model and recommendations for encoding of the information but they are to be used within IMS Content packaging. This was always understood as different from their being DC used within a DC term and they were specifically developed with their DC use in mind.
Impact on applications: Minimal. Since current DC-based applications provide no conflicting means of unambiguously referencing accessibility profiles, impact on those applications would be minimal. About the proposers: Scope of DC Accessibility Working Group:
The DC Accessibility Working Group has been engaged with the issue of developing metadata for accessibility since its inception. Members of the Working Group are involved in a range of accessibility activities in a range of countries and have endeavoured to work collaboratively across all communities.
Aims:
To maximise opportunities for accessibility for all users where accessibility is defined as the matching of resources in terms of control, display and content to user needs and preferences. Specifically, this will cater for the needs and preferences of those with disabilities.
Brief History:
Current status: A collaborative exercise was initiated in which the DC Accessibility Working Group worked with others to discover the best way to specify accessibility metadata. The IMS Accessibility Working Group, as part of the IMS Global Learning Consortium, hosted the work and will provide the ongoing support and publication of the relevant specifications on behalf of the collaborators who specifically include the DCMI. The IMS Accessibility Working Group has proposed the element to the IMS Technical Board and it has been accepted as an IMS recommendation.
Pointer to IMS Reports, Documents and Discussion Archives: http://www.imsproject.org/accessibility.