Mobile App Accessibility Compliance:ADA, Section 504, WCAG 2.2, and the EAA in 2026

Most mobile app accessibility content treats "ADA compliance" as one obligation with one deadline.It isn't. As of this article's research date, at least four separate legal regimes govern whether a mobile app has to be accessible, to whom, and on what technical standard — and two of the four had their compliance clocks reset by a full year within the last five months, while a third has no fixed deadline at all because no formal regulation exists for it yet.

This article covers DOJ's ADA Title II rule for state and local government apps and its April 2026 extension, HHS's parallel Section 504 rule for healthcare and other federal-funding recipients and its own May 2026 extension, the unsettled circuit-by-circuit exposure private businesses face under Title III with no formal rule at all, the European Accessibility Act, and what WCAG 2.2 and its mobile-specific companion documents actually require of a native app — not a website wearing an app's clothing.

On April 24, 2024, DOJ's Civil Rights Division published a final rule — codified at 28 CFR Part 35, Subpart H, titled "Web and Mobile Accessibility" — requiring state and local government entities to make their web content and mobile apps conform to WCAG 2.1 Level AA. The rule's scope is deliberately broad: it covers not just content a covered entity builds itself, but anything "provided or made available" to the public through a vendor, contractor, or licensor, so a city government can't outsource its way out of the obligation by hiring an agency that ships an inaccessible app.

The original rule set two deadlines based on population: April 24, 2026 for entities with a population of 50,000 or more, and April 26, 2027 for smaller entities and special district governments. Those are not the current deadlines.On April 20, 2026, DOJ published an interim final rule extending both dates by one year — to April 26, 2027 and April 26, 2028 respectively — citing concern that a meaningful number of covered entities, smaller ones especially, would not be ready in time.

The extension is also not without pushback. It was published as an interim final rule — legally effective immediately, but open for public comment through June 22, 2026 — and disability-rights organizations, including the National Federation of the Blind, have publicly challenged it. Treat April 2027/2028 as the current, but not necessarily final, state of this rule, and re-verify against ADA.gov's own fact sheet before you build a launch plan around either date.

A separate but structurally similar rule catches an audience most non-healthcare teams don't expect to be regulated at all. HHS's Office for Civil Rights published a final rule under Section 504 of the Rehabilitation Act on May 9, 2024, requiring the same WCAG 2.1 Level AA conformance for web content and mobile apps — but the covered population isn't government agencies, it's recipients of HHS federal financial assistance. That includes hospitals, community health centers, and many private healthcare providers and health plans that accept Medicare or Medicaid funding, which is a much larger and more surprising set of private organizations than Title II reaches.

Like DOJ's rule, it covers content provided directly or through a vendor, so a hospital system that licenses its patient-portal app from a third-party health-tech vendor is still the accountable party. And like DOJ, HHS moved its own deadline: an interim final rule published May 7, 2026 extended the compliance dates by one year, from the original May 2026/2027 dates to May 11, 2027 for recipients with 15 or more employees and May 10, 2028 for recipients with fewer than 15.

For a healthcare organization building or maintaining a patient-facing app, this rule — not a general "ADA compliance" framing — is the specific, dated obligation to plan around, and it sits alongside HIPAA's separate data-handling requirements rather than replacing them. Our healthcare app HIPAA compliance guide covers the data-privacy side of that same build; this article covers the accessibility side specifically.

If your organization is neither a government entity nor an HHS-funding recipient, neither rule above applies to you directly — but that doesn't mean you have no exposure. Title III of the ADA covers "places of public accommodation," and DOJ has never finalized a formal regulation specifying a technical standard for how that phrase applies to a website or app with no physical storefront. The result is a genuine, unresolved circuit split rather than a single national rule.

The leading precedent is Robles v. Domino's Pizza, LLC, 913 F.3d 898 (9th Cir. 2019), where the Ninth Circuit held that Domino's website and mobile ordering app were covered by Title III because a "nexus" connected them to Domino's physical pizza franchises — the app's inaccessibility impeded access to the goods and services of a real place of public accommodation. That nexus test binds only the Ninth Circuit's states. Other circuits have reached different, sometimes narrower conclusions, and none of it adds up to a single WCAG-mandating national rule the way Title II or Section 504 does.

Despite the absence of a formal rule, real exposure is measurable. UsableNet's 2025 Year-End Report on Web Accessibility Lawsuits counted 5,114 digital accessibility lawsuits filed across U.S. federal and state courts in 2025, of which 3,117 were federal filings — up 27% from 2,452 in 2024. And the app-specific trend is real and measured: 28% of 2025's digital accessibility lawsuits included a mobile app claim, up from 19%in 2023. That's still a minority of filings — most target websites and checkout flows — but the direction is unambiguous.

