- john@

Hi Oscar,
 
24.10.2014, 03:57, "John Foliot" <john@foliot.ca>:

Some of that fuss was documented by Derek Featherstone and I in the early 2000's, which showed many of the flaws with accesskeys (See: Using Accesskeys – Is it worth it?, More reasons why we don’t use accesskeys, Accesskeys and Reserved Keystroke Combinations, and  Link Relationships as an Alternative to Accesskeys for archived versions of our findings and thoughts from back then).

 
Most of what John and Derek documented (Jukka Korpela was another to provide early warning that not all was well) is very clear, but some of it is less of a problem than it seems.
 
It is true that most mainstream browsers have at best a pretty awful implementation of accesskey. But there are a few things that make this less of a problem than it might be:
 
1. Most browsers don't have any way of finding out if there *are* accesskeys defined. Any good implementation would provide this - but it means that most users won't be tempted to play with them.
2. Modern browsers generally don't do the most stupid thing, which is to allow the web page to override important functions through accesskey. Unfortunately, they normally *do* allow pages to do that using javascript key events - which is a very good reason why that is an even worse alternative than doing nothing, although it is sadly very very common on the web today.
3. A couple of browsers (iCab, the old Opera) actually have somewhat reasonable implementations that *don't* get in the way of browser function but *do* work, and allow users to find out how.
 
All that said…

 

With the work being done around HTML5, the Accessibility Task Force of the HTML5 Working Group at the W3C have started at looking at accesskeys again, with an eye to improving how they operate, and essentially re-thinking through the entire approach to author declared keyboard short-cuts.  As recently as *today* (http://www.w3.org/2014/10/23-html-a11y-minutes.html#item06) the topic was discussed on our weekly conference call, and work is underway (lead by Chaals McCathieNevile - https://www.w3.org/WAI/PF/HTML/wiki/Accesskey)  to re-energize accesskeys and get them figured out correctly. (Note, if you have thoughts or other input you want to contribute, I know Chaals is very open to feedback.)

 
Indeed. (Actually I wouldn't characterise it as entirely re-thinking so much as rescuing the good bits from a history of mistakes made in implementation. Luckily, perhaps, the people who have to really change things are the browsers - who are relatively few and in a far better position to make the changes if only they assign someone for a few days work).
 

The current state of the state however is not much different than what it was back when Derek and I reported our findings,

 
Actually it is reasonably improved, in that browsers have generally fixed the most harmful behaviours they had - although their implementations are generally somewhere between poor and terrible.
 

and today using accesskeys should be reserved for only the rarest of occasions -  for example data-input screens where operators are repeatedly interacting with the same interface over a prolonged period of time. In those situations, and after careful testing to ensure there are no keyboard conflicts between the web application and any AT that may be used by the group of operators, adding keyboard short-cut navigation can benefit those users with a faster, more streamlined navigation model.

 
For sites where people are going to interact a lot with a specific function, *and* where that function doesn't have a standard "role" (as in the HTML / ARIA attribute), accesskeys make sense. Where there is a reasonable "role", you should definitely make sure that is marked before you think of adding accesskeys.

 
 

For 'garden-variety' web sites (where the majority of users may only visit no more than a handful of times) I think not adding accesskeys is probably the better choice: the miniscule gain potential hardly out-weighs the problems that accesskeys may still introduce today.

 
In general I would agree with this advice for now.
 
I note that one thing which may be useful is to provide accesskeys for script functions, by using a link that activates the function.
 
One thing that is a bad idea is to try telling users what the accesskeys are and how they work *instead* of referring them to their browser's documentation. This is largely because almost invariably what you put there is incomplete and likely to be incorrect, and over time it is almost guaranteed that the situation will change.
 
cheers
 
Chaals
 

 

JF

------------------------------

John Foliot
Web Accessibility Specialist
W3C Invited Expert - Accessibility

Co-Founder, Open Web Camp

 

 

 

 

From: Oscar Cao [mailto:oscar.cao@live.com]
Sent: Thursday, October 23, 2014 5:46 PM
To: 'WAI Interest Group'
Subject: Accesskeys

 

Hello All

What's the current take on accesskeys?
I know a few years back people made a big fuss about them. But don't see them in newer sites and not even on the W3C sites.

Should we still include accesskeys or drop them altogether?

Regards
Oscar


Sent from my Windows Phone

 
 
--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com