Mobile App Accessibility Checklist for Small Teams

This checklist is written for small teams, one screen at a time, and it ends with a test you can run in ten minutes. It belongs to our studio notes, which begin with apps that work without an account. We do not claim that our own apps meet WCAG or any platform guideline. Near the end we list the settings they offer, as described on their pages, and nothing more.

Why start with a short list

Accessibility advice can run to hundreds of pages, and a small team can stall at the first one. A short list that you really apply beats a long one you postpone. The six checks below are the ones that most often decide whether a person can use a screen at all: can they hit the control, read the text, hear what the control is, and avoid being overwhelmed by motion?

Touch targets

The WCAG 2.2 success criterion on target size (minimum) requires pointer targets of at least 24 by 24 CSS pixels at level AA, which means a solid 24 by 24 square fits inside the target. It has exceptions: for example, an undersized target passes if a 24-pixel circle centred on it does not touch another target, and links inside a sentence are excused. W3C states the intent: make targets easy to activate without accidentally hitting a neighbour, which helps people with dexterity limitations and those who have difficulty with fine motor movement.

The platforms ask for more than the web minimum:

• Apple. Its guidelines give 44 by 44 points as the default control size on iPhone and iPad and 28 by 28 as the minimum. They also suggest about 12 points of padding around elements with a bezel and about 24 points around elements without one.
• Android. Each interactive element should have a touch target of at least 48 by 48 dp, and larger is better.

If you can, design to the larger platform figure, and treat the WCAG figure as the floor. Pay particular attention to icon-only buttons, close buttons and anything placed close to the screen edge.

Contrast and colour

WCAG 2.2 success criterion 1.4.3 asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, where large means 18 point or larger, or 14 point bold or larger. The ratios are thresholds, so 4.499:1 fails. Text in inactive controls, pure decoration and logos is excused.

Apple’s guidance gives the same two ratios, with its own size breakdown in points, and it adds three useful habits: offer a higher-contrast scheme when the system’s Increase Contrast setting is on, check contrast in both light and dark appearance, and prefer system colours, which adapt. Android’s guidance gives the same two ratios, with its sizes in sp.

Colour has a second rule. Success criterion 1.4.1 says colour must not be the only visual means of conveying information. Add a second cue, such as text, an icon or a pattern. W3C notes that not everyone sees colours, or sees them the same way, and this helps people who cannot tell certain colours apart.

Text size and scaling

WCAG 1.4.4 requires that text can be resized up to 200 percent without assistive technology and without losing information or function. Apple says much the same in its own words: ideally, give people the option to enlarge text by at least 200 percent, using Dynamic Type or your own controls.

Test this on a real screen. Enlarge text in the phone’s settings, then walk through your app. Look for clipped labels, buttons that push off the screen, and lines that overlap. Where text is the product, give it its own size control as well.

Screen reader labels and focus order

A screen reader reads the label of each control. If there is no label, a person hears nothing, or hears the word “button” and nothing else. Both platforms give the same advice in different words.

• Describe the purpose. Android’s guidance says to give each element a description of its purpose, and to describe the result and not the visuals.
• Avoid redundancy. Say “Submit”, not “Submit button”, because the element type is announced separately.
• Keep labels unique. Items in a list should each reflect their own content.
• Hide decoration. Purely decorative images should be skipped by the screen reader.
• Keep a sensible order. The MDN checklist asks for a logical, consistent focus order and for every activatable element to be focusable.

Apple’s guidance covers the same ground for VoiceOver, its screen reader: describe your app’s interface and content for it.

Motion, flashing and haptics: give a switch

Two fixed points apply to movement. First, WCAG 2.3.1 says that content should not flash more than three times in any one second, unless the flashing is below the general flash and red flash thresholds. Second, Apple asks apps to respond to the system’s Reduce Motion setting by easing automatic and repetitive animations, such as zooming and scaling.

