6

I am trying to maintain compliance with the Windows 7 User Experience Interaction Guidelines and I am having trouble in some dialog boxes with the rule that OK buttons should not have an access key (such as Alt+O) but instead should be the default key. In dialogs with simple controls it is easy to follow the rule, but in dialogs with controls that need to respond to the Enter key (such as a memo or a grid) there is no way to activate the OK button without tabbing to it. I have considered using a label like Finished (with an Access) key but that creates a new inconsistency (calling the button something other than OK when OK otherwise makes sense). How can I deal with this is a logical and consistent way while maintaining conformity with the guidelines?

Also, how hard and fast is this rule? The guideline states:

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.

This seems to imply that it might be acceptable to provide access keys for OK and Cancel if you are willing to accept that O and C will be unavailable as access keys for other buttons.       

4

You've got it almost right.

The Enter key and the OK button

Enter is the access key for the OK button, by default. As with all defaults, the user's actions can modify this. In the case of Enter and OK, users can only modify this temporarily, because the dialog box will (is supposed to) revert to the default.

At times the OK button cannot be accessed by the Enter key, because the Enter key temporarily has another function or is temporarily associated with a button or function other than OK. This temporary situation will be the direct result of the user's actions.

As the user moves the focus to other controls, some of those controls take the Enter key instead of the OK button. But as soon as the focus leaves such a control, the OK button again becomes the button that takes the Enter key. The point is to help the user as much as possible with the Enter-as-OK shortcut, but not to the user's detriment, so Enter-as-OK doesn't always work. Specifically:

  • not when it would be unexpected. For example, when a different button has focus, that button takes the Enter key.
  • not when it would be in conflict with another interaction paradigm. For example, "I'm typing, so Enter must enter a new paragraph." [Added after a comment.]

All this was a bit easier to see before the Modernist ("flat") UI of Windows 8 and Windows 10. Here's an illustration from Windows 7 that shows the dotted line on or around a control that has focus, and the blue border on the button that currently takes the Enter key. Sometimes they're both on the same control:

Focus and Enter on different controls or the same control

I've tried to write and illustrate this as clearly as I can. Sometimes a demo is clearer than words and pictures, because it shows the transition, so here's a 1-minute movie to illustrate.

The button name

As for the button name, follow the standard. Note that the first illustration is of a "typical" command button: OK. It's always a safe choice. If you need more creativity, then consider a pattern that uses command links instead of command buttons.

I hope that helps you move forward.

|improve this answer|||||
  • 1
    Thank you, that is helpful. The thing I am struggling with is this: If I don't provide an access key (&OK) for OK, then there are times when OK can't be activated by the keyboard (e.g., when a multiline edit has focus). This seems awkward -- if I call OK something else (like &Finished) then the user can directly accept the changes and close the dialog. So why not just go with &OK even though this is (at minimum) dscouraged by the UX guide? – TomT Aug 1 '15 at 22:27
  • Call it the OK button except where variations are permitted by the guidelines. And yes, at times, the OK button cannot be accessed by the Enter key, because the Enter key temporarily has another function or is temporarily associated with another button than OK. On a bit of a tangent, the section on command links may give you another design pattern to use: msdn.microsoft.com/en-us/library/windows/desktop/… – JeromeR Aug 1 '15 at 22:47
  • 1
    JeromeR your last comment completes your answer to my question -- that it is acceptable that OK is sometimes not KB-accessible until focused is moved away from a control that absorbs the enter key (such as a multi-line edit). I will accept your answer if you combine your comment above with your formal answer. Thank you for the video. – TomT Aug 2 '15 at 12:14
  • Hi @TomT, I've incorporated the comments into the answer, with a slight re-write. Thanks for voting this the answer. – JeromeR Aug 3 '15 at 5:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.