RE: techniques for author-defined UI controls

aloha, jon!

you wrote, quote
The HTML 4.0 does not provide much guidance in implementing the ACCESSKEY
feature
unquote

to which i reply (yet again) that that is precisely the reason why it is
necessary for any UA developer who decides to implement ACCESSKEY to address
(and document!) not only how it can be invoked (i.e. the triggering mechanism),
but what will actually happen when the ACCESSKEY is invoked by the user

why (with apologies to PETA) have i continued to beat the ACCESSKEY horse? 
because 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, as i have pointed out in the past [reference 1] the HTML4 Rec's definition
of ACCESSKEY [reference 2] is flawed , but not fatally so, as the
implementation of ACCESSKEY by a major mainstream UA manufacturer shows... yes,
there are problems with MSIE'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...  ACCESSKEY wouldn't be broken in MSIE had its
developers provided either an "ignore-next-input" mechanism [reference 3] or a
configuration option -- such as that which i outlined in section 2.1.1 of my
proposed techniques for author-defined UI controls [reference 4] -- which would
allow the user to define what key to use as the ACCESSKEY trigger... 

ACCESSKEY can be gracefully implemented precisely because the author only
defines half of the equation -- it is up to the user agent to define the
triggering mechanism, and it is that loophole which may well allow it to be
implemented in a platform (if not device) independent manner

and, since the HTML4 Rec is ambiguous as to the precise action that the use of
an ACCESSKEY should invoke, it is, therefore, the responsibility of the user
agent to (at least) document what action the user can expect to be performed
when the ACCESSKEY is invoked -- whether

a) the element for which the ACCESSKEY has been defined receives focus
or
b) the element for which the ACCESSKEY has been defined is activated -- in
other words, whether the link will be followed or whether the form control will
be toggled or activated

optimally, i would like to see the choice between move-focus-to-element and
activate-element reside with the user -- which isn't an unreasonable request,
in light of the fact that JFW 3.31 users can now -- using Henter-Joyce's
list-of-links script for MSIE5 -- choose to either move focus to a listed link
or activate the listed link [reference 5]

which brings me back to a point that i made at the redmond face2face --
adaptive technology has traditionally been compensatory, endowing the end user
with functionalities that were either overlooked by the mainstream
application's developers, or which were implemented by the mainstream
application's developers in a device dependent manner...  what, then, is
Henter-Joyce's implementation of a user configurable slash choose-on-the-fly
list-of-links other than (1) a very sound idea, and (2) a case of convergent
evolution?

we, like the developers at Henter-Joyce, should be looking forwards, and not
backwards,
gregory.

References
1. my summation of the ACCESSKEY issue for the UA mailing list
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0008.html 

2. definition of ACCESSKEY in the HTML4 Recommendation:
http://www.w3.org/TR/REC-html40/interact/forms.html#adef-accesskey 

3. three pointers on implementation strategies for ACCESSKEY and pass-through
slash ignore-next-input mechanisms:
3A) http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0224.html
3B) http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0233.html
3C) http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0235.html

4. proposed techniques for implementing ACCESSKEY
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0184.html

5. description of JFW 3.31's MSIE 5.0 scripts
http://www.hj.com/JFW/JFW331NEW.html#anchor99738
--------------------------------------------------------
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, 3 November 1999 16:05:31 UTC