[drupal-devel] [feature] Automatic access keys - considered harmful
danielc
drupal-devel at drupal.org
Thu May 26 13:57:11 UTC 2005
Issue status update for http://drupal.org/node/23628
Project: Drupal
Version: cvs
Component: base system
Category: feature requests
Priority: normal
Assigned to: Steven
Reported by: Steven
Updated by: danielc
Status: patch
I LOVE access keys. Here's a list of available keys:
Unused Access Keys
------------------
C I J K L m n O p R S X Y Z
NOTE: The case of the letters above indicates
availability. Upper case means the letter
is free in all browsers checked. Lower case
means the letter is only used only in Opera.
Preexisting Access Keys
-----------------------
A ie6
B m1.5 o7
D ie6 m1.4
E ie6 m1.5 o7
F ie6 m1.5 o7
G m1.5
H ie6 m1.5 o7
M o7
N o7
P o7
Q m1.5
T ie6 m1.5
U m1.5
V ie6 m1.5 o7
W m1.5 o7
NOTE: Keys used in m1.5 are also used m1.4.
Opera 7 is mentioned here for the sake of
completeness, but since Opera 7 doesn't
provide keyboard navigation, you may consider
avoiding letters it uses to be a non-issue.
danielc
Previous comments:
------------------------------------------------------------------------
May 25, 2005 - 20:30 : Steven
Attachment: http://drupal.org/files/issues/accesskey.patch (5.83 KB)
Access keys for forms are an important aspect of usability and
accessibility. Especially with form buttons, they allow you to select
the right button immediately (e.g. ALT-P preview, ALT-S Submit).
To add access keys to Drupal, there are several problems:
Due to the modularity, it is hard to ensure all access keys within a
form are unique. This puts a burden on the module author (who may not
care about access keys).
Also due to this, it is hard to ensure access keys for identical
commands can have the same access key across Drupal.
Drupal is localizable, so access keys need to be able to adapt to
languages. If I translate "Preview" to "Voorbeeld", it doesn't make
sense to assign it the accesskey P.
This patch addresses these problems elegantly, by assigning access keys
dynamically. It ensures access keys are unique, so no effort is required
from the module author.
It also contains some reserved commands which always receive their
access key first. This ensures these labels always have the same access
key, no matter which form they are in (e.g. Preview, Submit, Delete,
...). Once P is mapped to Preview, "Publish" will have to use U (or B,
or L, ...).
Localization is also handled, because the code for finding access keys
is completely UTF-8 aware and works on the translated labels. On a
russian site, russian characters will be mapped. The assumption is that
the user can type in the site's character set, which is fair.
Here's how it maps out in practice:
Preview -> P (priority, this will always be P on any page)
Publish -> U (handed out on a first-come basis)
Translated:
Voorbeeld -> V (priority, this will always be V on any page)
Publiceer -> P (handed out on a first-come basis)
Usually, access keys are displayed as underlined characters in the
label. I implemented this, but made it themable so you have full
liberty in it. The access key is marked with <span
class="accesskey"></span> in a themable function theme_label_key and
the class is styled with an underline in drupal.css.
------------------------------------------------------------------------
May 25, 2005 - 20:49 : Steven
Here's how it looks:
http://acko.net/dumpx/accesskey1.png
------------------------------------------------------------------------
May 25, 2005 - 21:01 : moshe weitzman
this kicks ass. nice work, unConed.
i only see form_button() in the patch. did you not patch the other
form_x functions?
------------------------------------------------------------------------
May 25, 2005 - 21:11 : Steven
No, form_button() is the only control which is used without a label and
which needs an access key. The other controls receive theirs through
<label for=".." accesskey="..">. This is how W3C recommends you use
access keys.
Bad news though: I have just discovered form submission is broken in IE
due to this patch. I had to convert the <input type="submit" /> to
<button type="submit">..</button> to allow the access key to be styled
on the form label.
W3 says <button> should send its value attribute on submission... IE
sends the button tag's contents instead.
As far as I know there is no known fix. Either we have to drop the
styling of button access keys (not hard to do, but a drop in usability)
or we have to somehow strip_tags() the styling back out again (and this
won't be 100% reliable if a themer decides to do more exotic stuff with
the access key).
------------------------------------------------------------------------
May 25, 2005 - 21:20 : Steven
There is a third option: don't output accesskeys for buttons, but re-add
them on non-IE browsers through JavaScript onload. Something like:
if (!document.all) {
var buttons = document.getElementsByTagName('button');
for (i in button) {
if (key = button[i],getAttribute('accesskey')) {
button[i].innerHTML = eregReplace(key, '<span
class="accesskey">'+key+'</span>', button[i].innerHTML, 1);
}
}
}
------------------------------------------------------------------------
May 25, 2005 - 21:43 : Junyor
Some browsers other than IE support document.all, so you'd have to check
something else. Because of spoofing, checking the useragent string also
isn't reliable.
------------------------------------------------------------------------
May 25, 2005 - 22:52 : willmoy
Access keys considered harmful...
"Go to the Zen Garden in any browser that allows the ALT+D key
combination to select the address bar (IE and most Gecko browsers will
do the trick, Safari will not). Try selecting the address bar from the
keyboard. Instead of doing so, some browsers will select the fourth
design from the list on the right, since that list has been assigned
sequential keys from ‘a’ to ‘h’." [1]
a) This patch will assign keys that should not be assigned
If you work down 'Publish' until you get to 'L', ctrl+L will no longer
give you open URL in IE or FireFox, or Links mode in IBM screen reader.
These clashes are important for accessibility and very difficult to
avoid. Some testing suggests that only three keys are unambiguously
safe: '\', '/' and ']' [2] It should be noted that people often access
english language website in other-language browsers, so the set of
system menu characters is not predictable (e.g. i think the Finnish
file menu is alt+T). Incidentally, alt+S is commonly used for 'skip to
main content' links.
b) This patch breaks screen readers
By putting markup in the middle of a words (according to Joe Clark, not
tested myself)
c) This patch will not assign keys that should be assigned
Various organisations, governments, specialists and what not have come
up with lists of 'standard' access keys that they will implement, e.g.
the BBC [3], the UK government [4] and diveintoaccessibility.org [5].
They have some things in common, which are as standard as access key
standards get (utterly tenuous) so if we're doing access keys, we
should define them, especially alt+0.
0 - should present a page on how the access keys work
1 - home page
4 - search page
2 - (less certain) skip to main content (HMG uses alt+S)
-1, it's a very elegant patch to do the wrong thing and as long as site
defined access keys overrule standard browser shortcuts, it shouldn't be
in core.
Sorry for the length of this.
Cheers,
Will
[1] http://www.mezzoblue.com/archives/2003/12/29/i_do_not_use/
[2] http://wats.ca/articles/accesskeys/19
[3] http://www.bbc.co.uk/accessibility/accesskeys/keys.shtml
[4]
http://www.cabinetoffice.gov.uk/e-government/resources/handbook/html/2-4.asp#2.4.4
[5] http://diveintoaccessibility.org/accessibility_statement.html
------------------------------------------------------------------------
May 25, 2005 - 23:29 : Steven
It's easy to modify the patch to not assign certain keys. That doesn't
mean we should can the whole idea.
In Firefox, all browser shortcuts use CTRL, so a page can safely use
ALT. The same is true for Opera and Internet Explorer as far as I can
tell.
As far as assigning standard keys like ALT-0 or ALT-1, that can be
included as an extra to this patch. We can update the reserved keys
list to not override them.
------------------------------------------------------------------------
May 26, 2005 - 06:25 : resmini
In Firefox, some functions are mapped to ALT as well, as pointed out
previously.
Alt + D moves the cursor to the address bar, for example.
See full list here: http://www.mozilla.org/support/firefox/keyboard
------------------------------------------------------------------------
May 26, 2005 - 07:24 : willmoy
"It's easy to modify the patch to not assign certain keys. That doesn't
mean we should can the whole idea.
"
But as I said before, there are almost no keys that it are safe to
allocate
"In Firefox, all browser shortcuts use CTRL, so a page can safely use
ALT. The same is true for Opera and Internet Explorer as far as I can
tell.
"
Every windows application uses alt+key to control the menus.
alt+D (for example) is the browser shortcut for 'take me to the address
bar' in firefox and Internet Explorer (I don't have Opera to hand). Just
because there are alternatives, that doesn't make it acceptable to break
functionality people may depend upon: they may not know about the
alternatives and it violates user expectations (bad UX). What if
pressing the key to type a new site into the address bar accidentally
deleted your page?
"As far as assigning standard keys like ALT-0 or ALT-1, that can be
included as an extra to this patch.
"
Thanks, but I've just noticed that the people who made new JAWS
extension for firefox decided to use alt+1 .. alt+6 for header cycling,
so I wouldn't suggest it.
And even if you make those changes, this patch will still break screen
readers by overriding their control keys.
------------------------------------------------------------------------
May 26, 2005 - 07:30 : Kobus
I don't know how possible this is in PHP, but since CTRL+key is used,
and ALT+key is used, what about CTRL+ALT+key? Wouldn't this reduce the
risk of these problems occuring? If you really want to make it hard to
press, you can even throw in a rogue SHIFT key or two ;)
Kobus
------------------------------------------------------------------------
May 26, 2005 - 07:48 : Thox
Kobus, accesskeys are a built-in browser feature which are accessed by
holding Alt + [accesskey] (for IE and Firefox, other browsers vary).
Using any other keys would require JavaScript and wouldn't be
particularly cross browser compatible.
I personally use Winamp with global access keys (e.g. CTRL + ALT + J to
bring up a playlist), so even there, I wouldn't appreciate my browser
using the same keys. In fact, although I originally agreed that we
could/should use accesskeys like S and P for Submit and Preview, I've
noticed that I'm already using ALT + S for the FF Sage extension.
In summary, I agree that there are no "Safe" keys for us to use. Are
there any alternatives? The basic functionality we are aiming for here
is to be able to quickly submit a form from Drupal without having to
scroll down.
More information about the drupal-devel
mailing list