- From: David Poehlman <poehlman@clark.net>
- Date: Thu, 02 Dec 1999 08:31:33 -0500
- To: Jamal Mazrui <jamal@empowermentzone.com>
- CC: w3c-wai-ua@w3.org, w3c-wai-ig@w3.org
Hello Jamal and all. Much of what you propose here seems to be covered or coverable in the techniques document. Of that which is not , would you be willing to accept that we expand it to cover it there? Greg Rosmeta and I have both ben concerned with both configuration and navigation issues and much work on this aspect of user agent development has been drawn out in the techniques document which for your reference incase you've not included its consumption in your review can be found at: http://www.w3.org/TR/WAI-USERAGENT-TECHS/ and is referenced in the last call notification. I appreciate your effort and input at this pivotal point in the development of the work. Please continue if you like to review and provide feedback to the process as we move forward toward ending this part of the process. Specifically as it reflects the guidelines propose checkpoints that are now missing or specific checkpoints that need rewording and prose that rewording if you could. Thanks! Jamal Mazrui wrote: > > The following is my input on the "last call" working draft of the > W3C's user agent accessibility guidelines: > > * In the guideline that mentions "relative position" as a > status message, also include "absolute size." An example of its > use is being able to determine the size of the current web page > in a browser in order to decide whether to read it now or > download it for later reading. The size should be stated in > commonly understood units of measure, sometimes in more than one > way to ensure it is readily understood. For example, the playing > time of an audio file could be stated in terms of hours, minutes, > and seconds. The size of a primarily text based web page might > be stated in both kilobytes and screens, where a screen of > information is calculated based on the current viewport (often a > window where the PageDown or Spacebar key invokes the next > screen). > > * When applicable (such as with a computer based browser), > provide a mechanism for downloading a batch of links to the > current page. It is common for a user to want several linked > pages downloaded, yet most browsers today require that each link > be visited and separately downloaded. An example would be a > dialog that includes a listbox of file extensions representing > files linked to the current web page. The user could select one, > multiple, or all of the extensions to be downloaded in an > automated process. The file names would be the same or closest > equivalents on the user's computer in a directory/folder that > could be chosen in another control of the dialog. An enhanced > option would place all downloaded files in a compressed archive > using an industry standard format (such as the public domain .zip > one). > > * Support the resumption of partial downloads so that a time > consuming but incomplete download is continued rather than > restarted. > > * When the system focus is on text (either plain or enriched), > support navigation by character, word, line, paragraph, and > screen. Precise and flexible navigation of this kind with a > system cursor is often useful when browsing with accessibility > aids. Evidence of this point is that the leading Windows screen > readers have super-imposed such navigation on a popular web > browser that does not natively support it (e.g., Winvision, > Window-Eyes, and JAWS with Internet Explorer). > > * In the guideline that mentions searching, also include ways > of indicating the beginning and direction of the search (forward > or backward starting from the current focus, beginning, or end of > the document). > > * In the guideline about status messages, also include an > indication when a web page is finished loading, an audio file is > finished playing, a video file is finished displaying, etc. The > mode of the "finished" status message should include text, audio, > and/or visual means of presentation. > > * In a guideline about keyboard input, also state that each > button on toolbars should have an equivalent keyboard shortcut. > Mouse clicking such buttons is often the primary way that users > without disabilities perform common commands. Given the benefit > of keyboard shortcuts for various disabilities and accessibility > aids, the user agent should be designed with complete equivalence > between buttonbar and keyboard operation. > > * In the guideline about documentation in HTML, also specify > that a manual should be available as a single, complete HTML file > when a system of multiple, linked files is provided as well. > > * In a guideline about viewports, also include a configuration > setting by which the application automatically maximizes the > current view port. For example, the parent window of the browser > would automatically be maximized when launched, and each child > window would automatically be maximized when it received input > focus. Maximizing does not necessarily mean occupying the whole > screen or parent window; it means expanding the current window > so that the need to scroll horizontally or vertically is as > * little as possible. > > I hope the above comments are useful. Although I reviewed the > material more than once, I may have missed or misunderstood > points that are already addressed. In such cases, perhaps my > comments can reinforce a need for emphasis or clarification. > Thank you for the open, inclusive, and systematic process that > has been evident in the development of these guidelines. > > Regards, > Jamal -- Hands-On Technolog(eye)s Touching The Internet ftp://ftp.clark.net/pub/poehlman http://poehlman.clark.net mailto:poehlman@clark.net voice 301-949-7599 Dynamic Solutions Inc. Best of Service for your small business network needs http://www.dnsolutions.com
Received on Thursday, 2 December 1999 08:33:13 UTC