DC.Accessibility Interest Group Workshop Report

DC 2002Florence, October, 2002

Aims of Workshop/Meetings

Agenda

• Review progress
• DC straw man
• a WG charter?
• Participation
• Funding
• Teleconferences? F2F?

Meetings of Interest Group members took place on a number of occasions, starting the first day and continuing until the last day.

Participation

There were a number of interested people and the following organisations, at least, were represented at the meetings:

• W3C
• INCITS
• IMS Global Project

Unfortunately, and without it being realised initially, some attendees were in the wrong place!

One person reported that she thought we were, at last, making the Dublin Core™ accessible, simple. Others were concerned with what turned out to be rights of access rather than 'accessibility' as the Interest Group has defined it - according to the W3C definition: access for all to the content of the web, by designing and implementing for device independence, including the devices used by people with disabilities. This confusion points to one of the problems with this field of endeavour!

Review of Progress

The original aim of the Interest Group was to provide a forum to:

1. consider the role of advice to DCMI about the accessibility of its products - web site, tools and recommendations - and report on a strategy for ensuring that DC recommendations and information are accessible in the future;
2. determine the relationship between accessibility (evaluation and repair) descriptions and DC descriptions - and report on an appropriate way to represent accessibility information in DC, and
3. promote the use of Dublin Core™ in identifying accessible resources as part of resource discovery - and conduct a half day workshop at WWW 2002 in conjunction with other accessibility promotion groups.

For those not working on accessibility issues, it is often hard to know why it is important or why it is not just a simple problem. A poster for the DC 2002 Conference may help in this respect.

The DC.Accessibility Interest Group members have worked in many contexts during the last year and some of the original questions have been refined. The meeting in Florence, however, attempted to first review the original goals.

1. Making DC work accessible

There has been little progress in this regard by the Interest Group. A resolution to work on the accessibility of the Dublin Core™ documents and the implications of Dublin Core™ recommendations has still to be worked on. Meanwhile the documents available on the Dublin Core™ web site have been organised in a structured way by the Usage Board Chairman Tom Baker, and navigation should be much more logical and useful.

The Dublin Core™ web site has been significantly improved in its accessibility, thanks to the good work of DCMI and the web master Beth Marsh.

Meeting Recommendation: the preparation of use cases to identify typical problems would help where problems are noted.

2. Is accessibility a DC issue?

DC 2002 keynote speaker Herbert van de Sompel reminded attendees that many of us currently work to mantras like "[digital] libraries are there to make information accessible". If this is so, accessibility is an issue for the DCMI community. Given the prevasiveness of the accessibility effort, discovery should provide for all users and demonstrate awareness of the need discoverers might have in terms of accessibility of the content to which they are being pointed.

In general, the answer depends upon what we want to do/say in metadata for the benefit of users. There are many types of users, some of whom are concerned with gaining access to content that is relevant to their content needs, some of whom have found the content to which they want access but are concerned about their access to this content using particular devices, and a third group of people want to discover the qualities of the content, including how it complies to particular accessibility standards. Typical questions from the users include:

• "Is this accessibility compliant according to yyy standards?"
• "Can I access this? and if so, how?"
• "Find me resources with the content I want but only point to ones I can access."
• "How can I make this resource more accessible?"

3. Promote DC in this context

In the UK, the European Union, the US, in Australia/NZ, and a number of other countries and circumstances, there are regulations about the accessibility of web content. In almost all cases, the standards are derived from the guidelines of the W3C WAI effort.

For example, in the US there is a legislative section ( s.508 ) that requires compliance with a subset of W3C WAI recommendations in certain circumstances. This has led to a need for many content providers to know if their content is compliant with this standard. As the providers are not all expert in accessibility, and many do not know how to or do not bother to comply, third parties often want to determine and register, or know about, the accessibility of these resources.

Dublin Core™ metadata is very pervasive, and encouraging the use of DC elements to record the accessibility of resources could achieve two goals:

• to increase awareness of the need to think about accessibility, and
• to increase the utility of the DC element set.

But it should be remembered that DC elements are successful because they are easily deployed, suitable for a very wide range of uses, and inter-operable. The DCMI principles that have led the DCMES development in the past should be observed: as many as possible of the relevant communities need to be involved in the recommendation of an accessibility metadata profile.

