Mobile app accessibility in practice: what 110 developers across 43 countries say they actually do

Original paper (source): arXiv / ICSE ’26 - “Practitioner Views on Mobile App Accessibility: Practices and Challenges” (submitted Jan 20, 2026)

• https://arxiv.org/abs/2601.14131

Why this matters for app growth teams

Accessibility is usually framed as an “engineering quality” topic. In practice, it is also a growth topic:

• it reduces avoidable churn (especially on onboarding + core flows)
• it improves reviews and store reputation
• it lowers support load
• it expands the addressable audience

This paper is valuable because it focuses on what practitioners actually do, across iOS and Android.

What the paper found (high level)

Based on a mixed-methods survey of 110 mobile developers across 43 countries, the authors report:

1) Developers value accessibility, but execution is inconsistent

Many developers intend to do accessibility work, but it often competes with time, tooling, and organizational constraints.

2) Platform guidelines drive behaviour

Developers tend to rely on platform-specific guidelines rather than a unified standard.

Implication: accessibility quality can vary by platform not because teams care less, but because the guidance + APIs differ.

3) Testing often happens late

Accessibility checks are frequently performed late in the development process.

Implication: bugs become expensive; “we’ll fix it later” turns into “we shipped without it”.

4) Work starts with text-first improvements

The paper notes developers primarily implement text-focused features first (labels, text sizing, etc.), while richer interactions can be harder.

5) Common blockers include API and org constraints

They call out limitations in APIs/tooling plus organizational factors as recurring barriers.

Practical takeaways you can apply this week

1. Add an accessibility gate to PR review for your top 3 screens (store landing, onboarding, paywall).
2. Run platform-native audits early (VoiceOver/TalkBack + dynamic type + contrast).
3. Treat accessibility as “conversion quality”: it should be measured and owned, not left to last-minute QA.

Read the paper: https://arxiv.org/abs/2601.14131