Re: Structure of deliverables: are we too PC for our own good?

William Loughborough writes:
 > At 12:27 PM 9/9/01 +1000, Jason White wrote:
 > >bearing in mind the technology-specific layer
 > 
 > It's not exactly sky-pie but it's definitely still vapo(u)rtext.
Not anymore. Several drafts exist already, and they are to be
discussed at the face to face meeting next week.
 > 
 > I can't speak for Al but as an interested observer there is essentially not 
 > much beyond motherhood in the principles. The "but what do I do?" so 
 > vociferously raised by those to whom we assign the doing is still in some 
 > sense glossed over.
Not in the technology-specific documents however, which will furnish
 > examples and assertions regarding how to implement each checkpoint.
 > 
 > This is most strongly evidenced by those items with "the vagues", e.g. 
 > checkpoint 1.3 Use markup or a data model to provide the logical structure 
 > of content. Even (or perhaps particularly?) with the subsequent explanatory 
 > success criteria and "informative" definitions/benefits/examples there is a 
 > residual unease with just what one attempting to conform is supposed to do. 
I don't think so; the examples and success criteria seem quite clear
 > and will be supported by further elucidation relevant to whatever
 > technology or technologies the content developer may be using.

 > I think this is underlined/emphasized by "The definition for data model is 
 > under discussion."
The problem with "data model" is not conceptual; we have a reasonably
 > clear understanding of what it must provide, but haven't found the
 > correct form of words with which to express it.
 > 
 > The model of the document as a sort of "constitution" or "legislative 
 > array" awaiting "case law" elucidations seems stale when so many 
 > participants could furnish *real* examples of "how-to" stuff. I think 
 > trying to divorce some hierarchical "principles" from the output isn't 
 > working out too well - YAGL, by the time it's through the process, 
 > something new has arisen to send the team back to the debating platform.
To the contrary, the purpose of the Candidate Recommendation period
 > and public review process is to minimize the possibility that this
 > will happen.
 > 
 > Those who write *for* rather than *about* Web inclusion use tools which, 
 > unless carefully designed, will undermine 
 > accessibility/usability/readability/function and IMHO between WCAG 1 and 
 > ATAG 1 that could now be approached fairly closely. The current document 
 > has the virtue of being internally politically correct by going through all 
 > the process that is required of a "recommendation" but in doing so makes a 
 > mockery of a favored mantra "it's a web, not a tree" because of the strict 
 > hierarchical attitude imposed with "levels of conformance", "priorities", 
 > and sterilized checkpoints carefully avoiding the contamination of any 
 > real-world examples whenever possible.
The examples are entirely real-world, they just stop short of naming
 > any particular technologies (though they do describe the kind of
 > technology, e.g., a style sheet, a script, a graphics language
 > etc.). If one wants technology-specific examples, then one should
 > read the technology-specific documentation; and of course it would
 > be possible to create a view in which the technology-specific
 > requirements appear below the relevant WCAG 2 checkpoints, with
 > accompanying examples, so that the reader doesn't have to move back
 > and forth between two documents in order to read the checkpoints in
 > the context of her/his preferred technologies.

At the outset of this process, the working group decided to generalise
the guidelines and checkpoints, and to separate them logically from
the technology-dependent requirements and examples. That is the
premise on which the development of WCAG 2.0 has proceeded, and I hope
these decisions do not need to be revisited now.

From the requirements document (http://www.w3.org/WAI/GL/wcag20-requirements):

<blockquote>
WCAG 2.0 requirements should be expressed in generic terms so that they may
apply to more than one markup language or content format.

2. WCAG 2.0 must clearly specify the minimal requirements necessary for
conformance. Each requirement must be easily verifiable. The WG will provide
resources to help readers evaluate conformance, such as technology-specific
checklists, sample sites, sample renderings (aural as well as graphical), and
processes for determining conformance (e.g., in conjunction with the ERT and
EO WGs).
</blockquote>

The WCAG 2.0 draft is intended to satisfy the first of these
requirements and, by providing success criteria, part of the second.
The remainder of the second requirement is to be met by (as the
Requirements Docuemnt indicates) technology-specific documents and
checklists, working examples, etc., the development of which is
underway but lags behind that of the guidelines themselves. This is
why much of next week's meeting is devoted to techniques and
technology-specific work.

Could we at least postpone discussion of this issue until the
technology-specific documents have started to stabilize, and we know
what "views" of the documents we plan to provide to readers? After
that we can check, with the aid of usability testing, to find out
whether there are any problems that haven't been addressed.

Received on Sunday, 9 September 2001 03:45:31 UTC