During the year, the DC.Accessibility interest group has held a face-to-face meeting at the WWW 2002 Conference in Hawaii, and contact has been made with other standards bodies that are similarly working on accessibility metadata problems. In particular, work being done by W3C, CEN-ISSS, IMS Project, and INCITS V2 has been considered. There are many standards relevant to the work. At DC 2002, it was discovered that important work is also being done in Japan at JTT (see DC 2002 Poster by Masatoshi Kawarasaki and Junichi Kishigami at http://www.bncf.net/dc2002/program/ft/poster9.pdf ).

Meeting Recommendation: to continue to work with those who are concerned with metadata in this field, so that a single, harmonised solution can be adopted by all groups. The other important reason for working together is so that those who are working in a particular area within the general field can be supported to do their work, for the benefit of others.

A brief description of some of the relevant standards and how they are relevant was written in mid-2002. This paper was designed to stimulate discussion and comments are invited. Since this paper was written, it has become more clear what is being done and what is relevant (see below).

Does DCMES offer enough?

• Are the existing elements and qualifiers sufficient?
• What is at stake if special elements/profiles are proposed?
• Have we a proposal?

The First Question is, "What do we want to do?"

• Provide compliance information
• Support personal discovery by
• Enabling search on compliance
• Matching users to resources
• Matching resources to repair tools
• Matching resources to transformations

Use of DC elements

The following elements seem relevant:

title

  <dd>not relevant</dd>

  <dt>identifier</dt>

  <dd>not relevant</dd>

  <dt>creator</dt>

  <dd>not relevant</dd>

  <dt>contributor</dt>

  <dd>not relevant</dd>

  <dt>publisher</dt>

  <dd>not relevant</dd>

  <dt>date</dt>

  <dd>not relevant</dd>

  <dt>language</dt>

  <dd>might be a place in which to indicate Braille or a sign
  language ????</dd>

  <dt>rights</dt>

  <dd>see notes below about the dc:government 'access'
  qualifier for rights</dd>

  <dt>subject</dt>

  <dd>this is used to describe the 'aboutness' of the content,
  not its form</dd>
</dl>

DC element qualifiers

The DC.Education Working Group has introduced some qualifiers:

dc:audience dc:audience.mediator

The education community likes to be able to identify the resource's target audience and the role that might be played by a mediating person, e.g. a teacher might be a mediator for a 3-year old who is going to play a game discovered on the web. In the case of people with special needs, possibly using a device without a screen for instance, a software agent might be a mediator, or in another case, a style sheet or some other form of additional content, might be. So this element and its qualifier are of interest.

Issues related to these terms include those that deal with whether their use is to do with content or form of that content.

Meeting Recommendation: Examine the implications and value of the use of, or extension of, dc:audience and dc:audience:mediator.

DC.Education also has introduced a qualifier for the dc:type

dc;type;extent is used to provide information about the duration of use of a resource. For example, a video might run for twenty minutes but prompt work for a class of 30 children for two days. Teachers like to know both these things about videos.

The DC.Government Working Group has introduced a qualifier for dc:rights

dc:rights.access

The use of the term 'access' is clearly going to cause confusion in many contexts. Above it was noted how it causes access with respect to its meaning and context. DC.Government's proposed use is to do with who is allowed to have access to the content of the resource.

The DC.Government Working Group has also introduced a qualifier that is used in several contexts.

dc:coverage:jurisdiction and dc:creator:jurisdiction...

This qualifier led to some discussion.

* Questions that were raised during the meeting:

• Are qualifiers really adjectives which can be used with any element?
• How do we control the quality of statements about accessibility?
• Why worry about jurisdiction? E.g. INCITS V2 wants devices to describe themselves with metadata (and to be described) but this may be something that is required in certain jurisdictions, and lack of accessibility might be enforceable only in certain jurisdictions.
• Would controlled vocabularies and the existing elements and qualifiers solve the needs of the accessibility community?
• Should we work hard to support the efforts to limit the number of DC elements?
• What about local vs global/inter-operable metadata?

The DCMES element dc:relation

This has qualifiers that might be of interest in the accessibility context.

dc:relation qualifiers include: replaces, is required by, is part of, is referenced by,

The main concerns for the accessibility community are;

• Is there the same content in an alternative format?
• Is there the same content (intellectually) in a different modality (e.g. a graphical representation of a mathematical statement may be an alternative to an algebraic statement of the same thing but more suitable for a blind person)?
• Can this content be rendered accessible to my device?

There was some discussion about the need for a way of identifying what is alternative and what is equivalent alternative content. Comments were made about the following qualifiers that might be relevant:

'is format of'

  <dd>* expects changes in format but not in content</dd>

  <dt>'is version of'</dt>

  <dd>* expects changes over time, perhaps not in types or form
  of content</dd>

  <dt>'conforms to'</dt>

  <dd>* relates to a standard</dd>

  <dt>'replaces'</dt>

  <dd>* implies one version has been replaced by another, not
  that they are equivalent</dd>

  <dd>
    <p>The meeting then considered the possibility of
    qualifiers 'is-equivalent-to' and 'has-equivalent'. With
    respect to these as possible qualifiers, the meeting had
    some questions.</p>

    <p>Questions raised and discussed</p>
  </dd>
</dl>

• Should qualifiers indicate they are referring to equivalent content?
• Should the qualifiers somehow indicate their relevance to accessibility?
• How useful would they be to people who are choosing to use the of access devices, such as telephones etc. rather than using them because they cannot use alternative forms of access/ Is this relevant?

Meeting Recommendations:

• to use the DC.Education's dc:relation:conforms-to for compliance information;
• to use dc:relation:has-format, dc;relation:is-version-of and dc:relation:replaces where they are relevant;
• to investigate a profile of metadata that is specific to accessibility so that it can be used in a modular fashion with domain specific metadata application profiles, and
• to work on the possibility of using the qualifiers 'is-equivalent-to' and 'has-equivalent' for equivalent alternative content.

How should we describe conformance?

'conforms to'

  <dd>* this will obviously be useful with respect to
  compliance to guidelines and standards but not so obviously
  useful when looking for an accessible alternative</dd>
</dl>

• It is important to remember that there are many standards to which web resources may comply in terms of accessibility and it is necessary to have a solution that allows for them all (retaining inter-operability while promoting local specificity)
• Does W3C's EARL * help by providing a controlled format for this information?
• Note that EARL statements are in Resource Description Framework (RDF) syntax, not HTML, e.g.
• Where do we get this information (the EARL statement)?
• How is it stored/used?
• Can we point to an EARL report rather than try to embed it in the resource?
• Does it work for HTML/XML/RDF?
• Are the RDF tools sufficiently advanced for this? Will they be used?
• How do we say who made the statement, indicate the provenance of the statement?

* Evaluation and Report Language (EARL)

EARL is a W3C recommended language for describing conformance (see http://www.w3.org/WAI/ER/ ). It uses a constrained form of RDF that allows for an assertion and information about who made the assertion and when. Typical examples are;

• Fred asserts that a given page complied with s 508 on 22 December 2002, and
• GGG Software asserts that a particular web page is compliant with WCAG Level 1 on 22 December 2002.

EARL is not only useful for conformance reporting in the accessibility context, but that is a good use of it.

EARL statements might not do more than make it evident how a resource complies of fails to comply with a given standard, but other applications might be able to use this information to repair the resource. Knowing how a resource complies does not make any difference to its ability to be accessed by all users. EARL might be used to describe usability information as well. An EARL statement may be thought of as a review, in which case it might be referred to in dc:relation:is-review-of.

These, and similar issues, occupied the minds of the meeting participants for some time.

Other issues

It is well-known that there are a number of activities relating to accessibility metadata. In the last year, a number of these have started to work together. Some of those who have already worked on collaboration have found it hard to understand who is doing what and what the outcome will be. At DC 2002 it was discovered, for instance, that NTT in Japan is working on reuseable resources that can be sent effectively to any device. The meeting discussed some of the different efforts and decided that it would be good to develop a structured way to talk about these activities. After more discussion, the participants developed a simple first matrix, and tried it with some of the activities to see how well it worked.

Meeting Recommendation: to work a little on the matrix and then to ask those conducting activities in the field if they could complete it with respect to their activity.

It was also considered relevant that activities using diagrams and models should be able to determine how to engage with one another. The exemplary diagram from NTT suggested one way of doing this. Another way of sharing understanding that was proposed was the contribution of use case scenarios form the various organisations.

Meeting Recommendation: that a DC Accessibility Working Group be chartered to develop a road map of relevant activities, with the help of any groups interested in collaborating.

This recommendation was followed by some discussion of the best way to achieve this goal and a time frame for it.

Meeting recommendation: that the Working Group be formed of a small number of representatives who are willing to commit to regular work on the task and to meet face to face in January 2003 to finalise a road map for general distribution. This work would be in anticipation of a Working Group being formed to develop the relevant DC metadata profile for accessibility.

Future work should include a metadata profile for accessibility, examples, and guidelines for accessibility metadata.