Build1 publisher3 min readPublished
"Follow the same standard" is how mobile accessibility debt gets onto the books
WCAG's four principles cross platforms intact. The markup, the gestures and the accessibility tree do not, and the W3C's mobile guidance is still an informative draft.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- The WCAG principles (perceivable, operable, understandable, robust) are universal and transfer across web, iOS and Android, but almost every mechanism used to satisfy them changes outside the browser: the markup changes, the assistive technology changes, the gestures change, and the way a screen reader builds its picture of the interface changes.
- WCAG was developed for web content, so some of its terminology and conformance concepts - such as a 'web page' as the unit of conformance - assume a web context.
- WCAG success criteria are intentionally written to be largely technology-neutral, but native applications have no HTML DOM, which means web-shaped requirements often need platform-specific interpretation and implementation.
- To bridge the gap between web-shaped requirements and native software, the W3C publishes interpretive guidance rather than separate app standards.
- WCAG2ICT provides W3C guidance on applying WCAG 2.0, 2.1 and 2.2 to non-web documents and software.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
Telling the mobile team to follow the same accessibility standard as the web team sounds like governance and behaves like an unfunded liability. According to a dev.to write-up on platform accessibility, WCAG's four principles - perceivable, operable, understandable, robust - transfer cleanly across web, iOS and Android, but almost every mechanism used to satisfy them changes the moment you leave the browser: the markup, the assistive technology, the gestures, and the way a screen reader assembles its picture of the interface [1].
Start with the standard, because it is web-shaped by construction. WCAG was developed for web content, and some of its terminology and conformance concepts - treating "a web page" as the unit of conformance, for instance - assume a web context [2]. The success criteria themselves are written to be largely technology-neutral, but native applications have no HTML DOM, so those web-shaped requirements need platform-specific interpretation and implementation [3].
The W3C's response has been interpretive guidance rather than separate app standards [4]. WCAG2ICT covers applying WCAG 2.0, 2.1 and 2.2 to non-web documents and software [5]. On top of it, the Mobile Accessibility Task Force published WCAG2Mobile, "Guidance on Applying WCAG 2.2 to Mobile Applications", as a Draft Note in May 2025 [6]. It does useful translation work, including moving the unit of conformance from a web page to a single screen or view within the application [7]. It is also informative rather than normative: W3C states that it does not establish requirements, is not endorsed by W3C or its members, and may change [8]. So the mobile team gets a translation, not a test it can be held to [8].
Regulation does not resolve the ambiguity either; it multiplies it. In Europe, the European Accessibility Act has applied to covered products and services since 28 June 2025 [9], while EN 301 549, the European technical framework covering web and non-web software, is still being revised under the EU standardization process to support the EAA and the Web Accessibility Directive [10]. That means the mobile-specific interpretation landed as a non-binding draft roughly a month before the European obligation date [15]. In the United States, Section 508 incorporates WCAG requirements for federal ICT, including provisions adapted for non-web software [11]; the Department of Justice has adopted WCAG 2.1 Level AA as the technical standard for state and local government web content and mobile applications under ADA Title II [12]; and under Title III, obligations exist but federal regulations do not currently establish WCAG as a universal technical standard for all private mobile applications [13]. One product can therefore sit under three different postures depending on who buys it [14].
The reason the debt is invisible is the accessibility tree. Every platform exposes one - a parallel representation of the interface that assistive technology actually reads, distinct from the visual layout - and it is assembled from completely different source materials on each platform [16]. On the web it is derived from semantic HTML, supplemented and corrected by ARIA [17]. Which is why, per the same piece, a button that is perfectly accessible on the web can be completely invisible to VoiceOver, and a label that TalkBack announces cleanly can be meaningless noise in Safari [18]. A passing web audit is evidence about one tree built from one set of materials [16][17].
Practical consequence for anyone running a build: platform-specific acceptance criteria and on-device screen reader testing, rather than one checklist inherited from the web team [1]. Watch whether WCAG2Mobile moves off Draft Note status, whether the EN 301 549 revision lands with mobile-specific detail, and whether your own procurement and contract language still names a web standard for an app deliverable [6][8][10].