|Status:||This working group is currently active.|
To provide a forum to:
1. The AccessForAll information model was developed in 2003 by IMS Global Project with participants from DC Accessibility and other organisations. The AccessForAll profile lists user preferences including those related to the range of devices that adapt user agents for people with disabilities. For instance, the user of a hand-held device will require appropriate formatting of content and users of screen-readers will need text-modality content. In fact, the profile describes three types of requirements: controls, displays and content requirements.
2. The accessibility application profile should be reflected in a resource profile that supports discovery of resources that accommodate the profile. This activity is under way in collaboration with members of other communities working on accessibility. In particular, the following W3C working groups: Web Content Accessibility Guidelines, Authoring Tools Accessibility Guidelines and Composite Capabilities/Personal Preferences and Device Independence; CEN-ISSS. The work is hosted by the IMS Global project who are providing technical infrastructure, telecommunications for weekly meetings, staff support and whose recommendation processes will be followed in order to deliver the profile in early 2004 for public use. The IMS Global Project will own the copyright and maintain the recommendation and it will be available licence free. The full charter for the activity is available at http://www.imsproject.org/accessibility The charter for this collaborative work includes the development of a suitable DC application profile for accessibility.
The Inclusive Learning Exchange (TILE) at the Adaptive Technology Research Center at the University of Toronto exemplifies the work to be undertaken. TILE ensures that if a user has an accessibility requirement, such as that the resource be suitable for use with a screen reader, captions, transcripts and other text aids will be discovered at the time of original discovery requests, and the appropriate formats of the content will be made available to the user.
This work was due to be completed by March 2004 and, although late, should be ready soon after that.
The first face-to-face meeting was a Special Session at DC 2003 in Seattle in October 2003. The next F2F meeting was held in Orlando, January 15-16, 2004. A F2F meeting was held in Zurich, February 10,11, 2004.
The information model for Accessibility Metadata is in an advanced draft form and application profiles for implementation in association with DC, IMS, SCORM and other specifications and standards is under way.
There are weekly teleconferences. In addition, several other face-to-face meetings will be scheduled for the period.
The AccessForAll Metadata Working Group maintains an open archive and public comment is invited on all development. The IMS formal public comment process will be used when draft recommendation stage is reached. There is an open mailing list for participants who either want to comment or to join the task force: see http://www.imsproject.org/accessibility/ or contact the group.
The Chair of the DC Accessibility Working Group is Liddy Nevile. The Co-Chairs of the AccessForAll Metadata Working Group are Jutta Treviranus and Anthony Roberts.
The DC Accessibility Working Group mailing list is: http://www.jiscmail.ac.uk/lists/dc-accessibility.html
2004-12-13, The next F2F Working Group meeting for DC:Accessibility will be held in melbourne in the we February 7 - 11 2005. Those interested in attending in person or via telecommunications should contact Liddy Nevile.
There is no need for accessibility metadata to be dealt with in isolation but there is a great need for some accessibility metadata to be included in regular application profiles. With this in mind, it seems like a good idea to specify the relevant terms and their use so that it is easy for users of Dublin Core™ to include accessibility metadata in their main application profiles. In some cases, this is only a matter of specifying a format or qualifier, in one case it suggests a new element, DC:ACCESSIBILITY. Some of the application profile seems to be available already, and this part of it should be implemented as soon as possible to support accessibility (see below). Other bits will require additional work, and this is the main work for 2004.
In particular, work is under way on the development of an accessibility profile for content (see above). Consideration of the use of the W3C Evaluation and Report Language (EARL) is likely to become an activity later in 2004 (see below).
Conformance with standards is an issue in a number of contexts. There is every reason why the existing dc:relation:conforms-to element is appropriate and useful for this. It should be used to record the conformance (or level of conformance), the standard that is being conformed with, and when conformance was tested. This is, thus, an element in which there is a declaration of conformance. A qualifier, the sub-element dc:relation:conforms-to:certification could be used to say who is making the declaration and how it was tested, the certification part of the statement.
An EARL ( http://www.w3.org/WAI/ER/#earl) statement can be used to contain all of this information. This is a very useful way to encode the information. EARL statements may not be popular in this context because they are not easily accessible to humans (they are in XML). This problem is overcome if a stylesheet is used to render the EARL statement accessible to humans.
Often, inaccessible content needs to be augmented or replaced by something else. It is possible to specify alternative content using the relation element, but this is not always going to work as the alternative is often created after the original and while it might be related back to the original, the original may not have a pointer to the newly created alternative.
A second problem occurs when the user wants to know if it is alternative or equivalent content. Of course, it is also important to know if the alternative content will be more accessible for this user.
So where content is to be managed automatically, clear paths to accessible content need to be identified. This problem can be dealt with in the short term with the dc:relation element but work is needed to develop a more useful solution for the longer term. The established DC elements, dc:relation:has-format, dc;relation:is-version-of and dc:relation:replaces can be used where they are relevant.
A really good solution to the problem of how to match users to suitable resources is not yet available. Work on this is proposed for the coming year (see below).
A number of major accessibility communities are working with the need for a user profile that specifies to what resource discovery should be matched, for instance. The AccessForAll user profile takes into account content, display and control needs. Work is currently underway to match this profile with a resource profile.
When the initial content is not accessible to a user, there is a need to discover alternative content, if possible. In the use of DC elements, implementers need to be careful if content is of a genre that is incompatible with its format. For example, some content may be meant to be read, but be presented as an image. This happens often with mathematical symbols, for instance. In this case, the content should be marked as type=text and format=image so the mismatch can be identified. Applications can then look for content where type and format match.
The accessibility metadata world is as widely distributed as the issues. In an attempt to discover who is doing what, a 'roadmap' exercise has been undertaken. There is a form for submissions ( http://www.dc-anz.org/access-roadmap/roadmap-form.html) and the results of the reports are available at http://www.dc-anz.org/access-roadmap/roadmap-db.html Anyone with an interest in this roadmap, or something to contribute, is encouraged to visit the roadmap activity and provide what information they can. It is hoped that this road map will make it easier for people working in the area to link up with others and, ultimately, for us to achieve a more unified result.
Two special sessions were held at the DC 2003 Conference: see http://www.ischool.washington.edu/dc2003/accessibility.html
There is a report of this meeting at http://www.dc-anz.org/access-roadmap/
* Some very general questions were raised during the meeting:
Three Meeting Recommendations led to the meeting and work reported above in relation to the roadmap. A full report of the DC 2002 meeting is available.
To join or leave:
There have been several activities of relevance to this Working Group. (If others know of relevant activities, please let us know!)
Members of the Dublin Core™ Community who met in Tokyo at DC2001 Workshop considered the need for DCMI to demonstrate its concern for accessibility of Web content by exemplifying good accessibility practices and providing a context for others who also take time to make their content accessible.