[drupal-devel] [feature] Automatic access keys - considered harmful

Thu May 26 04:29:35 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:   Steven
 Status:       patch

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.

Steven

Previous comments:
------------------------------------------------------------------------

May 26, 2005 - 03: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 26, 2005 - 03:49 : Steven

Here's how it looks:
http://acko.net/dumpx/accesskey1.png

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

May 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 05: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