- 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