The European Accessibility Act — Directive (EU) 2019/882 — became applicable on June 28, 2025. It covers specific product and service categories sold or offered to EU consumers, including e-commerce, consumer banking services, e-books and e-readers, and electronic communications, along with the mobile apps that deliver each of them. Its technical benchmark, EN 301 549, harmonizes closely with WCAG 2.1 AA, so an app already built to that standard for DOJ or HHS compliance is most of the way toward EAA conformance too, though the two aren't identical regimes.

Scope is based on where the product or service is offered, not where the company is headquartered — a U.S. company with no EU office is in scope the moment it sells a covered product or service to EU consumers through an app. Enforcement runs through each member state's own market-surveillance and consumer-protection authorities rather than a single EU court, and the first EAA-related lawsuits were reported filed in France in late 2025.

Every rule above names WCAG 2.1 AA, but the current W3C Recommendation is WCAG 2.2, published October 5, 2023. It adds nine new success criteria on top of 2.1 — six required at Level AA, three AAA-only — and it's backward compatible, meaning content meeting 2.2 AA also meets 2.1 AA, but not the reverse. A build that satisfies only 2.1 AA can still fail 2.2's newer criteria outright.

No rule covered in this article currently names 2.2 as the required floor — DOJ and HHS both specify 2.1 AA — but building to 2.2 AA costs little extra on top of 2.1 work and future-proofs against the version either agency is likely to reference the next time its rule is revisited. Target Size and Accessible Authentication in particular are exactly the kind of criteria a native mobile app is more likely to violate than a desktop web page, given how much smaller touch targets and how much more common biometric-or-PIN login flows are on mobile.

A separate, genuine gap: WCAG's success criteria were written for web content, and applying them literally to a native app's platform-specific controls and gesture model creates real ambiguity. The W3C's own answer is WCAG2ICT, an informative Group Note mapping WCAG to non-web software generally, and more specifically WCAG2Mobile, first published as a W3C Draft Note on May 6, 2025, which works through mobile-specific interpretation questions directly. WCAG 3.0 ("Silver"), which would eventually replace 2.x with an outcomes-based Bronze/Silver/Gold scoring model, remains a W3C Working Draft with no announced date for Candidate Recommendation status — not something to plan a 2026 or 2027 compliance program around.

A web-focused accessibility audit, or an automated scanner built for web pages, misses a specific, recurring set of native-app failure modes — because native platforms don't give you free baseline semantics the way HTML does, and because several of these failures are runtime behaviors an automated tool can't observe from static analysis alone.

The common thread across all five rows: every one of them is invisible to a sighted reviewer glancing at the screen and invisible to a scanner built for web markup. Catching them requires someone actually navigating the real, compiled build with VoiceOver on iOS and TalkBack on Android — ideally including someone who uses assistive technology as their primary interface, not just as a reviewer running through a checklist. For teams building cross-platform, our React Native vs. native development comparison covers a related tradeoff: a cross-platform framework's accessibility bridge has to correctly map to each platform's native accessibility APIs, and that mapping is itself worth auditing rather than assuming.

A visible methodology note, since this article cites regulatory deadlines, lawsuit statistics, and a widely cited web-accessibility measurement: everything above was checked as of 24 September 2026, against the Federal Register, ADA.gov, HHS.gov, W3C, and EUR-Lex directly where our research tooling could retrieve them, and against clearly attributed legal-trade-press corroboration where a primary domain could not be fetched directly (noted in Limitations below). Several claims common in this space did not survive that check.

• Any specific "X% conversion lift" or ROI figure from making an app accessible: we searched specifically for a methodologically transparent source for this common marketing claim and found none — we print no number for it.
• "95.9% of apps are inaccessible," stated about mobile apps: the WebAIM Million measures the top 1,000,000 web home pages for automatically-detectable WCAG 2 failures — not native mobile apps, and not full manual conformance. We found no WebAIM-Million-scale automated study of native app accessibility to cite; that gap is itself worth naming rather than papering over with a web statistic repurposed as a mobile one.
• A specific percentage of App Store or Play Store rejections caused by accessibility issues: neither Apple nor Google publishes a rejection breakdown isolating accessibility specifically, and we found no independently audited figure — so we don't print one.
• A named, confirmed "app-only" ADA lawsuit with a large, disclosed settlement figure: the most concretely documented mobile-app-specific case we could verify (Colak v. Sweetgreen) is described in public summaries alongside the website, not as an app-only claim — we present it with that caveat rather than overstating it as a pure native-app precedent.

Three matters, spanning the controlling nexus precedent, a live 2026 enforcement fight, and one of the more concretely documented app-specific ordering-flow claims, show this isn't abstract legal theory.

The Fashion Nova matter is worth sitting with specifically: DOJ's February 2026 statement of interest objected to a settlement not because the underlying accessibility allegation was weak, but because the claims process built to remedy itwas itself inaccessible to the exact population it was meant to compensate. That is the clearest possible illustration of a theme running through this entire article — a compliance artifact (a settlement, a label, a checklist) is not the same thing as the accessible experience it claims to represent, and regulators are actively checking the difference.

