- From: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
- Date: Tue, 15 Aug 2000 15:00:12 +1000 (EST)
- To: Web Content Accessibility Guidelines <w3c-wai-gl@w3.org>
Writing individually (and not in my capacity as co-chair): This is ground which has been well covered. Providing the practicing web site designer with guidance is only one of the purposes of the document. Its other functions include: (a) defining what it means for web content to be "accessible", more abstractly than can be achieved by a set of technology-specific requirements so that the guidelines can continue to apply as technologies evolve; (b) offering technology designers (including those creating, or extending, data formats) criteria with which to ensure that their technologies are accessible; and (c) providing input to other groups concerned with the design and development of accessible technologies, authoring tools, etc., associated with the web. These may include educational or policy-oriented groups--whoever finds a precise specification of what "accessible" design amounts to, in the web arena, to be valuable. One of the central shortcomings which this working group has identified with WCAG 1.0 is its failure to specify what "accessible" design means, independently of (or more abstractly than) requirements which pertain to particular, existing, standards and technologies. At the other end of the continuum, it has been argued that the checkpoints in WCAG 1.0 are not sufficiently specific and verifiable. This led to the so-called three-level hierarchy of requirements, its having been generally agreed that the upper two levels should comprise the guidelines. The guidelines themselves cannot be changed without proceeding through the W3C process. They are supposed to be (and must comprise) a stable document, subject to change only infrequently. Consequently, it is not practical to generate a new version whenever a new technology or standard emerges. However, this working group has also undertaken to publish checklists and a techniques document which should address the need for specific and precise, technology-specific requirements. These must be founded in, and constitute an application of the guidelines--but unlike the latter, as they are non-normative, they are more easily subject to change. Of course, as Charles has often pointed out, most web content developers should not be expected to read the guidelines, just as most content designers don't (and are not expected to) read the HTML specification. Rather, it is the task of authoring tools, training materials, checklists (including those furnished by this working group) and the techniques document to give practical guidance. When these sources are inadequate (for example under circumstances in which one is extending a markup language, proposing a technique of implementation and querying whether it should count as accessible, etc.), that it becomes necessary to consult the "official" (normative) guidelines.
Received on Tuesday, 15 August 2000 01:02:02 UTC