- From: m. may <mcmay@bestkungfu.com>
- Date: Sat, 19 Aug 2000 22:03:39 -0700 (PDT)
- To: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
- Cc: Ian Jacobs <ij@w3.org>, Web Content Accessibility Guidelines <w3c-wai-gl@w3.org>
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