- 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