Colour contrast Must

The colour of text and background content must have sufficient contrast.

Good colour contrast assists people with vision impairment, including colour blindness, and cognitive impairments when viewing content. It also accommodates lower specification devices with poor colour support and assists all users in a brightly lit environment.

Good colour contrast is also essential when using colour as a differentiator, for example, when colour is used to indicate the presence of a link or a selected tab with text. The colour difference between the link text and non-link text must have sufficient contrast.

In lieu of a proven colour contrast standard for mobile devices, the WCAG 2.0 Level AA contrast ratio must be met or ideally exceeded. It requires a contrast of at least 4.5:1 for non-bold text smaller than 18pt.

Examples

iOS

Use standard iOS colours for buttons, text, and other user interface objects or ensure the foreground and background provide sufficient contrast.

Android

Use standard Android OS colours for buttons, text, and other user interface elements or ensure the foreground and background colours provide sufficient contrast.

HTML

Key recommendations are:

  • For text or images of text avoid background colours or use background colours that have sufficient contrast from the foreground colour;
  • If background colours are used, apply the 4.5:1 contrast ratio to foreground colours.

Testing procedures

  1. Activate the app.
  2. Locate samples of text with background colours.
  3. Identify the colour values:
    • Open the module in the app
    • Take a screen shot of the module (home+power button on iOS)
    • Email or sync the picture to a desktop PC
    • View the image of the page to be tested
    • Determine the foreground and background colour of the content using an eye dropper tool to obtain the colour values for the background and foreground colours.
  4. Manually inspect the element's colour definition.
  5. Use a reliable tool, such as Snook.ca colour contrast check, Webaim color contrast checker or TPG colour contrast analyser, to check if contrast is sufficient.
  6. Enter the foreground and background values into the colour contrast analyser.
  7. Verify the luminosity requirements are met and that the colour contrast meets the minimum ratio requirements of 4.5:1 for standard size and non-bolded text.

Testing results

The following check is true:

  • Contrast between text and background meet minimum colour contrast (luminosity) ratio requirements indicated by WCAG 2.0 of 4.5:1 for standard font size that is not in bold.

Colour and meaning Must not

Information or meaning must not be conveyed by colour only.

Colours can be difficult to distinguish in bright sunlight and cannot be perceived by users who are colour blind, or vision impaired. Screen readers do not detect colour and some users will change colour settings for their whole computer. For example, setting their computer to grayscale or applying a tint to help with reading. Lower specification mobile devices also offer poor colour support.

Colour is often used to show:

  • a tab is selected,
  • a link is available,
  • text is an error message,
  • emphasis,
  • charts and graphics, or
  • other meaningful information.

Additional visual and non-visual methods of identifying information or meaning must be applied to support the use of colour:

  • Visual cues could be text attributes with suitable mark up (such as underline, bold or italic), patterns, or icons with suitable alternative text;
  • Non-visual cues, which are programmatically available to assistive technologies, could be element tags, hidden text or suitable labels, for example ARIA or UlLabel.

Examples

iOS

Use visual clues and icons with text equivalents to reinforce meaning. Refer to iOS Human Interface Guidelines

Android

Use visual clues and icons with text equivalents to reinforce meaning. Use the android:contentDescription property to provide short and concise alternatives. The exception is on EditText fields; these must be coded using the android:hint attribute. This helps users understand what content is expected when the text field is empty. When the field is filled, TalkBack reads the entered content to the user, instead of the hint text.

HTML

If colour is used to convey meaning ensure accessible alternatives are provided. This could be underlined text for links, visible text on buttons, alt text labels and so on.

Testing procedures

  1. Activate the app with a screen reader.
  2. Locate objects, images, or elements that use colour.
  3. Determine if colour is the sole means of communicating information.
  4. Verify that there is an alternative visual means of obtaining the same information.
  5. Verify that the screen reader announces the meaning conveyed by the colour.

Testing results

The following checks are true:

  • Colour used to convey meaning is also indicated by an additional non-colour visual;
  • Colour used to convey meaning is announced by the screen reader.

Styling and readability Must

Core content must still be accessible when styling is unsupported or removed.

Older mobile devices may have poor support for fonts, colours and styles. Additionally, assistive technology cannot draw meaning from styling. And some users will change settings (fonts, styles, colours, etc.) to suit their needs.

A user must still be able to complete the core purpose of a page or screen, whether reading or taking action, when background colours, images, layout or features are missing. For example, read a news article, play a radio station or navigate elsewhere.

