- From: John M Slatin <john_slatin@austin.utexas.edu>
- Date: Mon, 6 Sep 2004 03:43:34 -0500
- To: "John M Slatin" <john_slatin@austin.utexas.edu>, <w3c-wai-gl@w3.org>
- Message-ID: <C46A1118E0262B47BD5C202DA2490D1A0413577D@MAIL02.austin.utexas.edu>
[jms] I wrote: This message prposes a description of the purpose served by Gateway to Techniques for WCAG 2.0 and provides a rationale. I offer this as a starting-point for discussion about what the Gateway should be and do, and to explain the basis on which I've proceeded so far. Comments welcome! Proposal The purpose of Gateway to Techniques for WCAG 2.0 is to help readers identify technology-specific techniques for achieving conformance to WCAG 2.0. In order to do this, Gateway to Techniques discusses design strategies for applying specific guidelines and success criteria to different scenarios or different types of content. [jms] <postscript> Maybe we should consider changing the title from Gateway to Techniques for WCAG 2.0 to something like Design Strategies for WCAG 2.0 or something along those lines. We could then publish that document in addition to an annotated list of technology-specific techniques for each success criterion, along the lines of what I discuss in the Rationale section below. Publishing that list would give developers who want to jump straight to the granular techniques a way to do that, while the Design Strategies document would be available to people who wanted it. </postscript> The following is unchanged from the message I sent earlier today. Rationale Gateway to Techniques for WCAG 2.0 is not a techniques document. It is a bridge between WCAG 2.0 on the one hand and the set of technology-specific techniques documents on the other. The problem is that WCAG 2.0 is highly abstract, while the techniques documents are highly particularized. WCAG 2.0 is deliberately written at a high level of generality in order to apply across the widest possible range of current and future technologies. Because it is so general, there can be no precise counterpart to a document like Core Techniques for WCAG 1.0, which assumes HTML as the primary technology for producing Web content. Instead, specific techniques can be discussed only with respect to specific technologies. The technology-specific techniques documents are very granular: that is, each technique is presented as a self-contained unit, with little or no discussion of when the technique is to be applied or when another technique might be more appropriate. In other words, it is assumed that the person reading a technology-specific techniques document has a good understanding of what she or he is trying to accomplish and simply needs to know the necessary syntax, and perhaps to see an illustrative example. Gateway to Techniques should help developers bridge the gap between the abstractness of WCAG 2.0 and the granularity of the techniques documents. In theory, the Gateway document could achieve this purpose by providing nothing more than a list of links to the technology-specific techniques appropriate to each success criterion. Judging from comments on the IG list, there is at least one developer who would favor this approach. However, the short titles of many techniques are cryptic and often confusingly similar. At the very least, therefore, the list would need to be annotated so that developers would have some sense of the technique's purpose. It wouldn't be difficult to provide this annotation: the XSLT could be designed to pull in the description for each technique. In my view, merely listing links to techniques is insufficient, and would further mystify WCAG 2.0. If all we did was to provide a list of techniques, there would be no way for a reader to know why a particular technique has been recommended as a way to conform to a specific success criterion using a specific technology. I think it would be a mistake to assume that developers don't need a rationale for choosing particular techniques. We can't assume that everyone reading WCAG 2.0 or the techniques document is thoroughly familiar with accessibility. Even developers who have experience with accessibility may find themselves working with unfamiliar content or unfamiliar technologies. Therefore, I think the Gateway to Techniques for various guidelines and success criteria should present scenarios and/or design challenges in order to present the techniques as solutions to those scenarios or challenges. "Good design is accessible design." Dr. John M. Slatin, Director Accessibility Institute University of Texas at Austin FAC 248C 1 University Station G9600 Austin, TX 78712 ph 512-495-4288, fax 512-495-4524 email jslatin@mail.utexas.edu Web <http://www.ital.utexas.edu/> http://www.utexas.edu/research/accessibility
Received on Monday, 6 September 2004 08:43:51 UTC