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
  1. 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?
  2. 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.
  3. Guideline 3
     • preamble is confusing (Daniel) - move to intro applies to all. maybe shorten to first sentence.
     • usability?? (Rob)
  4. In intro - 4 categories - presentation, user interaction, comprehension, technologies. short phrase for each guideline and checkpoint.
  5. Categories, Guidelines, Checkpoints, Techniques - open issue (functional testing)
• Checkpoints
  1. 1.1 Example is unclear (Daniel) - editorial, wendy fix.
  2. 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.
  3. checkpoint 1.5
     • is hard to understand (Graham) - proposed suggestion
     • should it be combined with 1.4? (Aaron)
  4. checkpoint 1.6 surprised not part of guideline 2 (Daniel)
  5. 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.
  6. 2.1
     • surprised not part of guideline 3 (Daniel)
     • asks for consistency yet talks about navigation mechanisms. (suggests new checkpoint) (Aaron)
  7. 2.2
     • surprised not part of guideline 3 (Daniel)
     • Up to user agent. Perhaps part of 3? general design principal. delete. (Aaron)
  8. 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)
  9. 2.5 need an example (Aaron)
  10. 3.2 how about "Emphasize underlying structure of the data through the presentation" (Aaron)
  11. 3.3 Who won't do this? (Josh)
  12. 4.3 is too vague for intrepretation by people who are unfamiliar with accessibility (Aaron)
• Responses to review questions sent by judy
  1. Steven only one to respond to directly
  2. What background knowledge is assumed?
  3. Glossary definitely needs to be developed.
  4. Provides definition of "accessible"
  5. 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
  1. Appreciation of the emphasis on the end user. (Steven)
  2. Guideline 1 is my favorite - nice and down to earth. Guideline 4 is interesting because it considers the future (Aaron)
  3. recipe metaphor (Anne)
  4. Broken links (Daniel and Dave)

Comments by author

Graham Oliver - 26 January 2001 (sent to w3c-wai-ig)

1. 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.
2. 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.
3. 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.
4. 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.
5. I really appreciate the emphasis in the new guidelines on the 'end user'

Anne Pemberton - 10 February 2001

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.

Steven McCaffrey - 15 February 2001

Specifically answered the review questions in Judy's e-mail.

Is this draft easier to understand than 1.0?

1. 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?
2. 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.
3. 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>"

Daniel Dardailler - 23 February 2001

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