W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2000

RE: Proposed resolution of LC#112

From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
Date: Thu, 20 Jan 2000 17:17:27 -0600
Message-Id: <4.1.20000120171549.021dab20@staff.uiuc.edu>
To: Charles McCathieNevile <charles@w3.org>, Denis Anson <danson@miseri.edu>
Cc: w3c-wai-ua@w3.org
Currently the user agent guidelines list implementing ACCESSKEY at a P1
level in Checkpoint 6.1 Implement the accessibility features of supported
specifications (markup languages, style sheet languages, metadata
languages, graphics formats, etc.). [Priority 1] 



At 05:58 PM 1/20/00 -0500, Charles McCathieNevile wrote:
>Actually for someone who has mobility impairments (the more I type the more I
>fall into this category) accesskey would rate as a P2 at ;least. The fact
>that it is not as well-specified as it might be is irrelevant, since the
>requirement is not "implement HTML with accesskey" - that is a technique, but
>"implement shortcut methods of navigating documents - structure walking in
>any XML, implementing purpose-designed features in languages which have them
>available (HTML, MS Word, ...)
>
>Charles McCN
>
>On Thu, 20 Jan 2000, Denis Anson wrote:
>
>  Jon,
>  
>  I agree that we shouldn't allow Accesskey to hold things up, especially
>  since the AccessKey specification is essentially incomplete.  AccessKeys are
>  shortcuts, but not the only route to links or controls, so they cannot rise
>  to a Priority 1 issue.  Since they are conveniences, they are a priority 3
>  thing by my understanding.
>  
>  Until the HTML specification includes behavior for AccessKey, we really
>  can't mandate following it, can we?
>  
>  Denis
>  
>  -----Original Message-----
>  From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
>  Behalf Of Jon Gunderson
>  Sent: Thursday, January 20, 2000 12:42 PM
>  To: w3c-wai-ua@w3.org
>  Subject: Proposed resolution of LC#112
>  
>  
>  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
>  
>  
>  
>
>--
>Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
>W3C Web Accessibility Initiative                      http://www.w3.org/WAI
>21 Mitchell Street, Footscray, VIC 3011,  Australia 

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 Thursday, 20 January 2000 18:19:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:51 GMT