Mobile accessibility fails in a small number of predictable ways, and almost all of them are invisible to sighted testing on a modern device with default settings. The work is not large if it happens during development. It is a genuine project if it happens after a customer or a procurement questionnaire asks.
01The three that account for most failures
Screen reader support is first. Controls without accessible labels are announced as 'button' with no indication of what they do, which makes the app unusable rather than inconvenient. Custom components built from generic views are the usual culprit, because platform controls carry semantics for free and custom ones do not.
Touch target size is second and affects far more people than screen reader support does - anyone with a motor impairment, anyone on a moving train, anyone with larger hands. The platform minimum exists for a reason and dense custom UI routinely violates it.
Dynamic type is third. Users who set larger system text and find your layout clipping or overlapping have an app that does not work for them. Fixed-height containers around text are the standard cause.
02Finding problems without specialist tooling
Most of this is testable by anyone on the team in under an hour, which is why it is worth doing continuously rather than commissioning an audit.
- Turn on the screen reader and complete your primary flow without looking at the display. Anything you cannot do is a defect.
- Set system text to the largest setting and open every screen. Clipped or overlapping text is a layout bug, not a user preference.
- Check contrast on the actual device in daylight, not in a design tool on a calibrated monitor.
- Navigate with an external keyboard where the platform supports it; focus order problems appear immediately.
- Turn on reduce-motion and confirm animations respect it - vestibular triggers are a real accessibility issue, not a preference.
03Where teams get it wrong even when trying
The most common mistake is labelling everything, including decorative elements, which produces a screen reader experience so noisy it is worse than sparse. Decorative images should be hidden from assistive technology entirely.
The second is announcing state changes badly or not at all. When content loads, an error appears, or a filter changes results, a sighted user sees it and a screen reader user gets silence unless you announce it explicitly.
The third is focus management on navigation. When a screen changes, focus should move to the new content; without that the user is left on a control that no longer exists and has to explore to find out what happened.
04The compliance angle
Accessibility increasingly appears in enterprise procurement and in public-sector requirements, which means it moves from ethics to sales blocker. Being able to answer a questionnaire with specifics rather than intentions shortens deals.
The practical output is a documented conformance statement covering what you support, what you do not, and what is planned. Teams that build accessibility in can produce this in days; teams that did not are looking at a remediation project first.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer