Ian's Proposed Checkpoint 11.2 (was Re: proposed changes by Ian 1, 2, and 11)

aloha, thatch!

as regards ian's proposed 11.2, 

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.
unquote.

you wrote

quote
  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.
unquote

the P1 requirement outlined in 11.2 has nothing to do with ACCESSKEY, TABINDEX,
or any other specific UI control -- what it does address is a basic principle
of effective software design -- alerting the user which controls are currently
available, while providing a cascade mechanism so that conflicting controls can
be either handled via user intervention or can be gracefully transformed, and
the user alerted to the change...

the beauty of ian's proposed 11.2 is that it succeeds in preserving the point
tim lacey made at the redmond face2face -- the user doesn't care where the UA
obtains the array of UI controls available to him, the user simply wants to
know:
        1. what controls are available
        2. how the available controls can be invoked
        3. what will happen when they are invoked

in this wise, it is irrelevant whether or not a control is author defined, UA
defined, or OS defined -- the user just wants to know what functionalities are
available, and how they can be invoked, and what actions they will perform once
they are invoked...  the note -- and NOT the checkpoint text itself --
specifically mentions ACCESSKEY and TABINDEX because they are not very broadly
supported, despite the fact that acceleration keys such as those which the
author can supply via the ACCESSKEY in HTML4, are not only the keystone of
direct (versus serial) access to any UI that supports direct access, but the
very principle upon which a lot of adaptive technology for persons with motor
impairments is based...  yes, the HTML4 spec's definition of ACCESSKEY is
flawed, but not fatally so, as the implementation of ACCESSKEY by a major
mainstream UA manufacturer shows...  yes, there are a few problems with  IE's
implementation of ACCESSKEY (particularly when the ACCESSKEY defined conflicts
with a standard OS keybinding, such as ALT+F and ALT+H), but that is due not to
a defect in the HTML4 spec, but to the choice of the ALT key as the ACCESSKEY
trigger, and the failure to foresee the ramifications of that choice and to
provide a pass-through mechanism to allow the invocation of conflicting
keystrokes...

i suppose the crux of the argument is: how much control over the UA will the
user be given?

my view is that the less control over the UA the user is allowed, the less that
application deserves to be called a user agent...  the word "user" is part and
parcel of the term "user agent" for a reason -- what is a user agent, after
all, other than a mechanism whereby the user can retrieve and review content?

take the "user" out of "user agent", and what do you have?  last time i
checked, it was a one-way delivery system called television!
        gregory

--------------------------------------------------------
He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <unagi69@concentric.net>
   WebMaster and Minister of Propaganda, VICUG NYC
        <http://www.hicom.net/~oedipus/vicug/index.html>
--------------------------------------------------------

Received on Wednesday, 27 October 1999 10:54:24 UTC