Mobile Accessibility Is the Case Developers Keep Ignoring
The accessibility argument is made with sufficient frequency in developer conferences and engineering blog posts that it has acquired the character of something everyone agrees with and nobody acts on. Apps ship with missing accessibility labels, unlabeled buttons, broken VoiceOver navigation, and dynamic type support that was added for text elements but forgotten for layout constraints. The gap between the accessibility investment that development teams describe as important and the accessibility state of their shipped applications is among the widest in software development.
The reasons for this gap are structural rather than attitudinal. Developers who support accessibility do so in a context where accessibility testing is manual and time-consuming, accessibility regressions are not caught by standard automated testing, product roadmaps do not include accessibility as a first-class requirement, and the users affected by poor accessibility are underrepresented in usability testing panels.
The Legal Dimension
The legal risk associated with inaccessible mobile applications has increased. The Americans with Disabilities Act has been interpreted by multiple federal courts to apply to mobile applications, though the specific technical standards required are contested. Several major companies — including retailers, streaming services, and financial institutions — have settled accessibility lawsuits that included requirements for mobile app remediation.
The organizations most exposed are those operating in regulated industries where accessibility obligations are well-established — government services, financial services, healthcare — and those with sufficient public profile to attract advocacy organization attention. The organizations most likely to address accessibility before litigation are those where the legal exposure is highest and where leadership has been educated about it.
The accessibility lawsuit risk is not evenly distributed. A two-person startup shipping a niche productivity tool faces different legal exposure than a bank’s mobile app. The legal argument is a backstop, not a primary motivator, and it primarily motivates organizations with legal teams who are aware of the exposure.
The Business Case
The business case for accessibility is routinely understated because accessibility user populations are difficult to measure. Users who navigate apps using VoiceOver or TalkBack do not self-identify in product analytics. Users who increase text size significantly — a population that is larger than the strictly visually impaired, including aging users and users in low-light conditions — are visible in analytics only if the app tracks preferred content size category, which most do not.
The conservative estimate of users with disabilities who would benefit from better mobile accessibility is ten to fifteen percent of the total user population. The population of users who use accessibility features occasionally or situationally — one hand while holding something, loud environment forcing captions, bright sunlight washing out the screen — is larger. An app that works well in accessibility configurations works better for more users in more contexts than its accessibility audit scores would suggest.
What Good Looks Like
Accessible iOS apps run cleanly with VoiceOver enabled: every interactive element has a meaningful accessibility label, the navigation order follows a logical reading sequence, custom UI components expose their role and state through accessibility APIs, and actions that require specific gestures have alternative access through the accessibility actions system. Dynamic Type support means that every text element in the app scales appropriately when the user increases their preferred text size — which requires that layouts handle text size variation without breaking, something that requires intentional layout design rather than fixed heights.
On Android, TalkBack compatibility requires the same discipline applied to the Android accessibility API. ContentDescription attributes on views without text, meaningful announcement behavior for state changes, and focus management that does not leave users stranded in invisible UI states are the minimum baseline.
The practical path to accessible apps is the same as the path to any other quality outcome: establish a standard, test against it, and include it in the definition of done for new features. Teams that add accessibility to the PR review checklist — requiring that new screens are verified with VoiceOver before merge — build accessible apps incrementally without requiring dedicated accessibility projects. Teams that treat accessibility as a project to be done separately from feature development will continuously find that the project is never scheduled.
The users who need accessible apps need them as completely as anyone needs a functional app. The argument does not require a business case. It requires the decision to treat all users as users.