Consider a regional healthcare network — a Section 504 covered entity by virtue of its HHS funding, running a patient-facing appointment and records app built years ago by a now-departed contractor, with more than 15 employees and therefore a May 11, 2027 compliance date. Nobody on the current team can say with confidence whether the app meets WCAG 2.1 AA today, because nobody has actually tested it with VoiceOver or TalkBack — only glanced at it visually. That is precisely the situation the discovery-and-audit engagement ($9k–$22k, 2–4 weeks) exists for: a real conformance review against the current build, not an assumption based on how the app looks to a sighted reviewer, that tells the network exactly how much remediation work the 2027 deadline actually requires and gives its compliance and legal teams a documented starting point rather than a guess.

This is deliberately not a projected-savings or an avoided-lawsuit-dollar-figure scenario — for the same reason we refused the unsourced conversion-lift and settlement-figure claims above. The honest arithmetic here is: one regulatory deadline, one unaudited app, one contractor no longer available to ask. Most organizations in this position can count those three facts themselves before deciding whether a paid engagement is worth it.

Ownership matters as much as the audit itself. Engineering owns building and maintaining native accessible components rather than custom-drawn ones; whoever ships a UI change owns re-testing the screens they touched with a screen reader, not just visually; product or compliance leadership owns tracking which regulatory clock (Title II, Section 504, Title III exposure, or EAA) actually applies and re-checking it against the primary source, not a vendor's summary, whenever a deadline approaches; and legal counsel owns the final call on Title III exposure specifically, since no technical conformance level substitutes for that judgment in the absence of a formal rule. A task with no named owner is the task that quietly lapses the next time the app ships an unrelated update.

Senior-led work runs $150–$225 per hour, retainers run $2,500–$9,500 per month, every engagement carries a 30-day post-launch warranty, and full source-code and IP ownership transfers to you. We return a fixed-price phased proposal within 5 business days of a discovery call. If your compliance gap traces back to an older codebase built with custom, non-native UI components throughout, our custom mobile app development guide covers what that kind of broader remediation looks like before you commit to an accessibility-specific build on top of it.

• A guarantee of zero ADA lawsuit risk: no vendor can guarantee immunity from suit, especially under Title III where no formal technical-standard regulation exists at all — a specific guarantee is overselling, not describing a real process.
• An audit that's purely an automated scan with no manual assistive-technology testing: the failure modes that actually matter in native apps — custom controls, focus order, gesture-only actions — are runtime behaviors an automated scanner built for web markup can't see.
• No named answer for which specific rule and deadline applies to your organization: "ADA compliance" said generically, instead of naming Title II, Section 504, Title III circuit exposure, or the EAA specifically, is a sign the vendor hasn't actually mapped your obligation.
• Treating WCAG conformance as a legal guarantee rather than risk mitigation: even a fully conformant, rule-covered app can fall out of conformance on the next update, and Title III has no conformance-equals-compliance regulation to point to in the first place.
• An unsourced conversion-lift, ROI, or lawsuit-avoidance percentage presented as fact: we searched specifically for a methodologically transparent source for either claim and found none — a vendor citing one confidently is repeating an unverified number.
• No plan for re-testing after every UI update, only a one-time launch audit: a screen reader focus-order regression or a new custom component with no label is exactly the kind of thing that reintroduces itself silently in a routine release.

Several primary-source domains central to this topic — federalregister.gov, ada.gov, webaim.org, and ec.europa.eu among them — could not be directly rendered by our research tooling in this environment due to network restrictions, not any indication those pages say something different from what's cited here. Where this applies, we corroborated the specific facts — both 2026 compliance-date extensions, the WebAIM Million's current figure, and the European Commission's own EAA transition provisions — across multiple independent, clearly attributed legal-trade-press or standards-adjacent sources describing the same underlying primary document, and we name that limitation here explicitly rather than presenting single-sourced or unverified claims as fully primary-confirmed. We recommend directly re-checking ADA.gov, the Federal Register, and W3C's own pages before finalizing any compliance program built on the dates in this article.

This article is not legal advice. Circuit-by-circuit Title III exposure varies in ways only counsel familiar with your specific jurisdiction and business model can assess accurately, and we deliberately did not attempt to summarize every circuit's current position — only to name that a genuine, unresolved split exists rather than implying a single national standard where none is codified. We also did not independently test any specific commercial app named in the casebook section for its current accessibility state; the cases are cited for their legal and factual history as publicly documented, not as an audit of any company's app today. Every date, dollar figure, and regulatory detail here reflects our research as of 24 September 2026 — in a topic area that saw two major federal compliance-date changes in the preceding five months alone, treat this as a snapshot to verify against the primary source before you rely on it, not a permanent reference.