smell Status: ready

Compliance Theater

Status: ready

Symptom

The team writes "ADA ready", "EAA ready" or "WCAG passed" and can't show a single critical task completed with VoiceOver, Larger Text, Switch Control or Voice Control.

Accessibility compliance:  done
Evidence:                  scanner report
User task:                 not recorded

That's not compliance. That's a label on a box nobody opened.

Where it shows up

Vendor reports, release decks, procurement answers, App Store label review, public sector projects, banking, health, insurance, ticketing, e-commerce, support flows.

Regulatory brief

This isn't only about best practice.

ADA Title II (US):
  state and local government web content and mobile apps
  technical standard in the 2024 rule: WCAG 2.1 Level AA

Web Accessibility Directive (EU):
  public sector websites and mobile apps
  harmonised standard: EN 301 549 v3.2.1

European Accessibility Act (EU):
  selected products and services on the EU market, including
  e-commerce, banking, transport ticketing, e-books
  applies from 2025-06-28, with exceptions and transition periods

Not every PR needs a legal memo. But if the product is in scope, accessibility evidence is release material, not polish. Details: Legal context without legal theater.

Why it blocks the task

The law sets the bar. It doesn't make the UI usable. A native iOS app needs native answers:

Can a user finish the task?
Can assistive technology reach every control in it?
Does the spoken output explain the state?
Does AX5 keep the primary action on screen?
Is there a recovery path when something fails?

Without those answers, compliance wording hides the risk instead of reducing it.

Root cause

A legal phrase replaced product evidence.
A WCAG table replaced a walkthrough on iOS.
A scanner pass became "proof".
A vendor report was accepted without replaying our tasks.
Nobody wrote down which rule, which market and which part of the product are in scope.

Before

Claim:           WCAG compliant
Scope:           whole app
Task:            —
Assistive tech:  —
Evidence:        PDF report
Decision:        ship

Fix

Verdict: a claim names its scope: market, rule, task, profile, evidence. Never "the app is compliant".

Why: a scoped claim can be checked and repeated next release. "Compliant" can't be checked at all.

Scope:      public parking payment
Market:     US, public sector
Rule:       ADA Title II, WCAG 2.1 AA
Task:       pay a parking ticket
Profile:    VoiceOver
Result:     pass
Evidence:   transcript, screenshot, device, iOS version
Owner:      payments team

In a bug:

Rule:       Web Accessibility Directive, EN 301 549
Service:    public sector appointment booking
Failure:    VoiceOver user can't choose a time slot
Decision:   release blocker until fixed or an accessible alternative exists

That's the level of detail a product team can keep up without pretending to be legal counsel.

Four layers, kept separate:

Rule:       ADA Title II, EAA, WAD, EN 301 549, WCAG
Product:    user tasks
Platform:   VoiceOver, Larger Text, Switch Control, Voice Control
Evidence:   walkthroughs, audits, screenshots, bug links

When they're mixed, the team argues about words. When they're separate, it's clear what to check.

Check

Profile:   compliance review
Task:      verify a release claim
Expected:  the rule and the market are named
           the critical tasks are listed
           each task has evidence per profile
           each failure has an owner and a decision

WCAG mapping

Use WCAG 2.1 where the legal context points to it. WCAG 2.2 works as an internal reference. A filled WCAG table doesn't prove that a native app works.

Common anchors: 1.4.3 Contrast (Minimum), 1.4.4 Resize Text, 2.1.1 Keyboard, 2.4.3 Focus Order, 3.3.1 Error Identification, 4.1.2 Name, Role, Value.

App Store and product risk

Accessibility Nutrition Labels aren't ADA, EAA or WAD compliance. They're product claims. Treat them as evidence of task support, not as a legal shield.