Re: Proposed resolution of LC#112

Gregory,
Have your submissions to the UA group been accurately included in the
current UA techniques document?

Jon


At 04:22 PM 1/25/00 -0500, Gregory J. Rosmaita wrote:
>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>
>--------------------------------------------------------

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

Received on Wednesday, 26 January 2000 11:02:00 UTC