- From: Ian Jacobs <ij@w3.org>
- Date: Fri, 17 Dec 1999 17:04:12 -0500
- To: Judy Brewer <jbrewer@w3.org>
- CC: w3c-wai-ua@w3.org
Judy Brewer wrote: > > 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/>. [snip] > 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. Added to our issues list as issue 179 http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#179 > 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. This is discussed at the face-to-face meeting (issue 129). The WG resolved to leave the second part as part of 10.3. http://www.w3.org/WAI/UA/1999/12/ftf-19991210#issue-129 > 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. Added as issue 180 http://www.w3.org/WAI/UA/1999/12/ftf-19991210#issue-180 > 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. This would be a technique for checkpoint 7.4: "Allow the user to navigate all active elements." The note after this checkpoint reads: <QUOTE> Navigation mechanisms may range from sequential (e.g., serial navigation by tabbing) ... </QUOTE> The techniques document should say that the default order may vary and depends the natural language of the document. > [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. Two checkpoints relate to this: 8.1 Provide a mechanism for highlighting and identifying (through a standard interface where available) the current viewport, selection, and focus. [Priority 1] 9.2 Ensure that when the selection or focus changes, it is in the viewport after the change. [Priority 2] > If > the operating system does not provide it, then the user agent should. Checkpoint 8.1 covers both cases. > (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. [snip] > 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. Can you be more specific about that request? Here's a list of current supporting materials available from the home page: 1) Guidelines 2) Techniques 3) Impact matrix (being updated) http://www.w3.org/WAI/UA/NOTE-UAGL-impact-matrix-19990903 4) Evaluations of different UAs and the guidelines (This will serve to improve the guidelines and show implementation status of checkpoints) 5) Link to Alternative Browser page (EO) http://www.w3.org/WAI/References/Browsing 6) Link to UA Browser Support page http://www.w3.org/WAI/Resources/WAI-UA-Support 7) FAQ in development http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0502.html > - perhaps UAAG should add core reference note "How people with disabilities > use the Web" in reference section, once that note is more stable. Yes, we're waiting for it! > - may need a friendly wrapper or lead-in Web page specifically for > assistive technology developers, to explain relevance and focus of the UAAG. That is a good idea. Added as issue 181 http://www.w3.org/WAI/UA/1999/12/ftf-19991210#issue-181 > -------- > > Typo & Grammatical comments from Chuck Letourneau: [snip] All suggestions incorporated, and one proposal below. > 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. Proposed change: The keystroke-only command protocol of the user interface should be tested to ensure usability. Thank you, - Ian -- Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs Tel/Fax: +1 212 684-1814 Cell: +1 917 450-8783
Received on Friday, 17 December 1999 17:04:20 UTC