RE: Postscript RE: Proposal: purpose and approach for Gateway

When I look at the gateway doc it sounds an awful lot like techniques.

 

Also, after WCAG 1.0 I though we didn't want to put a doc between guidelines
and techniques.

 

What happened to the label "core techniques" for the doc. 

 
Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 

  _____  

From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of John M Slatin
Sent: Monday, September 06, 2004 3:44 AM
To: John M Slatin; w3c-wai-gl@w3.org
Subject: Postscript RE: Proposal: purpose and approach for Gateway

 

[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
<http://www.utexas.edu/research/accessibility> /research/accessibility