Accessibility checklist for a mobile app in 2026

On 28 June 2025 the EU’s European Accessibility Act came into force. For most b2c apps (banking, e-commerce, transport, ticketing, media, readers) accessibility is no longer “nice to have” — it’s a legal requirement with fines up to a million euros in some countries. In the US the ADA has long applied, and WCAG 2.1 AA is the de-facto global standard.

Despite all this, in many teams a11y testing reduces to “design said it’s fine — we signed off”. This checklist is what to actually test by hand, what to automate, and 10 kinds of bugs you can catch in a couple of hours on any app.

1. Screen readers: VoiceOver and TalkBack

The primary tool for a user with a visual impairment. Open the app, close your eyes, try to complete a key scenario — that’s not an exercise, that’s the baseline run.

iOS — VoiceOver:

Settings → Accessibility → VoiceOver → On (or triple-click the side button as a shortcut).
Swipe left/right — move between elements. Double-tap — activate. Three-finger swipe — scroll.
Open the Rotor (twist with two fingers on the screen) — Headings, Links, Form Controls modes.

Android — TalkBack:

Settings → Accessibility → TalkBack → On (or hold both volume keys as a shortcut).
Swipe — move. Double-tap — activate. Two-finger scroll.

What to check:

Reading order matches the visual order (not “cart → product → price → name”).
Every interactive element is spoken — unlabeled buttons sound like “button button button” and the user has no idea what to press.
Icons have accessibilityLabel (iOS) or contentDescription (Android). Decorative ones are marked hidden so the screen reader skips them.
The screen reader does not announce elements that are visually hidden (e.g. items behind a modal).
Custom components have proper accessibilityTraits / Role — a slider behaves as a slider, a checkbox as a checkbox.
When a form error appears, focus moves to the error, not stays on “Submit”.

2. Dynamic Type and Font Scale

A low-vision user enables a large system font. An app that breaks at 200% loses that user.

How to enable:

iOS — Settings → Accessibility → Display & Text Size → Larger Text → slider all the way (AX5).
Android — Settings → Accessibility → Font size → max. Display size additionally enlarges everything, including icons.

What breaks:

Text truncated in buttons (“Confir…” instead of “Confirm order”).
Text overlaps neighbouring elements.
Numbers in tabs and counters spill outside.
Fixed line height — text clipped top or bottom.
Layout is broken — buttons not tappable because of overlap.

The code-side fix is to use platform text styles (iOS — UIFontMetrics / scaledFont(for:); Android — sp units and ConstraintLayout with min/max). The QA test is to crank up the font and walk the golden path.

3. Contrast (WCAG AA / AAA)

WCAG 2.1 AA minimum — 4.5:1 text-to-background contrast (regular) and 3:1 (large, ≥ 18pt or ≥ 14pt bold). For UI components (button borders, icons) — 3:1.

Tools:

Xcode Accessibility Inspector (Xcode → Open Developer Tool → Accessibility Inspector) — eyedropper on the screen, shows contrast and flags issues.
Stark — Figma / Sketch plugin to check contrast at the design stage (often easier to catch there than in QA).
axe DevTools / Lighthouse — for the web, contrast checks built into the audit.
Android Accessibility Scanner (Play Store app) — scans the screen and surfaces all a11y issues, including contrast.

Common failures:

