Re: PROPOSAL: Checkpoint for ACCESSKEY

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?

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

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

Received on Friday, 7 May 1999 10:43:17 UTC