These are the comments received on the w3c-wai-gl mailing list about the 24 August 2001 Public Working Draft of WCAG 2.0. I have attempted to order them as they appear in the document, with some general issues appearing at the beginning and end. A list of editorial issues is at the end. Wendy Chisholm, 9 Sept, 2001.
The first sentence of the Purpose refers to 'creating accessible Web sites' but an 'accessible web site' remains undefined in the document. Suggest a definition of an accessible web site. One possibility 'An accessible web site is one that is easy and satisfying to use for people with disabilities'. Graham Oliver - 4 Sept 2001, #2.
Change first sentence to: "...creating Web sites that are accessible to more people." also deal with in conformance. The first sentence does suggest a binary definition of accessible and the group realizes it should be more gradiated.
I am unsure what the 'How to read this document' section is for. One of the issues of web sites in general is that designers 'impose' an information heirarchy on users that 'makes sense to the designers'. The statement 'How to read this document' seems similar to me. Suggest 'How to get the most out of this document' or 'Overview' (The latter seems closer to the contents of the section). Graham Oliver - 4 Sept 2001, #2.
Jo Miller and Charles Munat will propose a rewrite of the introductory material (everything from "Introduction" up to "Guideline 1...."). Starting from scratch to bring flow back to the document. Attempt to shorten. Some may be placed in other documents. Want to focus on guidelines, revisit intro as we get the rest sorted out. Will break into chapters to help treat it on its own. Will add a note to this effect at the beginning of the intro. Collect open issues on intro, revisit later. Focus on issues rather than wordsmithing.
The target audience defined in the WCAG charter does not align with the definition of audience in the latest draft. Graham Oliver - 28 August 2001.
Refer to the Requirements document, section 4 - Write to a more diverse audience that takes the requirement in the charter and attaches groups and purposes to it. The current section in the WCAG 2.0 draft, does need work. We have discussed the importance of supplementary material as well as the need for the document to stand on its own.
Are there plans to provide this document in formats other than that native to the web to enhance the review process? If so, When will this be done? David Poehlman - 28 August 2001.
Editor's note: a version in PDF was provided, but this is still a Web format. David wants plain text.
As with WCAG 1.0, we will provide a variety of formats. We will try to incorporate that into our editing process asap.
In reference to the Note to reviewers in the Scope section that reads:
Note to reviewers: it has been proposed to include a discussion of accessibility vs usability and how we define our scope.
I support this in perhaps the veign that other moves on accessibility such as that spawned by the ada make the physical world more usable by the general public. It seems to me that accessability may even encompass usability. David Poehlman - 28 August 2001, #2
My take on the difference between usability and accessibility is simply in the 'audience addressed'. That is using the definition of an accessible web site above
Graham Oliver - 4 Sept 2001, #2.
This is related to the introductory material and therefore put on hold as with the rest of it.
The success criteria indicates that interactive scripts need a "functional equivalent such as a form". This should be removed from the success criteria. Andi Snow-Weaver - 7 Sept 2001.
In reference to the definition of non-text content that appears under checkpoints 1.1 and 3.4:
Non-text content includes images, text in raster images, image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. Note to reviewers: This definition is under discussion. Suggestions are welcome.
Checkpoint 1.1 examples
Examples (informative) Example 1: a short label. A right arrow icon is used to link to the next slide in a slideshow. The text equivalent is "Next."
It would be best if the alternative equiv in this case were something like: "slide 22 next in series" or "next slide".
Example 2: a short label and a longer explanation of a data chart. A bar chart compares how many widgets were sold in June, July, and August. The short label says, "Graph of the numbers of widgets sold in June, July, and August." The longer explanation provides the data presented in the chart.
take out the word graph in the short label.
Example 3: a short label and a longer explanation of animation. An animation shows how to tie a knot. The short label says, "An animation showing how to tie a square knot." The longer explanation describes the hand movements needed to tie the knot.
the short label should be "how to tie a square not".
@@ who wrote?
Checkpoint 1.2 Provide synchronized media equivalents for time-dependent presentations
I don't understand this How about 'Provide captions and/or audio descriptions for multimedia presentations' Graham Oliver - 28 August 2001, #2.
Checkpoint 1.4 uses the phrase "natural language."
Graham Oliver - 28 August 2001, #2.
Checkpoint 2.1 has the following note:
Note to reviewers: We are currently discussing the scope of this checkpoint and what is required. Does providing multiple site navigation mechanisms increase accessibility or are we trying to get at something else? Refer to the benefits for the issue we are trying to tackle. Suggestions are encouraged. How do we set limits for when to apply this checkpoint? If a site consists of only 5 pages, a site map might look exactly like the home page.
Checkpoint 2.3 Either give users control of mechanisms that cause extreme changes in context or warn them of pending changes.
The word "pending" seems to indicate that something will happen regardless of what you do. Perhaps we need a different word as the example: "Link will open in new window." suggests here? David Poehlman - 28 August 2001, #2.
Checkpoint 2.3 Example 1 says:
Example 1: a form to deactivate pop-up windows. Provide a checkbox on a page of links to let the user select whether they want the resultant pages to appear in new windows or not.
I see a possible danger here. will I be able to undo the check box? suppose I am deep into the site or someone else has taken over browsing the site or I forget to check the checkbox? I may be using a user agent that does not support mechanisms that allow for this type of user interaction and this may not be under my controll. Could we discourage the use of new window spawning?
Checkpoint 2.4 Example 2 says:
Example 2: a news site that is updated regularly. A new site causes its front page to be updated every 1/2 hour. The front page contains minimal text and primarily consists of links to content. A user who does not wish the page to update selects a checkbox. The checkbox is in the "user preferences" portion of the site which is one of the first links on each page.
It's nice that there is a link to the site settings preferences though I still have a problem with sites providing an interface for manipulating their comment that may not be supported in some user agents and may not be necessary in others and may again be difficult from a verification and testing stand point. I have seen sites that provide some content manipulation capabilities and for many users, they seem awkward.
David Poehlman - 28 August 2001, #2.
Checkpoint 2.4 Either give users control over how long they can interact with content that requires a timed response or give them as much time as possible.
one example that is quite problematic but which is not included here is where you are litterally timed out after what constitutes a period of inactivity by a site for security reasons. Instead of being timed out, you should recieve an opportunity not to be timed out. @@ who from?
Suggest "if generic event handlers are not available, provide at least two device-specific event handlers. If the action or result of the action can be discerned textually, one of the device-specific event handlers must be encoding." Andi Snow-Weaver - 7 Sept 2001.
The success criteria indicates that "where possible, the user is allowed to select from a list of options rather than generate text". For blind users, this is not always desirable if the choices are intuitive and the list is long. For example, if the list is the 50 states, you should be able to enter the state without having to listen to all the choices in order to select one. Andi Snow-Weaver - 7 Sept 2001.
There are other types of input errors that can be "handled". Examples are validating that the double entries of an e-mail address or a password match. Andi Snow-Weaver - 7 Sept 2001.
Graham suggested rewording Guideline 3 as, "Create ('passive') content that is easy to understand". He also proposed a new checkpoint that would have a variety of "sub-checkpoints." We do not have "subcheckpoints" but we do have success criteria. I include his proposal with the assumption that subcheckpoints could be mapped to success criteria in some way and that a "barriers" section would compliment the "benefits" section, or perhaps combined in some way. (Wendy Chisholm, 9 Sept 2001).
Graham Oliver - 4 Sept 2001, #2.
Graham Oliver - 4 Sept 2001, #2.
Checkpoint 3.3 has the following success criterion
the audience is anticipated to have a wider range of educational levels and background knowledge than expected,
Couldn't penetrate the meaning of this sentence - .Graham Oliver - 4 Sept 2001, #2.
I don't see anything that makes it obvious that items like edit boxes, check boxes, radio buttons and the rest of the input controls on web pages need to have some sort of label however it is achieved. To me this should be made more explicit in the WCAG as it is a big problem faced by folks with disabilities in using web sites. Kelly Ford - 28 August 2001
Checkpoint 3.4 Supplement text with non-text content.
I've seen a lot of discussion on this topic not the least of which bears out the fact that there is no consensus on a lexical form for this. I ask also, do we then provide text alternatives for the non text alternatives? Text only pages are not accessible to lots of people so some indication of links, top, bottom, devisions, buttons and the like should be on them and perhaps some formatting and font styling if this is what you mean here. Anything that can aid in comprehention of a site should be employed if possible and prudent. This is kind of a turn around look at the other view. One should not go too far either way. While making sites attractive and orientative to those who cannot utilize text, it will be necessary to be sure that textual comprehention is aided as well and not necessarily in too simple a fashion as that may be a barrier in and of its self. David Poehlman - 28 August 2001, #2.
Success criteria 5 says "is supported by user agents and assistive technologies". This should read "is supportable by user agents and assistive technologies". If a technology has documented accessibility support and you implement your site according to the specification (per checkpoint 4.2), your site is "accessible". User agents and assistive technologies have a responsibility to support the spec too. If they don't support it yet, it is a different issue which is covered under checkpoint 4.4. Andi Snow-Weaver - 7 Sept 2001.
Success criteria 1 is covered by 4.2. Success criteria 3 is covered by 2.5. Success criteria 4 should be a recommendation, not a requirement. Andi Snow-Weaver - 7 Sept 2001.
Checkpoint 4.3 Success criterion #4 contains the following note:
Note to reviewers: there is active discussion on the requirement of user testing as success criterion.
since these are guidelines and not requirements, it seems reasonable and prudent to me that user testing is a good test of how something works if done correctly. Perhaps the word appropriate should be added when addressing issues of user testing. appropriate user testing should be part of any site development if for no other reason than to gage the effectiveness of the site as intended. If I had to access the web without assistive technology, I couldn't even crawl through it. assistive technology in this instance also includes someone to read the site and possibly manipulate the mouse. I might be able to crawl into a building. David Poehlman - 28 August 2001, #2.
Split 'content' into
Graham Oliver - 4 Sept 2001, #1
My reasoning is
One apparent consequence of this is to move checkpoint 2.6 into section 1 (if the user has no control over the frequency of the flickering)
Also ,the 'ease of use' moves from '3' to '2'. Note that I have also added the word 'abilities' to the first 2 principles. This mirrors comments I heard recently from Neil Scott from the archimedes project at Stanford Increasing focus on abilities would appear to create a more 'powerful' statement of 'working with' rather than 'working for' people with disabilities.
Graham Oliver - 4 Sept 2001, #1
Throughout the document the text '(informative)' appears alot after 'Benefits'. Is this necessary as the 'How to read this document' section details that 'benefits' are 'normative'? - Graham Oliver - 4 Sept 2001, #2.
$Date: 2001/09/10 17:14:33 $ Wendy Chisholm