The first question owners ask about an app is which rules apply, and the honest answer is that WCAG does not, directly. It is written for web content, and an app has no DOM, no browser and no page.
That is a technicality rather than an exemption. Two documents close the gap, and the law reaches apps regardless.
The Standard That Actually Applies
- WCAG2ICT is a W3C note explaining how to read each WCAG criterion when the thing is not a web page. It substitutes words: where WCAG says "web page", read "screen" or "document". Almost every criterion survives that translation.
- EN 301 549 is the European standard, and its clause on software applies directly to mobile applications. This is what EU procurement and the accessibility act point at.
- Platform guidance from Apple and Google sits underneath both, and is where the implementation detail lives.
The legal position, plainly
The European Accessibility Act names mobile applications explicitly, so an app selling to EU consumers is in scope. Section 508 covers software procured by US federal agencies. Neither cares that WCAG says "web page".
What the Platform Gives You
This is the genuine difference from the web, and it works in your favour. A standard iOS or Android control arrives accessible. A UIButton has a role, a label from its title, and a focus behaviour, with nothing asked of you. The same is true of a Material button.
The web has this too, in native HTML elements, and teams throw it away by building buttons from divs. Apps throw it away by drawing custom interfaces on a canvas, which is more common in games, charts and anything with a distinctive visual identity.
Where Apps Break
- Custom-drawn views with no accessibility information. The platform sees one opaque rectangle. Everything inside it is invisible to a screen reader unless you describe it.
- Images and icon buttons with no label. The same failure as missing alt text, and the most common finding on both platforms.
- Text that ignores the system font size. Someone who has set large text expects your app to honour it. Fixed point sizes and fixed-height containers are what break that.
- Focus order that follows the view hierarchy rather than the layout, which happens as soon as a view is repositioned after being added.
- Announcements that never happen. A loading state finishes, content changes, and nothing is spoken, which is the same class of failure as a missing live region on the web.
- Tap targets under the platform minimum, which is a recurring finding in toolbars and tab bars.
The Attributes That Do the Work
| What it does | iOS | Android |
|---|---|---|
| Names an element | accessibilityLabel | contentDescription |
| Says what kind of thing it is | accessibilityTraits | Role via the node info |
| Adds detail beyond the name | accessibilityHint | stateDescription and hint text |
| Groups children into one item | isAccessibilityElement | importantForAccessibility |
| Announces a change | UIAccessibility.post | announceForAccessibility |
| Honours the user's text size | Dynamic Type | sp units and font scale |
The pattern behind all of them is the same as 4.1.2 Name, Role, Value on the web. What is it called, what kind of thing is it, what state is it in.
Cross-Platform Frameworks
React Native, Flutter and the rest expose the platform accessibility APIs, and none of them applies the platform defaults for you as reliably as writing native code does. A component that renders as a touchable view is not automatically a button on either platform.
The practical consequence is that a cross-platform app needs testing on both platforms rather than once. The same code produces different accessibility trees, and a label that reads correctly under VoiceOver can arrive empty under TalkBack.
Testing It Yourself
- Turn on the screen reader and complete your main task. VoiceOver on iOS, TalkBack on Android. Fifteen minutes finds most of it.
- Set the system text size to the largest setting and look for clipped labels and overlapping views.
- Run the platform checker. Accessibility Inspector on iOS and Accessibility Scanner on Android both catch missing labels and small targets.
- Try it with a keyboard, since both platforms support external keyboards and many people use them, which is 2.1.1 Keyboard by another name.
- Turn on reduce motion and confirm the animations respond.
What the platform checkers miss
The same third they miss on the web. A label can exist and be wrong, an order can be valid and senseless. Watching somebody use the app is the only way to find those, which is covered in testing with disabled users.
If You Have Both a Site and an App
They are separate pieces of work with separate findings, and a conformance claim for one says nothing about the other. Where a process spans both, such as booking on the web and checking in on the app, each half has to work on its own.
Our audits cover web content, including web apps and progressive web apps. Native iOS and Android testing is a different discipline and we do not sell it, which is worth saying plainly rather than letting a mobile page imply otherwise.