RE: PROPOSAL: Checkpoint for ACCESSKEY

This is just the way microsoft implement the function and is similar to
what would be needed for form control that has a defined accesskey.
Jon


At 09:01 AM 5/10/99 -0400, Denis Anson wrote:
>Sorry I'm going through these in the reverse order, but there may be a
>behavior there that would make my previous missive on ACCESSKEY make sense.
>
>I had always assumed that activating an ACCESSKEY would activate the link.
>But if activating an ACCESSKEY simply moves the focus to the "next" element
>with that ACCESSKEY, and a separate keystroke (presumably ENTER) takes you
>through the key, then you have a way of navigating links with the ACCESSKEY,
>and a way of activating them directly.  An unfortunate side affect is that
>passing through the link requires two keystrokes rather than one.
>
>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 mark novak
>Sent: Friday, May 07, 1999 11:03 AM
>To: Jon Gunderson; w3c-wai-ua@w3.org
>Subject: Re: PROPOSAL: Checkpoint for ACCESSKEY
>
>At 9:48 AM -0500 5/7/99, Jon Gunderson wrote:
>>Response in JRG2:
>>At 04:46 PM 5/6/99 -0500, mark novak wrote:
>>>At 3:53 PM -0500 5/6/99, Jon Gunderson wrote:
>>>>Response in JRG:
>>>>
>>>>At 02:51 PM 5/6/99 -0500, mark novak wrote:
>>>>>i'd also vote that we do not need a checkpoint for sequential access to
>>>>>elements
>>>>>which have an ACCESSKEY.
>>>>>
>>>>>what i'd expect to happen in those cases where more than one element
>>>>>had the "same" ACCESSKEY, is that i'd be able to navigate between those
>>>>>elements by repeatedly typing that same ACCESSKEY, which is basically
>>>>>sequential access of sorts...otherwise, I think we already have access
>>to the
>>>>>element by virtue of the ACCESSKEY.
>>>>
>>>>JRG: That was the intention of the word sequential, if you have a better
>>>>phrasing please post to the list.
>>>
>>>MN:  wasn't trying to reword, still suggesting this checkpoint is not
>needed.
>>
>>JRG2: What other checkpoint do you see that covers the navigation to
>>elements using the ACCESSKEY?
>
>MN2:  I think we are getting hung up on semantics, what i was trying to
>say is that I agreed with Charles, in that I don't believe we should have a
>checkpoint "requiring sequential navigation to the ACCESSKEY", thats all.
>
>
>
>>
>>>
>>>
>>>>
>>>>>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?
>>>>
>>>>JRG: That is in the section under orientation.
>>>>Section 6 in the current guidelines.
>>>
>>>MN:  great.  suggest we add a link from navigation section
>>>also, it that is easily possible.
>>
>>JRG2: I think the techniques section is where the different checkpoints
>>need to be combined to demonstrate functional implementations of the
>>checkpoints
>
>MN2:  where ever you feel it best to reference is fine with me.
>
>
>>>>Jon
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>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
>>>>>
>>>>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
> 
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 13:01:05 UTC