RE: Accesskey in HTML

There are two basic issues with ACCESSKEY: the extent to which the keyboard
bindings are discoverable, and the extent to which they conflict with
programmatic keyboard bindings.  The third issue has to do with what an
ACCESSKEY should do when you activate it, which is also a problem.

ACCESSKEY, as it is currently implemented, and as it is poorly specified,
is, as I think it was Charles who said, broken.  Assuming the author was a
nice person, and put ACCESSKEYs into the document, the user has no way of
knowing what they are.  Also, in a long document, it can be very difficult
to create new keys for all links, so some wrapping is indicated.  (Which
means that, to be fully functional, you can't directly activate the link by
ACCESSKEY, or it can't wrap.) There must be some way to discover the
ACCESSKEY bindings.  At first, I thought of hovering over the key, so that
the ACCESSKEY could be displayed as they are with Titles, but if you could
hover, you wouldn't need ACCESSKEY, so that won't work.  That means that the
display of ACCESSKEY must be rendered in-line with the link, all the time,
for it to work.  (This might be a toggled feature of the user agent.)

Another approach to the process of keyboard activation would be to have the
browser provide it based on the currently visible links, as a "repair
strategy."  On the Macintosh, there are no keyboard equivalents for many
menus or for buttons.  But an aftermarket product, ClickIt!, provides
"control-key" activation of any menu or button item with a single keystroke.
It examines the actions available, finds unique characters for each, and
underlines its generated hotkeys.  A browser could do something like this
with the links in the viewport at any instant.  (Of course, the binding on
any given link might change when you scrolled the viewport!)  Such a dynamic
feature in a browser would give the same functionality as ACCESSKEY, without
the author having to write the keys into the code.



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
Website: http://www.resna.org
RESNA ANNUAL CONFERENCE -- "RESNA 2000"
ORLANDO, FL, JUNE 28 -- July 2, 2000

-----Original Message-----
From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On Behalf
Of Jon Gunderson
Sent: Monday, October 04, 1999 12:02 PM
To: Al Gilman; WAI PF group; Kynn Bartlett
Cc: w3c-wai-ua@w3.org
Subject: Re: Accesskey in HTML

Al,
I am going to post ACCESSKEY implementation as a issue to the UA group,
since our current techniques document doesn't deal with ACCESSKEY in much
detail.  I will also will create a depedency with PF on this issue so we
make sure we talk about it with the PF group before resolution.
Jon


At 10:21 PM 10/1/99 -0400, Al Gilman wrote:
>At 10:52 AM 10/1/99 -0700, Jon Gunderson wrote:
>>Potential Issues that I see that are related to User Agent:
>>
>>1. Author keyboard bindings and user agent default/custom keyboard
bindings
>>may conflict
>
>This is an end-to-end problem.  Yes it touches the UA but to fix it right
>we may want to change the formats and/or author practices as well.
>
>>2. Author keyboard bindings behavior in the user agent. What should user
>>agents do?
>
>This is a central issue.  It includes what should UAs do but the affected
>documents include X-Link as well as UAGL.
>
>>3. Visibility of author supplied keyboard bindings, how does a user know
>>they are there?
>
>I think this is part of 2.
>
>>Are these the central UA issues?
>
>Generally, yes.  I am just nervous about saying UA issues because I don't
>think we have the overall issues laid out well enough to go off in a closet
>and just work on the UA part.
>
>I want to look at the end-to-end issues some more: how to provide a mode
>with minimum keystrokes and a mode with minimum display depencency from the
>same document.  Each mode is a UA behavior but there is a chicken and egg
>relationship between the markup and the processing of the markup.
>
>Al
>
>>Jon
>>
>>
>>At 09:09 PM 9/30/99 -0400, Al Gilman wrote:
>>>At 07:36 PM 9/30/99 -0400, Charles McCathieNevile wrote:
>>>>Member-Private (like all PF stuff is by default)
>>>>
>>>>Accesskey seems to have a bunch of problems with it - there are only a
>couple
>>>>of implementations, (and IE4 and IE5 do different things with it), the
spec
>>>>seems poorly written about what should in fact happen (should accesskey
>give
>>>>focus, or should it activate?) and allowing any character in the
document
>>>>character set 9as the spec does) does not seem workable in practise.
>>>>
>>>>On the other hand the ability to navigate a structure is clearly needed,
>and
>>>>accesskey can provide a very flexible way to do that (when it works).
>>>>
>>>>Is it broken beyond repair, does it need major surgery, or is it fine
and
>>>>just waiting for better implementation?
>>>>
>>>>Persoanlly I suspect it is broken, but could possibly be repaired. I am
not
>>>>sure whether it is useful to do so, or whether proper structural
navigation
>>>>in general is a better approach.
>>>>
>>>>Thoughts?
>>>
>>>What works:
>>>
>>>People with vision and who can't point and have difficulty with
keystrokes
>>>get direct navigation with few keystrokes.
>>>
>>>What squeaks:
>>>
>>>Keybindings are page-specific; not web-generic things one can remember.
>>>
>>>Fights for keybindings with e.g. Opera.
>>>
>>>Blue sky (in the best of all worlds):
>>>
>>>Author characterizes action opportunities in the page and browser flows
>>>commands into a structure, e.g. short-wide or deep-narrow tree which is
>>>both rational with respect to the classification taxonomy and optimized
for
>>>the performance prices of the user.  I.e. to use little of what is hard
and
>>>lots of what is easy.  There is a variable ratio of workload assigned to
>>>sensation, perception and cognition.
>>>
>>>Baby steps (incremental things we can do):
>>>
>>>Go back to the person who posted the "please, no 'some assembly
required'"
>>>message to UA.  Get his ideal control protocol.  Try to decompose this
into
>
>>>performance axes.
>>>
>>>Experiment with ToC power-toy: give it a tunable fanout parameter for
>>>building the navigation tree.  Assign hot keys by this function.
>>>
>>>A simple version is to control show/hide or flow order of the hotkey
legend
>>>by user preference profile.  This should be doable by XSLT.
>>>
>>>Al
>>>
>>>
>>>>Charles
>>>>
>>>>--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
>>Chair, W3C WAI User Agent Working Group
>>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.w3.org/wai/ua
>>              http://www.als.uiuc.edu/InfoTechAccess
>>

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Chair, W3C WAI User Agent Working Group
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.w3.org/wai/ua
                http://www.als.uiuc.edu/InfoTechAccess

Received on Monday, 4 October 1999 11:39:44 UTC