W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1999

Review comments from EOWG on UAAG last call

From: Judy Brewer <jbrewer@w3.org>
Date: Thu, 09 Dec 1999 17:11:11 -0500
Message-Id: <3.0.5.32.19991209171111.009706a0@localhost>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:35 GMT