Mobile app accessibility: the most common WCAG failures in 50 audited apps
We analyzed audits of 50 iOS and Android apps: the WCAG criteria apps fail most, the errors that show up in almost every app, and how to fix them.
We analyzed accessibility audits of 50 iOS and Android apps across Europe to see where mobile app accessibility breaks down. Most of the digital barriers we found come from a short list of repeat mistakes, and most of them sit at the most basic level of the Web Content Accessibility Guidelines (WCAG). Here's what fails, how often, and which fixes close the most issues.
A banking app can look polished and still be impossible to use with a screen reader. In our audits, buttons read as plain text and icons with no name were among the most frequent errors.
What are the most common accessibility errors in mobile apps?
All four errors show up when someone uses a screen reader.
Recurring error | Apps (% of 50) | What a screen reader user experiences | WCAG |
Missing or wrong name, role, or state | 96% | Controls are announced with no name, the wrong role, or no role at all: an icon is read only as "button", a link as a button, or a button as plain text | 4.1.2 |
Element can't be reached with a screen reader | 84% | The screen reader skips the element, so people never hear it (an important image) or can't activate it (an interactive component) | 1.1.1, 2.1.1 |
Bottom navigation doesn't move focus | 72% | After tapping a tab, the screen reader stays on the tab bar instead of moving to the new content | 2.4.3 |
Headings not marked as headings | 62% | Text that looks like a heading is read as plain text, so people can't jump from section to section | 1.3.1 |
The third error is specific to apps. Bottom navigation bars are everywhere in mobile design, and switching tabs left screen reader users on the tab bar with no signal that the content had changed.
What are the most violated WCAG criteria in mobile apps?
Three criteria account for six in 10 issues: 4.1.2 Name, Role, Value; 1.3.1 Info and Relationships; and 2.4.3 Focus Order. All three are Level A, and all three decide whether a screen reader can make sense of a screen.
Across the whole dataset, 84% of issues fail Level A criteria and 16% fail Level AA. Severity is high too: every app had at least one issue rated critical.
WCAG criterion | Level | Apps affected (%) | Share of all issues |
4.1.2 Name, Role, Value | A | 96% | 38.1% |
1.3.1 Info and Relationships | A | 96% | 14.0% |
2.4.3 Focus Order | A | 96% | 9.5% |
4.1.3 Status Messages | AA | 94% | 3.5% |
1.1.1 Non-text Content | A | 94% | 5.6% |
2.1.1 Keyboard | A | 92% | 6.9% |
1.4.4 Resize Text | AA | 92% | 1.8% |
4.1.2 Name, Role, Value requires every interactive element to expose what it is (its role), what it's called (its name), and its current state. When it fails, a screen reader user hears "button" with no label, or hears a label with no clue that it can be tapped. You can read the full requirement in the W3C's Understanding 4.1.2 page.
A screen reader can only announce what the code tells it.
1.3.1 Info and Relationships fails when the structure people see isn't passed on to assistive technology: headings that look like headings but aren't marked as such, or form labels that aren't linked to their fields. 2.4.3 Focus Order fails when the screen reader jumps around the screen in an order that doesn't match what's on it.
Where the data comes from
This analysis draws on accessibility audits of 50 mobile apps that Accessiway's app team carried out for organizations across Europe in the past year. Together, the audits logged 6,652 issues.
Mobile app accessibility is the practice of making an app's screens perceivable, operable, understandable, and robust for everyone, including people who use screen readers, external keyboards, switch controls, or enlarged system text, and people who can't rotate their device. Our app accessibility guide covers the legal requirements and where to start.
Our auditors test each app against WCAG 2.2 Level AA and rate every issue as critical, high, medium, or low priority.
How we counted the results:
For WCAG criteria, each app is counted once, however many issues it has.
The most common errors come from the app team's analysis of the audit reports, which groups issues with similar descriptions. The shares are minimums: each error appeared in at least that share of the apps.
Issue counts depend on how many screens and flows each audit covered, so we rank by how many apps are affected, not by raw volume.
The share of all issues counts single occurrences, so a widespread error that appears only once in each app weighs little in that column.
We don't name any of the apps.
Which WCAG criteria should you fix first?
Start with 4.1.2, 1.3.1, and 2.4.3, which affect nearly every app. Then move on to these criteria:
1.1.1 Non-text Content: meaningful images and icons need a text alternative.
2.1.1 Keyboard: everything must work with a keyboard or other external input, not only by touch.
1.4.3 Contrast (Minimum): text must stand out clearly from its background.
1.4.4 Resize Text: nothing should be cut off when people enlarge the text.
1.3.4 Orientation: the app should work in both portrait and landscape.
You don't need to fix everything at once. A solid semantic structure, with names, roles, states, and a logical focus order, is what lets people use your app with keyboards, joysticks, voice control, and screen readers.
How do you fix the most common accessibility issues in mobile apps?
The fixes the auditors recommended most often target the same screen reader problems. Here's how to apply them.
Set the correct role on every control
Fixes controls announced without a role or with the wrong role. Declare roles through each platform's accessibility API: accessibilityTraits on iOS, AccessibilityNodeInfoCompat.setClassName() on Android, accessibilityRole in React Native, and Semantics in Flutter.
Give every control a clear accessible name
Fixes controls with no accessible name. Set a meaningful accessibilityLabel on iOS and contentDescription on Android, especially on icon-only buttons.
Meet the contrast minimums
Use a contrast ratio of at least 4.5:1 for normal text, and 3:1 for large text and meaningful icons, borders, and state indicators. Check both light and dark mode. Our guide to accessible color combinations explains how to test them.
Move focus to the new content
Fixes bottom navigation that leaves screen reader users on the tab bar. On iOS, set accessibilityElements in the correct order. On Android, set the focus order with nextFocusDown/Up/Left/Right in XML, or focusProperties in Compose. In React Native, move focus with AccessibilityInfo.setAccessibilityFocus.
Group related elements into one component
Fixes cards that need several swipes to read. A product card made of an image, a title, and a price should be one focus stop, not four. On iOS, set isAccessibilityElement on the parent and give the group a label. On Android, use android:screenReaderFocusable on the container.
Native components handle much of this by default. When a team builds its own controls, it has to declare the role, name, and state by hand.
What this means for EAA compliance
Apps that serve consumers in the European Union fall under the same rules as websites. Since 28 June 2025, the European Accessibility Act (EAA) has required accessible apps for in-scope services such as banking, e-commerce, and passenger transport. Its technical requirements build on WCAG.
Measured against WCAG, most apps we audited don't yet meet the baseline that every higher standard builds on. Automated scanners catch part of this, such as low contrast. They can't judge whether a label makes sense or whether focus lands where it should after a tap, which is why our comparison of manual and automated testing recommends combining the two.
Frequently asked questions about mobile app accessibility
Does WCAG apply to mobile apps?
Yes. WCAG was written for the web, but EN 301 549, the European standard for accessible ICT, applies its success criteria to mobile software. Some criteria need interpretation outside a browser, which the W3C covers in its guidance on applying WCAG 2 to non-web software.
What is the most common accessibility issue in mobile apps?
Errors linked to WCAG 4.1.2 Name, Role, Value: controls with no accessible name, or with a missing or wrong role. They appeared in 96% of the apps we audited.
Which WCAG level do mobile apps fail most?
Level A, the most basic level of WCAG. Its criteria cover whether people can identify, reach, and operate each element at all.
Where to begin?
The fixes are known and repeatable on both platforms.
Book an accessibility audit that maps each issue in your app to WCAG 2.2 and includes testing with people with disabilities.
Fix Level A issues on your highest-traffic flows first.
Build roles, names, and states into your shared design system components, so new screens inherit them.
Add a screen reader check to your release process, so new versions don't bring old barriers back.
Additional resources
Want to know where your digital products stand? Talk to our team about an accessibility compliance platform that gives you visibility and tools to manage accessibility continuously.
Content generated with the support of artificial intelligence and subject to human oversight and review
Editorial Board
An accessible color palette preserves visual identity and ensures that text, states, and components stay readable for everyone who uses them, including people with visual disabilities.
Digital Accessibility
Editorial Board
For many people, morning coffee is a small ritual: a moment of pause before everything begins. If that gesture depends on an app, it shouldn't become an obstacle. That's where we started with Lavazza.
Digital Accessibility
Author
An unlabeled icon is enough to block a purchase. What the rules require, which barriers show up most often, and the seven fixes to start with to make an app accessible.
Digital Accessibility