How do you ship accessibility as a bar, not a backlog: a definition of done, accessible-by-default components, release gates, ownership and legal context?
Predict first
A new feature ships with 40 accessibility issues found in a final audit and a plan to fix them next quarter. What is the most useful change to the process?
// A: keep the final audit and add more testers at the end
// B: add accessibility to the definition of done, use accessible-by-default components, and gate CI on new issues
// C: stop shipping features- A
- B
- C
Mental model. Building codes put ramps in the plans from day one. Adding a ramp after the building is finished costs more and still looks like an afterthought.
The failure mode is the “accessibility sprint”: a late audit produces hundreds of issues, a few are fixed, and the next release regresses them. The fix is to make accessibility part of how the team builds. Put it in the definition of done for every feature: designs show the screen at the largest text size, in RTL, with focus order and labels; the implementation passes the audit and has been tried with VoiceOver; reviews check it. Build it into the design system: components that are accessible by default (labels required by the API, Dynamic Type, 44-point targets, contrast-checked colour tokens, Reduce Motion handling, RTL), so using the standard component is the accessible choice and feature teams do not re-solve it. Enforce with automation: audits in UI tests, lint rules for missing labels and fixed fonts, snapshot tests at large type and RTL (Q448), and a CI gate on new issues so the count only goes down.
Give it ownership and measurement: a named owner or champions network, a tracked issue count and age per release, accessibility in the release checklist (staged rollout and field feedback), and regular testing with disabled users and assistive-technology experts, because internal testers will never find everything. Provide a visible way for users to report problems and treat them as high priority. Know the context: accessibility is a legal and market requirement in many places (for example the European Accessibility Act, disability discrimination law and public-sector procurement rules such as Section 508), and WCAG at level AA is the common target; ask your legal team what applies. The App Store also lets apps describe the accessibility features they support on their product page, so claim only what you have verified. The staff-level answer is cultural: accessibility is a quality bar like crash-free rate, owned, measured and designed in, not a project that finishes.
Prevent and detect early, where fixes are cheap, rather than inspect late.
Common traps
- An end-of-project accessibility audit. It finds problems when they are most expensive and leaves nobody owning the regression.
- Claiming accessibility support that was not verified. Declared features that do not work harm users and create legal risk.
They might follow up with
- What makes the biggest difference at scale? Accessible-by-default design-system components and an automated gate in CI.
- How do you know it is working? Falling audit-issue counts per release, user feedback from people who use assistive technology, and no regressions.
Related questions
- 24.5.1 How do you test accessibility: the Accessibility Inspector, automated audits in XCUITest, identifiers versus…
- 24.1.1 How does VoiceOver read your UI: accessibility elements, labels, values, hints and traits, and how do you fix…
- 24.2.1 How does Dynamic Type work, how do you support it in UIKit and SwiftUI, and how do layouts adapt at…
- 21.3.2 How do you build a performance culture on a team: budgets, regression gates, ownership and release guardrails?
- 22.5.1 How do snapshot tests work, and what are their pitfalls: rendering differences, dynamic content, size, and…
- 22.7.2 How do you design a quality system for a large team: test tiers, ownership, coverage, flake budgets and…
← How do you test accessibility: the Accessibility Inspector, automated…