Does WCAG Apply to Your Store’s Mobile App the Same Way It Applies to Your Website?
Most accessibility advice aimed at e-commerce SMBs — including Quietramp’s own overview of ADA compliance risk — talks about “your website.” A growing number of mid-market stores also ship a native iOS or Android shopping app. WCAG itself was written for web pages — its success criteria repeatedly say “web page,” not “screen” or “app.” That raises a real, practical question: if your app was never a web page to begin with, does WCAG even apply to it the same way?
Quick answer: courts have already answered the legal half of that question for U.S. e-commerce businesses — Robles v. Domino’s Pizza, LLC, 913 F.3d 898 (9th Cir. 2019), held that Domino’s website and app were covered together under Title III of the ADA, because both connected customers to the goods and services of its physical restaurants (full case background in Quietramp’s ADA compliance risk overview). The technical half is less settled but has real guidance behind it: the W3C’s WCAG2ICT — “Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies” — translates WCAG’s web-specific language for native software, and the U.S. Department of Justice’s 2024 Title II mobile-app rule for government entities directs implementers to that same document to determine which success criteria apply and how.
This article is general accessibility information, not legal advice. Whether the ADA applies to your specific app, and to what extent, is a legal question for an attorney familiar with your business — not something this article, or any general article, can answer for your specific facts.
Your app was never a “loophole” — that question is already settled for the web-vs-app split
Nothing here suggests a native app is somehow outside ADA Title III’s reach just because WCAG was written with “web pages” in mind. In Robles, the Ninth Circuit held that “the alleged inaccessibility of Domino’s website and app impedes access to the goods and services of its physical pizza franchises — which are places of public accommodation,” and separately rejected the argument that the lack of a specific DOJ technical regulation excused non-compliance. That’s the binding precedent for the circuit, and it treated the website and the app as one question, not two. Quietramp’s existing ADA compliance risk article covers that case and the demand-letter and lawsuit landscape around it — this article doesn’t re-derive any of that.
What Robles didn’t settle is the practical question a developer actually has to answer: WCAG’s success criteria are written in web terms — “web page,” “set of web pages,” HTML-specific techniques. A native app has none of those. Saying “meet WCAG 2.1 AA” for an app without more is a bit like handing someone a recipe written entirely in grams and asking them to cook without a scale.
WCAG2ICT is the W3C’s own answer to that gap
WCAG2ICT exists specifically to close it. Per its own abstract, it “describes how the Web Content Accessibility Guidelines (WCAG) versions 2.0, 2.1, and 2.2 principles, guidelines, and success criteria can be applied to non-web Information and Communications Technologies (ICT), specifically to non-web documents and software.” It’s published as a W3C Group Note — the document is explicit that this is “informative guidance (guidance that is not normative and does not set requirements),” not a new standard layered on top of WCAG. It covers Level A and AA success criteria only, matching the scope most e-commerce audits — including Quietramp’s — already test against.
Two mechanical changes explain most of what’s different:
Web-specific terms get translated. Per WCAG2ICT’s own text: “When certain web-specific terms or phrases like ‘web page(s)’ were used in success criteria, those were replaced with non-web terms or phrases like ‘non-web document(s) and software.’” Since “the unit of conformance in WCAG 2 is a single web page,” the document treats “a single ‘web page’ was equated to a ‘software program’” for general non-web software.
Mobile apps get their own refinement. A companion document, WCAG2Mobile, narrows this further for phones and tablets specifically: “the task force agreed that the equivalent unit of conformance for mobile applications is a single screen within the application. It follows that an equivalent unit of evaluation for a ‘set of web pages’ would be a ‘set of screens’, not — as previously interpreted in WCAG2ICT — as a ‘set of software.’” In practice, that means an audit against a shopping app tests individual screens — the product detail screen, the cart screen, the checkout screen — the same way a web audit tests individual pages, rather than treating the whole app as one indivisible unit.
What doesn’t carry over cleanly
Not every success criterion translates one-to-one, and WCAG2ICT is upfront about that. It notes that other standards have already drawn lines here: “some local standards such as Section 508 in the U.S., and EN 301 549 in Europe, state that WCAG 2.0 Success Criteria 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent Identification do not apply to non-web documents and non-web software.” The reasoning behind each is specific to what the criterion actually tests — 2.4.1 Bypass Blocks, for instance, exists to skip repeated blocks of content across multiple pages, a structure a single-purpose app screen doesn’t have in the same way. That’s informative context on how Section 508 and EN 301 549 have handled the question, not a claim that any of these criteria are formally waived for a private-sector app under U.S. Title III — WCAG2ICT itself says it “does not specifically say which criteria can or should apply,” leaving that judgment to whoever is implementing it.
Why a government-only DOJ rule still matters for a private store’s app
The clearest regulatory signal behind WCAG2ICT actually comes from a rule that doesn’t bind private businesses at all. In April 2024, DOJ finalized a rule under Title II of the ADA — which covers state and local governments, not private companies — requiring their web content and mobile apps to meet WCAG. Per the live ADA.gov fact sheet: “The Web Content Accessibility Guidelines (WCAG) Version 2.1, Level AA is the technical standard for state and local governments’ web content and mobile apps.” Compliance dates are staggered by population — April 26, 2027 for entities of 50,000 or more, April 26, 2028 for smaller entities and special districts (the same figures covered in more depth in Quietramp’s ADA vs. Section 508 vs. WCAG overview).
That rule is narrow — it reaches governments, not e-commerce stores. What’s notable is which document it points to for the mobile-app half of the job. WCAG2ICT states this directly: “the U.S. Department of Justice regulation, Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities (89 FR 31320, 24 April 2024), directs implementers to utilize the guidance in this document to determine the applicability of success criteria and how to apply the requirements to mobile applications.” A federal regulator choosing WCAG2ICT as the reference for mobile-app conformance is a signal of how credible the framework is — not proof a private store’s app is legally required to follow it, since Title III has no equivalent regulation of its own.
What this means in practice for a shopping app
Put the two halves together: case law (Robles) already treats your app as fair game under the
same ADA Title III theory that reaches your website, and no separate regulation currently tells a
private business exactly which technical standard its app has to meet. In that gap, WCAG2ICT is the
most credible, non-vendor, off-the-shelf framework available for translating a WCAG 2.1 AA target
onto native screens instead of web pages — a practical observation, not a legal requirement.
Concretely, that means testing each app screen the way you’d test a web page: does every
interactive element have a real accessible name exposed through the platform’s own accessibility
APIs — iOS’s Accessibility framework,
read by VoiceOver, or Android’s contentDescription, read by TalkBack (per Android’s own
guidance: “include a description
that describes the element’s purpose”)? Does focus order make sense navigating by swipe gesture
instead of Tab? Does color alone distinguish a selected size or an out-of-stock item? Same WCAG 2.1
AA questions Quietramp already audits for on the web — WCAG2ICT is what justifies pointing them at
a screen instead of a page.
FAQ
Does this mean our app needs a separate audit from our website? Functionally, yes — the underlying WCAG success criteria are largely the same, but the markup, platform APIs, and testing tools are completely different (native accessibility APIs and tools like VoiceOver/TalkBack, not axe-core or a browser DOM). A web-only audit doesn’t cover a native app.
Is WCAG2ICT itself a law? No. It’s explicitly informative W3C guidance, not a normative standard and not a law. Its significance here is that DOJ’s own Title II mobile-app regulation points to it as the reference for applying WCAG to apps — a strong signal of credibility, not a legal mandate for private businesses.
We only have a website, no native app — does any of this apply to us? No — this article is specifically about native iOS/Android software. A responsive website accessed through a mobile browser is still a web page under WCAG’s original scope; WCAG2ICT’s non-web translation doesn’t come into play there.
Get your website checked by a person, not just a scanner
Quietramp’s $890 audits are built around manual verification — a person confirming every automated finding and doing the keyboard, screen-reader, and semantic checks a scanner structurally can’t. That’s currently scoped to your website, tested with a browser-based pipeline (Playwright + axe-core, plus a manual review). As the FAQ above notes, testing a native app’s screens needs different tools — a screen reader running on a real device, not a browser-based scanner — which is outside what our $890 audit covers today. WCAG2ICT is what tells you which WCAG 2.1 AA questions to bring to that testing once you’re ready for it. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.
This is provided for general educational purposes and does not constitute legal advice. Case law, regulatory text, and W3C guidance described here reflect the sources cited as of this article’s publish date and may change; only a qualified attorney can assess whether the ADA applies to your specific app and what, if anything, you need to do about it.
Quietramp is an AI-operated agency with human oversight — this article was drafted by our Content/SEO writer role.