Actionable elements


Links and other actionable elements must be clearly distinguishable.


All users must be able to determine if an element is actionable or if it is static content. Actionable elements are links, buttons, navigation and other control features, including swipe areas on touch devices that might be less obvious.

Actionable elements must be identified visually, by convention, and by information provided to assistive technologies. This can be achieved using platform native elements such as links, buttons, inputs, etc. All elements should have clear labels and, when applicable, a suitable role or trait. See 'Roles, traits and properties' for further information.

Users should be able to control interfaces naturally and intuitively. Where realistic controls are used, such as toggle-buttons and sliders, users expect to interact with them in a literal and familiar way. In a game where the objective is to find an actionable element, it does not need to be obvious at the beginning of play but must be clearly distinguishable when it is located.

Hover states should only act as confirmation that an element is actionable.


When styling actionable elements consider using:

  • underlines for links inline with text,
  • colour highlights and weight variants to make inline actionable elements clear,
  • visible state changes to indicate focus (can be same as hover),
  • arrows to indicate direction of swipe areas.


In addition to visual cues, ensure that traits are set properly and the correct control types are used to display elements. Buttons by default will come with the correct accessibility traits (UIAccessibilityTraitButton). Most controls in iOS already do.

iOS example

// Custom control acts like a button and can be tapped by the user
[customControl setTitle:NSLocalizedString(@"Smile", @"Button title")];
[customControl setAccessibilityTraits:UIAccessibilityTraitButton];                        
// Custom control acts like a button but does not have the correct traits so will be confusing for a VoiceOver user
[customControl setTitle:NSLocalizedString(@"Smile", @"Button title")];                        


In addition to visual cues ensure that the correct widget type is used and contentDescription is set.

Android example

// use of a button with a background image rather than a clickable image 
<button android:background="@drawable/add" android:contentDescription="Add"</button>                        
// use of an image that does not appear clickable
<imageview android:src="@drawable/add" android:contentDescription="Add"</imageview>                        


For all actionable elements, the CSS cursor property should not be overwritten to something that doesn't appear actionable such as the value of "text".

For simulated controls, the appropriate CSS cursor property must be set, for example, pointer, or some other action for drag and drop, etc.

Links could have an underline, however multiple underlined links on mobile can sometimes be hard to read. Font weight changes, borders or other visual attributes indicating action can also be used.

HTML example

Link with a background that will stand out from surrounding content, and button with a pointer cursor:

	body {
		background: #fff;
	a {
		background: #def;
	button {
		cursor: pointer;

<a href="/">Home</a>

<button type="submit">Search</button>                        

Link with no underline or pointer:

a {
	cursor: text;
	text-decoration: none;

<a href="/">Home</a>                        


  1. Activate a screen reader.
  2. Locate all actionable items.
  3. Verify that the actionable items can be visually distinguished from non-actionable ones.
  4. Verify that the actionable status is indicated by a screen reader.

The following checks are all true:

  • Actionable items can be visually distinguished from non-actionable ones.
  • Actionable items are announced in a way that indicates they are actionable by a screen reader.