Explore

WCAG Mobile Guidelines

This page is designed to break down the mobile accessibility guidelines set out by WCAG into a way that is easier to understand.

Alex Shepherd

Table

Table

Guideline

Guidance

Best practice

AA Compliance

⁠

Small Screen Size⁠

⁠

Limited size places constraints on the amount of information that can be perceived by users at any one time. Even when high screen resolution might enable large amounts of information to be rendered, the amount that can be displayed is even less when magnification is used

Minimising the amount of information that is put on each page e.g:

fewer content modules,

fewer images,

focus on important mobile usage scenarios.

Responsive design contains content that stays the same, but CSS stylesheets are used to render it differently depending on the viewport width. e.g. on narrow screens the navigation menus may be hidden until the user taps a menu button.

Providing a reasonable default size for content and touch controls (Touch Target Size) to minimise the need to zoom in and out for users with low vision.

Adapting the length of link text to the viewport width.

Positioning form fields below, rather than beside, their labels (in portrait layout)

⁠

Zoom/Magnification⁠

⁠

A variety of methods allow the user to control content size on mobile devices with small screens (these methods are available as accessibility features, usually found in accessibility or display settings):

Set default text size. Note: System text size is often not supported by mobile browsers.

Magnify entire screen. Note: Using this setting requires the user to pan vertically and horizontally.

Magnifying lens view under user's finger

Except for subtitles and images of text (i.e. text that is part of an image), text can be resized without assistive technology up to 200 percent without loss of content or functionality.

⁠

Contrast⁠

⁠

Mobile devices are more likely than desktop devices to be used in varied environments including outdoors, where glare from the sun or other strong lighting sources is more likely. This increases the importance of good contrast for all users and may compound the challenges that users with low vision have accessing content with poor contrast on mobile devices.

Large scale text = at least 18 point or 14 point bold

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

Large-scale text and images of large-scale text have a contrast ratio of at least 3:1.

Text or images of text that are pure decoration, have no contrast requirement.

Text that is part of a logo or brand name has no contrast requirement.

⁠

Keyboard control & Touch screen⁠

⁠

Mobile design has evolved away from built-in physical keyboards towards devices that maximise touchscreen area and display an on-screen keyboard only when the user has selected a user interface control that accepts text input (e.g. a text box).

However, keyboard accessibility remains as important as ever and most operating systems do include keyboard interfaces, allowing mobile devices to be operated by external physical keyboards or alternative on-screen keyboards (e.g. scanning on-screen keyboards).

Supporting these keyboard interfaces benefits several groups with disabilities:

People with visual disabilities who can benefit from some characteristics of physical keyboards over touchscreen keyboards (e.g. clearly separated keys, key nibs and more predictable key layouts).

People with dexterity or mobility disabilities, who can benefit from keyboards optimised to minimise inadvertent presses (e.g. differently shaped, spaced and guarded keys) or from specialised input methods that emulate keyboard input.

People who can be confused by the dynamic nature of onscreen keyboards and who can benefit from the consistency of a physical keyboard.

All functionality of the content is operable through a

keyboard interface⁠

⁠

If focus can be moved to a component using a

keyboard interface⁠

, then focus should also be able to be moved away, and, if it requires more than standard exit methods, the user is advised of the method for moving focus away.

Focus should be navigated in an order that preserves meaning and operability

Any UI that uses a keyboard must display the keyboard focus indicator (i.e. blinking cursor or colour change background)

⁠

Touch Target Size & Spacing⁠

⁠

The high resolution of mobile devices means that many interactive elements can be shown together on a small screen. These elements must be big enough and have enough distance from each other so that users can safely target them by touch.

Ensuring that touch targets are at least 9 mm high by 9 mm wide.

Ensuring that touch targets close to the minimum size are surrounded by a small amount of inactive space.

Note: Magnification should not need to be used to obtain this size, because magnifying the screen often introduces the need to pan horizontally as well as vertically, which can decrease usability.

