Summary of WCAG 2.0 comments
From the 25 January 2001 public
working draft. I took notes during the F2F of some of the resolutions, the
rest are in the minutes from the meeting. (Wendy Chisholm $Date: 2001/03/07
22:49:42 $).
Summary
- 6 people sent comments
- None of the comments are the same (except about broken links)
- Comments received for Guidelines 1, 2, 3
- Comments received for Checkpoints 1.1, 1.4, 1.5, 1.6, 1.7, 2.1, 2.2,
2.3, 2.4, 2.5, 3.2, 4.3
- One person specifically answered Judy's review comments
- A few other interesting comments and compliments
Overview
- Guidelines
- Guideline 1
- "Design in a way that allows..." (Graham) - open issue
- Distinguish more between Guidelines 1 and 2 (Graham) - highlight
difference - yes.
- Visual presentation mush include illustrations, minimum of 1 per
page. "Design content that be presented visually (images and
text), auditorily, or tactually, according to the needs and
perferences of the user" (Anne) - wrong guideline version. what
about laws - what picture include?
- Guideline 2
- differentiate from gudieline 1 (Graham) - see above
- the word "preferences" is easy to interpret as saveable
settings, which isn't what you mean (Aaron) - that is what we
mean. it does refer to saveable settings.
- Afriad it sounds like we're limiting people's creativity in
guidelines 2 and 3. Explain in common sense terms. (he gives
examples) (Aaron) - may be requiring more creativity. yes,
limiting space. include short rationale.
- Guideline 3
- preamble is confusing (Daniel) - move to intro applies to all.
maybe shorten to first sentence.
- usability?? (Rob)
- In intro - 4 categories - presentation, user interaction,
comprehension, technologies. short phrase for each guideline and
checkpoint.
- Categories, Guidelines, Checkpoints, Techniques - open issue
(functional testing)
- Checkpoints
- 1.1 Example is unclear (Daniel) - editorial, wendy fix.
- checkpoint 1.4 - is the mention of italics, presentation specific?
use emphasis instead? - delete sentence. it is not presentation. need
similar style for each checkpoint.
- checkpoint 1.5
- is hard to understand (Graham) - proposed suggestion
- should it be combined with 1.4? (Aaron)
- checkpoint 1.6 surprised not part of guideline 2 (Daniel)
- checkpoint 1.7
- confusing to have style sheets as an example of how to mitigate
since style sheets is an example of a technology that can be
turned off or not supported (Graham)
- surprised not part of guideline 4 (Daniel)
- hard for most people to interpret. need resources for
developers. be explicit and say, "need to work with Lynx?" use
"standards" instead of "technologies? (Aaron) - agree open issue
re: newwer.
- move to guideline 4. WC do editorial changes.
- 2.1
- surprised not part of guideline 3 (Daniel)
- asks for consistency yet talks about navigation mechanisms.
(suggests new checkpoint) (Aaron)
- 2.2
- surprised not part of guideline 3 (Daniel)
- Up to user agent. Perhaps part of 3? general design principal.
delete. (Aaron)
- 2.3 and 2.4 - user agent issues. should be removed or moved to a
general "what basic problems we're trying to solve" document to
explain effects on users. (Aaron)
- 2.5 need an example (Aaron)
- 3.2 how about "Emphasize underlying structure of the data through
the presentation" (Aaron)
- 3.3 Who won't do this? (Josh)
- 4.3 is too vague for intrepretation by people who are unfamiliar
with accessibility (Aaron)
- Responses to review questions sent by judy
- Steven only one to respond to directly
- What background knowledge is assumed?
- Glossary definitely needs to be developed.
- Provides definition of "accessible"
- 3 layered approach, fine but concerned about how much knowledge it
takes to navigate to the appropriate place in a different layer.
Assumptions of background knowledge should be stated.
- Compliments and other interesting comments
- Appreciation of the emphasis on the end user. (Steven)
- Guideline 1 is my favorite - nice and down to earth. Guideline 4 is
interesting because it considers the future (Aaron)
- recipe metaphor (Anne)
- Broken links (Daniel and Dave)
Comments by author
- I would like to see the title of Guidelines 1 and 2 altered to read
'Design in a way that allows........' My reason being that the word
'content' is used to make an important distinction in Guideline 1.5 and
has a specific meaning within that guideline.
- It took me about 10 minutes to realise that the title of Guideline 1 was
different to the title of Guideline 2. Perhaps an emphasis on the word
that is different in each title would be better.
- I found guideline 1.5 hard to understand. I can discuss this with anyone
who may be remotely interested ;-) Another possibility 1.5 Separate
content from the way it is presented By separating content from the way it
is presented, the range of people that can usefully interpret that content
is increased. The primary way of achieving this is by the use of external
style sheets.
- I am confused about one part of Guideline 1.7 To me a style sheeet is an
example of 'newer technology (that) is (/can be) not supported or turned
off'. So having a style sheet as one of the technologies that can help
mitigate against these circumstances really confused me. This may be
helped by an example.
- I really appreciate the emphasis in the new guidelines on the 'end
user'
Guideline 1 should somehow say that the visual presentation must include
illustrations , a minimum of one per page ... Perhaps Guideline1 could say:
"Design content that be presented visually (images and text), auditorily, or
tactually, according to the needs and perferences of the user."
Anne responds to william's post (in the Steven McCaffrey thread): that
recipe is a good metaphor. The novice follows it exactly while the more
experienced cook can make some changes since they are more aware of how
different ingredients interact or how different temperatures create different
affects.
Specifically answered the review questions in Judy's e-mail.
Is this draft easier to understand than 1.0?
- easier to understand: It depends what this phrase means. I may
"understand" something without being able to perform a task because the
term is not on a low enough level to be executed. What background
knowledge is assumed?
- filling in the Glossary ...: Yes, it is not possible to give very
specific comments without the definitions. if the definitions are critical
to understanding the content.
- terms that are not listed...: Yes, accessible. In WCAG 1.0 the
definition was " Content is accessible when it may be used by someone with
a disability.", which, logically, by the use of "someone" could be
interpreted to mean "at least one". This is not the intent. Rather it
should read: Content is accessible if it may be used by a wide range of
people with various characteristics, technologies, and environments" or
something like this. Some on the WAI IG list still seem to believe that if
just some people can, potentially (if only they had browser x and screen
reader y ...), access the page, then it is accessible. This is of course
not the case.
What do you think of a 3-layer approach?
- A three layerred approach is a good idea. However this means the linking
to the next layer is even more important. The more abstract layer X is,
the more guidance is needed to select that specific portion of the next
layer that is needed to implement the guideline. It could be the case
though that the generalized guidelines are so abstract, it is not clear to
the reader which link to choose. In other words, paradoxically, he will
have to read all of layer 3 in order to figure out which link in layer 2
to select. Technically speaking, I would not describe the guidelines as
"how" instructions but rather "what" instructions. The techniques are how
items. This distinction is critical because the task of a document like
this is to carefully and unambiguously provide the reader with a path from
high level what items to the corresponding how items. One person's what is
another person's how. The difference is background knowledge. I
don't know what background is assumed. There were many discussions on WAI
IG about exactly how conversant with HTML a developer needs to
be.
Have we generalized the guidelines too much (22 checkpoints vs 60)
- Again this depends on assumed background knowledge. Almost by definition
a generalization of a specific instance cannot be understood without
knowledge of that specific instance. Generalizations can help traverse a
tree of knowledge from root to leaves or to build a tree from leaves to
root. If "to generalize" means "to group together, to bring under one
category", then I must already have knowledge of the individual instances.
However, if you are teaching something, you might start at the highestt
level and then give specific examples later. This means though that real
understanding is deferred until all the examples are internalized. If the
highest levels are clear enough, it will be possible for the reader to
generate her own examples. Generalization can provide a framework in which
to place a range of specific instances at a later date.
- Which kind of generalization is intended? In other words, are you trying
to get the reader to create the tree or to traverse an existing one? If
you want the tree to be traversed, then it must be clear to the reader at
each level, using knowledge at that level only, which child node is
appropriate. Do I go to the HTML, XML, SVG, etc techniques document? If I
don't even know what these languages are and have never seen examples of
these how will I know which link to choose?
- What level of knowledge is assumed? Mathematics is often used as an
example of a prerequisite intensive subject meaning knowledge of the
subject must be "built up" on analogy with the construction of a house.
One cannot understand Calculus without having a thorough knowledge of
Algebra, Trigonometry and Analytic Geometry. Algebra in turn cannot be
understood without a thorough knowledge of Arithmetic. However, recently,
in some educational circles it is thought that teaching the "concepts" of
Calculus can be taught perhaps as early as say fifth grade, that is,
without the prerequisite knowledge of Algebra etc. Well, sure, the
"concept" of rates of change, slope etc. can be understood but this does
not mean a fifth grader could actually calculate a derivative. So, it
depends on what you want your students (readers) to be able to do. You
have to break it down to very small pieces: I want my students (readers)
to be able to do: <list>" "I am assuming my student (reader) already
can do the followoing:<list>"
Several comments about Intro (e.g., use of styles to denote edits)
I am surprised that
- 1.6 Use device-independent event handlers. is not part of Guideline 2.
Design content that allows interaction ..
- 1.7 Ensure that content remains accessible when newer technologies are
not supported or turned off. is not in Guideline 4. Design for
compatibility and interoperability
- 2.1 Provide consistent interaction behaviors and navigation.. and 2.2
Minimize content that interferes with the user's ability.. are not in
Guideline 3. Design for ease of comprehension
Also
- In Example 1 it's unclear what the "that this is what he is doing" is
referring to. I thought it was the "talking to himself" part, but the
short description is about the "lays the trail" part.
- Example 1. A clip from a movie is published on a Web site that
contains a scene where a child is trying to lure an alien to the
child's bedroom by laying a trail of candy. The child is talking to
himself as he lays the trail, but it is not obvious when not watching
the video that this is what he is doing. Therefore, a short
description is interspersed with the child's talking that says
"Charlie lays a piece of candy on each stair leading to his room."
Similar descriptions are included throughout the rest of the
clip.
- In 2.1 ... These [Navigation] mechanisms may include: .. image maps.
image maps are just a way to implement a toc/index, etc. so should not be
there, different level.
- The preamble of Guideline 3 is confusing. In the XMLGL PF work, we're
now making the difference between XML languages used to represent data
(and structured database is ok) and XML languages used to represent
metadata (whether it's a program like XSLT or XML Query, or statements,
like RDF). The UI part is confusing. UI is always supplied by the client,
by definition.
- Note: this guideline is applicable only in circumstances in which
the Web content is intended to be presented to a human reader. A
structured data base or collection of metadata, in circumstances where
the user interface is supplied entirely by the client application,
lies outside the scope of this guideline.
Broken links
Daniel and Dave Poehlman both pointed out broken links. Use of ID rather
than A name.
Aaron Leaventhal (sent privately to Wendy)
- Guideline 1 is my favorite - nice and down to earth. Guideline 4 is
interesting because it considers the future.
- Checkpoints 1.4 & 1.5 seem related. Should they be under the same
point?
- You mention italics in 1.4.1. Is that presentation specific? Should you
call it emphasis instead?
- For 1.7, this is going to be hard for most people to interpret. There
needs to be some kind of on-line resource so average developers can find
out what's current. Perhaps we need to be explicit instructions for HTML
developers, such as "hey - make sure your site can be browsed with Lynx,
or any plain HTML browser". Also, should the checkpoint wording say
"standards" instead of "technologies"?
- In Guideline 2, the word "preferences" is easy to interpret as saveable
settings, which isn't what you mean.
- I see what you're trying to do with Guidelines 2 & 3. I'm afraid,
with some checkpoints, it sounds like we're trying to limit or control
people's creativity. Perhaps what's needed is an explanation in common
sense terms, the kinds of people who need special consideration. For
example, "Your audience may contain people with cognitive disabilities,
who have trouble understanding complex sentences, and may be easily
distracted by advertisements, animations and complex layouts".
- The brief description of 2.1 asks for consistency. At first glance, this
has little to do with "needs and preferences." Also, how do the ideas for
accessible navigation mechanisms, such as links to jump to the next
heading, relate to 2.1? Doesn't that make the page *less* usable for some
people? Perhaps we need a checkpoint, "consider alternative navigations
mechanisms to enhance accessibility". In any case, the description for 2.1
is a bit strange considering it's title.
- On 2.2, I'm not sure it's appropriate to ask corporate content
developers to provide an advert free version of their website. That's
their revenue stream. It's up to the user agent to allow freezing
animations. As a whole, I think this checkpoint shouldn't exist. It should
be a separate document that describes common problems of users (the clear
writing checkpoint is another example of this). We should try to get
content developers to understand the basic problem we're solving, so that
it's in their heads while they design. If this stays, perhaps it should be
under guideline 3?
- 2.3 & 2.4 - These seem completely like user agent issues. I think
they should be removed. Perhaps in the "what basic problem are we solving"
document we can explain how this affects users.
- 2.5 ... Interesting, can we point people to embeddable search services
or open source technologies that satisfy these needs? Otherwise we're
asking a whole lot of people to invent the same wheel. That seems
counterproductive, because everyone will make it work differently.
- 3.2 - how about "Emphasize underlying structure of the data through the
presentation"
- I think 4.3 is too vague for intrepretation by people who are unfamiliar
with accessibility.
$Date: 2001/03/07 23:08:02 $ Wendy Chisholm