Re: Use first letter as ACCESSKEY

At 12:43 AM 2/24/2003, Jesper Tverskov wrote:
>In response to Nick and Bill, I would like to propose a new approach to 
>the use of the ACCESSKEY.
>
>Please consider the ideas in my article:
>
>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.

Various notes and comment:

"Many people have physical disabilities and motor impairments but still 
want to use the Internet. They need to rely less on the mouse and more on 
the keyboard and similar more robust devices for navigation. People with 
functional limitations as a result of computer related RSI (Repetitive 
Strain Injury) and other mouse injuries also need to use the mouse less. 
The mouse is great for most of us but we will all benefit by making the web 
easier to navigate with the keyboard as a supplement to the mouse or even 
with the keyboard alone."

This (and a later passage) seems to discount the usefulness of accesskey to 
those of other disabilities, such as the blind.

"The access key letter works together with the ALT key."
On Windows OSes, yes.

"On the Internet we can have hundreds of links on each web page. We soon 
run out of unique access key letters and the poor web designer or coder has 
a hell of a time figuring out what letter to assign to each link."

Your solution is solving a problem that does not exist.  There is no 
rationale for requiring that every link have an accesskey.  Even the 
recommendations call for assigning accesskeys to "important links" as 
opposed to every link.

"The traditional approach to ACCESSKEY using unique letters had all reasons 
to fail and it did. Hardly anybody is using access keys to his or her links 
today except the most enthusiastic accessibility freaks. The principle of 
the first letter as access key on the other hand has all reasons to 
proliferate and become a winner. "

The issue is not that of coders having difficulty assigning unique 
accesskeys.  In my opinion, the major problem with implementing accesskeys 
is that the method of activation (using a modifier key such as ALT in 
Windows) almost automatically causes conflicts with accesskeys of the 
user's OS and applications, including the user agent itself.

"Pressing the ALT key in different ways in the two situations can solve the 
problem."
"Some users will probably have to learn the two different ways of using the 
ALT key in a classroom."
(and then later) "This implementation of the ACCESSKEY attribute can only 
be done manually and has no chance of ever becoming popular on the Internet. "

To expect to tell users, whether to use accesskeys or not (especially if 
not), that they have to relearn how to use ALT is not a realistic or 
implementable solution.  Further, why should a user be forced to change how 
he/she interacts with their OS/applications because of a web page's 
markup?  What other HTML accessibility technique requires such an 
intrusion?  Why do you think forcing people to change how they use their 
user agent and their OS is going to be more popular than current accesskey 
techniques?

As someone already noted, Mozilla's "Find as you Type" is much closer to a 
solution to the accesskey problem, without introducing all the new issues 
that your solution does.

"But Microsoft is without doubt doing it right, if the ACCESSKEY attribute 
ever is going to make sense. We need to be able to use hundreds of access 
keys on each page,"

Why?

"...to generate them without effort based on the first letter, and to be 
able to move on to he next link with the same access key."

This is almost a description of tabbing, first letter notwithstanding.

You might prefer Microsoft Internet Explorer's behavior since it fits your 
technique, but it is a poor implementation.  The accesskey, in my view, 
should give immediate results for the object being navigated to via 
accesskey.  For form elements, the user should be able to immediately input 
data/set the field value/submit/etc. with their next keystroke.  For links, 
I would expect to follow the link -- not have to press another key to 
activate the link I just asked for.

That said, I believe IE's accesskey behavior with links -- giving focus but 
not following -- is truer to the HTML 4.01 specification.  I believe the 
specification is self-contradictory in its link example: "Pressing an 
access key assigned to an element gives focus to the element. The action 
that occurs when an element receives focus depends on the element. For 
example, when a user activates a link defined by the 
<http://www.w3.org/TR/html4/struct/links.html#edef-A>A element, the user 
agent generally follows the link."  Giving focus to a link is not the same 
as activating a link.  By the example's logic, :focus and :active CSS 
pseudo-classes would be equivalent.

"The Danish Parliament, www.folketinget.dk, uses tooltips to indicate what 
access key to use. Why Alt+Q is used for "documents" is anybody's quess! 
Tooltips are better than nothing, and could work if you use the website on 
a regular basis. But it is a bit of a joke to point the mouse to a link in 
order to reveal the tooltip and then use the shortcut key!"

The title will be read aloud by at least some screen readers.  The essay is 
somewhat biased in not considering how accesskeys are used by other 
disabled users besides those having physical/motor impediments to using a 
mouse to the fullest extent.  It also considers the title attribute has 
having no function beyond a visual tooltip.

"W3C Valid XHTML 1.1 logo"

Your page is being served as text/html, which you should never do with 
XHTML 1.1.

"W3C Valid CSS logo"

The validator is currently reporting 1 error in the CSS code.

Bill Mason
Accessible Internet
w3c@accessibleinter.net
http://www.accessibleinter.net/

Received on Monday, 24 February 2003 17:01:44 UTC