- From: <tina@greytower.net>
- Date: Tue, 5 Aug 2003 22:07:18 +0200 (CEST)
- To: public-comments-wcag20@w3.org
Firstly, I would like to reiterate the comments made by Christian Buehler on the use of WCAG 1.0. Currently, the 1.0 version of WCAG is the official standard not only in Germany, but in the EU. Sweden, where Greytower has its main office, is among the countries who has adopted this standard. This means that a smooth transition, as Christian points out, between version 1.0 and 2.0 is absolutely essential. It is not likely that 1.0 will be dropped from use in a good, long, time. Three points can not be emphasized too strongly: 1) There must be an exact mapping between versions 1.0 and 2.0, with new and deleted material clearly indicated and explained. We will all be in it up to our ears if a requirement previously considered important is dropped without a logical, clear, explanation. 2) WCAG 2.0 must have an associated list of checkpoints that can be easily, repeatably, and objectively controlled. 3) WCAG 2.0 must, if at all possible, avoid any and all ambiguities. It can never be said too often: the WCAG 1.0 is now firmly entrenched with several Governments. This is a good thing. The very last effect we want from WCAG 2.0 is muddied waters. Further comments on the draft itself: 1) The document in itself is singularly lacking in clarity. The language is reminiscent of bureaucratese and at times nonsensical. After working with accessibility since 1996, I find myself shocked by sentences such as "These are additional checkpoints that may be reported in addition to Core conformance if the Required Success Criteria for a given Extended Checkpoint are satisfied." This is difficult to understand, hard to sell, and very nearly impossible to follow when reviewing material. I am, personally, still not clear on the exact meaning of the above, and would be hard pressed to explain it to people who will decide on whether or not to comply with this standard. The draft must be cleared up, and the language taken to a point where it is actually understandable; less this becomes an exercise in futility. 2) The concept of "Core" and "Extended" are horribly unclear. What exactly does a "valid conformance" claim mean ? Is the site then accessible to *all* ? To some ? To whom ? Will "core conformance" mean roughly the same as WCAG 1.0 'A' ? 'AA' ? 'AAA' ? This needs to be dealth with right away - preferably by going away from the entire concept and staying with the definitions of priority 1, 2 and 3 from WCAG 1.0 which are clear and easily understandable. However, it might be useful to rename them from the rather nonsensical 'A', 'AA' and 'AAA' to, for instance: "Priority 1: Basic" "Priority 2: Standard" "Priority 3: Complete" A question that must be answered is: why were the priorities dropped ? 3) Issues have been fluffed up and weakened in this draft. We have, for instance, this: "Perceivable. Ensure that all content can be presented in form(s) that can be perceived by any user - except those aspects of the content that cannot be expressed in words." which is a miracle of grammatical pink-bunny-wabbit phrasing. This "guideline" says to me that we should make sure everyone that can see, read, and understand can perceive the content. If you don't do all three, tough. There is no way this is the intent of the WCAG. Even worse is this: "... for markup, except where the site has documented that a specification was violated for backward compatibility, the markup has ... " which gives a carte blanche for site developers to ditch any and all markup standards as long as they tell users what they are up to. Yes, my impressions may be based on being a non-native English speaking individual - but quite a few of those who are going to apply or attempt to apply WCAG 2.0 will be in the same position. If this version of WCAG is to be functional, i.e. be applied and followed, then it needs to cut to the chase and state what is required: "Perceivable. Ensure that all content be presented in form(s) that can be perceived by any user." with an added sidenote of "If one form of content is impossible to perceive by a certain user, it should be transformed - automatically and without information loss - to a form that is perceivable" Suggested rewrites and status changes: (required) 1.1: All non-text content should have a textual alternative explicitly associated with it. If the content has no informational value, signal this by setting an explicitly emply textual alternative. Avoid descriptions if possible, if not avoid descriptions that refer to specific physical realities (ie. "blue" is often nonsensical to a blind person, "high C" might not mean much to deaf visitors) (required) 1.4a: Text in the content is provided in an ISO character encoding scheme such as 8859-1 or 10642, and served according to established standards so that a user agent can identify the encoding without ambiguity. [The handling of UA defaults should go into UUAG] (required) 1.4b: All abbreviations and acronyms are clearly identified with the topic-specific expansion every time they occurr. If the expansion is in another natural language than the one used in the document itself, this change should be clearly identified. (required) 1.6: Foreground content is easily differentiable from background for both auditory and visual default presentations. (required) 2.4: Structure and/or alternate navigation mechanisms have been added to facilitate orientation and movement in content. (required) 3.1: Clearly, and according to standard, identify the natural language of both the document as a whole and - if any part of the document is written in a different language - fragments of it. (moved to required 1.4b) 3.2: The definition of abbreviations and acronyms can be unambiguously determined. (required) 3.4: Layout and behavior of content is consistent or predictable. [unless WCAG 2.0 REALLY requires all sites to avoid having identical layout from page to page - which it doesn't, when reading the criteria] (required) 4.1: All code, whether structure (such as HTML), presentational (css), logical (script), or otherwise should follow a formal, published, standard. If possible, the code should pass validity tests for that same standard. [a note should be added that this isn't strictly possible for scripts, but should ALWAYS be done otherwise] Additional comments: On the editorial comment on glossaries under 3.2: a standard format for linking to glossaries allready exist - atleast for HTML and XHTML - in the form of the LINK element. It would be a good idea to suggest this for use on sites utilizing these markup languages. On 4.2: what is the point ? Why list a set of "required" technologies and not, instead, ensure that the content transforms gracefully to the user's physical reality ? Finally, it seems to me that alot of GOOD things previously in WCAG 1.0 has been removed from 2.0. I've noted that some say that the new version must be judged as a stand-alone specification, but as Christian Buehler points out: 1.0 will be with us for a long time. There are things missing here; things which made sense in WCAG 1.0 and would make sense here as well. The priorities need to come back; and the language tightened up; the ambiguities taken out. As it is, WCAG 2.0 will be terribly difficult to take out in the field; doing so is not a prospect I relish. -- - Tina Holmboe Greytower Technologies tina@greytower.net http://www.greytower.net/ [+46] 0708 557 905
Received on Tuesday, 5 August 2003 16:31:43 UTC