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

Proposed resolution of LC#112

From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
Date: Thu, 20 Jan 2000 11:41:42 -0600
Message-Id: <4.1.20000120101341.00d034f0@staff.uiuc.edu>
To: w3c-wai-ua@w3.org
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
Received on Thursday, 20 January 2000 12:44:00 GMT

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