Re: techniques for author-defined UI controls

aloha, al!

sorry for not having responded to you earlier, but my phone line has been out
of order since 22 october, and i was offline for the past 4 days, best-manning
at my oldest friend's wedding...

to address a few of your concerns slash observations on my proposed techniques
for author-defined UI controls, let me begin by stating that the reason the
technique is structured in the manner posted to the UA mailing list is:

a) i was asked to take this action item, although my opposition to any
differentiation between author-defined UI controls and UA-defined UI controls
is quite well known to the WG and to the chair

b) what i offered was a quote first whack unquote, and should not (by any
means) be considered the final word on the topic (especially as regards my
mouth and fingertips!)

c) i included specific techniques for the exposition and invocation of
ACCESSKEY, as that is something upon which i have been working and something
which (in the absence of PF action on the matter, and in the interim in which
it would take for anything stemming from PF action on the matter being
implemented) needs to be explicitly and exhaustively addressed, given the
ambiguity of the HTML4 definition of ACCESSKEY, and the importance of
accelerator keys to accessibility

in any event, enough preamble -- let me address your concerns...

Al wrote, quote
It would seem that you only considered two options: that author-defined UI
elements would be given less attention than client-software-defined UI
elements, or equal attention.  It would seem that there is a significant
difference between author-defined elements and client-software-defined elements
which suggests that _more_ attention needs to be given to ensuring that the
author-defined elements are well explained to the user than for
client-software-defined elements.
unquote

as i indicated above, the parameters of the action item was to define a cascade
method through which an end user could have access to author-defined UI
controls -- especially when such controls have the possibility of interfering
with, or being over-ridden by, UA or OS defined UI controls...  i do, however,
agree that _more_ rather than _less_ attention needs to be given to the
exposition and invocation of author-defined UI controls, and that both the
author and the UA share in this responsibility....

Al also wrote, quote
This has to do with consistency.  The client-software-defined elements are
present in the environment of all visited pages.  If the explanation of what
they do is a little weak, the user can establish what they do by trial and
error, remember what they do, and the weakness of the tutorial information
ceases to be an issue.
unquote

this is not completely true...  if i, as an author, define F and H as
ACCESSKEYs on a page (as i have done on the reformatted RFB&D form [1] which i
have cited as an ACCESSKEY test-bed page in past posts), MSIE won't acknowledge
them, as both F and H are reserved as accelerator keys that -- when pressed in
conjunction with the ALT key -- open the "File" and "Help" menus
respectively...  however, if one uses V or E as ACCESSKEYs (as i also have done
on the aforementioned form), MSIE allows it to over-ride the accelerator keys
which open the "View" and "Edit" menus,. respectively...  and, yet, "View" and
"Edit" are nearly as ubiquitous in the Windows environment as are "File" and
"Help"

there are also a host of UI-controls that are un-invokable when an action (such
as the loading of an image) is being performed, or under other
circumstances...  

moreover,  author-defined accelerator keys were never meant to combat with UA
controls slash keybindings -- that they do is the fault of both poor
implementation and the unsatisfactory definition of ACCESSKEY in the HTML4 Rec,
although i am convinced that it is more the former than the latter...

Al also observed, quote:
For author-defined UI elements, however, they come and go with each page.  If
they are not made excruciatingly clear, they become a major obstacle or trap.
unquote

yes, in general, i agree, although this sounds to me more like the problems
posed by the use of APPLETs, SCRIPTs, and ActiveX controls, than it does
ACCESSKEYs and TABINDEX...

as regards ACCESSKEY, however, it is, then, the responsibility of WCAG,
authoring tools, and ER tools -- to implore authors to:

a) be consistent in the use of ACCESSKEYs across pages when identical events or
resources are being ACCESSKEYed
b) document the use of ACCESSKEYs

but it is still the responsibility of the UA to (at least):

a) recognize ACCESSKEY
b) provide a well documented method for invoking ACCESSKEY
c) activate elements invoked via an ACCESSKEY in a well-documented and
consistent manner
d) provide a (all together now!) well-documented and consistent mechanism
whereby conflicting accelerator key combinations can either be passed through
to the UA or remapped by the UA

Al further commented, quote
But unless the key assignments are consistent across pages, I don't know how
much time is actually saved.  So a "behavior sheet" or other community-based
method of assigning these would seem to be preferable to what we have now.
unquote

i don't agree with this premise at all...  when using ACCESSKEYs to improve the
usability of forms, is it reasonable to expect the author to use the same
ACCESSKEYs on each form?  is it not more reasonable to encourage the author to
associate ACCESSKEYs with form fields that make (at least mnemonic) sense? 
that is what i attempted to do on the reformatted RFB&D form, but the
ACCESSKEYs i used for that page won't port well to other, unrelated forms...  

likewise, i might use certain ACCESSKEYs universally throughout a site, but
then again, the problem arises -- is it simpler for the user to remember that
the ACCESSKEY for the contents of a page is "C" or should i impose a numeric
schema upon the site, with a clear link to a list of universal ACCESSKEYs for
the site, so that 1 is always the accesskey that takes the user back to the
index page (or at least to the link that leads back to the index page for the
site); and 2 is the ACCESSKEY that takes the user to the list of ACCESSKEYs,
etc.?

what is needed is a way for the UA to alert the user that quote the following
range of controls are available on this page unquote, or for the UA (based on
the user's preferences) to simply generate a list of ACCESSKEYs for the page
when it encounters the ACCESSKEY attribute -- this could be configured so that
a simple keystroke would display the list of author-supplied keybindings slash
accelerator keys or could be automatically generated when the page has finished
loading (provided, of course, that the user configured the UA to act in such a
manner)

moreover, as i have been crying into the wilderness for some time now, as an
"until user agents..." strategy for exposing the ACCESSKEYs embedded in a
document, authors should be encouraged to link to (or include in the body of
the document) a list of ACCESSKEYs that have been defined for that document --
think of it as a LONGDESC for the author-defined keybindings defined for the
page...

Al's last observation was, quote
Are there defacto standards for keystroke usage in ACCESSKEY emerging through
the natural language pressure to repeat winning expressions?
unquote

such as what?  i'm at a loss as to what quote defacto standards for keystroke
usage in ACCESSKEY emerging through the natural language pressure to repeat
winning expressions unquote means...  could you please elucidate?

gregory.

References
1. http://www.hicom.net/~oedipus/books/rfbd_form.html#form
--------------------------------------------------------
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 Tuesday, 2 November 1999 14:03:54 UTC