Design controls for easy operation

With custom controls, developers have an additional responsibility to ensure that the control can be operated effectively by people with disabilities, beyond ensuring keyboard operation and visible focus indication. This is particularly important for supporting effective touchscreen interaction, for example via a smartphone.

  • Make sure that the control is big enough to operate. The size should be large enough that people with reduced dexterity or vision can activate it without undue effort, with using a mouse, through touch or other input method. The BBC Mobile Accessibility guidelines recommend that actionable controls are at least 9.6mm wide, or 44 by 44 pixels on a standard smartphone screen, so that they are large enough for users to activate.
  • Make sure that controls are sufficiently spaced apart. For all controls, including custom controls, follow best practice in usable interface design to ensure that adjacent controls are spaced apart sufficiently to minimize the chance of the wrong control being inadvertently activated.
  • Make sure that controls are positioned to minimize impact of error. Be careful when placing pairs of controls where inadvertently selecting one instead of the other could have significant consequences (such as adjacent Save and Delete buttons).
  • Make sure that controls have sufficient color contrast. Active user interface components (e.g., buttons) and meaningful graphics must be distinguishable by people with moderately low vision. For this to occur, the visual presentation of user interface components and graphical objects need to have a contrast ratio of at least 3:1 against adjacent colors.
  • Make sure that content can be operated using simple inputs on a wide range of pointing devices. Any functionality that operates by using multipoint or path-based gestures, can be operated with a single pointer (e.g., finger, stylus, eye-gaze, head pointer), unless a multipoint or path-based gesture is essential. Single pointer functionality is especially important for people with mobility impairments.
  • Design interfaces to minimize accidental or erroneous input by users. It is critical for people with motor impairments and/or cognitive disabilities to be able to cancel a pointer function in order to prevent unintended results. For this guideline to operate successfully, developers need to ensure that completion of the action occurs when a user releases a pressed mouse button, lifts a finger or pointer, or releases a key (i.e., up event, not the down event) and the user can abort the action or undo it after completion. The down event can be used, if essential (e.g., piano-playing simulation).
  • Make sure that functions that are triggered by moving a device can also be operated by conventional user interface components. For people with limited mobility, for those whose device must remain in a fixed position, and for others with a variety of needs, it's critical that another method beyond device motion (e.g., tilting, shaking) exists to complete a task.


