WCAG 2.0 Draft - Comments.

 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

AltStyle によって変換されたページ (->オリジナル) /