If embedded media is not supported then a suitable message should be displayed instead.

Jump to:

Examples

Testing

Examples

iOS

Not applicable.

Android

Not applicable.

HTML

Content must be separated from presentation. Content and functionality must still work without CSS or with CSS disabled. When using ARIA or HTML 5 techniques, use fallback techniques such as CSS off-screen text to identify custom controls, these must still be readable with CSS disabled.

Testing procedures

  1. Identify styles that are not supported by older devices or assistive technologies.
  2. Verify that all content is available on older devices and assistive technology that do not support these styles:
    • alternatives for background images
    • colours
    • fonts

Testing results

The following check is true:

  • All content is available and readable.

Touch target size Must

Touch targets must be large enough to touch accurately.

All users benefit from larger touch targets. For young users, and users with motor and/or vision impairments, this is even more important as accuracy can be difficult.

Content touch targets must be large enough to read and have a large enough interactive target area to tap comfortably with one finger.

The recommended size of touch targets is 7 – 10mm. This size is equivalent to the smallest average finger. An interactive target area should be at least 7 x 7 mm. If not, it must be no smaller than 5 x 5 mm inside an exclusion zone of at least 7 x 7 mm that does not overlap with any other touch target. The recommendation is to provide a bigger touch target where possible.

Sometimes text that is big enough to read is too small to touch. For example, a linked letter in an A-Z listing would be too fine to touch accurately and should be placed in a linked container to increase the target area.

Tip

Group adjacent related elements that link to the same resource as a single linked touch target. This increases the touch area and simplifies the interface.

Examples

iOS

For text elements include some white space around the text in the element frame. The autoResizingMask property can be set to ensure that if an object is resized it still meets the requirements. Use larger controls or increase the padding around content to ensure a large touch area.

All actionable controls must be 44pt x 44pt or larger. This sits within the comfortable hit area size for touch screen finger touch (7-10mm). See iOS Human Interface Guidelines for details.

Android

Include white space around text elements in the element frame using setPadding . Use layout_width and layout_height attributes of a LayoutParams object to set an appropriate width and height for the targeted device. Use larger controls or increase the padding around content to ensure a large touch area.

All actionable controls must be 48dp x 48dp or larger. This sits within the comfortable hit area size for touch screen finger touch (7-10mm). See Android Material Design guidelines for details.

HTML

Provide padding around links to ensure all actionable controls are at least 7mm across. Use larger controls, i.e. 9mm, or increase the padding around the content to ensure a large touch area.

Testing procedures

  1. Activate the app.
  2. Locate all touch targets/actionable items.
  3. Measure the size.
  4. Verify the size is larger than 9.6mm.

Testing results

The following check is true:

  • All touch targets/actionable items are larger than 9.6mm across.

Spacing Should

An inactive space should be provided around actionable elements.

Anyone can find it challenging to interact with small controls that are closely grouped together, in particular users with motor or vision impairment.

Actionable elements should not touch or overlap, and there should be an inactive space between actionable elements in order to reduce the risk of activating the wrong control. The minimum space possible to set on any device or screen resolution is 1 pixel, preferably the space would be larger.

Jump to:

Examples

Testing

Examples

iOS

When placing targets/actionable items ensure there is at least one (1) pixel between targets and that the edges of targets do not touch unless the space is non-actionable.

Android

Use the layout_margin attribute or set the margin programmatically using the setMargins method.

HTML

Ensure that borders, margins or some other mechanism for spacing exists around each target/actionable item.

Testing procedures

Because 1 pixel of space is very small it may be difficult to verify this item visually unless there is a visual separator between the two targets. In the case of no visual separation such as when a consistent background image is used around toolbar icons the code or .nib/.xib file may need to be inspected.

  1. Activate the app.
  2. Locate all touch targets/actionable items.
  3. Verify that there appears to be inactive space between every touch target/actionable item.

Testing results

The following check is true:

  • All touch targets/actionable items have inactive space between them.

Content resizing Must

Users must be able to control font sizing and user interface (UI) scaling.

All users benefit when they can adapt the size of content to see and read it. This may be a constant or temporary adaption due, for example, to screen size, screen glare, or vision impairment.

Ensure that content responds to platform native text resizing, and that scaling (or "zoom") is supported.

Users who magnify or zoom in on content only see part of the screen. Try to keep on-screen changes close to the point of interaction. For example, if a user completes an input field incorrectly add a visual cue above, below or inside the field, rather than out to the side.

