13958 2011-08-29 18:47:51 +0000 Authors should be able to request specific modifiers for accesskeys 2012-09-15 12:17:07 +0000 1 1 1 Unclassified HTML.next default unspecified All All RESOLVED LATER RFE a11y P2 enhancement --- 1 ayg dave.null chaals devarshipant ehsan ian laura.lee.carlson mike plh public-html-a11y public-html-admin public-html-wg-issue-tracking rniwa robin public-html-bugzilla oldest_to_newest 56001 0 ayg 2011-08-29 18:47:51 +0000 Ryosuke, Ehsan, Annie, and I discussed this at our face-to-face meeting last week. See the "Keyboard shortcuts" section of the Etherpad, for the second day: http://etherpad.mozilla.com:9000/html-editing-mozilla-google-meeting-minutes Currently, authors get no control over which modifiers are used for accesskeys. accesskey=b might mean Alt-B, Ctrl-B, Alt-Shift-B, Shift-Esc-B, etc. This is fine in a lot of cases, but sometimes authors want more control. For instance, users expect that pressing Ctrl-B (or Cmd-B on Mac) will make text bold in a rich-text editor. Thus authors intercept key events. This is bad, because it's a pain and easy to get wrong. Authors have to manually sniff Mac vs. Windows/Linux to decide whether to recognize Cmd or Ctrl. Also, the accesskey won't be visible as an accesskey when hitting Shift-Esc in Opera or anything else that cares about accesskeys. This might include AT (I don't know). It would be better if authors could declaratively request a specific modifier, and programmatically detect if they got it or not. For the use-cases I know of, the only modifier authors would need to request is the accelerator (Cmd on Mac, Ctrl on Windows/Linux). Perhaps in the accesskey attribute, tokens could be optionally prefixed by "accel-" to request the accelerator instead of the normal modifier. Like this: <button onclick="execCommand('bold')" accesskey="accel-b"><b>B</b></button> Whether it worked could be detectable using accessKeyLabel. 56058 1 ehsan 2011-08-30 19:31:57 +0000 Should accessKeyLabel be the same as the accesskey attribute value if this works? 56060 2 ayg 2011-08-30 19:33:43 +0000 I don't think so. I'd want accessKeyLabel to reflect cmd vs. ctrl, at least, not be a generic "accel". 56061 3 ehsan 2011-08-30 19:36:34 +0000 But that would require authors to handle Mac and Windows/Linux cases separately in their code, right? Why can't we just require UAs to map "accel" to the default platform accelerator key? 56062 4 rniwa 2011-08-30 19:38:54 +0000 (In reply to comment #3) > But that would require authors to handle Mac and Windows/Linux cases separately > in their code, right? Why can't we just require UAs to map "accel" to the > default platform accelerator key? I don't think that's necessary true. As far as I know, the label is intended to be used a part of UI; not something the authors should be parsing. 56068 5 ayg 2011-08-30 20:20:17 +0000 Right. accessKeyLabel is (I think) meant to be used to inform the user what the accesskey is. I filed bug 13902 to request that the format be standardized so that authors can easily parse it if they want, though. 58619 6 ian 2011-10-21 05:37:21 +0000 This is already on the medium-term plan for accesskey. I intend to add "modifier+" prefixes to what is currently just single-letter items, as well as key names ("home", "F1", etc; see bug 13576). That's why the spec currently says to ignore values longer than one character. First I'm waiting for implementations to pick up the stuff we've specced so far. One open question is what to do about the way that different platforms use different accelerators for different purposes. e.g. Windows uses Ctrl where Mac uses Command; Mac and Unix have accelerators like Ctrl+A for going to the start of the line, and each platform has their own eccentricities, e.g. Mac's "Home" key doesn't act like Windows' "Home" key; "Shift-Delete" on Windows is quite different than on Mac, etc. I don't really want to have to list a bazillion "virtual" keys for these purposes. Any suggestions welcome. For now I'm marking this LATER; please don't hesitate to reopen this if you notice before I do that browsers have adopted what we have here so far (accesskey="a b c", accessKeyLabel, etc). 58624 7 rniwa 2011-10-21 06:19:26 +0000 (In reply to comment #6) > One open question is what to do about the way that different platforms use > different accelerators for different purposes. e.g. Windows uses Ctrl where Mac > uses Command; Mac and Unix have accelerators like Ctrl+A for going to the start > of the line, and each platform has their own eccentricities, e.g. Mac's "Home" > key doesn't act like Windows' "Home" key; "Shift-Delete" on Windows is quite > different than on Mac, etc. I don't really want to have to list a bazillion > "virtual" keys for these purposes. I think we should translate these to editing command name; e.g. Delete, DeleteForward, etc... In WebKit at least, home, end, etc... are also translated to editing commands internally. Once we add beforeeditingaction and editingaction events (or extend beforeinput/input events), then authors can intercept those commands instead of adding specific key bindings by menu/command/etc... 73955 8 chaals 2012-09-15 12:11:02 +0000 (In reply to comment #7) > (In reply to comment #6) > > One open question is what to do about the way that different platforms use > > different accelerators for different purposes. e.g. Windows uses Ctrl where Mac > > uses Command; Mac and Unix have accelerators like Ctrl+A for going to the start > > of the line, and each platform has their own eccentricities, e.g. Mac's "Home" > > key doesn't act like Windows' "Home" key; "Shift-Delete" on Windows is quite > > different than on Mac, etc. I don't really want to have to list a bazillion > > "virtual" keys for these purposes. > > I think we should translate these to editing command name; e.g. Delete, > DeleteForward, etc... In WebKit at least, home, end, etc... are also translated > to editing commands internally. > > Once we add beforeeditingaction and editingaction events (or extend > beforeinput/input events), then authors can intercept those commands instead of > adding specific key bindings by menu/command/etc... Where there are commands (see IndieUI - someone else is inventing those wheels), there should be no need to define accesskeys, as the user agent should take care of providing access to the commands in a way that makes sense to the user. Letting the author interfere in this is simply a recipe to perpetuate the mess we have had for the last decade, of things that don't actually work at all on many systems in the name of giving the author the ability to force everything to match whatever system s/he did imagine. 73956 9 chaals 2012-09-15 12:17:07 +0000 (In reply to comment #6) > This is already on the medium-term plan for accesskey. I intend to add > "modifier+" prefixes to what is currently just single-letter items, as well as > key names ("home", "F1", etc; see bug 13576). That's why the spec currently > says to ignore values longer than one character. First I'm waiting for > implementations to pick up the stuff we've specced so far. > > One open question is what to do about the way that different platforms use > different accelerators for different purposes. e.g. Windows uses Ctrl where Mac > uses Command; Mac and Unix have accelerators like Ctrl+A for going to the start > of the line, and each platform has their own eccentricities, e.g. Mac's "Home" > key doesn't act like Windows' "Home" key; "Shift-Delete" on Windows is quite > different than on Mac, etc. I don't really want to have to list a bazillion > "virtual" keys for these purposes. > > Any suggestions welcome. For now I'm marking this LATER; please don't hesitate > to reopen this if you notice before I do that browsers have adopted what we > have here so far (accesskey="a b c", accessKeyLabel, etc). Suggestion: Please don't add modifiers as a way to give authors more control. (Adding key names is fine - and as we appear likely to get more voice commands in the web being able to add words is going to help attach commands directly to the interface of a page instead of relying solely on the browser). Accesskeys have a fighting chance of being useful precisely to the extent that authors *don't* control them, and accept that the user agent won't allow that. They were fine for a decade on mobile phones that had keypads even while they were unusable on a number of desktop browsers that gave authors the ability to interfere with the browser's user interface.