Re: Proposed resolution of LC#112

aloha, jon!

while i would rather see 10.1 and 10.3 merged, and accorded a P1, i wanted to
address some of your assertions about ACCESSKEY...

while it is true that the other WAI guidelines groups have accorded ACCESSKEY a
priority rating of 3,  ATAG's indirect prioritization of support for ACCESSKEY
is dependent upon WCAG's explicit prioritization of ACCESSKEY...  i have
repeatedly made a specific proposal (on this list and others) that the priority
level accorded ACCESSKEY in WCAG be raised (at least to 2, although i think it
a P1), and that a checkpoint encouraging authors to include ACCESSKEY
information either inline or in a linked file, be added to WCAG at a lower
priority...

as i have oft noted in this forum, author-defined UI controls, such as
acceleration keys, which the author can supply via the ACCESSKEY attribute 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 an entire class
of adaptive technology for persons with certain classes of disabilities is
based... 

moreover, i am extremely concerned that ACCESSKEY is being given such
short-shrift because of the (from what i understand) intentional  vagueness of
the HTML 4.0 definition of the functionality of ACCESSKEY, the lack of
implementation, and the poor choice of an invocation mechanism (the ALT key) by
the one mainstream UA developer which has implemented ACCESSKEY...

i have spent hours on this topic, and have posted extensively on the topic to
this and other WAI lists...  my posts have included many techniques that would
either provide a user-configurable cascade order for conflicting keystrokes, a
user-defined triggering mechanism, and a pass through key...  i have raised the
issues associated with ACCESSKEY (and TABINDEX) on the PF list, and have been
tracking developments in this area in CSS3 and XHTML, and am loathe to let this
issue die such an ignominious death...  in my posts on the subject, i have not
attempted to quote fix unquote ACCESSKEY, or to force UAs to do so, only to
show that ACCESSKEY isn't necessarily broken if:

1. the UA does not bind ACCESSKEY to only one triggering mechanism (such as the
ALT key)

2. the UA offers the user the choice between moving-to the element for which
the ACCESSKEY has been defined and activating (if appropriate) the element for
which the ACCESSKEY has been defined

3. authors are encouraged (by WCAG and ATAG) not only to incorporate ACCESSKEYs
into their document source, but to provide an inline or linked list of the
accesskeys defined for that page (although i would welcome a user agent that
could provide such a list on the fly)

a few other ideas are:

a. let the user define the triggering mechanism,
b. provide a cascade order for controls and a pass through (ignore-next-input)
key, for cases where ACCESSKEYs, in conjunction with their triggers conflict
with OS or UA keybindings)
c. provide a special mode (such as Opera's forms mode) that would allow the
user to enter "naked" ACCESSKEYs

so, when it comes to ACCESSKEY, the fact of the matter is:

1. for certain classes of users, ACCESSKEY is indispensable
2. ACCESSKEY is implementable
3. implementation of ACCESSKEY can be improved, and suggestions for such
improvement have been documented by this WG

gregory.

At 11:41 AM 1/20/00 -0600, you wrote:
>We have spent considerable time before last call discussing issues
>surrounding the user interface providing information about the current
>input configuration and the accesskey information to the user.  I would
>like to summarize the discussion and propose a resolution to this issue so
>that we can move the document forward.
>
>Issues
>1. Some user agents provide for user configuration of input controls
>(typically keyboard commands) and other do not allow configuration.  In the
>later case static documentation can be used to provide information to the
>user on the current configuration.  Other checkpoints address the
>accessibility of static documentation.  Static documentation can also
>explain how accesskeys is supported on a particular user agent.
>
>2.  Accesskeys is a currently the only know way to the UA group for authors
>to provide document specific short cuts to links and form controls.  
>
>3. Some people in the UA group feel that accesskey specifications are an
>extension to the user interface and the responsibility of the user agent to
>document their existence in a particular document, while others feel that
>accesskeys is part of the authors content and it is the responsibility of
>the author to provide information on their existence in the resource.
>
>4. There are no specifications (other than the markup syntax a UA should
>recognize) of how a user agent should implement accesskey and the UA group
>decided not to try to suggest one.  Currently only IE implements the
>accesskey feature.
>
>5.  Accesskey is currently a priority 3 requirement in WCAG for authors to
>include in their document and a Priority 3 requirement in ATAG for
>authoring tools to support authors including in their documents.  I have
>not seen any requests for changes in priority of these requirements to
>either of these two working groups to raise the priority of the use or
>authoring of accesskeys.
>
>We only received comments from 2 last call reviewers on this issue:
>John Gardner: Combine 10.1 and 10.3 (10.2 in Last Call Working Draft) as a
>priority 2
>Liam Quinn: Leave as is in Last Call working draft
>
>We briefly discussed this issue at the December FTF meeting in Austin.  The
>focus of that discussion was the terminology added to checkpoints "through
>APIs" addition to the checkpoints from the last call draft.  I have
>proposed that this terminology be removed from both in a separate e-mail.
>
>I am not sure further extended discussion on this issue will change the
>view points of members of the working group.  The issue is also primarily
>over providing accesskey information and since other guidelines make this a
>priority 3 topic I don't think it should hold up the UA guidelines from
>moving forward to CR.  There were also no external reviewers that wanted to
>see the current 10.3 (formerly 10.2 in last call working draft) moved to
>Priority 1.  
>
>My recommendation is that we do NOT combine the checkpoints 10.1 and 10.3
>and leave the priorities of the checkpoints as stated in the last call
>working draft.  Issue LC#112 is currently an accesskey issue and that since
>there are other ways the user agent is required to provide access to
>elements with associated accesskey information, providing information about
>the current access keys does not meet the requirement for a priority 1.  I
>feel the user agent must document how accesskey are activated (if supported
>by the user agent) and this requirement is covered in other documentation
>checkpoints at a priority 1 level.  Telling the user what accesskeys are
>currently associated with form controls and links in a document I feel is a
>priority 2 level issue, since it only makes it difficult to use accesskeys
>if you do not know the current elements and accesskey specifications that a
>document provides. 
>
>Working group members who disagree with this proposed resolution can post a
>minority opinion(s) and these can be carried to the director and W3C
>members during Candidate Recommendation and Proposed Recommentation stages
>for further comment from these working groups.  If the director or any of
>the W3C member companies support the minority opinon(s) the working group
>could readdress the issue at that time.
>
>We will discuss this proposal today.
>
>Jon
>
>Jon Gunderson, Ph.D., ATP
>Coordinator of Assistive Communication and Information Technology
>Chair, W3C WAI User Agent Working Group
>Division of Rehabilitation - Education Services
>College of Applied Life Studies
>University of Illinois at Urbana/Champaign
>1207 S. Oak Street, Champaign, IL  61820
>
>Voice: (217) 244-5870
>Fax: (217) 333-0248
>
>E-mail: jongund@uiuc.edu
>
>WWW: http://www.staff.uiuc.edu/~jongund
>WWW: http://www.w3.org/wai/ua
--------------------------------------------------------
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, 25 January 2000 16:14:57 UTC