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

Re: proposed changes by Ian 1, 2, and 11

From: Ian Jacobs <ij@w3.org>
Date: Tue, 26 Oct 1999 23:11:16 -0400
Message-ID: <38166D53.F5D22E8D@w3.org>
To: thatch@us.ibm.com
CC: w3c-wai-ua@w3.org
thatch@us.ibm.com wrote:
> Ian, a number of checkpoints have come in under your proposal
> about which I have very serious concerns. I feel like new issues have
> popped up like mushrooms encouraged by the Seattle weather.
> Several issues below.
> quote. 1.5 Ensure that information output as part of operating the
> user agent is available through ouput device APIs implemented
> by the user agent. [Priority 1]  endquote.
> This is too broad-banned (read impossible) to even make sense.
> The new love of API's is a flaw in my opinion. 1.5 could be
> read as a total no-brainer. What could any user agent output not
> through output device API's?

The UA might output information with graphics alone. Or sound alone.
Two dimensional graphical rendering alone is insufficient. I don't
know what it means to talk about a device, however, only the
API to operate the device.
> Quote. 11.1 Document the default input configuration for the keyboard,
> graphical user interface, voice commands, etc. [Priority 1]  endquote.
> I have trouble parsing 11.1. Is it output configuration for the gui, or
> does this ask to document the gui? This is not an accessibility issue.
> Where and why did this arrise. It is important to know accessibility
> features of the UA, but "document the gui?"

It does strike me at first glance as more of a 
usability than accessibility issue, but there's some 
background to this. It was discussed at the December
 1998 face-to-face in Boston [1].

[1] http://www.w3.org/WAI/UA/1998/12/wai-ua-f2f-19981211.html#gl34

Here's  a quote from the 12 November 1998 Draft:

Keyboard access can be vital to users having any of several 
disabilities. The more apparent the keyboard commands are to 
all users, the more likely it is that new users with disabilities
will find them. Readily available information about keyboard 
access is crucial to its effective use by users with visual 
impairments and some types of movement impairments, 
otherwise a user with disabilities may not think they can 
accomplish a particular task or may try to use a very
inefficient technique with a pointing device, like a mouse. 

[2] http://www.w3.org/TR/1998/WD-WAI-USERAGENT-19981112/

This suggests some reasons why it's an accessibility issue. 
> quote. 11.2 Provide information to the user about the current input
> configuration for the keyboard, graphical user interface, voice
> commands, etc. [Priority 1]
> The current configuration is the result of a cascade of author-specified
> user interface information   (e.g., "accesskey" or "tabindex" in HTML),
> browser defaults, and user-modified settings.  endquote.
> Here is a P1 requirement based on what everybody agreed was a
> broken requirement of access key. There is *** No *** reason to
> document tab index. This is another checkpoint from left field.

This is not about access key. The requirement is that, whatever
the current configuration is, the user needs to know it. It
doesn't matter where the configuration came from. It may be
accesskey or it may not. But that  doesn't matter to the user.
The user only needs to know how the user interface currently
works. Otherwise the interface is useless.
> quote. 11.3 Allow the user to control the input configuration for standard
> input devices, including the keyboard, graphical user interface, voice
> commands, etc. "One stroke" access should be possible, for example
> a single key stroke, voice command, or button to activate an important
> functionality. [Priority 2]  endquote.
> Talk about mushrooms. Where in heavens name did this come from?
> If I understand it, it is very hard. No apps do it. 

I can do this in Word, for example. And Netscape Navigator
in Linux. And emacs, of course. And amaya. What about 
internationalization? That requires that functionalities be
extremely separated from the input methods used to activate them;
otherwise the software won't be localizable.
> How can you require P1
> that user agents do it. I think it means that a user can change Ctrl+P for
> print to Alt+F4. These are controls that should *not* be given the UA
> user.

I think it's not a good idea for the user to go against system
but why shouldn't I be able to change some bindings? And who can tell
me which are reasonable and which are not? 

> Quite. 11.4 Use system conventions to provide information to the user
> about the current input configuration for the keyboard, graphical user
> interface, voice commands, etc. [Priority 2]
> For example, on some platforms, if a functionality is available from a
> menu, the letter of the key that will activate that functionality is
> underlined.
> endquote.
> The whole concept of "current input configuration," trying to generalize
> a broken concept, gives me great pain. I know we don't really care about
> my pain. But darn it, I thought at the face to face we agreed not
> to focus on accesskey.

The goal here is exactly to bypass accesskey. The functional

1) How does the tool work out of the box?
2) How can I change the configuration to suit my needs?
3) What's the current configuration?

It so happens that the current configuration may be modified by
the author's specification, but that doesn't change the third
functional requirement.

> Quote. 11.5 Avoid default keyboard, graphical user interface, voice,
> or other input configurations that interfere with or deviate from system
> conventions. [Priority 2]  endquote.
> This seems like a reasonable UI guideline, independent of accesskey,
> why is it here.

> Quote. 11.7 Provide default keyboard, graphical user interface, voice,
> and other input configurations for frequently performed operations.
> [Priority 3]   endquote.
> This seems gratuitous. And then again, I don't understand it. Why here.

Gratuitous may be strong. "Provide useful defaults". I imagine that
this is appreciated by people with motor difficulties who would like
to be able to use the tool without reconfiguring it, and with
one-stroke access to the key features.  That's why it's a P3.

 - Ian
> Jim Thatcher
> IBM Special Needs Systems
> www.ibm.com/sns
> HPR Documentation page: http://www.austin.ibm.com/sns/hprdoc.html
> thatch@us.ibm.com
> (512)838-0432
> Ian Jacobs <ij@w3.org> on 10/25/99 08:04:42 PM
> To:   w3c-wai-ua@w3.org
> cc:
> Subject:  Proposed changes to Guidelines 1, 2, and 11 re: keyboard
> Hello,
> Please consider a proposal [1] to make changes to Guidelines 1, 2, and
> 11
> based on Marja's comments [2] about Guideline 2 and Rich's comments
> about
> some checkpoints of Guideline 1.
> At [1] you will find background information, motivation, list of
> changes,
> and the proposal itself (minus rationale text). Please note that in this
> proposal, there are no new checkpoints. There are three fewer
> priority 1 checkpoints.
>  - Ian
> [1] http://www.w3.org/WAI/UA/1999/10/g1g2-proposal
> [2] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0437.html
> [3] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0098.html
> --
> Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
> Tel/Fax:                     +1 212 684-1814
> Cell:                        +1 917 450-8783

Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814
Cell:                        +1 917 450-8783
Received on Tuesday, 26 October 1999 23:11:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:24 UTC