innovation in metadata design, implementation & best practices

Accessibility Working Group - ResponseToUsageBoard

Accessibility Working Group

> ResponseToUsageBoard









Aim of this doc is to:

  • briefly characterize and point to current work or position papers,

  • summarize the reactions of WG members to the decision text, and

  • summarize in a paragraph or so the discussion on Adaptation versus Accessibility.

Usage Board Decision Components with Responses

Changing the name of the element from "Accessibility" to "Adaptation"

The scope of the proposed element was originally everything to do with accessibility. In the light of the Usage Board's comments, and other considerations, it was decided to narrow the scope of the new element to be one that dealt only with the major aspect that was not already covered in Dublin Core, the adaptation characteristics of the resource, and to use it and re-use other Dublin Core elements in an accessibility application profile.

This change allowed the structure of the values for the new element to be significantly simplified and also allowed it to be more easily generalised for other applications, such as for device independence uses to do with mobility, and flexibility for e-learning. It also meant the name could be changed to disambiguate the element with access which seemed to cause some people problems. Instead of singling out accessibility, it acts to mainstream accessibility issues, satisfying another issue that caused concern to some.

Changing the definition of the element

The definition of the proposed 'accessibility' term was:

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.

With a narrower scope element about adaptation characteristics, the current proposal is for:

A statement describing characteristics of the resource that affect how it can be sensed, understood, or interacted with by users or agents.

There has been significant discussion of these changes. A couple of people commented on the DC-Accessibility mailing list that they were not sure about the changes, including one who was on the Task Group, but there has been a lot of informal discussion in the accessibility community in general and within the task group and the consensus is that adaptation is a better term and the narrow scope is more useful than the original wider 'accessibility'. All the work has been exposed on the DC-Accessibility Wiki for some time and it has been presented in major fora such as the W3C annual conference, accessibility conferences, standards organisations including ISO JTC1 SC36, and more.

UB members considered it necessary to put the changed proposal through the standard procedure of discussion and approval by the wider Accessibility/Adaptation community, along with a public comment period, before it could be approved by the Usage Board. This has been done. There was also discussion about a new working group for adaptation but that proposal has been withdrawn.

Relationship between new element and DC Abstract Model

The Usage Board questioned how an Adaptation element fits into the DCMI Abstract Model. Work on this was undertaken by the Task group who have developed an abstract model for the new element and clarified how it complies with the DC Abstract Model. See AccessForAllFramework.

Specific concerns of the Usage Board with respect to the abstract model:

  • As proposed, the element is intended to hold several property-value pairs within a value string for a single element.

The need for structured values has been avoided with the new proposal.

  • A basic requirement was pointing from a Dublin Core description to an "alternative description" of the same resource.

This has been avoided by the adoption of the narrower scope for the elemetn and the re-use of the existing relation element.

  • The set of properties needed to describe a resource from the standpoint of accessibility seemed to overlap with the set of properties needed to describe a resource using Dublin Core itself (e.g., Type, Format, Language, and Relation). Accordingly, the alternative, accessibility-oriented description pointed to from a Dublin Core description could perhaps itself be an application profile of Dublin Core.

With the exception of the new narrow element, this is true as so this approach has been adopted. The new element provides information about a resource which is not appropriately expressed in any existing element. The final application profile is not yet developed, but there has been considerable work to ensure that the new term is necessary and if so, what the application profile would look like. This work is reported at AccessForAllApplicationProfile.

RefreshCache for this page (cached 2005-09-02 05:58:27)

EditText of this page (last edited 2005-09-01 12:59:32 by DavidWeinkauf)