⁠

Touchscreen & Gestures⁠

⁠

Many mobile devices are designed to be primarily operated via gestures made on a touchscreen. Some OS provide work-around features that let the user simulate complex gestures with simpler ones using an onscreen menu.

Gestures in apps should be as easy as possible to carry out.

Gestures should not override existing OS specific gestures

Mouse users clicking on actionable elements (links, buttons, submit inputs) should have the opportunity to move the cursor outside the element to prevent the event from being triggered.

Another issue with touchscreen gestures is that they might lack onscreen indicators that remind people how and when to use them. For example, a swipe in from the left side of the screen gesture to open a menu is not discoverable without an indicator or advisement of the gesture

⁠

Device Manipulation Gestures⁠

⁠

In addition to touchscreen gestures, many OS provide developers with control options that are triggered by physically manipulating the device (e.g. shaking or tilting). While device manipulation gestures can help developers create innovative user interfaces, they can also be a challenge for people who have difficulty holding or are unable to hold a mobile device.

Some OS provide work-around features that let the user simulate device shakes, tilts, etc. from an onscreen menu. Therefore, even when device manipulation gestures are provided, developers should still provide touch and keyboard operable alternative control options.

All functionality of the content is operable through a

keyboard interface⁠

⁠

Placing buttons where they are easy to access⁠

⁠

When designing mobile web content and applications many developers attempt to optimise use with one hand. This can benefit people with disabilities who may only have one hand available, however, developers should also consider that an easy-to-use button placement for some users might cause difficulties for others (e.g. left- vs. right-handed use, assumptions about thumb range of motion). Therefore, flexible use should always be the goal.

Position interactive elements where they can be easily reached when the device is held in different positions. Some OS provide work-around features that let the user temporarily shift the display downwards or sideways to facilitate one-handed operation.

⁠

Changing screen orientation⁠

⁠

Some mobile applications automatically set the screen to a particular display orientation (landscape or portrait) and expect that users will respond by rotating the mobile device to match. However, some users have their mobile devices mounted in a fixed orientation (e.g. on the arm of a power wheelchair).

Apps should try to support both orientations. If it is not possible to support both orientations, developers should ensure that it is easy for all users to change the orientation to return to a point at which their device orientation is supported. Note: Changes in orientation must be programmatically exposed to ensure detection by assistive technology such as screen readers.

⁠

Consistent Layout⁠

⁠

Components that are repeated across multiple pages should be presented in a consistent layout.

e.g. An app has a logo, a title, a search form and a navigation bar at the top of each page; these appear in the same relative order on each page where they are repeated (even if one is missing).

Navigational mechanisms that are repeated on multiple pages within a set of pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

Components that have the same functionality within a set of pages are identified consistently

⁠

Position important page elements before the page scroll⁠

⁠

The small screen size on many mobile devices limits the amount of content that can be displayed without scrolling. Placing important elements before the page scroll also helps ensure that elements are placed in a consistent location and supports a number of different users.

Positioning important page information so it is visible without scrolling can assist users with low vision and users with cognitive impairments.

⁠

Grouping operable elements that perform the same action⁠

⁠

This reduces the number of redundant focus targets, which benefits people using screen readers and keyboard/switch control. This also increases the touch target size for all users and benefits people with dexterity impairments.

When multiple elements perform the same action or go to the same destination (e.g. link icon with link text), these should be contained within the same actionable element.

The purpose of each link can be determined from the link text (stand alone or in context)

⁠

Provide clear indication that elements are actionable⁠

⁠

Elements that trigger changes should be clearly distinguishable from non-actionable items (e.g. content, status information, etc). Visual users who interact with content using touch or visual cursors (e.g. mice, touchpads, joysticks) should also be able to clearly distinguish actionable elements such as links or buttons. Visual features that can set an actionable element apart include shape, color, style, positioning, text label for an action, and conventional iconography.

Examples of distinguishing features:

