- From: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
- Date: Wed, 18 Sep 2002 19:02:44 +1000
- To: "Ian B. Jacobs" <ij@w3.org>
- Cc: Charles McCathieNevile <charles@w3.org>, WAI Cross-group list <wai-xtech@w3.org>
In general I agree with the substance and underlying intention of Ian's comments. To be more precise, I think there are at least two directions which this document could take: 1. It could be renamed "Principles of XML Accessibility" (or similar) and slated for publication as a W3C note. In this case, it would not be a W3C guidelines document, XML-based markup languages would not conform to it, but on the other hand the requirements would not need to meet the level of precision and testability expected of W3C specifications. This may, in fact, be better suited to the nature of the case, as there is such a great diversity of actual and potential XML-based languages that can be, and have been, designed, and any precise, testable set of requirements is likely to overlook possibilities which have not yet occurred to the authors of the document, and may, in some instances, even be historically without precedent. Thus it might be better to write a "Principles" document, akin to the Principles of Device Independence, than to write a set of guidelines. I am not here supporting, or opposing, this solution, but merely raising it as an issue that demands further examination. 2. If this document is to become a fully-fledged set of W3C guidelines, then I agree with Ian that the so-called checkpoints need to become much more precise - that is, they need to resemble WCAG 2.0 checkpoints to a far greater extent than they resemble WCAG 1.0 checkpoints. To these ends I agree with Ian's detailed suggestions. I also agree with Ian that they ought to be mapped to corresponding "content-level" requirements of WCAG 2.0: where there is a mismatch, either a correlative content requirement should be added to WCAG 2.0, or the requirement should be either removed from XAG, or treated merely as a note to implementors. 3. This document also needs to be regarded within the broader context of W3C architectural activities. To be more specific, consideration should be devoted to the prospect of developing a Consortium-wide set of principles, even guidelines, for the construction of web-based technologies, taken into account broad principles of sound design, as well as more particular questions of accessibility, internationalization, etc. I think the principles enunciated in XAG are likely to have greater impact if they are taken up as part of a more general framework. 4. The main strength that I perceive in the current document is its well chosen range of examples, combined with an explanation of why each of the illustrated choices in the design of a markup language has an impact, whether positive or negative, on accessibility. This kind of information is worth collecting, though it may better be presented as a tutorial or a set of principles than as guidelines. Here, more than ever, it is important to convey conceptual understanding to the designer, rather than to set forth a prescription. What must be borne in mind, I would argue, is that new markup languages are likely to be developed in response to unforeseen problems and circumstances, possibly even in domains of data representation that haven't been explored from the standpoint of accessibility, and this is the context in which the developer needs not a checklist, but a set of guiding ideas, examples and suggestions founded on the pertinent expertise of others. On the other hand, if a guidelines document is wanted, then it will have the disadvantage of demanding greater specificity and testability in the specification of its requirements, hence a reduced scope so far as applicability is concerned, as Ian indicated in his thoughtful contribution to the discussion. 5. I would welcome any move toward a W3C-wide set of principles, or even guidelines, for the design of interoperable, internationalized, flexible and accessible technologies, and would encourage moves toward harmonization of efforts in this area, aiming at the creation of either a single document or a series of closely coordinated and integrated publications. 6. Before the present draft proceeds farther, it is time to make basic, strategic choices regarding its scope, content and ultimate status.
Received on Wednesday, 18 September 2002 05:02:59 UTC