Mobile accessibility: the five things that actually matter
Accessibility audits produce long documents that get filed. In practice a small number of fixes cover most of the real-world impact, and they are cheap if done while building.
Accessibility work often arrives as a report with ninety findings, which gets read once and filed. The length is the problem: it flattens a handful of things that block people entirely into the same list as a contrast ratio that is marginally off.
These are the five that, in our experience, cover most of the actual impact.
1. Everything interactive has a label
An icon-only button with no accessible label is announced as Button. A screen with six of them is unusable with VoiceOver or TalkBack, and this is the single most common blocking defect we find.
The label describes the action, not the icon. It is Delete message, not Trash can.
The failure is almost always a custom control. System buttons created with a title are labelled for free; a tappable image or a stack of views wired to a gesture has nothing to derive a label from, so it announces nothing useful unless somebody remembered. That is also why this defect clusters in exactly the screens a team is proudest of.
2. Text scales without breaking
A significant share of users run larger text sizes, and many people who would benefit never try because apps break. Test at the largest standard size, not the largest possible.
The failures are predictable: fixed-height containers clipping their text, truncation that removes the important word, layouts that overlap. All are cheap to fix while building and tedious afterwards.
Truncation deserves particular attention because it fails silently and asymmetrically. A button reading Save changes that truncates to Save is still sensible. One reading Delete all messages that truncates to Delete all is sensible and wrong. Put the distinguishing word early, and check the controls that destroy something first.
3. Contrast is checked while choosing colours
Contrast is trivial to get right at design time and expensive to retrofit, because by then the colour is in the brand, the marketing site and the client's expectations.
Check it when picking the palette. The worst offender is almost always mid-grey placeholder and helper text.
Two cases get missed even by teams who check. Text over a photograph has no fixed contrast at all, because the photograph changes; it needs a scrim or a guaranteed background rather than a measurement taken against one sample image. And a palette checked in light mode has not been checked, because the dark variant is a different set of pairings.
4. Colour is never the only signal
A red border on an invalid field says nothing to a colour-blind user. Errors need an icon or text alongside the colour, and so does any status indicator that carries meaning.
If the screenshot still works in greyscale, the information survives.
The greyscale test is worth running literally rather than imagining. Take a screenshot, desaturate it, and look for anything you can no longer read. Charts and status dots fail this constantly, and both are usually fixed by adding a shape or a label rather than by changing the palette.
5. Touch targets are large enough
Small targets fail for far more people than those with a recognised motor impairment: anyone on a train, holding a child, or using a phone one-handed in the cold.
Where a control must look small, the visual size and the touch size do not have to match. Extend the hit area without changing the design.
Two targets close together are their own problem. A row with a small delete control tight against an edit control produces mistaken taps even at a generous size, and the mistake is expensive in one direction only. Space them, or move the destructive one somewhere it cannot be hit by accident.
Test with the assistive technology, not a checklist
Automated checks catch missing labels and contrast failures, which is worth having and is not the same as the app being usable.
Turn the screen reader on and complete one real task with your eyes closed. Sign up, or buy something. It takes ten minutes and it finds the problems no checker can see: an announcement order that makes no sense, a modal that does not trap focus, a toast that reports success to nobody, a control that is labelled correctly and still leaves you unable to work out what the screen is for.
Most developers find this uncomfortable the first time, which is itself the useful part.
Why this is cheap during the build
Every item here costs minutes while a screen is being written and hours once it is finished, spread across a codebase, with a regression risk attached. That is the entire argument for doing it as you go, and it is why our definition of done includes it rather than scheduling an audit for later.
There is a commercial argument too, and it is worth making plainly to clients who see this as optional. Accessibility requirements are increasingly written into procurement, particularly for anything sold to government or large enterprises. A product that cannot answer the question is not merely awkward; it is excluded from the tender, and retrofitting under that deadline costs several times what building it in would have.
