Loading today’s stories
Build1 distinct publisher3 min readUpdated
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
Compiled by The EngineerSomething wrong?How this is made
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].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
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.
The Mobile Accessibility Task Force published WCAG2Mobile, 'Guidance on Applying WCAG 2.2 to Mobile Applications', as a Draft Note in May 2025.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Checkable standards facts, one uncited source
The substantive claims are statements about public artifacts - WCAG's web-derived conformance unit, WCAG2ICT's scope, WCAG2Mobile's Draft Note status and caveats, the EAA date, EN 301 549's revision, Section 508, ADA Titles II and III - which are the kind of thing that can be verified against primary documents, and the article is careful to mark the mobile guidance as informative rather than normative. What holds the score down is that this is a single dev.to explainer with no citations, no links and no dates for the DOJ adoption, and the load-bearing technical illustration (accessible on the web, invisible to VoiceOver) is asserted from practice rather than shown via a test case or audit.
Regulation adopted, mobile guidance still a draft
Adoption is split. The regulatory layer is genuinely in force: the EAA has applied since 28 June 2025 and DOJ has fixed WCAG 2.1 Level AA for ADA Title II state and local government web and mobile, with Section 508 covering federal ICT - these are binding adoptions of WCAG-shaped requirements onto mobile software. The interpretive layer that would tell teams how to satisfy those requirements on a touchscreen is not adopted: WCAG2Mobile is a Draft Note, informative and subject to change, and EN 301 549 is mid-revision. The cluster supplies no evidence at all of practitioner uptake - no counts of teams using WCAG2Mobile, no conformance or audit statistics.
Careful on standards, unmeasured on cost
Slightly overstated overall. The standards and regulatory portions are hedged accurately - informative versus normative, US posture varying by buyer, no universal private-sector standard - and the piece is arguing against a simplification rather than for a product, which keeps the gap small. The overshoot is in the framing: 'compliance debt you cannot see', 'one of the more expensive assumptions a product organization can make', and the absolute claim that there is no shared attribute flowing between platforms, none of which is supported with cost figures, enforcement data, or any treatment of cross-platform toolkits where authoring is not strictly three times over.
Practitioner explainer, no product being sold
Incentive pressure appears low but not absent. The single source is an individual-authored post on a developer community platform; it promotes no vendor, tool, audit service or paid standard, and its recommendations point to free W3C documents. The residual incentive is the ordinary one for this format - reach and professional positioning as a platform-accessibility expert, which rewards the strong 'this is expensive and you cannot see it' framing. The cluster contains no disclosure statement, funding note or affiliation information, so this reading is based only on what the source itself shows.
Plausible and internally consistent, uncorroborated
Moderate. The claims are internally consistent, specific enough to be falsifiable, and the regulatory dates and document statuses match the kind of detail an informed practitioner would get right, so the core of the story is likely accurate. But there is one publisher, no citations, one undated legal claim (DOJ Title II), and two claims explicitly about moving targets - WCAG2Mobile 'may change' and EN 301 549 is under revision - which means the specifics could be stale relative to the article's late-2026 publication date. That combination supports acting on the direction of the story while verifying any individual date or standard against primary sources.
build
The EAA exemption most vendors skip: Article 4(5) also cancels the paperwork1 distinct publisher
invest
556 wallets, 78,496 bets: Polymarket's insider problem now has a denominator1 distinct publisher
invest
Washington licenses private hacking, and hands the contractor the liability1 distinct publisher
product
White House lets vetted firms hack back and leaves liability blank for 60 days1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 18, 2026