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.

CommentFileSizeAuthor
accesskey.patch5.83 KBSteven

Comments

Steven’s picture

Steven commented

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

moshe weitzman’s picture

moshe weitzman commented

this kicks ass. nice work, unConed.

i only see form_button() in the patch. did you not patch the other form_x functions?

Steven’s picture

Steven commented

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

Steven’s picture

Steven commented

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);
    }
  }
}
junyor’s picture

junyor commented

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.

willmoy’s picture

willmoy commented
Title: Automatic access keys » Automatic access keys - considered harmful

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...
[5] http://diveintoaccessibility.org/accessibility_statement.html

Steven’s picture

Steven commented

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.

resmini’s picture

resmini commented

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

willmoy’s picture

willmoy commented

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.

Kobus’s picture

Kobus commented

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

Thox’s picture

Thox commented

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.

danielc’s picture

danielc commented

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.

moshe weitzman’s picture

moshe weitzman commented
Title: Automatic access keys - considered harmful » Automatic access keys

Admins who don't want this should simply disable it. I think it can be used with great success on many sites.

Steven’s picture

Steven commented

Firstly, a note about existing access keys... many programs include a host of unofficial access keys.

For example, in Windows on many apps, the old DOS-style keys for copy/pasting work (CTRL-INSERT copy, SHIFT-INSERT paste, SHIFT-DELETE cut). But they are indicated nowhere.

My Firefox says CTRL-L is the key for moving to the address bar. ALT-D works, but it is a legacy key with no documentation.

Just because a key is mapped does not mean that it is the default key.

That is why I would agree with moshe to make this behaviour optional, preferably per-user, and only to not map to keys that are reserved as "primary" or "official" key shortcuts in browsers.

The question is: can people who experience access key conflicts get into the account page? I would prefer it if the default value was "enabled".

Steven’s picture

Steven commented

Also, as far as windows menus goes, you can always access them by pressing ALT, then the key, without holding anything.

Kobus’s picture

Kobus commented

I still vote a +1 for this, however Moshe said that it should be an admin issue, but I think it should be a user issue though. I might not have specific uses for shortcut keys in my browsers, but my site visitors may...

Kobus

willmoy’s picture

willmoy commented

I basically agree with Kobus - as a per-user option, it is actually a really useful idea and great for usability.

But it should be off by default.
- Access keys are basically a power user's tool, especially on websites where >99% wouldn't have a clue what they are. Power users won't have a problem enabling it.

- This patch could create a situation in which someone trying to do something completely normal (like getting the menu for a Mozilla extension) unexpectedly made something happen in Drupal (published, deleted, whatever). That would be bad UX and, I think, a bug. If they've enabled it themselves, it's just their own silly fault ;)

- Drupal should be as accessible as possible out of the box. IBM Home Page Reader makes extensive use of alt+char key combinations, including almost all the ones mentioned as free by danielc. Somebody browsing a site with this functionality using HPR is likely to activate an access key long before they get past the menu... whoops :)

Finally, I would suggest you consider adding a site-wide setting that gives admins the options of: always on | user decides | always off.

If it's not on by default, I would consider this a usability boost, particularly for sites like drupal.org.

Crell’s picture

Crell commented
Status: Needs review » Needs work

Personally I like the idea of access keys, but the patch is now very old and no longer applies, since it predates the new form API. Setting to "needs work" accordingly.

moshe weitzman’s picture

moshe weitzman commented
Version: x.y.z » 6.x-dev

The world has changed. I'd love to see this reimplemented as a Contrib module using either form_alter() or jquery to add the accesskey markup.

pancho’s picture

pancho
Location UTC+2 🇪🇺 EU
commented
Assigned: Steven » Unassigned
Priority: Normal » Critical

Why shouldn't this be a core feature? I mark this critical, but bump it to D7.

pancho’s picture

pancho
Location UTC+2 🇪🇺 EU
commented
Version: 6.x-dev » 7.x-dev

To be more direct: This should be in core, because it is very useful functionality. Most important, it can't be consistantly introduced via contrib as other contrib modules would need to support it.

choster’s picture

choster commented

The world may have changed, but accesskeys remain unstandardized, device-dependent, and prone to conflict with browser and OS shortcuts. Objections raised years ago such as http://lists.w3.org/Archives/Public/w3c-wai-ig/2003AprJun/0549.html and http://www.joedolson.com/accesskeys.php remain unaddressed. Johansson again discouraged their use just a few weeks ago, http://www.456bereastreet.com/archive/200712/overdoing_accessibility/ .

If implemented at all, they should be *user*-definable; cf http://juicystudio.com/article/user-defined-accesskeys.php .

jabba_29’s picture

jabba_29 commented
Version: 7.x-dev » 6.0

Is there any way to implement this in v6?

I managed to override this in v5 but can't for the life of me figure out to do this in 6

scoutbaker’s picture

scoutbaker commented
Version: 6.0 » 7.x-dev

@jabba_29: Don't change the version number. Feature requests always go against the current development version. In this case D7. If this feature is implemented, it is possible it may be backported to D6.

mgifford’s picture

mgifford
he/him
Primary language English
commented

Here's another call for user definable access keys:
http://www.blether.com/archives/2006/02/userdefined_acc.php

Would be nice to see this brought into Drupal. Anything but user defined accesskeys wouldn't work for us because as they say here:
http://www.hc-sc.gc.ca/home-accueil/help-aide/specific-caracteris-eng.php

According to the Treasury Board's Next link will take you to another Web site Common Look and Feel Guidelines, the use of Access Keys M, 1 and 2 are to be eliminated, and the use of any other access keys discouraged because there is no way of knowing which access keys conflict with any assistive technology or other applications installed and running on users' desktops.

So, it has to be user defined in order to work.

davidwhthomas’s picture

davidwhthomas commented

This module provides access keys

http://drupal.org/project/accesskeys

Perhaps the key could be wrapped in t() to allow translation.

DT

mgifford’s picture

mgifford
he/him
Primary language English
commented
Issue tags: +Accessibility

adding accessibility tag. Do think that this should fit into the won't fix status line.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

If this is a 'power user' feature that only 1-2% of site users are going to use, why is this appropriate for core instead of a contrib module?

Jeff Burnz’s picture

Jeff Burnz commented
Priority: Critical » Normal

Does not seem like a critically needed core feature. Setting back to normal.

Everett Zufelt’s picture

Everett Zufelt commented

Agree that access keys should be user defined. As a user of assistive technology I sometimes find myself on a site that has implemented an access key that interferes with my AT, or with browser access keys.

I do not believe that this is an issue for core, at least at this time.

I would agree that this should be set to won't fix.

Everett Zufelt’s picture

Everett Zufelt commented
Status: Needs work » Closed (won't fix)

Doesn't appear to be any opposition to setting this to won't fix. This is better left to a contrib module as even assistive technoloy users sometimes wish to not have access keys present on a page.

Access keys are not required for compliance with WCAG 2.0 http://www.w3.org/WAI/WCAG20/from10/comparison/

mgifford’s picture

mgifford
he/him
Primary language English
commented
Issue tags: +accesskey