- From: Judy Brewer <jbrewer@w3.org>
- Date: Thu, 09 Dec 1999 17:11:11 -0500
- To: w3c-wai-ua@w3.org, ij@w3.org, jongund@uiuc.edu
Dear User Agent Guidelines WG, The following are comments from the Education & Outreach Working Group on the User Agent Accessibility Guidelines last call document <http://www.w3.org/TR/1999/WD-WAI-USERAGENT-19991105/>. My apologies for the delayed timing in relaying these to the User Agent Guidelines Working Group. We hope that they are still useful to WG members in considering issues before taking the document to the next stage. The comments include comments from individuals (Alan Cantor = AC; Helle Bjarnø = HB; CL = Chuck Letourneau) and/or from discussion in the working group = EOWG). Regards, - Judy --------------- 5.8 Follow operating system conventions and accessibility settings. In particular, follow conventions for user interface design, default keyboard configuration, product installation, and documentation. [Priority 2] [AC] This should be Priority 1. I have conducted accessibility audits of many software packages that break conventions for user interface design. Almost always, non-standard interfaces create accessibility nightmares. A product with non-standard keyboard mappings may be in some sense “accessible,” but it will probably be so unusable that it is, in effect, inaccessible. The ability to install — or reinstall — software is vital. A product that cannot be independently installed is not accessible: if you can’t install it, use can’t use it. Similarly, a user who cannot get at documentation may not be able to use it at all. 10.3 Allow the user to change and control the input configuration. Users should be able to activate a functionality with a single-stroke (e.g., single-key, single voice command, etc.). [Priority 2] [AC] This is not clear. The second is really a subset of the first, but I suggest presenting them as two points: [AC] 1. The user should be able to customize the means by which control and input are accomplished. This should be Priority 1. I have seen lots of software rendered inaccessible because important features are not readily available. It is common to find important accessibility features poorly documented or undocumented. [AC] 2. The user should be able to activate any feature with a single keystroke, button press, or voice command. This is Priority 2. 10.8 Allow the user to configure the graphical arrangement of user interface controls. [Priority 3] [AC] This should be Priority 2. In accommodating people with learning and cognitive disabilities, the ability to rearrange the interface is sometimes key — the strategy that renders the interface accessible and not. Two other points: [AC] There should be clearer reference for the need for logical tab order (generally top to bottom, left to right) when navigating through a user agent screen by keyboard. [AC] How about something about ensuring that focus indicator is visible AND conspicuous at all times? The lack of conspicuous focus indicator is a big barrier for people who are sighted and who rely on keyboard-only access. If the operating system does not provide it, then the user agent should. (Two examples of exemplary focus indicators: Opera highlights the hypertext links in focus. The default keyboard shortcut in Windows 95/98/NT for task switching is Alt + Tab. This pops a window showing tasks, the one with focus surrounded by a well-defined blue box. ----------------- [HB] There are problems due to delays in localized language versions of the software. It relates to both standard and assistive technology software. The scenarios are different from language to language e.g. in France they develop their own AT software (like braille browsers) while in small language areas e.g. Danish we translate/localize a few products. I know that WAI or W3C can't change this but it is important to inform about it on the WAI homepages and in the guidelines and if we could set up a page with information on differences between different language versions. Your suggestions in the minutes from November 12 could be used to set up this page, and we could urge local people to send in the information as to the policy pages. [JB comment on preceding HB comment: e.g., we should track differences in implementation timelines among localized versions of user agents and/or assistive technologies, as it may affect timing of priority shifts in WCAG. Maybe this is Web Content Guidelines WG work] --------- Additional comments from EOWG discussion [EOWG]: - UAWG should consider what other types of supporting materials may be needed for user agent developers to fully understand and easily implement the guidelines. - perhaps UAAG should add core reference note "How people with disabilities use the Web" in reference section, once that note is more stable. - may need a friendly wrapper or lead-in Web page specifically for assistive technology developers, to explain relevance and focus of the UAAG. -------- Typo & Grammatical comments from Chuck Letourneau: CL: I couldn't help spotting some typo and grammatical problems as I was reviewing the draft, but I end with general comments as requested by Judy. Legend: [suggested text additions] i.e. additions between square brackets, {suggested text deletions} i.e. deletions between curly brackets, CL: comments or questions i.e. comments preceded by CL:. 1.1 Principles of Accessible Design This document is organized according to several principles that [, if translated into actions,] will improve the design of any type of user agent: CL: i.e. principles will not improve the design... implementation of the principles will. Checkpoint 1.4 Ensure that every functionality offered through the user interface is available through the standard keyboard API. Priority 1 The keystroke-only command protocol of the user interface should be efficient enough to support production use. CL: What is meant by "production use"?. This is the first and only time this phrase appears and it is not defined. Checkpoint 2.2 If more than one alternative equivalent is available for content, allow the user to choose from among the alternatives. This includes the choice of viewing no alternatives. Priority 1 For example, if a multimedia presentation has several tracks of {closed} closed captions CL: duplicate word "closed". Guideline 7. Provide navigation mechanisms Sequential access (e.g., line scrolling, page scrolling, tabbing access through active elements, etc.) means advancing through rendered [content] in well-defined steps CL: first bullet point: I presume the missing word is "content". Guideline 8. Help orient the user Provide information about resource structure, viewport structure, element summaries, etc. that will assist the user [to] understand their browsing context. -- Judy Brewer jbrewer@w3.org +1.617.258.9741 http://www.w3.org/WAI Director, Web Accessibility Initiative (WAI) International Program Office World Wide Web Consortium (W3C) MIT/LCS Room NE43-355, 545 Technology Square, Cambridge, MA, 02139, USA
Received on Thursday, 9 December 1999 17:12:23 UTC