Appendix 10: Overview of author's accessibility metadata work

For many years, Nevile has worked on problems related to computer technology and people with disabilities (starting in 1983 while working at Barson Computers). For the most recent decade, the work specifically aimed to increase the accessibility of the Web, particularly as part of the W3C's Web Accessibility Initiative [WAI] work.

To establish a clear image of current activity with respect to accessibility of Web resources, early on the research involved development work that included a translation into operational practices of the best-known specifications for accessibility, those developed by the community working with the Web Accessibility Initiative (see Chapter 4). The idea was that although the principles for accessibility were being established by the various WAI-sponsored guidelines, developers needed some way of simply and quickly discovering what they had to do. The resulting version is organised by purpose rather than principles, as is WCAG. This means that a developer making a table should be able to simply go to the section on tables, copy a model, and find out what to do with it. That is, the functional aspects should be made clear but the principles only in as much as they are necessary to work correctly with the table example, for instance.

W3C/WAI Guidelines [WGAC], [ATAG], [UAAG] (see Chapter 4) contain the advice of many in a form that is, as best it can be, generic across technologies and future proof. The guidelines aim to provide criteria against which resources can be tested to determine if the maximum number of people, despite any disabilities they may have or any accessibility constraints they may reasonably be expected to suffer, can access the resource.

