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: Kobus Status: patch 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 Kobus 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... [5] http://diveintoaccessibility.org/accessibility_statement.html ------------------------------------------------------------------------ May 26, 2005 - 06: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 - 13: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 - 14: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.