RE: Proposed resolution of LC#112

Which seems right to me.

I was responding to the idea that acceskey could only be P3...

Charles McCN

On Thu, 20 Jan 2000, Jon Gunderson wrote:

  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
  
  

--
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

Received on Thursday, 20 January 2000 18:55:53 UTC