W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2012

Re: Access Keys as a means to passing 2.4.1 Bypass Blocks

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Tue, 16 Oct 2012 08:28:28 +1100
Cc: "Vivienne CONWAY" <v.conway@ecu.edu.au>, Userite <richard@userite.com>, "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
To: deborah.kaplan@suberic.net, "Harry Loots" <harry.loots@ieee.org>
Message-ID: <op.wl8olqtay3oazb@www.bigpondsitehelp.com>
TL;DR: Accesskey is no longer actively harmful, but implementation in most  
browsers is still terrible. It is only helpful for power users and Opera  
users.

It is a good thing to use, but not a sufficient technique for real-world  
accessibility today.

More detail...

Do *not* read what HTML 4 says about implementation, and using  
alt+accesskey. That's the terrible advice that led to people doing stupid  
implementations that really were harmful. In this case HTML5 is a really  
significant improvement.

On Tue, 16 Oct 2012 02:54:51 +1100, Harry Loots <harry.loots@ieee.org>
wrote:

> On 15 October 2012 17:30,  <deborah.kaplan@suberic.net> wrote:
>>
>> On Mon, 15 Oct 2012, Harry Loots wrote:
>>
>>> Alt+ 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, S and a few others are not bound to  
>>> any browser as far as I am aware?

There is no key that is unbound and cannot conflict.

Modern implementations (even IE 8) tend to be less stupid, and use  
modifiers that are less likely to get in the way (or at least not accept  
accesskeys that do get in the way, as in IE's case). But they still don't  
tell you what the available accesskeys are, which makes them pretty bad by  
default. Opera's implementation is intelligent enough to be usable as is -  
sadly that makes it unique.

>> You will want to do your testing beyond just what is bound  to the
>> browser, however. Many people have other adaptive technologies in
>> place and the default settings of other adaptive tech may use
>> those key bindings -- I'm not sure of those in particular.
>
> AT shortcut keys override HTML access keys.

*may* - depends on the software :( In some cases IE won't let the  
accesskey override "important functions". But I believe not all normal  
functionality is considered important, and it is unclear what will happen  
in some cases :(

> If an AT user encounters ALT+S, and they already have an ALT+S defined  
> as part >of the AT shortcut keys, the AT shortcut key will take  
> precedence. Given that AT shortcuts override HTML accesskeys, adding  
> >shortcut keys, in my opinion, brings no benefit to AT users.

IE likewise overrides some things.

>> I know, for example, that people frequently put into place
>> keystroke bindings on websites (Ajax, not access key)
>
> I was specifically referring to accesskeys (as HTML attribute)

Yeah, using javascript to create web bindings is significantly worse than  
accesskey in terms of interfering.

>> (Another thing to take into account with access keys is how you
>> expose them to non-screen reader users. Frequently lists of
>> access keys are published via text hidden from visual display but
>> not from screen reader via CSS, and neither zoom nor
>> keyboard-only users ever know the list exists.)
>
> By using the 'focus' event it is possible to expose shortcuts, etc to  
> keyboard users, while keeping them hidden from the >conventional visual  
> display.

Although by the time you get to the thing, you don't need an accesskey.

Here Opera's implementation is really streets ahead of anyone else.  
Unfortunately that means it is basically functional, when the competition  
is still pretty poor. That's a big step forward from "actively harmful"  
which was the state of many implementations five years ago.

Press shift-esc (I used to reconfigure that to "," which Opera also lets  
you do) and you get a menu that tells you what the access keys are. Click  
one. Or click esc and the thing goes away.

There are extensions for other browsers to show the accesskeys - as the  
Wikipedia article [0] says, you only need a single line of CSS like

  *[accesskey]:after {content: "[" attr("accesskey") "]"}

to show the accesskey. So it's pretty sad browsers by and large still  
don't manage this.

I wrote an extension called Excesskey [1] for Opera that does a few other  
useful things. Like allowing the user to decide what keys to use - and  
remapping the actual accesskeys to those in the list (e.g. I can set  
accesskeys to all use cyrillic, which is handy for me when I am using a  
cyrillic keyboard).

> Smart design can will ensure accesskeys are exposed to users when  
> applicable.

Yes.

> Ignoring the benefits accesskeys can bring to >a large segment of the  
> user population [...] who >do not have AT installed, is like throwing  
> out the baby with the bathwater. Careful consideration of how the  
> accesskey >attribute is used, can enhance the experience for a huge  
> group of people without causing interference to others.

Yes. Although until browsers make decent implementations, few of the  
people who should benefit actually will. It's still something that takes  
specialist knowledge on the part of a user ;(

[0] http://en.wikipedia.org/wiki/Access_key
[1] http://my.opera.com/chaals/blog/excesskey

cheers

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
         chaals@yandex-team.ru         Find more at http://yandex.com
Received on Monday, 15 October 2012 21:29:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 15 October 2012 21:29:13 GMT