In the Accessible Content Development section (Appendix 8), there were techniques, examples and reasons with the aim that anyone using them would know what in fact they were aiming to achieve. It was hoped that not only would the section provide a sort of how-to approach based on the goals of a developer, but that developers would be able to make wise decisions about how to use the specifications. This is an approach to accessibility that is simple, effective, and saves developers from having to read pages and pages of what are often considered impenetrable texts. The section was designed to engage a community of developers using it within a university and adding to it. The site was never promoted or used as proposed but a similar approach has been very successfully implemented by the Web Standards Group of developers [WSG]. (The site was published by La Trobe University for several years on their main Web site as part of that university's accessibility effort.)

Developing the section for developers acted as a catalyst for thinking about other ways to increase the accessibility of the Web, given the dismal failure of international accessibility work to date.

At this time, accessibility appeared as often as not to be a marketing issue as much as a technical one. People did not find it easy to follow the guidelines for accessibility of content [WCAG] if they did happen to know about them and want to follow them. More and more developers were finding that if they did succeed in following the guidelines, they were not seeing any particular advantages from having done so. In particular, the major browser developers were not complying with the guidelines for user agents [UAAG] and the major authoring tools did not conform to the guidelines for authoring tools [ATAG]. Realistically, only people who took extra care and worked at the encoding level could expect to make accessible content. The common perception was that it was difficult, expensive, and most developers did not know how to do it anyway. Although there was, even then, the threat of anti-discrimination or other legal actions, in fact these were not happening. In the United States, the legislation that related to accommodations for people with disabilities in the Federal Government context was operating but on such a low level of what might be called 'accessibility' and in such limited circumstances that it too, was not offering much hope. Recognition of these problems led the WAI to develop and publish resources to help those working on accessibility to 'sell' their efforts to their management and other relevant people (Arch??? ???).

About this time, the IMS Global Project [IMS GLC] started to write a set of accessibility guidelines for education. The guidelines were not supposed to replace the WCAG, but rather to be contextual, interpretive and easy for those in education who may not have a deep understanding of or interest in accessibility or content coding, or the time to study them despite the requirement in most places that they provide accessible content. The WGBH National Center for Accessible Media [WGBH/NCAM] SALT project initiated and sponsored this work within IMS. Co-authoring of these guidelines complemented work on the guidance site for developers and extensive text was taken from that site for the new guidelines (ref).

In 2001, IMS GLC work was extended to engage directly with the relevant work of the Adaptive Technology Resource Center [ATRC] at the University of Toronto where, within the university, work had been underway to produce a prototype system that would match resources to users' needs. This work was demonstrated in the system now known as The Inclusive Learning Exchange [TILE]. The ATRC specialises in accessibility so that it was able to develop a system for combining already available accessible content into customised packages for its clients. Taking this idea and making it a generalised approach for education (under the umbrella of the IMS Global Learning Consortium [IMS GLC]), was the first task. Then it was taken to the rest of the world as a fast-tracked development of an ISO/IEC JTC1 SC36 Learning, Education and Training Standard [SC36]. Nevile was an author and co-editor.

Nevile had already established the international Dublin Core Accessibility Working Group [DCMI Access] to examine the use of metadata in the accessibility field and was aware of the problems associated with trying to use Dublin Core metadata as it was, in this new context. The context was new in that it was not just a purpose beyond the more common goal of resource discovery, for which DC metadata was designed, but because it was to enable resource management and to achieve what was seen as a political goal as well, the increased accessibility of the Web. Using metadata for management purposes involved making explicit an emerging way of thinking about the DC metadata for the DCMI and particularly a major challenge when metadata was to be used to describe the attributes of a fictional or abstract resource (a set of needs and preferences for an unidentified, metaphoric person (Nevile, 2005b). (This problem is considered further in Chapter 7.)

At the time, Dublin Core metadata as defined was being pushed to its limits and in some cases proving problematic. Although the metadata model had been designed to be simple so that it could easily be standardised, users in some contexts had stretched it out of its original scope and found it wanting and there were slight differences in how they were using it so that the desired interoperability was not always achieved (Currie et al, 2002).

The early research questions within the Dublin Core Metadata Initiative Accessibility Working Group [DCMI Access] that finally led to the metadata work as finally determined, included:

At this early stage, the idea was to find a simple way of describing resources so that users could find and use what they needed. It assumed that the WCAG guidelines would provide the best measure of this quality, but required greater detail than the simple pass or failure of the tests those specifications could offer.

In 1998, the United States Federal Government introduced legislation [s.508] that required all federally funded bodies publishing on the Web to ensure their resources were compliant with a subset of the WCAG for content accessibility. This legislation included some requirements from the Authoring Tools Accessibility Guidelines [ATAG]; see also Chapter 4). In 2004-6, some in Europe have endeavoured to create what is known as a quality mark to assert an absolute measure of accessibility of a resource (CWA 15554). Neither of these activities, even if they were achieved, could be expected to solve the discovery problem for an individual user.

The AccessForAll team, as it now was, chose to broaden the metadata work from the beginning, ensuring that it was done in an open environment and that the members of the Dublin Core Metadata Initiative Working Group [DCMI Access], and others, were able to participate. The hope was to follow the open working model of the W3C's Web Accessibility Initiative (ref). Nevile was also involved in European Commission activities to do with the development of DC metadata and so brought the work into that realm as part of work done in the European Committee for Standardization Meta-Data (Dublin Core) Workshop [MMI-DC]. By now, three otherwise distinct communities were interacting:

There was also the involvement of a range of sectors:

Local, national and international issues were becoming relevant. Local developers would need to be able to work with the proposed metadata and so were concerned to ensure their tools would handle the proposed metadata; national bodies needed to ensure their national standards would be supported, and internationally there were issues to do with multiculturalism (actually an issue inside some countries as well).

In addition, by involving the Dublin Core metadata community, the problem of interoperability was increased: Dublin Core metadata is based on a very different data model from IMS metadata that is derived from IEEE/LOM (see Chapter 7) and so there were to be a number of technical problems. The aim of working with the DC community was to take advantage of the widespread use of DC metadata in domains other than education, including for resources that were often used in educational settings. In particular, many government resources are described using DC metadata (UK, Canada, NZ, Australia, ??? ref), so they could become part of the system without too much trouble if the solution was suitable. It was assumed that working with DC-style or DC-interoperable metadata would also render the resources more useful in the Web 2.0 world, as they would be tagged in ways that were more consistent and therefore more interoperable with other Web 2.0 resources, including with any Web services that might be involved.

The work was also broadened to anticipate it being used in a distributed environment, where there would not always be accessible content available, or, at least where users might require discovery of that content, for substitution or augmentation of existing resources. This introduced a new set of problems. The original resource might have been discovered by a search but how would a replacement resource be found? Nevile collaborated with researchers in Japan to explore the use of a FRBR model of metadata to trace back from a resource to its source in order to find another manifestation of it that could be used to provide additional accessibility (Morozumi et al, 2006). This work is continuing and now includes an interest in the new work proposed by Online Computer Library Catalog [OCLC] for GLIMIRs (Weibel, 2008a).

All this work is supported by the literature with respect to the issues:

A draft roadmap of related specification and standards activities was developed in early 2003 (Nevile, 2003a). There is now a formal W3C 'roadmap' document [W3C Roadmap]. In order to ensure maximum effect from the work being undertaken, it was essential to make sure it would not only be interoperable with other work, but that it could take advantage of that, where possible. The main community working on related specifications and standards was the W3C WAI.

There is a significant problem for the W3C in the development of their specifications for accessibility. If a resource is not touchable, for example an early digital image of something where the image is of historical importance and by law cannot be altered in any way, and the resource is not accessible to users with vision disabilities, W3C either cannot have a specification requiring alteration of the resource (because this resource must fail) or must introduce exceptions to their specifications. The latter course is not attractive to those responsible. As it is now possible to add metadata to the URI of a file using POWDER, without touching that file, even such a case could now satisfy a specification requiring metadata to link the resource to a non-visual alternative and so metadata is now to be included in WCAG 2.0 (ref).

Nevile worked with the W3C WAI community and been involved, and continues to be involved on a spasmodic basis, particularly in the development of the Authoring Tools Accessibility Guidelines [ATAG]. She also worked closely with the INCITS V2 community as they developed the Universal Console specifications [INCITS V2] and ISO/IEC standard [JTC1 SC35 WG8], and the Australian National Archives for the Australian Government Locator Standard [AGLS]. Others involved in the work included participants in the CEN ISSS Learning Technologies Workshop [CEN/ISSS LT]. (A brief introduction to the most relevant organisations and standards bodies is available Chapter???.)

 

Next ->