chapter Status: draft

18. Release checklist

Status: draft

Chapter goal

The release decision for accessibility is made on evidence: which critical tasks were walked through, with which profiles, what failed, who accepted the remaining risk. Not on a dashboard color and not on "QA said it's fine". This chapter is the checklist for the last three days before release.

The situation

Release in three days. QA has five open accessibility bugs. The App Store Accessibility Nutrition Labels may need an update because checkout changed. The team needs a decision per bug: block, ship with a fix date, or ship.

One page accessibility release checklist — The checklist on one page.

Constraints

A blocked critical task blocks the release. "Ship and monitor" is not an option for a task the user can't complete.
For legally covered flows, the default for a failure is block. ADA Title II, the Web Accessibility Directive and the European Accessibility Act apply to the service, not to the release schedule.
"Compliant" is never written for the whole app. Only for a scope: market, rule, tasks, profiles, evidence.

The checklist

1. Critical flows listed (login, checkout, payment, account recovery, support, ...)
2. Each flow walked through on a device with:
   [ ] VoiceOver   [ ] Larger Text AX5   [ ] Switch Control or Voice Control
   [ ] Full Keyboard Access (iPad)       [ ] Captions (if media)
3. performAccessibilityAudit() passing in CI, exceptions reviewed
4. Every open bug has: blocked task, severity, owner, decision
5. App Store labels re-checked against the changed flows
6. Legal scope: flows in scope listed, each with evidence
7. Vendor screens in critical flows included in the walkthrough
8. Localization: longest language and RTL checked on forms and checkout
9. Support briefed on known gaps and their workarounds

Each line has a name next to it. A checklist without owners doesn't get done.

Decision 1: Every critical flow has an evidence record

Verdict: one record per flow per profile. Pass or fail, with evidence attached.

Flow:      checkout, declined card recovery
Build:     4.12.0 (4120)
Device:    iPhone 15, iOS 26.1
Profile:   VoiceOver
Result:    pass
Evidence:  transcript.txt, caption-panel.png
Tester:    Payments QA
Date:      2026-11-10

Why: "tested" without a record can't be checked, repeated or compared with the next release. The record is also what the App Store labels and legal statements are based on.

Format: Testing Evidence Record.

Decision 2: The ship decision follows severity

Verdict: severity from Chapter 16. The decision follows from it, and nobody negotiates it down without a written reason.

Severity	Decision	Condition
Blocker	Don't ship	None. Fix or remove the feature from the release
High	Ship only with a fix date	Owner and date in the record, support briefed
Medium	Ship	Ticket in the next sprint
Low	Ship	Backlog

Issue:     Pay button read as "button"
Flow:      checkout
Impact:    VoiceOver user can't confirm payment
Business:  lost orders, support contacts
Severity:  blocker
Decision:  don't ship
Owner:     Payments UI

Ship decision matrix for accessibility issues — The ship decision by user impact.

Why name the business impact: "VoiceOver bug" gets minimized in a release meeting. "Users can't pay" doesn't. Both statements describe the same bug.

Decision 3: App Store labels are re-checked when flows change

Verdict: if a release changes a common task, every label that the task supported is re-checked before submission.

Label:            VoiceOver
Common tasks:     first launch, login, search, purchase, order history, settings
Changed in 4.12:  purchase (new address sheet)
Re-checked:       purchase with VoiceOver, pass (modal focus returns)
Status:           keep label

Why: labels are claimed once and then forgotten. A redesign can break the task behind a label without anyone noticing (App Store Label Drift). A user who chose the app because of the label finds out first.

Decision 4: Legal readiness is written per scope

Verdict: a legal readiness statement names market, rule, tasks, profiles, evidence and decision. Never "the app is compliant".

Market:    EU
Rule:      European Accessibility Act (EN 301 549)
Area:      ticket purchase
Tasks:     search event, choose seat, pay, recover from error, contact support
Profiles:  VoiceOver, Larger Text AX5, Voice Control
Evidence:  records EV-201..EV-215, CI audit
Decision:  ship, no blockers

When a covered task fails:

Rule:       ADA Title II
Flow:       public benefits application
Failure:    VoiceOver user can't submit after a validation error
Alternate:  none
Decision:   don't ship
Owner:      benefits team

An accessible alternate path (phone support, a web form) is recorded if there is one. It can reduce the harm while the fix is made. It doesn't make the failure acceptable, and for covered services it often doesn't satisfy the requirement.

Details: Regulatory Evidence Map, Legal context without legal theater.

Decision 5: After release, feedback goes back in

Verdict: for two weeks after release, support tickets, App Store reviews and drop-off data on critical flows are checked for accessibility signals.

Signals: "can't find", "doesn't work with my settings", "text cut off", "can't tap", a drop in conversion on a step with a changed UI. Each one is triaged with the same severity scale.

Post release accessibility feedback loop — Support, reviews, analytics, bugs, design system, next release.

Release smells

If the release relies on	It's
A scanner score without walkthroughs	Scanner Theater
An AI summary without checks	AI Verification Theater
Legal claims without task evidence	Compliance Theater
Testing only the app's own screens	Vendor Blind Spot
Labels claimed last year	App Store Label Drift

Where AI fits

Summarizing the open bugs for the release meeting:

Group these accessibility bugs into blocker, high, medium, low by the
blocked task. For each, name the affected App Store label and legal scope.
List flows that have no evidence record yet.

The summary helps the meeting. The decision is made by people, against the evidence records.

What we don't do

We don't ship a known blocker with "monitor after release".
We don't write "compliant" without a scope.
We don't keep App Store labels that weren't re-checked after the task changed.

Platform notes

The checklist covers everything the task passes through: SwiftUI, legacy UIKit, AppKit, Catalyst, web views and vendor SDKs.

Scanner Theater: tools replace tasks.
AI Verification Theater: AI replaces checks.
App Store Label Drift: label claims without evidence.
Compliance Theater: legal claims without evidence.
Vendor Blind Spot: vendor screens missing from the release check.
Testing Evidence Record: the record format.
Regulatory Evidence Map: legal scope plus native evidence.
Evidence Based Release: from evidence to decision.
Business case for accessibility: framing for leadership.

Chapter takeaway

Evidence record per critical flow, decision by severity, labels re-checked when tasks change, legal readiness written per scope. A blocked critical task blocks the release.