Experience design

What a nice gesture…

…as long as you provide users with an alternative way to interact with your experience. When designing interactions:

Use simple single pointer actions

A single pointer action is when the pointer can be used with only one point of contact on the screen, such as single taps/clicks, double taps/clicks, click & hold and long presses. Some users rely entirely on pointing devices or find simple pointer inputs much easier than multipoint (see what is a multipoint gesture?) or path-based gestures (see what is a path-based gesture?). Additionally, some pointing methods and assistive technologies (like head pointers, eye-gaze systems, or speech-controlled mouse emulators) either can’t or inaccurately perform multipoint or path-based gestures so using a single pointer action improves a user’s chance of completing their task or action.

Don’t rely on multipoint gestures

Relying solely on these gestures neglects users with motor differences or users who are new to these gestures. If multipoint gestures are adopted, then the functionality should also be possible to operate by single pointer methods (see simple single pointer actions). For example, an interactive map can be used with pinch and zoom but also has zoom in (+) and zoom out (-) buttons that can be used with a click or tap.

Don’t rely on path-based gestures

Path-based gestures aren’t achievable by everyone so should be used sparingly and should always have an alternative method for those with motor differences to engage with. If you were to require a user to drag something to achieve a task, it should also be achievable with the arrow keys on their keyboard. Some more examples of these gestures include swiping, dragging, tracing or drawing, sliders and carousels. These types of gestures may be drawn with a finger, stylus, graphics tablet, trackpad, mouse, joystick and more.

Don’t depend on device or user motion

Functionality that can be operated by device motion or user motion (e.g. shaking, tilting or sensor-dependant gestures like waving) can also be operated by more typical user interface components and user should be able to turn the motion functionality off to prevent accidental action. Some users with disabilities are not able to operate these device sensors (either not at all, or not precisely enough) because the device is on a fixed mount (perhaps a wheelchair) or due to motor impairments.

Accuracy is overrated

Reduce the need for user’s interactions with our designs to be accurate by:

Using target sizes to avoid relying on precision

By relying on precision, we’re restricting users with motor differences such as hand tremors, those with low vision or those in certain situations i.e. using a device with only one hand or on a shaky train journey, from accessing information or carrying out important actions. A great way to avoid precision is to use target sizes for pointer and touch actions. These target sizes need to be large enough for users to easily interact with them whether on desktop or mobile as this reduces the need for accuracy. Target sizes should be at least 44 x 44 pixels. The only time target sizes aren’t applicable is for inline targets i.e. text links in a sentence.

Dynamic content appears upon selection, not hover

Avoid content appearing on hover, i.e. a tool tip opening and closing, because it requires precision from a user to find and hold their mouse or touchpoint on a specific area of a page to access information. It’s always better to have content appear upon selection because it shows clear intention from the user. Whereas content on hover ignores users intentions, meaning new content could interfere with their ability to do a task or be missed by the user. Some users with disabilities are not able to operate these device sensors (either not at all, or not precisely enough) because the device is on a fixed mount (perhaps a wheelchair) or due to motor impairments. If you do design content to appear on hover, the content must remain open to the user until they dismiss it so they have the chance to engage with the content to their satisfaction. Dismissing the content should be easy (see Dismiss notices with Esc key) and not disrupt the user’s page experience.

Don’t rely on mouse only

Some people with hand tremors find using a mouse very difficult so they usually prefer to use a keyboard. Therefore, anything that a user can do with a mouse or pointer, should also be possible with a keyboard. In essence, a keyboard user should easily be able to:

You can design for keyboard navigation by annotating wireframes to highlight interactive components or hover triggers (see ‘Dynamic content appears on selection not hover’) and including them in the tab order. Take care to display information in an order that is consistent with the meaning of the content, and that the focus order makes sense for keyboard navigation and screen readers.

Be a role modal

These are some helpful ways you can use to make your modals, overlays and notices usable for those navigating with a keyboard only:

Modals and overlays have a keyboard trap to stop users getting lost

If a user can navigate and move the focus of the page to a modal, overlay, notice, pop-up or other similar components with their keyboard, then the focus and functionality should stay (“trapped”) in that component until the user dismisses it. Users should be able to dismiss it with the ‘Esc’ key (on desktop) or by activating a close or cancel action. Otherwise, the user could get lost navigating through the rest of the page while the modal component is still open and obstructing their view.

Dismiss modals, overlays and notices with the Esc key

A quick and easy way to give your keyboard-only users more control and confidence in your product is to let modals, overlays and notices be dismissed by using the ‘Esc’ key. This easy and simple exit option avoids users getting stuck or having to tab through lots of content to find a close or cancel action (i.e. a button). For information on when you might need to implement this, see our ‘dismissing content on hover’ guideline. Include an annotation of this in your wireframes to inform UI designers, developers and testers of the Esc key functionality.