Re: Organizing WCAG 2.0

On Sat, 19 Aug 2000, Jason White wrote:

> I like Ian's proposal, a variation of which might well work. One problem,
> however, is as follows:
> 
> Suppose that an individual or organisation either develops a new
> technology, for example a markup language, or extends an existing
> technology (noting that most of the recent W3C formats are designed to be
> extensible). Further, let it be assumed that the W3C has not developed a
> profile for this technology (or, in the case of an extension, the profile
> does not take account of the added features). Two questions arise:

Let me add a twist here. Let's say that a new, uncovered, but
theoretically and practically accessible technology is introduced. Through
pressure, political or otherwise, organizations adopt WCAG 2.0 as an
accessibility baseline, and require all browsers/apps, tools and
deliverables accommodate the guidelines. In the absence of valid
technology-specific checkpoints, these organizations aren't allowed to use
the technology.

This puts the W3C in the precarious position of keeping tools out of the
hands of potential customers. That stands a chance of becoming a political
hot potato, and the W3C may risk losing the support of some affected
vendors.

My proposal:
- A list of general checkpoints to satisfy the requirements of
accessibility which is appropriately abstract and extensible. This is a
W3C Recommendation.
- Technology-specific checkpoints, as appropriate, delineate how to
completely satisfy goals of accessibility in each technology. This is a
W3C Note. (My understanding is that Notes are easier to revise and extend;
I feel that's necessary for this kind of document. If I have it wrong,
that extensibility is my intent, anyway.)
- Compliance is based on the tech-specific checkpoints where they exist,
and on the general checkpoints where they do not.

I think we also need to remember that many of the techniques being
discussed are, essentially, errata: they're fixes for holes that have been
exploited in the technology's specification. As such, the tech-specific
documents need to be living documents, and thus shouldn't be subject to
the W3C recommendation process.

And in that vein, another issue I'd like to raise comes from something
Jason mentioned: Many recent W3C protocols are designed to be expanded,
and the resulting products may not map directly to an already-published
technical doc. For example, XML can be _anything_. Accessibility when it's
used as RDF means a whole different thing from when it's used as XHTML, or
simply as an object database. I think there's going to be an awful lot of
hair-splitting when it comes down to implementation because accessibility
rules change not just by technology, but just how it's used. In the
absence of a spec for everything under the sun, requiring conformance with
the higher-level rules seems like a fair compromise.

Anyway, that's my spin. :)

----
matt

Received on Sunday, 20 August 2000 01:03:44 UTC