Legal context without legal theater
Status: draft
When to use this guide
The project mentions ADA, the European Accessibility Act, the Web Accessibility Directive, EN 301 549 and WCAG, and the team expects one scanner report to answer all of it.
This isn't legal advice. It also isn't a list of preferences. ADA, WAD and EAA are laws. For a product team that means a flow in legal scope can't sit in the "nice to have" backlog.
The rule
Verdict: the law sets the scope and the reference standard. Product evidence proves whether the task works. Both go into the record, in separate fields.
Why: a legal reference without evidence is a claim nobody can check. Evidence without the reference doesn't tell legal what was covered.
Legal context: which market, entity or service is in scope
Standard: WCAG or EN 301 549 mapping
Native proof: VoiceOver, Larger Text, Switch Control, Voice Control
Evidence: screenshots, transcripts, audits, bugs, owners
Without native proof, the claim is weak.
Quick reference
| Law | Applies to | Technical reference | What the team does |
|---|---|---|---|
| ADA Title II | US state and local governments: services, programs, activities | 2024 rule: WCAG 2.1 Level AA for covered web content and mobile apps | Name the public service tasks, walk the app flow, keep vendor screens in scope |
| ADA Title III | US businesses open to the public | DOJ guidance says web goods and services must be accessible. No single technical rule for apps in that guidance | Don't claim "ADA compliant" without legal. Treat a blocked checkout, booking or support flow as real legal and product risk |
| Web Accessibility Directive | EU public sector websites and mobile apps | EN 301 549 v3.2.1 (harmonised) | Walk public service tasks, keep accessibility statement evidence, map findings to EN 301 549 |
| European Accessibility Act | Selected products and services on the EU market: e-commerce, banking, transport ticketing, e-books, payment terminals, smartphones and others | Requirements apply from 2025-06-28, with exceptions and transition periods | Decide whether the service is covered, walk purchase, payment, support and account flows, keep conformity evidence |
WCAG is usually the technical language. For a native iOS app it isn't the whole proof. The proof is VoiceOver, Larger Text, Switch Control, Voice Control and the keyboard on the real flow.
US: ADA
Title II covers state and local government services, programs and activities, including those offered through websites and mobile apps. The 2024 rule sets WCAG 2.1 Level AA as the technical standard. According to ADA.gov, a 2026 interim final rule extended the compliance dates to April 26, 2027 for public entities serving 50,000 or more people, and April 26, 2028 for smaller entities and special district governments. Check ADA.gov for the current dates before quoting them.
Title III covers businesses open to the public. DOJ guidance says their web goods and services need to be accessible, but doesn't give the same single technical rule for mobile apps. Write "ADA risk" or "in ADA review scope", not "our app is ADA compliant", unless legal has made that determination.
Where it reaches iOS teams:
public parking payment
public benefits or permit applications
health service booking run by or for a public entity
payment flows of a business open to the public
a support flow that's the only way to reach the service
a vendor SDK inside any of these
Questions for a US review:
1. Is this a public entity, a contractor, or a business open to the public?
2. Which tasks give access to the service or goods?
3. Which screens block equal access?
4. What evidence shows it works on iOS?
EU: two separate laws
There's no single "European ADA".
The Web Accessibility Directive covers public sector websites and mobile apps. The harmonised standard is EN 301 549 v3.2.1. The European Commission notes that it draws heavily on WCAG 2.1 but also contains requirements beyond WCAG.
The European Accessibility Act covers selected products and services, for example smartphones, e-books, ATMs, payment terminals, online shops, ticketing and banking. According to Your Europe, the requirements apply to products and services placed on the market after 28 June 2025, with exceptions.
Where it reaches iOS teams:
e-commerce checkout
banking: transfers and account management
ticket search, seat selection and payment
transport booking and status
e-book reading and purchase
support, authentication and error recovery in a covered service
Questions for an EU review:
1. Is this a public sector app?
2. Is this a covered product or service?
3. Does the flow involve e-commerce, banking, ticketing or payment?
4. Which EN 301 549 or WCAG criteria apply to the finding?
5. Which iOS walkthrough proves the task?
The evidence record
Market: EU
Rule: EAA (e-commerce service), EN 301 549
Area: checkout
Task: pay after a declined card
Profile: VoiceOver
Expected: focus on the error after Pay, the card field keeps its value
Actual: focus stays on Pay
Evidence: transcript, screenshot, device, iOS version
Decision: blocker
Owner: payments
This connects the legal context to Evidence Based Release without turning engineers into lawyers.
What changes day to day
- A PR doesn't say "accessibility checked". It names the changed task and attaches evidence.
- A vendor SDK isn't accepted on a certificate. Its task is walked on a device.
- In legal scope, a task the user can't complete is a blocker candidate, whether or not the bug "looks" serious.
- A scanner report is one artifact in the evidence, not the evidence.
- WCAG 2.2 can be the internal baseline. When the rule points to WCAG 2.1, the compliance record says 2.1.
Checking it
Start with the critical tasks:
health: book an appointment, read a result, contact support
banking: log in, review a transaction, transfer, recover from an error
payments: pay, handle a decline, change method
public sector: apply, pay a fee, check status, file a request
support: find help, send a message, reach an alternative channel
For each task, at least:
VoiceOver walkthrough
Larger Text AX5 screenshots
Switch Control or keyboard path where there are many actions
Voice Control name audit on command-heavy screens
Accessibility Inspector or XCTest audit as a guardrail
Results go into a Testing Evidence Record, the decision into Evidence Based Release.
What we don't do
- We don't write "WCAG passed" without a task.
- We don't say "the vendor owns it" while the user is stuck inside our flow.
- We don't accept a web report for native SDK behavior.
- We don't accept "AI says compliant".
- We don't claim App Store labels without walking the common tasks.
- We don't use WCAG 2.2 as a legal shortcut where the rule says 2.1.
Where it connects
Compliance Theater when the team hides behind claims. Vendor Blind Spot when third-party UI blocks the flow. Regulatory Evidence Map for structure. Compliance Ready PR while the change is still in review.
Chapters: Chapter 13, Chapter 16, Chapter 18.