- From: Kynn Bartlett <kynn@idyllmtn.com>
- Date: Sat, 2 Aug 2003 22:42:43 -0700
- To: w3c-wai-gl@w3.org
- Cc: public-comments-wcag20@w3.org
WCAG 2.0 Working Draft 24 June 2003
The W3C has posted a request for reviews of the current draft of the
updated version of the Web Content Accessibility Guidelines (WCAG).
Version 2.0 is intended to improve on WCAG 1.0 as well as going
beyond
simply being a revision to being a rewrite, as I understand things.
I promised Wendy Chisholm I'd take a look, so here's my take on WCAG
2.0.
Comments are in no particular order; they're simply what popped into
my head when reading through the draft. I will attempt to identify
the
key points with <strong> emphasis; these comments are numbered for
reference. A permanent URL for this post is
http://www.maccessibility.com/archive/000764.php
A note on approach: Although I am very familiar with WCAG 1.0, I am
not referring to it while reviewing this draft, and in fact, I am
trying to forget that I know it at all. For many people -- from 2004
to 2009, at least -- this will be their first introduction to these
concepts, and the document needs to stand alone as a complete
reference.
1. Organizational: There is a lot of "legalese" at the beginning,
and
that might be a good place for "skip to table of contents" links.
2. Abstract: The final version of the abstract should not describe
this document primarily in terms of WCAG 1.0 -- as per my comment
on "approach" above. The existence of 1.0 can be mentioned, but
the abstract should stand alone.
3. Terminology: "Normative" and "non-normative" are used a lot but
are not defined in this spec. The specific use of "normative"
should be noted under "how to read this document".
4. Audience: I want a better definition of the audience. For a
writing project of this kind of scope, audiences must be defined
clearly and explicitly, as well as how those audiences will use
this document.
5. Priorities and Techniques: Hopefully the final version will not
reference WCAG 1.0 so much.
6. Suggestion: A "conversion document" between WCAG 1.0 and WCAG 2.0
would be helpful.
7. Conformance: This section uses terms before defining them, such
as
"Required Success Criteria" and "Best Practice."
8. Suggestion: I would really like to see a graphical representation
of the concepts for both the document structure as well as the
conformance criteria. Without a visual representation, it is very
hard to understand what's what.
9. Conformance: The terminology Core, Core+ and Extended are not
clear terms. I am concerned that these specific terms, while they
have meaning to the working group, will be opaque to the readers
of the document.
10. Core+ Questions:
How should conformance claims state which Extended Checkpoints
are met? in metadata? in a site accessibility statement?
some other method?
Metadata, accessibility statement, and (ugh) graphic are
all acceptable and should be supported; furthermore,
this
should be an open list not a closed list.
How should conformance claims state how many Extended
Checkpoints
are met? in metadata? with core+n (n=number of Extended
checkpoints)? in a site accessibility statement? some
other method?
In the same way as above, but not literally "core + N".
If Core+ is claimed, should we require a statement about which
Extended checkpoints are met?
Definitely yes.
Is there a separate logo for each level: core, core+, and
extended? If so,what does the logo point to?
Does it have to point to anything?
Comparisons of Core+ conformance claims can not be made unless
detailed information is provided about the Extended
checkpoints that are met.
Yes. Was this a question?
Should detailed conformance information be provided in metadata?
There is doubt that it will be kept up to date,
especially if the site becomesless accessible over time.
Also, we may be unable to require metadata since some
companies have indicated that the legal and ISO 9000
ramifications would prevent them from posting metadata
describing the exact conformance.
Any way to indicate conformance can become out of date.
If companies don't wish to make claims using one or more
of the methods described by this document, they don't
have to. This should not be a barrier for providing
metadata schema for conformance claims.
If it were possible to claim "Core+n" where "n" denotes the
number of Extended Checkpoints that are met, some
developers report that they would be encouraged to meet
more Extended Checkpoints and increase the number they
can report. However, people are likely to compare the
number and these comparisons could be misleading. For
example, a site that claims "Core+2" could be more
accessible than a site that claims "Core+3" depending on
which checkpoints are met.
Heh. Let's call it Extended Minus Four, etc.
11. Scope of conformance claim: For purposes of metadata claims,
scope
should be identified via URI identification whenever possible,
just because that's how the Web tends to function.
12. Overview of Design Principles: The four principles --
Perceivable,
Operable, Understandable, Robust -- are a great example of a
place
where images can be used to reinforce important points. An iconic
representation of each of these concepts would help a lot.
13. User Needs: The statements "cannot hear", "cannot see", etc. have
a tendency to reinforce the notion that all visually impaired
people can't see at all, all deaf people can't hear at all, etc.
Present these instead as user preferences based on what works
best
for each user, rather than as black-and-white disabilities.
Remember that this document may be some Web developers' first
exposure, at all, to the use of the Web by people with
disabilities. Example:
+ Someone who cannot see well may want to hear information
which is usually presented visually.
14. Guideline organization: Guideline one needs some introductory
material explaining what is meant by "perceivable".
15. Clear and simple language: I tried mentally diagramming the
sentence that comprises checkpoint 1.1 and it wasn't easy. I
think
this checkpoint has been overworked and needs to be stated simply
and clearly. Note that this particular way of phrasing the
checkpoint text makes it really impersonal. Compare to:
+ If you use content which is not simply textual, include a
text equivalent for the parts of that non-text content which
can be expressed in words. The text equivalent should convey
the same function or meaning as the non-text content.
This is an extreme example -- from one style ("W3C clinical" to
"Kynn chatty") -- but it is meant to illustrate how a checkpoint
can be rewritten to be understandable.
16. Markup point for 1.1: Suggest using <em> instead of <strong>
on
the words "can" and "can not" in the success criteria.
17. Checkpoint 1.1 "informative" material: Again, "informative" is
used without definition (how does it differ from
"non-normative"??).
18. Checkpoint 1.1 examples: Since this checkpoint is both basic and
vastly complex, some definitive examples of when and where and
how
to use text equivalents should be here, not just relegated to the
techniques.
19. Checkpoint 1.2 editorial note: This is a big headache. Ugh! No
good answer here.
20. Checkpoint 1.3: I don't understand the [information/substance]
phrasing. Are you asking which one is better?
21. Checkpoint 1.3: Because this seems so open-ended -- as with 1.1
--
I would want know what exactly this checkpoint requires me to do.
For example, there are some tags which are rarely used in HTML
4.01 by anyone -- are those required if they convey structural
information? Does this checkpoint ban the use of <b>? Help me
understand it, without going into techniques -- ideally, someone
(like me) who understands HTML 4.01 should be able to "derive"
the
techniques document from reading the guidelines. I don't get it,
though.
22. Checkpoint 1.4 example: In example 2 (where is example 1?) it
talks about "a page title" -- well, you can't use the <acronym>
element within the <title> element! So the page title wouldn't
have anything to indicate what the string "W3C" is supposed to
be.
Furthermore, the acronym element does not indicate pronunciation
-- that is a function of aural CSS, if anything. This example is
misleading.
23. Checkpoint 1.5 phrasing: What do you mean by "more people"? This
is amazingly vague phrasing, and thus problematic.
24. Checkpoint 1.6: This is assuming that there is such thing as
"foreground content" and "background content" -- does this model
make sense, though? Is it generally applicable?
25. Checkpoint 2.1: When you say "at a minimum" I wonder what that
minimum is. If something has multiple functions, are they all
required to work, or is there some minimum defined? Does the
concept of "minimum" as applied here really play an important
role?
26. Checkpoint 2.1 editorial: Be careful how you write that up -- if
something is "less than infinite tabbing" is it still acceptable?
By what criteria can a Web developer judge if there are enough,
or
too many, tab keypresses to access functionality?
27. Checkpoint 2.2: By granting an exception for "competitive or
realtime events" you are making a global value judgment which
says
"it's okay to be inaccessible if you have certain goals in mind."
This is a bad idea, because the "loophole" in this checkpoint
essentially says, "...so it's accessible." Guess what: a
competition is still inaccessible if it is time-based. The
purpose
of this document is to define if a practice is accessible or
inaccessible. Games don't magically become accessible by virtue
of
being games. Inaccessible coding should be labeled inaccessible
if
it is, indeed, inaccessible. There should be no loopholes.
Someone
who requires six times as much time to do something doesn't
magically speed up just because it's a competition -- the
competition is still inaccessible to that person, and should be
stated as such.
28. Checkpoint 2.3: An explanation of "Hz" would be helpful. Not all
Web developers would know what this means.
29. Checkpoint 2.3 Editorial Note: Okay, there's no tool to check for
this. Question: Are there documented examples of anyone with
photosensitive epilepsy ever getting clobbered by a Web page? If
so, can you please point me to them, preferably from a reputable
source (such as a medical journal) rather than just hearsay?
30. Checkpoint 2.4 phrasing: Again, a very ugly sentence diagram.
Huh?
31. Checkpoint 2.4 editorial note: Also, the concept of Web
application further weakens the page/site divide.
32. Checkpoint 3.1 best practice: It should also be possible for
other
data sent with the document, such as HTTP headers, to identify
the
primary language of the document.
33. Checkpoint 3.2 best practice: What's a cascading dictionary?
Which
unabridged dictionary is one required to use? Are there different
ones for en-us, en-uk, en-ca, and en-au?
34. Checkpoint 3.3: Is this written in English?
35. Checkpoint 3.3 best practice: Will this be applied to WCAG 2.0?
36. Checkpoint 3.3 definitions: ASCII art is text.
37. Checkpoint 3.3 "Note": "Designers need to be cautious in deciding
when to use illustrations " -- this reads as if it is
discouraging
the use of illustrations. Please don't discourage the use of
illustrations. Phrasing of this sort will be misinterpreted --
look at how many media articles have reported that you shouldn't
use color.
38. Checkpoint 3.4 phrasing: Whaaaaat? I don't understand what this
checkpoint is trying to say to me.
39. Checkpoint 4.2: Is this checkpoint saying use JavaScript as long
as you say you're using JavaScript? Or does it mean something
else?
40. Checkpoint 4.2 best practice: Are two supporting implementations
sufficient? I can think of things which are supported on Mozilla
and Safari, but not in Internet Explorer. IE is used by the
majority of people with or without disabilities. Can you claim
accessibility if 95% of your audience is unable to access?
41. Checkpoint 4.2 definitions editorial note: I'm not sure I
understand the "low cost" requirement. Can you define low cost?
42. Checkpoint 4.3 phrasing: Many of these sentences seem to be
written as mathematical equations and could use some sort of
grouping symbols around them. :p I get lost in this one's
structure, too. Clear and simple language, please!
43. Checkpoint 4.3 editorial note: I think that process is important
and should be discussed in another W3C document.
44. Appendix A Glossary: Isn't there a WAI-wide glossary in the
works?
45. Content definition: This is probably the worst definition of
content I've seen for a long time. :)
46. Mechanisms That Cause Extreme Changes in Context definition: The
term itself is problematic, especially the overused word
"extreme." "Mechanisms," of course, sounds like some sort of
hardware function. So maybe this refers to an ejector seat. Can
we
get a better phrase?
47. Structure definition: This is as bad as the content definition.
Hope this is helpful. If you want to do your own review, look over
the
draft and send your comments to the working group.
--
Kynn Bartlett <kynn@idyllmtn.com> http://kynn.com
Chief Technologist, Idyll Mountain http://idyllmtn.com
Shock & Awe Blog http://shock-awe.info
Author, CSS in 24 Hours http://cssin24hours.com
Inland Anti-Empire Blog http://inlandantiempire.org
Received on Sunday, 3 August 2003 01:42:52 UTC