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