Examples

iOS

iOS settings provide a means for users to enlarge text and increase system level zoom. As an additional feature, apps may provide font switchers, gradients, and other settings to facilitate easier reading. This is useful in apps that contain a lot of text.

Android

Android settings provide a means for users to enlarge text and increase system level zoom. As an additional feature, apps may provide font switchers, gradients and other settings to facilitate easier reading. This is useful in apps that contain a lot of text.

HTML

Using relative size units helps to ensure content is responsive to screen size and scaling ("zoom") without becoming unavailable or cut-off.

Key recommendations include:

  1. Ensure the viewport meta tag is set to permit scaling;
  2. Do not disable horizontal or vertical scrolling;
  3. Support font resizing by using relative size units.

Testing procedures

Most devices support pinch-zoom, or the browser has a Zoom in/out setting. Most devices and some browsers also have a way to adjust the default text size within the settings.

  1. Open the web page or activate the app.
  2. Verify that UI scaling ("zoom") is not disabled.
  3. Verify that content can still be accessed when scaled up ("zoom in").
  4. Change the device default text size.
  5. Verify text resizes and properly reflows on the page/screen.
  6. Verify that scrolling is not disabled.

Testing results

The following checks are true:

  • It is possible to change the UI scale without losing access to content.
  • The default text size is respected.
  • Content properly reflows and scrolls as required when resized (no extra horizontal scrolling)

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 '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.

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),
  • arrows to indicate direction of swipe areas.

Examples

iOS

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.

Android

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

HTML

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.

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.

Testing results

The following checks are 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.

Visible focus Must

When focused, all actionable and focusable elements must have a visible state change.

Visible focus helps all users track where they are within the content. Sighted keyboard and switch device users track progress as they navigate focusable elements, similar to using a remote control with a TV interface. Touch users also receive confirmation that an element is interactive.

Visible focus states happen when hover, focus or touch interactions occur. Do not depend on a browser's default visible states for hover, focus, or touch, as they may not work with the design. Do not inadvertently remove any default visible states for hover, focus, or touch unless providing an alternative. The visible focus state for all three interactions may look the same.

Hover, focus and touch states should not be used to convey information that is not available elsewhere.

Examples

iOS

iOS provides visible state change for elements when input is provided by the onscreen keyboard.

Focus for other actionable and focusable elements is provided by Voice Over via assistive technology.

Accessibility focus is determined by the property which is provided for all subclasses of UIView. Ensure that objects do not override the visual focus indication or set the accessibilityFrame property to nil.

Android

Developers should provide a visible indication when an element has focus. This is done by default for standard elements but for custom elements that have their own style sheets the focus style must be set in the style sheet when state_focused="true".

HTML

By default, standard HTML elements have a visual focus indicator provided by the browser. Therefore all links and focusable elements must not have their outline suppressed via CSS changes with the :focus pseudo class or the outline property unless a custom focus is provided. If using a custom focus give elements the same visible focus on :focus as on :hover and provide visible focus for form fields.

Note, mobile browsers don't have good support for the CSS pseudo property hover.

Testing procedures

  1. Navigate through the active on-screen components.
  2. For each active element that receives focus:
    • Verify where the text input location is;
    • Verify that the focus location is indicated at all times and follows traversal of the user interface;
    • Verify that the focus indicator can be clearly distinguished from other on-screen elements.

Testing results

The following checks are true:

  • The text input location is indicated;
  • When switching page tabs, the focused tab is indicated visually and announced by a screen reader;
  • The object, element, or control that has focus is indicated in a clear, visually distinguishable manner that meets the colour contrast requirements.

Consistency Should

A user's experience should be consistent.

Consistency allows all users to predict where to find information and how to use it. This is particularly helpful for users with cognitive impairments, in particular autistic users.

Consistent and logical structure and language help all users understand where they are and how to navigate or perform a task. Consistent and logical layout helps both sighted and non-sighted users predict where they should touch or interact.

For example, navigational aids such as back buttons should consistently move the user back to the previous step and act as a breadcrumb trail.

The look and sound of a control, object or element should inform the user how to interact with it.

For example, unless there is a recognised convention, such as for navigation, do not use links that are styled to look like buttons. This can be confusing for users of assistive technology, such as voice control or screen readers.

Additionally, use common gestures alongside other controls for commonly used design patterns:

  • swipe gestures for slideshows and carousels,
  • drag gestures for toggle and slider elements,
  • and, where available, support native inertia for scrolling.

