Mobile App Accessibility Checklist: Fix WCAG 2.2 Issues Fast

I was on a train once, one hand on a coffee, the other trying to buy a ticket in an app that clearly hated thumbs. The “Pay” button sat politely at the bottom… right where my phone’s gesture bar lived. I tapped. Nothing. I tapped again—harder, like that helps. Still nothing.

It wasn’t a “bug” in the usual sense. The app worked fine… if you had perfect vision, steady hands, and the patience of a saint. For everyone else, it was a little obstacle course disguised as a checkout screen.

That’s what mobile app accessibility is, in practice: removing the tiny, everyday barriers that turn simple tasks into stress. The W3C frames it as making apps and sites usable for people with disabilities on mobile devices—and WCAG 2.1 (2018) and WCAG 2.2 added specific guidance for mobile accessibility. And if you’re thinking, “Sure, but is this really that common?”—the State of Mobile App Accessibility (SOMAA) report found 72% of mobile user journeys tested had accessibility barriers. That’s… a lot of stuck people.

This is a checklist you can actually use. Not a compliance sermon. More like: if you fix these WCAG 2.2 issues, you’ll remove the most common friction fast—and your app will feel calmer for everyone.

Start with the stuff that blocks people today

I’m going to assume you’re either building an app for your business or trying to improve one that already exists. In both cases, you probably don’t have infinite time. So we’ll prioritise the “journey killers”—things that stop someone completing a task, not the tiny edge-case polish.

WCAG 2.2 introduced nine new success criteria, and a few of them are absolute gold for mobile. They’re also (mostly) practical: touch targets, focus behaviour, avoiding accidental activation, not hiding controls behind gestures… the kind of stuff you can see and test without needing a PhD.

Here’s how I’d tackle it when I’m trying to fix accessibility issues quickly without breaking half the UI.

WCAG 2.2 mobile accessibility checklist (the fast wins)

1) Make touch targets big enough (and spaced out)

If you only fix one thing, fix this. People miss small buttons. People with tremors miss them more. People on a bumpy bus miss them constantly. WCAG 2.2 added Target Size (Minimum) (2.5.8), which is basically the standard saying: “Stop making people play darts with their thumbs.”

Checklist:

Make tappable targets at least 24×24 CSS pixels (that’s the WCAG 2.2 minimum). 44×44 is a nicer real-world target if you can manage it.
Give targets breathing room so you don’t accidentally hit “Delete” when you meant “Details”.
Don’t rely on tiny icons alone. If it’s important, add a label or increase the hit area.
Watch out for “invisible” targets—icons that look big but only respond if you tap the exact centre.

Quick test: try using your app one-handed with your thumb. If you have to slow down and aim, users will too—except some won’t be able to.

2) Don’t hide key actions behind complex gestures

Mobile loves gestures. Designers love gestures. Users… tolerate them, until they don’t. WCAG has been nudging this for a while (WCAG 2.1 brought in gesture-related criteria), and the practical takeaway is simple: keep gestures simple, and always offer a plain alternative.

Checklist:

Any action that uses a gesture should have a visible control too (a button, menu item, link).
Avoid multi-finger gestures as the only way to do something important.
Don’t make “swipe” the only navigation between critical steps (like checkout stages or form sections).

And yes, I know—gestures can feel “clean”. But clean for who? If your app’s core flow depends on discovering a secret swipe, you’re building a puzzle, not a product.

3) Stop accidental activation (especially on release)

This one sounds fussy until you see it bite someone. WCAG 2.2 added Dragging Movements (2.5.7) and Target Size, but accidental activation is also tied to older criteria like Pointer Cancellation (2.5.2 from WCAG 2.1). On mobile, accidental taps happen when controls trigger too early—like on touch down instead of touch up.

Checklist:

Trigger actions on “up” not “down” (so users can slide off to cancel).
Provide an undo for destructive actions (delete, archive, cancel booking). Undo is accessibility and good manners.
For drag-and-drop, provide buttons as an alternative (move up/down, add/remove). WCAG 2.2’s Dragging Movements is basically asking for this.

Real-world example: reordering a list by dragging tiny handles. Looks lovely in a prototype. In reality, it’s a nightmare for motor impairments—and honestly, for everyone with dry hands and a cracked screen protector.

4) Make focus visible and predictable (keyboard and assistive tech)

Mobile accessibility isn’t just “make it bigger”. People use external keyboards, switch controls, voice control, screen readers. And when focus gets lost, they’re stuck.

WCAG 2.2 added Focus Not Obscured (Minimum) (2.4.11) and Focus Not Obscured (Enhanced) (2.4.12). Translation: when something is focused, don’t hide it behind sticky headers, cookie banners, bottom nav bars, or that floating chat widget your marketing team insisted on.

Checklist:

