RE: PROPOSAL: Checkpoint for ACCESSKEY

ACCESSKEY is not well defined functionally, but is available for a number
of different elements.
Microsoft already has an implementation of the ACCESSKEY attribute.   In
discussions on UA there was suggestions by Mark Novak, Charles
McCathieNevile and Jim Allan, that this was not a critical issue for
accessibility.  They have suggested that it only be mentioned in the HTML
compatibility section, with no further references in either the navigation
or orientation sections of the guidelines.  There can be discussion of
implementation issues in the techniques document on the issues from the IG,
but it would be informative only.  Developers would not be required to do
something a particular way.

 Do you disagree with the analysis of Mark, Charles and Jim analysis?

I will put it on our issues list for discussion and resolution.

Jon


At 08:51 AM 5/10/99 -0400, Denis Anson wrote:
>Jon,
>
>Here is a question about AccessKey behavior.  The theory of AccessKeys is
>that you would be able to directly select a link by a keyboard command,
>independent of the location of the focus.  Correct?
>
>Now, suppose I am designing a page, and using AccessKeys for my links.  I
>would want the user to be able to access all of the important links on the
>page, wherever they were.  Since I can access the link directly, why would I
>need to search for it?  Or navigate to it?  I just hit the AccessKey, and
>I'm through the link.
>
>Now, suppose I have a page with more important links that characters.  (This
>is, I'll admit, bad design.)  Do I still have a way to know what pressing
>Alt-A will do?  Presumably, I will pass through the next link from my
>current position.  But if I don't know where the keys are located, I don't
>know which of the ACCESSKEY=A links I'm before or after!  It seems to me
>that this is a more complex issue that it at first appears.  How will the
>user know what behavior they will get with any access key, and, if the link
>navigation via Focus works correctly, are AccessKeys redundant?
>
>Denis Anson, MS, OTR
>Assistant Professor
>College Misericordia
>301 Lake St.
>Dallas, PA 18612
>
>Member since 1989:
>RESNA: An International Association of Assistive Techology Professionals
>
>-----Original Message-----
>From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On Behalf
>Of Jon Gunderson
>Sent: Friday, May 07, 1999 1:25 PM
>To: allan_jm@tsb1.tsbvi.edu; Charles McCathieNevile; mark novak
>Cc: w3c-wai-ua@w3.org
>Subject: RE: PROPOSAL: Checkpoint for ACCESSKEY
>
>So you just want the guidelines to say the the attibute ACCESSKEY is good
>for accessibility in the current section 7 and I am assuming that you want
>the features needed for accessible implementation be be in the techniques
>document?
>
>I think it would make it clearer to developers if they saw the access key
>implementation information as part of other navigation commands.  If it is
>only in the compatibility section, it will not have the weight or the
>visibility of a checkpoint.
>
>Jon
>
>
>
>
>At 10:40 AM 5/7/99 -0500, James Allan wrote:
>>I agreee with Charles and Mark, I don't see a need for a checkpoint for
>>sequential navigation of elements with accesskeys, you can already get to
>>the elements by link access, form control navigation, etc.
>>
>>> -----Original Message-----
>>> From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
>>> Behalf Of Charles McCathieNevile
>>> Sent: Friday, May 07, 1999 9:59 AM
>>> To: Jon Gunderson
>>> Cc: mark novak; w3c-wai-ua@w3.org
>>> Subject: Re: PROPOSAL: Checkpoint for ACCESSKEY
>>>
>>>
>>> 7.1.1 Priority 1 Support Accessibility features for HTML
>>>
>>> seems to cover it for me.
>>>
>>> Charles
>>>
>>> On Fri, 7 May 1999, Jon Gunderson wrote:
>>>
>>>   We have no specific checkpoint in the current WD, so I would like to
>>>   document that the group would like to include a specific
>>> checkpoint.  For
>>>   the accesskey attribute I recommend that we have a specific checkpoint.
>>>   Jon
>>>
>>>
>>>   At 11:04 PM 5/6/99 -0400, Charles McCathieNevile wrote:
>>>   >There was such a checkpoint in the previous draft. I haven't
>>> checked the
>>>   >document, but I was under the impression that this had not
>>> been dropped. Some
>>>   >time ago I suggested that this checkpoint be clarified to
>>> specify exactly
>>>   >what kind of information was necessary.
>>>   >
>>>   >Charles
>>>   >
>>>   >On Thu, 6 May 1999, mark novak wrote:
>>>   >
>>>   >  I do have another question however:
>>>   >
>>>   >  Do we need a checkpoint for a "where am I"  function, something that
>>>   >  would return information such as page title, location on
>>> page, element
>>>   >  with focus, previous page title was, summary, etc., while navigating
>>>   >  with in a page?
>>>   >
>>>   >
>>>   >
>>>   >
>>>   >  At 11:00 AM -0500 5/6/99, Jon Gunderson wrote:
>>>   >  >In response to CMN:
>>>   >  >The sequential statement is due to the potential multiple
>>> definitions of
>>>   >  >the same accesskey in a document.  If more than one
>>> control, link, label,
>>>   >  >... uses the same accesskey we want people to be able to
>>> navigate to each
>>>   >  >one.  In the case of single definitions of an accesskey in
>>> a document then
>>>   >  >the sequential part is a mute point, the focus would move
>>> directly to that
>>>   >  >associated focusable element.
>>>   >  >Jon
>>>   >  >
>>>   >  >At 11:44 AM 5/6/99 -0400, you wrote:
>>>   >  >>I don't think that we should not have a checkpoint for
>>> ACCESSKEY. I do
>>>   think
>>>   >  >>that a checkpoint requiring sequential access to elements
>>> which have an
>>>   >  >>ACCESSKEY is inappropriate - the purpose of the element is
>>> to provide
>>>   access
>>>   >  >>to certain elements in a non-sequential manner.
>>>   >  >>
>>>   >  >>Charles McCN
>>>   >  >>
>>>   >  >Jon Gunderson, Ph.D., ATP
>>>   >  >Coordinator of Assistive Communication and Information Technology
>>>   >  >Division of Rehabilitation - Education Services
>>>   >  >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
>>>   >  >       http://www.als.uiuc.edu/InfoTechAccess
>>>   >
>>>   >
>>>   >
>>>   >
>>>   >--Charles McCathieNevile            mailto:charles@w3.org
>>>   >phone: +1 617 258 0992   http://www.w3.org/People/Charles
>>>   >W3C Web Accessibility Initiative    http://www.w3.org/WAI
>>>   >MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA
>>>   >
>>>   Jon Gunderson, Ph.D., ATP
>>>   Coordinator of Assistive Communication and Information Technology
>>>   Division of Rehabilitation - Education Services
>>>   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
>>>      http://www.als.uiuc.edu/InfoTechAccess
>>>
>>>
>>> --Charles McCathieNevile            mailto:charles@w3.org
>>> phone: +1 617 258 0992   http://www.w3.org/People/Charles
>>> W3C Web Accessibility Initiative    http://www.w3.org/WAI
>>> MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA
>>>
>>>
>>
>Jon Gunderson, Ph.D., ATP
>Coordinator of Assistive Communication and Information Technology
>Division of Rehabilitation - Education Services
>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
>        http://www.als.uiuc.edu/InfoTechAccess
> 
Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
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
	http://www.als.uiuc.edu/InfoTechAccess

Received on Tuesday, 11 May 1999 12:59:55 UTC