GNOME Bugzilla – Bug 302057
Keys for <default> and Cancel should be Enter and Escape, and nothing else
Last modified: 2021-07-05 10:53:47 UTC
Distribution/Version: Ubuntu 5.04 Currently the HIG specifies that Enter *must* activate the default button in information alerts, *may* activate the default button in error alerts, *must do different things* depending on which control is focused in authentication alerts, and that "Return" (not Enter) *may* activate the default button in dialogs. It specifies nothing in particular for the Escape key (bug 124902). At the same time, the HIG says to "Give all labeled components an access key (underlined letter), with the exception of toolbar controls" <http://developer.gnome.org/projects/gup/hig/draft_hig_new/input-keyboard.html#choosing-access-keys>. Usually developers choose C for "Cancel" or and O for "OK". This is a wee bit of a mess. Because the support of Escape and Enter is not compulsory, people cannot be sure whether those keys will work for a particular alert or dialog. So they'll either hesitantly try them, slowing them down, or they'll start using access keys all the time, slowing them down. (Alt+someLetter is (1) more keys, (2) smaller keys, and (3) less predictable.) Giving those buttons access keys also prevents (for example) C or O from being used as the access key for *any* control in *any* tab of *any* panel of the same dialog. I suggest fixing all this with the following wording, distributed among HIG sections as necessary. In any alert that has only one button, that button should be labelled 'OK'. Enter (and also Ctrl+Enter) should activate this button. Do not also give it an access key, as that would slow people down. In any alert or dialog that has two or more buttons, Escape should activate the "Cancel" button. Enter should activate the main action button, unless a multi-line text field is focused (and Ctrl+Enter should activate the button regardless of focus). Do not also give either of these buttons access keys, as that would slow people down. (These guidelines apply only to alerts and dialogs, not to instant-apply windows.) As special protection, Enter should not activate the main action button if the resulting action is highly destructive (for example, erasing a disk). In these cases do not make Enter do anything else either, as people may press it expecting it to work. In a progress window, Escape should activate the only button in the window ("Cancel" or "Stop"). Do not also give it an access key, as that would slow people down.
I'd agree with binding Escape to the 'Cancel' button, but not with forcing Enter to always activate the main action. It'd break familiarity (every system I can remember using has (mostly) followed the convention of "Enter activates the focused control"), and likely cause confusion among users who don't understand why, when they tab to the control they want and press Enter, GNOME is doing something else instead.
In Mac OS X, Enter always activates the default button, not the focused button. The focused button is activated by Space, and indicated by a focus ring (very different from the solid blueness of the default button). The current GNOME behavior cannot work well for any theme that makes the default button look unmistakably different from other buttons: for that different appearance to bounce around as the focus changed would be jarring.
Since I reported this bug, Microsoft has partly adopted the guidelines I proposed. (Mac software already follows them, though as far as I know the existence of access keys has never been acknowledged in Apple interface guidelines.) The Windows Vista User Experience Guidelines say: "Don't assign access keys to OK and Cancel buttons, because Enter is the access key for the default button (which is usually the OK button), and Esc is the access key for Cancel. Doing so makes the other access keys easier to assign." <http://msdn.microsoft.com/en-us/library/aa511453.aspx#labels>
*** Bug 315047 has been marked as a duplicate of this bug. ***
I've added recommendations for always binding return and escape: https://git.gnome.org/browse/gnome-devel-docs/commit/?id=f6e60f87203ad4e74fe1da262735aa8e3c375fd0 The only part of this bug that remains (if I'm following correctly), is whether mnemonics should be provided for keys that are already covered by return/escape.
(In reply to comment #5) > I've added recommendations for always binding return and escape: > > https://git.gnome.org/browse/gnome-devel-docs/commit/?id=f6e60f87203ad4e74fe1da262735aa8e3c375fd0 > > The only part of this bug that remains (if I'm following correctly), is whether > mnemonics should be provided for keys that are already covered by > return/escape. IMO they should be provided. It is not in all cases obvious that return/esc is the way to go so if the user explicitly presses alt to see the mnemonics, we should show him some for every button.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-devel-docs/-/issues/ Thank you for your understanding and your help.