Ensure the focused element is not covered by fixed UI (headers/footers).
Don’t trap focus inside a modal with no clear way out.
Keep focus order logical—top to bottom, left to right, matching the visual layout.
Make focus styling obvious (not a faint grey outline on a grey background).

Quick test: connect a Bluetooth keyboard and use Tab. If you can’t tell where you are, neither can a lot of your users.

5) Give people more time (or at least don’t punish them for being slow)

WCAG 2.2 introduced Accessible Authentication improvements and also Timeouts got more attention across teams because mobile sessions time out constantly—banking apps, booking flows, anything with security.

WCAG 2.2 added Timeouts (2.2.6). It’s not saying “never time out”. It’s saying: warn people, let them extend, and don’t wipe their progress like a villain.

Checklist:

Warn before a timeout with enough time to act.
Allow users to extend the session without losing what they entered.
Save form progress locally when possible (especially long forms).

If you’ve ever had an app log you out mid-form, you know the particular rage that follows. Now imagine you type slowly, or use dictation, or need breaks. Same rage—more often.

6) Make authentication less of a “prove you’re human” obstacle course

WCAG 2.2 added Accessible Authentication (Minimum) (3.3.7) and Accessible Authentication (Enhanced) (3.3.8). This is a big deal for mobile apps because login flows are where businesses lose people—and where accessibility gets quietly ignored.

The gist: don’t force people to solve puzzles, remember obscure passwords, or transcribe codes in ways that depend on perfect vision, memory, or dexterity.

Checklist:

Support password managers properly (correct input types, no weird “disable paste” nonsense).
Avoid CAPTCHA as the only option; if you must use it, provide accessible alternatives.
Allow copy/paste for one-time codes and provide clear error messages when codes fail.
Offer biometrics (Face ID/Touch ID) as an option, not a requirement.

I’ve seen teams block paste in password fields “for security”. It’s not security. It’s theatre. And it hurts real users—especially those relying on assistive tech.

7) Don’t make people re-enter information they already gave you

This one is quietly brilliant. WCAG 2.2 added Redundant Entry (3.3.9). If someone already entered their address, don’t make them type it again in the next step “just because”.

Checklist:

Pre-fill known information when the user has already provided it.
Allow selection from saved data (addresses, payment methods, contact details).
Don’t force re-entry after an error; preserve inputs when validation fails.

This is accessibility, yes. It’s also conversion rate optimisation without the sleaze. Less typing. Fewer mistakes. More completed checkouts.

8) Give help where people actually get stuck

WCAG 2.2 added Help (3.2.6). It’s basically: if you offer help in one place, don’t hide it in another. Keep it consistent, and keep it findable.

Checklist:

Keep help options in the same place across screens (support link, chat, phone).
Make error recovery obvious—tell people what happened and what to do next.
Use plain language in validation messages. “Invalid input” is useless. “Postcode must include letters and numbers” helps.

Most “support” is really “I’m stuck and ashamed and I need a hand”. Make that hand easy to find.

The boring basics still matter (and they’re not that boring)

Even with WCAG 2.2, the biggest mobile app accessibility issues I see are the classics: low contrast text, missing labels, weird reading order, and interfaces that fall apart when text is larger.

Keep text readable: use a decent font size, allow Dynamic Type / font scaling, and don’t lock layouts so hard they break when someone increases text size. High contrast helps everyone, especially outdoors. And yes, “outdoors in sunlight” is basically a disability simulator for low contrast design.

Label everything properly: icons need accessible names. Form fields need labels. Buttons need meaningful text. “Click here” is bad on the web; “Tap here” is the same crime in a different coat.

Respect screen readers: test with VoiceOver (iOS) and TalkBack (Android). You don’t need to become an expert overnight. Just listen to what the app sounds like when it’s read aloud. If it sounds like chaos, it probably is.

A quick way to run this checklist without losing your mind

If you’re improving an existing app, don’t start by auditing every screen. Pick one high-value journey: sign-up, booking, checkout, or “contact us”. Run the checklist there first. Fix the blockers. Then move to the next journey.

I like doing a scrappy three-pass test:

Pass 1: One-handed thumb use. Can you complete the task without precision tapping?
Pass 2: Large text / display zoom. Does anything get cut off, overlap, or disappear?
Pass 3: Screen reader. Can you understand what each control is and what it does?

It’s not perfect. It’s not exhaustive. But it catches a shocking amount of real WCAG 2.2-related pain quickly.

Mobile app accessibility can feel like this massive, technical mountain. And sure—sometimes it is. But a lot of it is just noticing where people slip, then putting a handrail there.

Make the tap targets bigger. Stop hiding actions behind fancy gestures. Don’t let focus vanish under a sticky header. Let people use password managers. Don’t make them type the same thing twice.

Do that, and your app starts to feel… kinder. Not in a marketing way. In the quiet way where things just work, even on a shaky train, with one hand on a coffee.