Proposal: purpose and approach for Gateway

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.

 

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