Shape: Button shape (rounded corners, drop shadows), checkbox, select rectangle with arrow pointing downwards.

Iconography: conventional visual icons (question mark, home icon, burger icon for menu, floppy disk for save, back arrow, etc)

Colour offset: shape with different background colour to distinguish the element from the page background and text colour

Style: Underlined text for links, colour for links

Positioning: Commonly used positions:

- top left = back button

- menu items within left-aligned lists in drop-down menus for navigation

Navigational mechanisms that are repeated on multiple pages within a set of pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

Components that have the same functionality within a set of pages are identified consistently

⁠

Provide instructions for custom touch screen and device manipulation gestures⁠

⁠

The ability to provide control via custom touchscreen and device manipulation gestures can help developers create efficient new interfaces. However, for many people, custom gestures can be a challenge to discover, perform and remember.

Instructions should be easily discoverable and accessible. The instructions should also be available anytime the user needs them, not just on first use (although they may need to be made more apparent on the first use)

Labels or instructions are provided when content requires user input.

Help related to the function being performed is available.

⁠

Set the virtual keyboard to the type of data entry required⁠

⁠

On some devices, the standard keyboard can be customised in the device settings and additional custom keyboards can be installed. Some devices also provide different virtual keyboards depending on the type of data entry. This can be set by the user or can be set to a specific keyboard.

Setting the type of keyboard helps prevent errors and ensures formats are correct but can be confusing for people who are using a screen reader when there are subtle changes in the keyboard.

⁠

Provide easy methods for data entry⁠

⁠

Users can enter information on devices in multiple ways e.g. on-screen keyboard, Bluetooth keyboard, touch, and speech. Text entry can be time-consuming and difficult in certain circumstances.

Reduce the amount of text entry needed by providing select menus, radio buttons, check boxes or by automatically entering known information (e.g. date, time, location).

⁠

Support the characteristic property of the platform⁠

⁠

Devices provide many features to help users with disabilities interact with content. These include platform characteristics such as zoom, larger fonts, and captions. The features and functions available differ depending on the device and operating system version.

⁠

Text alternatives⁠

⁠

Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language

If none text content:

is a control or accepts user input, then it has a name that describes its purpose

is time-based media, then text alternatives at least provide descriptive identification

is pure decoration, then it is implemented in a way that it can be ignored by assistive technology

⁠

Time-based media⁠

⁠

An alternative is provided that presents equivalent information for prerecorded audio-only/video-only content.

(Pre-recorded) Provide a transcript / link to textual comparable information / captions on video

Captions are provided for all live audio content

Audio description is provided for all pre-recorded video content

For AAA, click

here⁠

⁠

Adaptable⁠

⁠

Create content that can be presented in different ways (e.g simpler layout) without losing information or structure

All information / structure / relationships conveyed through the UI, are also available in text.

The sequence in which content is presented is meaningful.

Instructions provided for understanding and operating content is not only reliant on UI e.g. shape, size, visual location, orientation, or sound

⁠

Distinguishable⁠

⁠

Make it easier for users to see/hear content including separating foreground from background through:

Using readable fonts

Making sure any text in images of text is at least 14 points and has good contrast

Providing a highly visible highlighting mechanism for links or controls when they receive keyboard focus

Colour is not the only visual means of conveying information or distinguishing a visual element.

If any audio plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

Large-scale text and images of large-scale text have a contrast ratio of at least 3:1.

Text or images of text that are pure decoration, have no contrast requirement.

Text that is part of a logo or brand name has no contrast requirement.

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

Where possible, text should be used to convey information, rather than images

With the exceptions of images & video, content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions (i.e. user doesn’t have to scroll in all directions to read content, even when text size is increased)

None text content has a contrast ratio of at least 3:1 against adjacent colour(s)

For AAA, click

here⁠

⁠

There are no rows in this table

⁠

Web WCAG that also applies to Mobile

Web WCAG that also applies to Mobile