Light-grey placeholder in an input field (#CCCCCC on white — contrast 1.6:1).
Disabled buttons — grey on grey.
Icons on gradients and photos — variable contrast.
A link distinguished from regular text only by hue (see next section).

4. Color as the sole carrier of information

Colour-blind users don’t distinguish red and green (~8% of men). If order status is “green dot = delivered / red = cancelled” with no icon or label — that’s an accessibility bug.

Test cases:

Screenshot the app → convert to grayscale (or iOS Settings → Accessibility → Display & Text Size → Color Filters → Grayscale). Are all states still distinguishable?
Charts and diagrams — every series has its own pattern (dots, hatching), not just colour.
Form validation — an error is shown not only as a red border but also as error text or an icon.
In-text links — underlined, not just coloured blue.

5. Touch target sizes

iOS HIG requires a minimum 44×44pt for any interactive element. Android Material — 48×48dp. WCAG 2.5.5 (AAA) — 44×44 CSS pixels. See Apple HIG: Accessibility.

Common failures:

A small ”×” close button in the corner of a modal — 20×20pt.
Checkboxes whose tap area equals the size of the checkbox itself (you need to extend hitTest to 44pt).
Adjacent tab icons — easy to mistap a neighbour.
In-text links — line height 16pt, hard to hit with a finger.

In Xcode, check via Accessibility Inspector → Audit. In Android Studio — Layout Inspector + Accessibility Scanner.

On iOS, users with a Bluetooth keyboard (including Switch Control users) navigate via Tab. Same on Android. The web — required from the start.

What to check:

All interactive elements reachable via Tab.
Focus order matches the visual order (top to bottom, left to right).
Focus is visible — there’s a highlight on the current element (border, ring).
In modals focus is trapped inside (focus trap) — Tab doesn’t escape to elements behind the modal.
Esc closes the modal, Enter activates.

7. Reduce Motion, Reduce Transparency, Bold Text

Animation can cause nausea in users with vestibular disorders. Transparency hurts readability. Apps must respect all these settings.

How to enable:

iOS — Settings → Accessibility → Motion → Reduce Motion / Auto-Play Video Previews / Limit Frame Rate.
iOS — Settings → Accessibility → Display & Text Size → Reduce Transparency / Increase Contrast / Bold Text.
Android — Settings → Accessibility → Remove animations.

What should change:

Parallax, autoplaying feed videos, long fade/slide animations — disabled or replaced with cross-fade.
Semi-transparent nav bars and tab bars — become opaque.
Bold text — actually applied (often ignored by custom fonts).

8. Video, audio, multimedia

Video has captions — mandatory. For international content — multilingual.
Captions are toggleable in the player, not baked into the video (otherwise you can’t turn them off or translate).
Audio content has a transcript or an alternative text description.
Video doesn’t autoplay with sound — a user shouldn’t get a sudden noise out of silence.
Animated images (GIF, Lottie) can be paused.

9. Semantics and labelling

The number-one reason screen readers work badly — missing or uninformative labels.

iOS — main properties:

accessibilityLabel — what it is (“Favorite button”).
accessibilityHint — what happens on activation (“Adds to favorites”).
accessibilityValue — current value (sliders, checkboxes).
accessibilityTraits — role (.button, .selected, .header).

Android — main properties:

contentDescription — what it is.
importantForAccessibility — hide decorative elements.
Custom views — set AccessibilityNodeInfo through a delegate.

Antipatterns:

Label = “image” or “button button”.
Label duplicates hint (“Favorite button. Button for favorites”).
Label contains “tap to” — the screen reader says “double-tap to activate” itself.

A manual screen-reader run is always required, but the basics — labels, contrast, touch targets, duplicate IDs — can be automated.

iOS — XCUITest accessibility audit: XCUIApplication().performAccessibilityAudit() (Xcode 15+). Runs the audit and fails the test on detected issues.
Android — Espresso AccessibilityChecks + Accessibility Test Framework. One line to enable, checks every action.
Web — axe-core, Lighthouse in CI. Doesn’t catch everything but gives a quick baseline.
Design — Stark in Figma — catches issues before they reach code.

Automation catches ~30–40% of real problems (Deque data). The rest — manual screen-reader walks and real users.

11. The final checklist

Minimum regression before release:

All key screens are completable using only VoiceOver / TalkBack with eyes closed.
The golden path is not broken at Dynamic Type / Font Scale 200%.
Text contrast ≥ 4.5:1 (regular), button borders ≥ 3:1.
In grayscale all states are distinguishable, form validation doesn’t rely on colour alone.
Touch targets ≥ 44×44pt / 48×48dp.
External-keyboard tab navigation works, focus is visible, modals have focus trap.
Reduce Motion / Reduce Transparency / Bold Text are respected by the app.
Video has captions, no autoplay with sound.
Icons and custom controls have correct labels and traits.
An accessibility audit runs in CI (XCUITest or Espresso).

Accessibility is not “helping a few people”. 15% of the population lives with some form of disability (WHO), plus situational impairments hit everyone — sun on the screen, holding the phone one-handed with a coffee, dead earbuds and no captions. A11y is about the product working for everyone.