techniques for author-defined UI controls

Prologue
First of all, I do not believe that there is any need to
differentiate between "author-defined" user interface (UI)
controls and any other type of UI control. I also believe that the
crux of the argument isn't "where do the UI controls come from",
but, rather, "how much control over the UA will the user be
given?"  The less control over the UA the user is allowed, the
less that application deserves to be called a user agent.  What is
a user agent, after all, other than a mechanism whereby a user can
retrieve and review content?

That being said, the following is submitted in accordance with the
action item that I took at today's teleconference.

----
Techniques for Exposing Author-Defined UI Controls

Introduction/Background
The first question to be answered is: "What Are Author-defined
User Interface controls?"

1. Author-defined UI controls include the following:
  ActiveX controls
  JavaScript
  applets
  ACCESSKEY (HTML4)
  TABINDEX (HTML4)
  HTML4 event handlers
  [your favorite author-defined UI mechanism here!]

The second question to be answered is: why differentiate between
UA-supplied UI controls and author-supplied UI controls, since --
to the user -- the source of the control is irrelevant?

2. Reasons for differentiation between UA- and author-defined UI
controls

  A. UA doesn't know what to expect from author-defined UI
  controls, or necessarily what to do with them or where to look
  for them

  B. author-defined UI controls may conflict with OS and UA UI
  controls / keybindings

  C. documenting / exposing / supporting author-defined UI
  controls could be accorded a lower priority than UA-defined UI
  controls

3. Reasons for not differentiating between UA- and author-defined
UI controls:

  A. the user doesn't care where the UA obtains the array of UI
  controls available at any given time; 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

  B. the ubiquity of author-defined UI controls makes them as much
  a part of a user's online experience as does UA-defined UI
  controls (please refer to the list of author-defined control
  types above before barking at me for this assertion.)

  C. documenting / exposing / supporting author-defined UI
  controls could be accorded the same priority as UA-defined UI
  controls

  D. the source of UI controls which authors are currently 
  able to define are well known, so the UA could easily be 
  primed to look for and expose them.  What to expect from 
, or necessarily what to do with them once they are exposed, 
  however, remains potentially problematic.

Techniques for Exposing Author-Defined UI Controls

1. General Techniques

  1.1 Make a list of keybindings for the currently rendered page
  available to the user.  If any of the author-defined keybindings
  conflict with application or OS keybindings, alert the user in a
  device independent manner. Do not, for example, rely exclusively
  on font or color changes, on the playing of an audio clip, or
  upon an icon to convey this information to the user.
  
  1.2  Provide a cascade order for keybindings, through which the
  user would be able to choose from among the following options:

     a) Do not over-ride default system and UA controls, but alert
     the user if author-supplied keybindings conflict with them,
     and provide a pass-through mechanism to allow the user to
     invoke author-specified UI controls that conflict with
     default UA or OS controls/keybindings.
     
     b) Allow author-defined keybindings to over-ride UA and OS
     keybindings, but      alert the user of the conflicts, and provide 
     a pass-through mechanism so that the conflicting UA / OS 
     keybindings can still be invoked
     
     c) Allow the user to choose to have the UA re-map author-
     supplied keybindings to currently unused keystrokes, then
     alert the user to which keystrokes the author-supplied UI
     controls / keybindings have been re-mapped


2. Specific Cases

 2.1 ACCESSKEY
  
  2.1.1 Allow the user to define the triggering mechanism for
  ACCESSKEY.
  
  Rationale: When an author defines an ACCESSKEY, only the
  accelerator key is defined. It is left to the user agent to
  apply a triggering mechanism which will invoke the ACCESSKEYs
  defined by the author for the document currently being rendered.
  For example, Microsoft Internet Explorer 5 uses the ALT key as
  the ACCESSKEY trigger when running on the Windows platform.
  This triggering mechanism, however, conflicts with some default
  OS and application keybindings which also rely upon the ALT key
  for their triggering mechanism, such as ALT+F (the keybinding
  that invokes the "File" menu) and ALT+H (the keybinding that
  invokes the "Help" menu).
  
  Why then, is it not the author's responsibility to avoid using
  ACCESSKEYs that conflict with OS and application keybindings?
  There are simply too many possible permutations that could be
  applied as ACCESSKEY triggers across platforms for the author to
  realistically predict such conflicts.
  
  A means of endowing the user with the ability to define the
  triggering mechanism for ACCESSKEY, therefore, would alleviate
  both of the impasses outlined above.  The advantages of allowing
  the user to define the triggering mechanism for ACCESSKEYs
  include:

     1. the onus of avoiding key conflicts is placed on the user
     and not the user agent;

     2. the user agent can not only ask the user to define an
     ACCESSKEY trigger, but -- through context sensitive help, a
     "More Information" button, a field label, explanatory text in
     a .cfg file, etc. -- could also warn the user of potential
     key conflicts.  While the interactivity level of such a
     mechanism is best left to individual developers to define, a
     basic definition request could take a form similar to the
     following, platform-specific, example:

       "Please define a triggering mechanism for ACCESSKEYs.
       ACCESSKEYs are author-defined accelerators which make it
       possible to activate a link, move through a page, or
       activate form controls using a keystroke combination.  Half
       of the combination (an alphabetic or numeric character) is
       pre-defined by the author. In order to trigger the
       ACCESSKEY, however, it is first necessary for you to define
       a "trigger key", which -- when pressed in conjunction with
       the ACCESSKEY defined by the author -- will activate the
       element for which the ACCESSKEY has been defined.  It is
       highly recommended that you do not use the ALT or CONTROL
       keys as the ACCESSKEY trigger, as they are commonly used to
       trigger application and system events in the Windows
       environment."
     
     Such a mechanism/message could be displayed to the user the
     first time that a page upon which ACCESSKEYs are defined is
     loaded.  Such a mechanism should also form part of the
     general configuration mechanism for the user agent.

  2.1.2 Ensure Uniform Action Upon Invocation.
  
  Rationale: The user needs to know what to expect when he or she
  invokes an ACCESSKEY: will the focus be moved to the element for
  which an ACCESSKEY has been defined, or will invocation of an
  ACCESSKEY cause the element for which the ACCESSKEY has been
  defined to be activated (i.e. the link followed or the form
  control toggled)? To ensure uniform action upon invocation of an
  ACCESSKEY, provide the user with the following options:

     a) move focus to the element for which the ACCESSKEY has been
     defined

     b) activate the element for which the ACCESSKEY has been
     defined

     c) prompt the user each time an ACCESSKEY is invoked
       (Note: any such prompt should also endow the user
       with the ability to "Save current choice as the
       default action for ACCESSKEY")

--- end proposed techniques

Supplemental References
1. Minutes of the 26 October 1999 User Agent Teleconference
    http://www.w3.org/WAI/UA/1999/10/wai-ua-telecon-19991027.html#minutes

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

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

4. my thinking-out-loud about ACCESSKEY post to the member-confidential PF
list:
     http://lists.w3.org/Archives/Member/w3c-wai-pf/1999OctDec/0065.html

5. my post to w3c-wai-ua on the irrelevance of the source of UI controls
     http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0172.html

6. Keyboard Control section of the User Interface for CSS3 Working Draft
     http://www.w3.org/TR/css3-userint#keyboard

7. HTML4 Event Handlers
     http://www.w3.org/TR/REC-html40/interact/scripts.html#events 
--------------------------------------------------------
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 21:53:22 UTC