Mobile Accessibility Guidelines - Design

Actionable elements must


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 ‘’ 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.

Tip 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),
  • shapes such as buttons, rounded corners, drop shadows and arrows to indicate direction of swipe areas,
  • familiar icons such as questions marks, information, download icons, - Refer to for more details.
  • commonly used positioning such as menus top right, back buttons top left.

iOS

In addition to visual cues, make sure that the correct trait is applied to user interface element so that they are conveyed correctly by VoiceOver. Most native controls (particularly buttons and labels) have the required semantics and behavior built in by default. However, for custom interface elements, traits must be added manually, either through Interface Builder’s Inspector Utility or at code level.

iOS Example (Objective-C)

[myCustomButton setAccessibilityTraits:UIAccessibilityTraitButton];
[myCustomButton setIsAccessibilityElement:YES];
[myCustomButton setAccessibilityLabel:@"My Custom Button];

Android

Roles are automatically assigned when using standard user interface elements. As far as possible, use common native elements rather than building custom solutions, as the required semantics and behaviour are built into native elements by default, and have the “look and feel” that users will be accustomed to.

Android Pass Example

<Button
  android:id="@+id/button_myButton"
  android:background="@drawable/add"
  android:layout_width="wrap_content"
  android:layout_height="wrap_content"
  android:contentDescription = "Add";
  
 />

HTML

Use native HTML elements for actionable controls, rather than repurpose another element, as the required semantics and behaviour will already be built in by default. Use the button element for buttons, the a element for links, input elements for form controls, etc. Additionally, native controls present users with a “look and feel” that they are already accustomed to. When using CSS to style page elements, make sure that styles do not impact on the intended meaning of page elements; for example, ensure that buttons have the visual appearance to suggest that they are clickable, rather than plain text.

HTML Pass Example

<button onclick="
">I am a button</button>
<a href="
">I am a link</a>

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

<style>
 body {
  background: #fff;
 }
 a {
  background: #def;
 }
 button {
  cursor: pointer;
 }
</style>
 
<a href="/">±«Óătv</a>
 
<button type="submit">Search</button>

Testing

Procedures

  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.

Outcome

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.