Jump to:

Examples

Testing

Examples

iOS

Ensure accessibilityFrame, traits, and accessibilityLabels correctly indicate the purpose and function of the object to users who cannot see. Use standard controls to indicate the purpose of objects to users who can see. Refer to iOS Human Interface Guidelines design principles.

Android

Use standard controls to indicate the purpose of objects to users who can and cannot see. There is no ability to change accessibility role or trait information on the Android platform. Refer to Android Material Design principles.

HTML

Use visual styling to indicate that an item is actionable. Links should be different from static text for example a different font weight, outline, or some other visual styling that doesn't rely on colour alone. Use of standard elements without custom styling will automatically provide this for links and buttons, although multiple or long links can become illegible on small screens.

Testing procedures

  1. Activate a screen reader.
  2. Navigate through actionable items.
  3. Verify that the visual appearance of the screen and control, elements, and objects indicate their purpose and action status.
  4. Verify that the purpose of elements, objects, and control is announced.

Testing results

The following checks are true:

  • The visual layout and style of elements, object, and controls indicates their action;
  • The actionable status and purpose of elements, controls, and objects is announced.

Choice Must

Interfaces must provide multiple ways to interact with content.

Providing multiple ways to interact with content gives users choice and increases inclusivity. This supports different user expectations on how to interact with elements, and users who have difficulty with one type of interaction can use another.

Some elements provide multiple types of interaction. For example, a button element can be navigated to via mouse, touch, keyboard, or switch device, and then clicked, tapped or otherwise activated. Swipe gestures, which only cover touch interaction, must be supported by alternatives that perform the same actions. Additionally custom controls must be consistent with similar native controls, providing multiple ways to interact with them to cover all types of user interaction.

Avoid describing gestures in an alternative, tooltip, or hint, as the gesture or action might be different for users with assistive technology enabled.

Jump to:

Examples

Testing

Examples

iOS

Use standard controls when possible and set accessibility traits for custom controls.

Android

Use standard controls when possible and set appropriate focus states, descriptions and roles on custom controls.

HTML

Using standard elements will most often provide choice of interaction as this is already built in.

Testing procedures

  1. Identify the different actionable elements.
  2. Verify they can be accessed and controlled, as appropriate for the device, by:
    • mouse
    • touch
    • keyboard
    • with or without screen reader enabled

Testing results

The following check is true:

  • Actionable elements can be controlled in multiple ways.

Adjustable Should

Interactive media, including games, should be adjustable for user ability and preference.

Users of interactive media have differing abilities and preferences. Where appropriate, adjustment should be offered to make an experience inclusive and enable everyone to join in.

For example, users in bright sunlight, experiencing a migraine, or with vision impairment may choose to adjust the contrast and text size, or enable a colour blind mode. Users in a noisy environment, needing quiet, or with hearing impairment may wish to adjust the volume or enabled subtitles. Users carrying something, nursing a hand injury, or with motor impairment may want to adjust the controls and pace. Younger users, those less familiar with technology, or with a cognitive impairment may adjust a difficulty level, use tutorials or enable hints.

Tip

Consider the following:

  • Avoid complex controls and interactions.
  • Provide multiple ways to control interactions.
  • Provide means to adjust the number of choices.
  • Give the user control over speed and timeouts.
  • Provide means to adjust target area sizes.
  • Provide a specific accessible control scheme.
  • Respect device settings, such as text size.

Jump to:

Examples

Testing

Examples

iOS

None documented

Android

None documented

HTML

None documented

Testing procedures

  1. Verify that settings work as required.

Testing results

None documented

Flicker Must not

Content must not visibly or intentionally flicker or flash more than three times in any one-second period.

Visual flicker, flashing and strobe lighting can affect anyone, but some users will be more susceptible than others. Symptoms may include eyestrain, dizziness, fatigue, headaches, migraine, and nausea. Users with medical conditions such as Ménière's or photosensitive epilepsy can be severely affected, experiencing vertigo, hearing loss and seizures.

A well-documented example of the effects of flicker is Pokémon Shock.

If flicker is unavoidable, the user must be warned before they reach the content.

Where editorially appropriate, provide an alternative version of content that does not flicker but is as close to the original as possible.

Examples

iOS

None documented

Android

None documented

HTML

None documented

Testing procedures

Use a tool or app, such as Flicker Tester, to determine the rate of flicker.

Testing results

None documented