Guides and Sample Code


macOS Human Interface Guidelines

On This Page

Interaction and Input

Support the Keyboard

All users need to use the keyboard sometimes, and some users prefer using the keyboard to using a mouse or trackpad. VoiceOver users often use only the keyboard.

image: ../Art/keyboard_prefs_2x.png

Provide keyboard-only alternatives. Many people prefer using a keyboard to using a mouse or a trackpad. Others, such as VoiceOver users, need to use the keyboard. There are two main ways to support keyboard users:

  • Respect the standard keyboard shortcuts and create app-specific shortcuts for frequently used commands.

  • Add support for full keyboard access mode to all your custom UI elements. Full keyboard access mode allows users to navigate and activate windows, menus, UI elements, and system features using the keyboard alone.

Avoid overriding the standard keyboard shortcuts users are familiar with. Users expect these shortcuts to mean the same thing in each app they use. The standard shortcuts are also listed in Table 72-3. Standard shortcuts are not marked with the Apple symbol shown here.

image: ../Art/ks_apple_icon_2x.png

In rare cases, it is acceptable to redefine a common keyboard shortcut. For example, if users spend most of their time in your app, it can make sense to redefine shortcuts that don’t apply to the tasks your app enables. Or, if most of your users have used your app on a different platform, you might not want to change the keyboard shortcuts they already know.

Don’t feel that you must create a shortcut for every command in your app. If you try to do this, you’ll probably end up with some shortcuts that are unintuitive, hard to remember, and physically difficult to perform. Instead, identify the most frequently used commands in your app and create logical shortcuts for them. Examine Table 72-3 for characters and combinations that are not reserved by macOS or commonly used.

Gestures Can Enhance the User Experience

A trackpad gives people another way to move the pointer and activate UI elements. macOS supports Multi-Touch trackpad gestures, which let people perform actions such as revealing Mission Control, switching to a different full-screen window or desktop, and returning to the previous page in an app, and Force Touch trackpad actions, which enable a richer experience for specific controls. Users expect to be able to use these familiar gestures throughout the system and in the apps they download.

image: ../Art/gesture_prefs_2x.png

Pay attention to the meaning of a gesture, not to the physical movements users make. In other words, instead of preparing to respond to a three-finger swipe, be prepared to respond to a "go to the previous page” gesture. Users can also change the physical movements that perform the system-supported actions, so your app should listen to the gesture that macOS reports.

As much as possible, respond to gestures in a way that’s consistent with other apps on the platform. For the most part, users expect gestures to work the same regardless of the app they’re currently using. For example, users should be able to use the “go back” gesture whether the app displays content in document pages, webpages, or images. In a system with a Force Touch trackpad, users expect apps to behave in predictable and consistent ways when they force click a control to get more information or accelerate an action.

Avoid redefining the systemwide, inter-app gestures. Even when users are playing a game that might use app-specific gestures in a custom way, they expect to be able to use systemwide gestures to perform actions, such as revealing Mission Control or switching to another desktop or full-screen window. (Note that users can change the precise gestures that perform these actions in Trackpad system preferences.)

Handle gestures as responsively as possible. Gestures should heighten the user’s sense of direct manipulation and provide immediate, live feedback. To achieve this, aim to perform relatively inexpensive operations for the duration of the gesture.

Ensure that gestures apply to UI elements of the appropriate granularity. In general, gestures are most effective when they target a specific object or view in a window, because such views are usually the focus of the user’s attention. Start by identifying the most specific object or view the user is likely to manipulate and make it the target of a gesture. Make a higher level or containing object a gesture target only if it makes sense in your app.

Define custom gestures cautiously. A custom gesture can be difficult for users to discover and remember. If a custom gesture seems gratuitous or awkward to perform, users are likely to avoid using it. If you feel you must define a custom gesture, be sure to make it easy to perform and not too similar to the gestures users already know.

Avoid relying on the availability of a Force Touch trackpad or a specific gesture as the only way to perform an action. You can’t be sure that all your users have a trackpad or want to use it. In addition, trackpad users can disable some gestures, or change their meaning, in Trackpad preferences.

Make Entering Text Easy

Most apps need to support text entry in some form. It’s a good idea to make the process as easy and convenient as possible.

When possible and appropriate, automatically fill in text fields as users type. Users appreciate the convenience of having some information supplied for them, as long as it’s correct. If you can’t guarantee the accuracy of the information you provide, it’s better to leave text fields empty. If you supply text, be sure to indicate the fields you are filling in (perhaps by highlighting them), so that the user can easily distinguish the information your app provides from the information they provide. Note that a password field should always be empty.

Perform appropriate edit checks as users enter information. For example, if the only legitimate value for a field is a string of digits, the app should alert users as soon as they type a nondigit character. Verifying user input as your app receives it helps avoid errors caused by unexpected data. For a more complete discussion of when to check for errors and apply changes in text fields, see Accepting and Applying User Input in a Dialog.

Defer displaying a "required" icon next to a required field until users leave the context without handling it. Preemptively displaying an asterisk or a custom icon next to each required text field and selection control can make your UI appear cluttered and unappealing. Instead, assume that users will fill in all the required fields; if they forget one, display an asterisk or custom icon next to the forgotten field when they attempt to exit the current context. This strategy helps you maintain an attractive UI, while at the same time helping you avoid treating users as if they were children.

Preserve users’ privacy as they enter a password. In this situation, each character the user types should appear as a bullet. If the user deletes a character with the Delete key, one bullet is deleted from the text field and the insertion point moves back one bullet, as if the bullet represented an actual character. Double-clicking bullets in a password field selects all the bullets, but does not allow them to be copied. When the user leaves the text field (by pressing Tab, for example), the number of bullets in the text field should be modified so that the field doesn’t reflect the actual number of characters in the password.