- From: David Poehlman <poehlman1@home.com>
- Date: Tue, 28 Aug 2001 16:34:02 -0400
- To: <w3c-wai-gl@w3.org>
Thanks to all who have contributed to the process so far. I have an over all good feeling about the document and what it is shaping up to be. I took some notes while reading through it, which I share in hopes of assisting and being assisted below. I will be happy to Address any issues raised here or answer questions. I was especially aware of the notes for reviewers and provided feedback where possible. To reach me since I am not on the list, please feel free to reply through this address or use the link to it at the bottom of this message. Begin review: I have placed my comments after portions of the guidelines beginning with the word "comment" and ended each section with three dashes on a line by themselves. --- Note to reviewers: it has been proposed to include a discussion of accessibility vs usability and how we define our scope. Comment: 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. --- 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. Comment: This seems fine to me. the more inclusive the better. --- According to the deffinition of alternatives, I have proposed some rewording of examples of alternatives below: 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." comment: 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. comment: 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. comment: the short label should be "how to tie a square not". --- comment on the use of the word natural as in natural language: perhaps it should be human instead of natural language in order to distinguish it from machine or programming or other processing languages? --- 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. comment: this seems to be a function of the user agent. we are asking in the user agent accessibility guidelines that user agents provide multiple paths to navigation and views. I would caution that If I had to wade through a list of possible views on a site not knowing what the content, presentation or structure of the site was that I might have a hard time with this. I would also caution that being a developper, This might not be something that could be tested through automation and unless authoring tools are quite inteligent in this regard, it may be difficult not only to decide which and how many to provide but to provide them effectively. --- Checkpoint 2.3 Either give users control of mechanisms that cause extreme changes in context or warn them of pending changes. comment. the word pending here 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? --- 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. comment: 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 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. comment: 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. --- 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. comment: this is equivalent to the other check box example I mention above. 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. --- Checkpoint 3.4 Supplement text with non-text content. comment: 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. --- Note to reviewers: there is active discussion on the requirement of user testing as success criterion. comment: 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. --- Hands-on Technolog(eye)s Touching The Internet http://members.home.com/poehlman1/ mailto:poehlman1@home.com voice: 301.949.7599
Received on Tuesday, 28 August 2001 16:39:12 UTC