- From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
- Date: 26 Apr 2006 22:43:07 -0600
- To: public-comments-wcag20@w3.org
- Cc: W3C XML Coordination Group <w3c-xml-cg@w3.org>
This email conveys some comments on "Requirements for WCAG 2.0" http://www.w3.org/TR/2006/NOTE-wcag2-req-20060425/ The XML Coordination Group asked me to review this document, but the XML CG has not reviewed the comments given here, and I alone am responsible for them. In general, the document seems clear and persuasive. Thank you for it. On some points, however, I do have questions and/or suggestions. (a) Is WCAG 2.0 intended to replace (or make obsolete, or succeed) the XML Accessibility Guidelines document (http://www.w3.org/TR/2002/WD-xag-20021003)? Does the publication of a WCAG 2.0 requirements document mean that I can remove 'Review XAG' from my long-term guilt list? (If it does, perhaps the time has come to move XAG down into the list of "Working Drafts no longer in development". If not, then the relationship of WCAG 2.0 to XAG needs clarification.) (b) On requirement 1 (applicability across technologies). I agree that this is highly desirable, but tremble when I contemplate the difficulties involved. If I were you, I would either add clarifying prose establishing an achievable standard of success for meeting this requirement, or else classify it not as a requirement but as a goal. (In line with the practice of some WGs, I am here taking 'requirement' to mean something which one must do or fail, and 'goal' to mean something one will try to do, but the omission of which does not constitute "failure". In those WGs, failure to achieve requirements is a distinct cause of shame and loss of face, possibly compensated for -- or not -- by other successes, while unachieved goals may yet allow one to hold one's head high.) It would be useful, perhaps, if some clearer definition were given of what is to count as being applicable "across technologies". A simple reading of the requirement might assume that every rule should be applicable to all technologies in question. But a rule like "Alternate text should be provided for images" can only apply to systems in which images can be incorporated. I hope therefore that this simple reading of the requirement is false: it would reduce WCAG 2.0 to a discussion of features common to all target technologies and enforce silence on any topic not universally applicable. I suspect that with some effort I could formulate a more plausible way to formulate the import of the first requirement. But what is important here is not how I might try to formulate it, based on my understanding of the requirement, but how YOU would formulate it, based on YOUR understanding of the requirement. A different sort of difficulty is entailed by the fact that the technologies you describe include specifications which operate at different levels (if I may use that term without defining it). Some of the technologies mentioned define specific vocabularies which may be used in creating Web content; others (XML, at least) are one level of abstraction higher. XML is a set of rules which in the first instance govern the creation of vocabularies, and (I oversimplify slightly) only indirectly govern the creation of content. (More on this below, a propos of requirement 4.) (c) On requirement 2 (ensure that conformance requirements are clear). The introductory paragraph says "Each requirement must be verifiable." Readers of the WCAG 2.0 spec will be in a position to tell whether that spec meets this requirement only if verifiability is defined more clearly. In particular, this reader would like clarification on whether it means that all requirements are to be automatically verifiable, e.g. by software, or whether verifiable requirements include such as require intervention by human intelligence. (I imagine you understand quite well what I mean, but an illustration may be offered, just in case. The requirement that an HTML 'img' element have a non-empty 'alt' attribute value can be checked by machine; a requirement that it contain an accurate description, in some natural language, of the image and its relevance to the document cannot be checked by machine given the current state of the art in natural language processing and artificial intelligence.) The voices of all those who must check documents for conformance to WCAG will surely be raised to urge you to concentrate on requirements which can be automatically checked. And the voices of those who rely on conformance will, I assume, urge you with equal fervor not to limit yourself to things that can be checked by machine, but to state the real requirements. The more I think about it, the more obvious it seems to me that verifiability, in this sentence, cannot mean 'checkable by purely automatic means' -- but I will stand by my suggestion that it would be useful to the reader if you said so explicitly. (d) On requirement 4 (diverse audience) Given the list of technologies offered in requirement 1 (and given my assumption that WCAG 2.0 is among other things to play the role originally envisaged for XAG), the list of audience members given here seems incomplete. I realize that it is introduced with the words "including people who" and is not intended as an exclusive list. But still .... Creators of content are included (in the first bullet). Creators of vocabularies (the key users of XML, and the creators of SVG, CSS, SMIL, etc.) are not explicitly addressed. Nor are creators of meta-vocabularies (e.g. those responsible for defining meta-vocabularies like XML). I believe the requirements document will be clearer and more useful if you make clear either that designers of vocabularies (XML or other) are indeed among the intended audience, or that they are not. And ditto for the designers of meta-language specifications like XML. You are between a rock and a hard place here: if you try to address both content providers and vocabulary definers, you will have to switch gears constantly between the level of Web content and the level of vocabularies for Web content (or vocabularies for defining vocabularies for Web content -- and heaven help us if someone takes it into their minds to define a spec describing how the creators of meta-languages ought to go about their business). But if you don't address the creators of vocabularies, you will not succeed in promoting accessibility of Web content as well as I hope you will. It is not enough to tell creators of documents to use appropriate methods to make their content accessible -- you must tell creators of vocabularies that they must make it POSSIBLE for users of the vocabularies to create accessible content. "Use the 'alt' attribute" on one level, "Provide for alternative delivery mechanisms, in the spirit of the 'alt' attribute -- but preferably not as an attribute" on a separate but perhaps even more important level. More important because the ratio of documents to vocabularies is n:1, with n usually greater than 1. But also more difficult, because the requirements must be couched in more general and abstract terms. Good luck. Perhaps the solution will be to distinguish the audiences (content providers, vocabulary providers, metalanguage providers) in the text, in something like the same way that the Character Model distinguishes rules for Web content from rules for specs from rules for software. A different solution might be to address the different levels in different documents -- but I think that would have serious problems of its own. (e) On requirement 6 (compatibility) This requirement says in part that "WCAG 2.0 should introduce as few changes as possible to the definition of accessible Web content". Does this mean only that content defined by WCAG 1.0 as accessible should not be classed as inaccessible by WCAG 2.0? Or does it mean that content defined as inaccessible by WCAG 1.0 should not be defined by WCAG 2.0 as accessible? Or both? I hope it does not mean that WCAG 2.0 must not clarify the nature of accessibility in regions where WCAG 1.0 sheds insufficient light. But I take requirement 1 as a promise that it does not. Thank you. --C. M. Sperberg-McQueen World Wide Web Consortium MIT CSAIL
Received on Thursday, 27 April 2006 04:43:46 UTC