For each custom actionable control:

  • View the control on an Android or iOS smartphone. Measure the size of the control. Is it at least 9.6mm across?
  • Is there sufficient spacing between the control and any neighboring active controls?
  • Do neighboring controls have sufficient error handling capability so that inadvertently selecting one does not have irreversible consequences?
  • Does the control (e.g., button) have at least a 3:1 contrast against adjacent colors? [Hint: Test with color contrast analyser. See 'Graphical Objects and User Interface Components section.]
  • Can the control be activated with a single input?
  • Can the control be activated on the up event?
  • Can functions that are triggered by moving a device also be operated by conventional user interface components?


✎ Technique: Differentiating controls

Placement of controls affects their ease of use. For example, for a search feature, the “submit” button should be positioned right after the input field. Appearance and positioning are particularly important when providing a control that supports “destructive” actions, such as a “delete” or “clear” button. In these cases, ensure that these controls are clearly differentiated .


This example shows two closely spaced buttons, one to submit the form and one to reset the form fields to blank. The buttons are similarly sized and they’re positioned close together. So users could inadvertently select the “Reset Form” button, and they’d have to re-enter their information.

two similar blue buttons of the same size, very close together, with the text submit and reset respectively.

When juxtaposing two controls with potentially negative consequences, use two distinct controls. In this example the reset button is red, diminished in size and well spaced:

In this version, the reset button is red, further away and smaller

✎ Technique: Hit areas

Interactive elements should not be difficult to select or activate when using a mouse or a touchscreen.

Generous sizing and spacing is important, and their implied visual “hit area” should correspond to the control’s active area.


In these examples, page navigation is provided through “prev” and “next” links. The two controls are separated by 0.5em, ensuring that it’s not easy to accidentally activate the wrong control when the user is interacting by touch or user’s mouse hand is shaky.

Here's how they look:

Two large button shaped links sitting next to one another with a white space between them

✓ Good example

For the “prev” control, display: block and padding is applied to the <a> element. As you can see by focusing this control, the entire visual box is clickable: Everything that looks interactive is interactive.

The blue button shape on the left displays a black outline around its outer perimeter

✗ Bad example

The “next” control has been styled differently. The non-interactive <li> element provides the blue background and the padding. By focusing the link inside it, you can see that the focus outline fits tightly around the link text—a much reduced and deceptively small hit area compared to the “prev” example. Targeting this control could prove difficult.

The second control shows a black outline just around the text, not the whole box

Code editor

You can compare the different hit areas in this code editor and use it as a starting point for your own solutions to the problem.

See the Pen compare hit areas by HUIT - Web, UX and Digital Accessibility Services (@hwpdas) on CodePen.

✎ Technique: Motion actuation

Ensure that functions that are triggered by moving a device (for example, shaking or tilting) or by gesturing towards the device (so that sensors like a camera can pick up and interpret the gesturing), can also be operated by more conventional user interface components, unless the motion is essential for the function or not using motions or gestures would invalidate the activity. 

Users who may be unable to perform particular motions (such as tilting, shaking, or gesturing) because the device may be mounted or users may be physically unable to perform the necessary movement, should still be able to operate all functionality by other means (e.g., touch or voice input).

Some users may accidentally activate sensors due to tremors or other motor impairments. The user must have the ability to turn off motion actuation to prevent accidental triggering of functions.


✗ Bad example #1

After text is input in a field, shaking a device shows a dialog offering users to undo the input; and, there is no mechanism for disabling motion actuation.

Screen capture of interface without cancel button

✓ Good example #1

An Undo button next to the text field offers the same functionality.

Screen capture of interface with cancel button

✗ Bad example #2

A user can tilt a device to advance to the next or a previous page.

Interface with a tilting feature

✓ Good example #2

Buttons or links are also provided to perform the same function.

Interface with a manual feature

✗ Bad example #3

A user can move or pan a device to change the view in an interactive photo.

Interface without manual controls

✓ Good example #3

A text option or button is also available to perform these same functions.

Interface with manual controls

✗ Bad example #4

A user can gesture towards the device to navigate content.

Gesture interface without manual controls

✓ Good example #4

Text option or button is also available to navigate.

Gesture interface with manual controls

✎ Technique: Non-text contrast

The contrast of icons and graphical objects is just as important as that of text. Use sufficient contrast for all elements on the screen, with a minimum contrast ratio of 3:1.


✗ Bad example: icons.

The figure inside of the icon must have good contrast with the icon background. The images below show a calendar icon with a contrast ratio of only 2.2:

Images of a calendar icon with&nbsp;a contrast ratio of only 2.2

✓ Good example: icons.

The images below show a calendar icon with a contrast ratio of 5.3:

Images of a calendar icon with&nbsp;a contrast ratio of only 5.1

✗ Bad example: buttons.

Buttons with no background color, referred to as ghost buttons, have become popular. These buttons usually have text (which must meet 1.4.3 Contrast Minimum) but the button outline against the background must also meet the contrast requirement. If the button is solid, the button color against the background needs proper contrast. This button has a grey outline with the word “Menu” against a white background. Its contrast ratio is only 1.6, too low:

Button with contrast ratio of 1.6

✓ Good example: buttons.

The images below show a button with a contrast ratio of 9.0:

Button with contrast ratio of 9.0

Many sites use a change in color to identify the selected or focused element. This can violate 1.4.1 Use of color. But, if the color change meets the 3:1 contrast ratio of this success criterion, it is acceptable.

(Source: Knowbility article on contrast)

✎ Technique: Pointer cancellation

Make it easier for users to operate functionality through various inputs beyond keyboard; however, it is essential that functions emulate a keyboard and that a mechanism to undo or abort an action is provided.

This guideline helps people with tremors or mobility impairments who may touch or click on the wrong location by mistake. This mistake can cause an unintended action. This success criterion also benefits people with cognitive disabilities, who can become confused when something unexpected happens because they activated a control by accident.


✗ Bad example: limited interaction options. 


An interface shall not provide just one interaction option. This interface only allows for drag and drop.

Screen capture of an interface with no interaction alternatives

✓ Good example: several interaction options.

An application that accepts donations can provide more than one way to make a donation.

  • The user makes a donation by clicking on a coin shaped button with the donation amount. The user can move the pointer off of the coin before releasing it to stop the donation.
  • Another example uses drag and drop. The user clicks down and drags the coin into a donation bucket. The user cancels the donation by releasing the pointer before it is over the target bucket.
  • In the drag and drop example, when the user releases the coin into the bucket, a confirmation dialog requires the user to confirm the donation. Of course, to support success criterion 2.1.1, the drag and drop example also provides full keyboard support!

Screen capture of an interface with several interaction options

(Source: Knowbility article on pointer cancellation)

✎ Technique: Pointer gestures

All operations must use simple gestures that need only a single touch. Gestures that need two fingers or complicated movements can be hard to operate for people with hand tremors or limited movement.  Users with alternative input devices such as a mouth stick, sip-and-puff, or head mouse also benefit. Simple gestures are easier for someone with cognitive impairments to remember and use. If the site or application does use multi-touch gestures, be sure to also provide simple interfaces. 


✗ Bad example: map application without zoom controls.

Google Maps mobile app only relies on pinch gesture for zooming.

Screen capture of a mobile app without zoom controls

✓ Good example: map application with zoom controls.

The TopoView map viewer application from the US Geological Service is a good example.  It supports 2 fingered pinch and zoom gestures but also has + and - buttons to perform the same zoom actions.  The + and - buttons are single pointer gestures. The application also supports touch and drag to pan around the map.  To make this into a simple gesture, add up, down, left and right arrow buttons along the left hand navigation area. Now a user can pan around the map by clicking an arrow button. The screenshot below shows these added arrow buttons.

Screen capture of the TopoMap interface

(Source: Knowbility article on pointer gestures)