Re: Use first letter as ACCESSKEY

Summary:
+ The functionality you propose can be readily implemented in browsers 
(and is, in mozilla). But I don't think that getting authors to do it 
is a good idea, and it doesn't actually replace accesskey.
  + There should only be a few accesskeys on a page, and consistency 
across sites is a good thing. Browsers may reassign keys, but authors 
should start with easily memorised ones that look like things they have 
seen elsewhere.

  + this has been discussed before in WAI - starting from 
http://lists.w3.org/Archives/Public/wai-xtech/2002Sep/0045 there was 
one response listed in our threading system (which breaks down if 
discussions go across months :( The discussion continued with most of 
the messages in 
http://lists.w3.org/Archives/Public/wai-xtech/2002Oct/thread and 
http://lists.w3.org/Archives/Public/wai-xtech/2002Nov/thread and 
finished with the message at 
http://lists.w3.org/Archives/Public/wai-xtech/2002Dec/0001 (Not the 
summary message, just the last)

That discussion has talked about ways to find out what accesskeys are 
available. This mail only addresses one possible approach to that 
problem - there are others.

Details:

Accesskey is a way of providing a quick way to get to the handful of 
most important links or controls on a page, and I think that its value 
is increased when the same set of shortcuts can be used across a site 
or group of sites (as proposed by Nick, and in the earlier discussion 
for Canadian sites, and implemented on sites like 
http://www.ubaccess.com and others).

The most efficient use of this, for people who have trouble with 
producing input (poor hand control, using a slow system like a 
switch/scanner or morse-code, etc) is to directly activate the control 
with the minimum work - like iCab and many mobile phones, which allow 
directly following a link by pressing just the relevant key itself. 
(Note that for phones this is generally limited to number keys).

For some people it is too easy to get lost doing this, and they prefer 
a browser that takes a couple of cancelable steps before the control is 
activated - IE requires alt, an accesskey, and then pressing 
enter/return to activate a link.

So far so good - you configure or choose your browser to have the most 
direct activation or the safe mode, and there are a few accesskeys on a 
page.

What should the accesskeys be assigned to?

The author of a page is likely to have an idea about what are the 
important controls (because they did market research and usability 
testing to find out, in an ideal world or where they care about their 
service and their users). They are also likely to have enough of an 
overview of the site to think about the collection of accesskeys that 
might be useful throughout the site (not all keys might be relevant to 
all pages).

Obvious candidates are things that appear on most pages - search, the 
top of the page, a link to some start page or homepage, major parts of 
the site. Cool things, or popular things. Divisions in a page that are 
very common (the table of contents in W3C specifications, for example). 
Important configuration controls. The list can be long - think 
carefully and choose. (Then test with users, and try a few 
variations...)

Given a reasonable set of controls that should have an accesskey, what 
should the value of that be?

Something memorable, and if possible like something else. There is no 
point imagining that you will get universal agreement on what to use. 
Among Unix users there are two seperate groups - those who use vi, and 
those who use emacs. Most good Unix software lets you choose a keyboard 
shortcut preference that uses one or the other as a basis - they are 
different, and they are not going to be united. Similarly, different 
Windows screen readers have different control keys, and good ones allow 
you to select the "native" keyboard commands or change them to match 
something else you have become used to.

Likewise, in spanish there are two terms in common use for "file" - 
"fichero" or "archivo". Which letter should be selected as memorable? 
(The same problem came up recently in choosing whether to use 
"biblioteca" or "librería" for a term). And most people in the US 
probably don't know how to generate  ب (the arabic character for "b") 
anyway, including people who regularly read Arabic, in my experience. 
This is no reason for people who write arabic all day not to assign it 
as a default accesskey on an arabic site.

So we have a set of controls with allegedly memorable accesskeys. How 
should browsers handle them?

This is something that browser makers should work out. Simply ignoring 
them makes for a pretty weak browser. Even if it provides a different 
feature like incremental search ("find-as-you-type" - first implemented 
in emacs before there was a web to browse, and much beloved of emacs 
users)

Two possible approaches that browsers could use:

One - the "iCab" approach: Don't use any plain characters for 
controlling the browser. This leaves them all available to select or 
activate the control (according to user preference, with luck). This is 
my personal favourite - for various reasons reducing keystrokes is 
important to me as a user - but it isn't everyone's preference.

For extra credit, the browser could ask the system what keyboard is 
active at the moment. If I have an Australian keyboard running, and a 
page is in Arabic with arabic accesskeys, it could remap the keys to 
activate those controls to phonetically similar latin characters. (Lynx 
presents arabic pages in latin fonts by doing this mapping - it isn't 
technology that would need to be developed.)

Two - the "pass-through" approach: In a browser like Opera which has 
very substantial and powerful keyboard control already, Mozilla which 
uses bare keys for its find-as-you-type functionality, or Amaya which 
allows editing using the bare keys, you need some other way to get at 
the accesskeys. This has already been figured out for screenreaders, 
which need to re-use controls, or allow the user to activate the 
underlying software with the same controls. For example, the browser 
might reserve the command-p key for pass-through. So to activate an 
accesskey the user presses command-P and then the accesskey. Or the 
browser might apply the accesskey as a default, and use command-P to 
allow the user to access other commands.

There are more "extra credit" approaches possible too. The browser 
could, on the pass-through key, open a list of controls that have 
accesskeys. This would allow people to move up and down that very short 
list - similar to the headings list that systems like iCab or Jaws 
provide, or the links list available in Amaya, Lynx, or most 
screenreaders.

There is a parallel to a lot of this in HTML - the link element. It is 
most commonly used at the moment to point to a stylesheet, and 
sometimes to an alternative version. But it is possible to point to the 
"next page" or "previous page", "contents" or "index" or "copyright 
page" or "help page" of a site. These links are then rendered in a 
browser-specific way - Lynx, iCab, Mozilla, Opera all show approaches 
to making these links available through the user interface. In this 
case the way of activating the link is the same for every site, because 
it is determined entirely by the browser.

Authors can also define other link elements...

cheers

chaals

On Monday, Feb 24, 2003, at 19:43 Australia/Melbourne, Jesper Tverskov 
wrote:

> Use first letter as ACCESSKEY
> www.klapmusen.dk/artikel.aspx?xml=20021031&lg=en
> (a new approach to the use of the ACCESSKEY)
>
> 1. If we always use first letter of the link text as ACCESSKEY, they 
> can be generated by code.
> 2. We do not have to mark the access key letter, because it is always 
> the first one.
> 3. We can have scores of access keys on each page, because the same 
> access key letter can be used many times.
>
> Please read my article carefully, and think it over before responding. 
> If we do it right, the ACCESSKEY could become a benefit to all 
> keyboard users of the Internet.
>
--
Charles McCathieNevile           charles@sidar.org
Fundación SIDAR                       http://www.sidar.org

Received on Thursday, 27 February 2003 16:44:00 UTC