Re: Organizing WCAG 2.0

Here is a very slight modification to that proposal:

We provide a list of checkpoints, which are the abstract requirements for
accessibility - for example that there is a text equivalent of all
information. It is important that they are testable. But they don't need to
be machine testable since that may not be possible.

These abstract checkpoints are part of a Recommendation.

We should also provide technology-specific ways of meeting the
checkpoints. Since these are going to change more often, and since they are
unlikely to be unique in most cases (there are several ways to provide
text equivalents for an image in HTML 4.0. On the other hand, there is more
or less one way to ensure that code is syntactically valid) these might as
well be a note. Each of these methods (which I propose we call
"Techniques") may be a way to completely satisfy one or several checkpoints,
or it may be a way to partially satisfy a checkpoint. This information should
be part of the technique.

That way, conformance is always to the checkpoints of the Recommendation, but
there is a clear way to achieve it for a given technology - by choosing
techniques that meet all the checkpoints.

This proposal has the added advantage of nobody having to learn a new way of
dealing with WAI guidelines, since that is how it works at the moment. And
even the terminology remains stable.

cheers

Charles McCN

On Sat, 19 Aug 2000, m. may wrote:

  
  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
  

-- 
--
Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
Location: I-cubed, 110 Victoria Street, Carlton VIC 3053
Postal: GPO Box 2476V, Melbourne 3001,  Australia

Received on Sunday, 20 August 2000 07:35:22 UTC