| Area | Value or requirement | Planning use |
|---|---|---|
| WCAG scope | Covers web pages, web apps and mobile-device content; WCAG 2 applies to native and hybrid apps | Use WCAG as the audit yardstick for native screens too |
| Normal text contrast | 4.5:1 at WCAG 2.2 AA | Check body copy and secondary labels first, since they are the usual failures |
| Large text contrast | 3:1 at WCAG 2.2 AA | Relax only for text that genuinely qualifies as large |
| Colour as a signal | Needs another cue besides colour, such as underlined links | Add an underline, icon or text to every colour-only state |
| Screen reader labels | Text equivalent for every non-presentational non-text element; labels on all form controls | Drives the VoiceOver and TalkBack pass |
| Touch targets | Large enough for the user to interact with | Set one minimum in the design system and test with a thumb |
These requirements come from W3C’s mobile accessibility guidance and MDN’s mobile accessibility checklist.
Mobile app accessibility is best checked by walking real screens with VoiceOver, TalkBack and large text switched on, then fixing each failure against its WCAG requirement. Start with labels and contrast, because both have clear pass or fail tests.
If you are still shaping the product, how to build a mobile app covers the wider build. This guide covers the accessibility pass once real screens exist, organised as phases you can run in order.
How WCAG applies to mobile apps
WCAG covers web pages and web applications, including content used on mobile devices. W3C’s mobile guidance goes further and explains how WCAG 2 applies to mobile web content, mobile web apps, native apps and hybrid apps, so a native screen does not need a separate rulebook.
W3C also publishes Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile). Open it whenever a criterion reads as if it were written for websites and you need to translate it to a native screen. For the numeric checks in this guide, treat WCAG 2.2 AA as the target.
Audit setup: devices and settings
A useful audit follows one complete user journey on real hardware, not a loose tour of screens. Pick the journey that matters most, such as sign-up through to the first completed task, and keep a log organised by WCAG area: labels, contrast, large text and target size.
- Choose the journey. List each screen in the order a user meets it, including screens reached from outside the app. If you use links that open inner screens, see mobile app deep linking and include those entry points in the list.
- Turn on the screen readers. Use VoiceOver on an iPhone and TalkBack on an Android phone, so each platform’s behaviour is checked separately.
- Set the largest system text size. Do this on both devices before you start the journey.
- Record findings by area. Note the screen, the control and which of the four areas it fails, so fixes can be grouped later.
Screen reader pass: labels
MDN’s checklist requires a text equivalent for every non-presentational non-text element in the app. That is the core of the VoiceOver and TalkBack pass: move through each screen and confirm every icon, image and control announces something meaningful.
What to listen for
- Icon-only buttons. A silent or generic announcement means the control has no text equivalent. This is the most common fix.
- Decorative images. Only strictly presentational elements are exempt, so decide deliberately which images carry meaning.
- Form fields. MDN’s checklist says all form controls must have labels, so a field that announces only its type needs one.
Labels in React Native
In a React Native app, attach the label to the component the user actually touches, such as the pressable around an icon or the image itself, using that component’s accessibility props. MDN’s checklist names aria-label, aria-labelledby and aria-describedby as the ways to supply custom label text on the web. Check React Native’s accessibility documentation for the prop each component takes, then confirm the result by listening in both VoiceOver and TalkBack rather than trusting the code.
Standard controls such as buttons and form fields are focusable by default, so custom-built touchables are where focus and labelling problems cluster. Audit those first.
Contrast and colour pass
Contrast is the easiest area to measure and the easiest to get wrong in a design review, because screen brightness hides weak pairs.
Text ratios
Under WCAG 2.2 AA, normal text needs a contrast ratio of 4.5:1 and large text needs 3:1, as set out in MDN’s checklist. Measure the real foreground and background colours with a contrast checker instead of judging by eye. Text inside buttons and tabs falls under the same text ratios, so check those labels as well as body copy. For icons and control outlines, use the contrast criteria in W3C’s mobile guidance.
Colour as the only cue
Information conveyed by colour must also be available another way. Underlined links are the usual example. On a form, pair a red error state with an icon or an error message, and do the same for any status that relies on a colour change alone.
Large text pass
Dynamic Type on iOS lets people choose their own text size, and a supporting app lets its text follow that setting. With the largest system size on, move through the journey again and look for clipped lines, overlapping labels and buttons whose text no longer fits.
Fix these by letting containers grow with their content instead of fixing heights, and by letting text wrap. If a screen only works at the default size, treat it as a defect and log it against the screen, not as an edge case. Run the same pass on Android with its font size setting raised, since the two platforms break in different places.
Touch targets
MDN’s checklist says touch targets must be large enough for the user to interact with. That is a requirement about reliable tapping, and it matters most for small icon buttons, close controls and rows of adjacent actions.
Take the exact minimum from the target size guidance in W3C’s mobile material and your platform’s design guidelines, then apply a single rule across the app. Test by tapping each control with a thumb while holding the phone normally, not with a precise fingertip at a desk.
Legal standards for accessible apps
In the United States, the Department of Justice published its ADA Title II final rule on April 24, 2024. The compliance date is April 26, 2027 for state and local government entities with a total population of 50,000 or more. Public entities with a total population of less than 50,000 have until April 26, 2028, according to the ADA.gov small entity compliance guide.
If you build apps for a public entity, read the rule’s technical standard in that guide and agree which release must meet it. For other clients, WCAG 2.2 AA remains a sound target because it is the measure used in the contrast figures above. After the audit, review mobile app security best practices as the next pre-release check.
Fix list by finding
Group the audit log by the type of failure, so one fix clears a whole class of defects.
| Finding | Fix | Check afterwards |
|---|---|---|
| Icon button is silent in VoiceOver or TalkBack | Add a text equivalent to the touchable component | Listen again on both platforms |
| Form field announces no label | Give the control a label | Move through the form by screen reader only |
| Grey secondary text looks faint | Darken it until normal text reaches 4.5:1 or large text reaches 3:1 | Re-measure the actual colours |
| Link or error shown only in colour | Add an underline, icon or message | View the screen without relying on colour |
| Custom control cannot be focused | Make it focusable like the standard links, buttons and fields | Move to it with the screen reader |
The finding types and thresholds follow MDN’s mobile accessibility checklist.
Frequently asked questions
Which text counts as large for the 3:1 ratio?
Text of 18 pt or larger, or 14 pt bold, qualifies as large. Anything smaller uses the stricter normal text ratio.
Are standard controls accessible without extra work?
They are focusable by default, which is a good starting point. Their labels and contrast still need checking, and custom controls need to be tested one by one.
Does the ADA Title II rule reach mobile apps?
Title II applies to all services, programs or activities of state and local governments, which includes online services and apps.
Do form fields need labels even if the layout makes their purpose obvious?
Yes. MDN’s checklist states that all form controls must have labels, and screen reader users depend on them.
