[drupal-devel] [feature] Automatic access keys

[Steven]

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

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);
    }
  }
}




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).