The principle is simple: where an effect is not essential, give people a switch. This post is not medical guidance, and the thresholds above are design measures from W3C and Apple. Vibration and sound follow the same rule. A setting that turns haptics off costs a team very little and removes a barrier for some people.

Gestures and orientation

The MDN checklist makes two further points that small teams often miss. Content should not be locked to one orientation unless it is essential, such as a piano app. And, following the pointer cancellation guidance it cites, an action should not run on the first touch: it should complete when the finger lifts, with a way to abort or undo. Games and keyboards are among its exceptions.

How to test in ten minutes

You do not need a lab to find the worst problems. Take your phone and run this routine on your three most important screens.

1. Turn on the screen reader. Use VoiceOver on iPhone or TalkBack on Android. Move through the screen with the screen dimmed. Does every control announce a clear label, in the order you would expect?
2. Enlarge the text. Set the largest text size the phone allows, or at least double the default, and look for clipping and overlaps.
3. Switch to grayscale. Is every status still clear when colour is gone?
4. Use one thumb. Hold the phone in one hand and try to reach and hit each control without a second hand.
5. Turn on Reduce Motion. Does the app calm down, or does it carry on moving?
6. Check one contrast pair. Pick your smallest, lightest text and measure it against its background with any contrast checker.

Write down each problem as you find it, fix the ones that block a task first, and repeat the routine after every release. It is one line of any app pre-release checklist.

What we do in our own apps

We can describe only what our pages already say, and that is a list of settings, not a claim of conformance.

• Cuelift lets you set text size, line spacing and side margins, choose left or centre alignment, and read in white on black or black on white. It also offers very large type. You can mirror the text, and a countdown of off, 3 or 5 seconds gives you time before the scroll starts. You can read more on the Cuelift page in the Store.
• Gloomrush has larger touch targets, easier-to-read text and scrolling lists. Its settings let you switch damage numbers, screen shake and flashes on or off, change the text size and turn vibration on or off. It is on the Gloomrush page in the Store, and our post on game accessibility settings worth looking for goes further.
• Spareday describes a layout that follows your text size, which fits the text-scaling check above. For the widget side of a habit tracker, see our notes on designing home screen widgets.

For our website, the accessibility statement describes what we aim for. That is a different thing from a claim about our apps, and we keep the two apart on purpose.

Do you need to meet WCAG for a mobile app?

W3C says it has no separate guidelines for mobile accessibility. WCAG covers web pages and web applications, including content used on mobile devices. WCAG 2 can also be applied to native and hybrid apps, with supporting guidance, such as the in-progress WCAG2Mobile draft and the more general WCAG2ICT. WCAG 2.1 and 2.2 added success criteria that address mobile accessibility. Whether you must meet it is a question about your own situation, and the checklist above is a sound place to start either way. We built it on the measures W3C and the platforms publish, so that the thresholds come from them and not from us.

Questions

What is the minimum touch target size?

WCAG 2.2 sets 24 by 24 CSS pixels at level AA, with exceptions. Apple’s default control size on iPhone is 44 by 44 points, and Android recommends at least 48 by 48 dp. Aim for the larger platform figure.

What contrast ratio does text need?

At least 4.5:1 for normal text and 3:1 for large text under WCAG 2.2 level AA. Large means 18 point or larger, or 14 point bold or larger. Check each appearance, light and dark.

How do I test an app with a screen reader?

Turn on VoiceOver on iPhone or TalkBack on Android, dim the screen and move through each screen. Every control should be announced with a label that says what it does, in a logical order.

Do I need to meet WCAG for a mobile app?

WCAG covers web pages and web applications, including content used on mobile devices, and can be applied to native apps with supporting guidance. W3C has no separate mobile guidelines. Whether you must meet it depends on your situation.

What is the first accessibility fix to make?

Fix what blocks a task: controls with no label and targets too small to hit. Then move on to contrast, text size, motion and the rest of the list.