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: moshe weitzman Status: patch this kicks ass. nice work, unConed. i only see form_button() in the patch. did you not patch the other form_x functions? moshe weitzman Previous comments: ------------------------------------------------------------------------ May 25, 2005 - 20: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 25, 2005 - 20:49 : Steven Here's how it looks: http://acko.net/dumpx/accesskey1.png

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

On May 25, 2005, at 6:43 PM, Steven wrote:

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

+1 This is big plus for the documentation team, that needs to be able to apply lots of consistent edits quickly to the handbooks. This saves time and improves accesibility. Kieran

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

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: willmoy Status: patch "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. willmoy Previous comments: ------------------------------------------------------------------------ May 26, 2005 - 01: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 - 01:49 : Steven Here's how it looks: http://acko.net/dumpx/accesskey1.png ------------------------------------------------------------------------ May 26, 2005 - 02: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 - 02: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 - 02: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 - 02: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 - 03: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 - 04: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 - 11: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

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: Thox Status: patch 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. Thox Previous comments: ------------------------------------------------------------------------ May 26, 2005 - 01: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 - 01:49 : Steven Here's how it looks: http://acko.net/dumpx/accesskey1.png ------------------------------------------------------------------------ May 26, 2005 - 02: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 - 02: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 - 02: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 - 02: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 - 03: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 - 04: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 - 11: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 - 12: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. ------------------------------------------------------------------------ May 26, 2005 - 12:30 : Kobus 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

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: moshe weitzman Status: patch Admins who don't want this should simply disable it. I think it can be used with great success on many sites. moshe weitzman Previous comments: ------------------------------------------------------------------------ May 25, 2005 - 20: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 25, 2005 - 20:49 : Steven Here's how it looks: http://acko.net/dumpx/accesskey1.png ------------------------------------------------------------------------ May 25, 2005 - 21: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 25, 2005 - 21: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 25, 2005 - 21: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 25, 2005 - 21: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 25, 2005 - 22: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 25, 2005 - 23: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 - 06: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 - 07: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. ------------------------------------------------------------------------ May 26, 2005 - 07:30 : Kobus 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 ------------------------------------------------------------------------ May 26, 2005 - 07:48 : Thox 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. ------------------------------------------------------------------------ May 26, 2005 - 08:57 : danielc 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.

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 Also, as far as windows menus goes, you can always access them by pressing ALT, then the key, without holding anything. 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... [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. ------------------------------------------------------------------------ May 26, 2005 - 14:30 : Kobus 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 ------------------------------------------------------------------------ May 26, 2005 - 14:48 : Thox 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. ------------------------------------------------------------------------ May 26, 2005 - 15:57 : danielc 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. ------------------------------------------------------------------------ May 27, 2005 - 03:19 : moshe weitzman Admins who don't want this should simply disable it. I think it can be used with great success on many sites. ------------------------------------------------------------------------ May 27, 2005 - 05:06 : Steven 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".

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: willmoy Status: patch 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. willmoy Previous comments: ------------------------------------------------------------------------ May 26, 2005 - 01: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 - 01:49 : Steven Here's how it looks: http://acko.net/dumpx/accesskey1.png ------------------------------------------------------------------------ May 26, 2005 - 02: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 - 02: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 - 02: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 - 02: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 - 03: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 - 04: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 - 11: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 - 12: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. ------------------------------------------------------------------------ May 26, 2005 - 12:30 : Kobus 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 ------------------------------------------------------------------------ May 26, 2005 - 12:48 : Thox 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. ------------------------------------------------------------------------ May 26, 2005 - 13:57 : danielc 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. ------------------------------------------------------------------------ May 27, 2005 - 01:19 : moshe weitzman Admins who don't want this should simply disable it. I think it can be used with great success on many sites. ------------------------------------------------------------------------ May 27, 2005 - 03:06 : Steven 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". ------------------------------------------------------------------------ May 27, 2005 - 03:14 : Steven Also, as far as windows menus goes, you can always access them by pressing ALT, then the key, without holding anything. ------------------------------------------------------------------------ May 27, 2005 - 06:26 : Kobus 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