Where do accessibility checks belong across design review, component acceptance, a build gate and periodic audits?

## Four placements, four different jobs Accessibility work fails in one of two ways: everything is pushed to a single gate at the end, or checks are scattered with no statement of what each one is for. The fix is to say, for each placement, both what it catches and what it **provably cannot**. | Placement | What it catches | What it provably cannot | |---|---|---| | Design review | Meaning carried by colour alone; a flow with no non-pointer equivalent; missing text alternatives; an intended reading order that fights the visual order; targets too small to hit | Anything about the artefact that actually got built | | Component acceptance | Each control exposes a name, a role and its state; the widget is operable from the keyboard; the focus point is visible | Composition — how a screen made of clean components behaves as a whole | | Automated gate in the build | Regressions on the measurable criteria, on every change, without anyone remembering to run it | Any criterion stated as equivalence, appropriateness or preserved meaning | | Periodic deeper audit | Whole-task judgement, the meaning-level criteria, real paths through the product | The weeks between two audits | ## Why each one is load-bearing **Design review.** The cheapest accessibility defect is the one that never gets built. A required step distinguished only by colour is a design decision, and it is a defect against the criterion prohibiting colour as the only visual means of conveying information (1.4.1 Use of Color, level A). So is a flow whose only path is a drag, or a diagram with no planned text alternative. Reviewing designs also fixes the ownership problem: it puts the meaning-level criteria in front of the people who can still decide them. **Component acceptance.** A shared control is the highest-leverage place to be right, because a name that is wrong once is wrong in 90 screens. This is where you pin the criterion requiring components to expose a name, a role and a value (4.1.2 Name, Role, Value, level A) and where you check the widget can be operated from the keyboard. Its limit is composition: correct components arranged badly still produce a screen with duplicated structure, an order that contradicts the layout, and content that appears with no announcement. **Automated gate in the build.** This is a **regression** device. It runs on every change without anyone remembering, it is consistent, and it protects exactly the criteria stated as measurable facts. Two rules make it usable: it must fail the change rather than warn — a gate that only warns is a report — and it must be scoped so a pre-existing failure on an untouched screen does not block unrelated work, or the team will disable it within a month. **Periodic deeper audit.** The only stage that meets a whole task the way a user meets it, and therefore the only one that reaches the criteria none of the other three can. Its cost is why it is periodic, and its being periodic is exactly why it cannot be the whole programme. ## The sequencing that actually works 1. Put the **meaning-level** questions as early as they can be asked — in the design review, where changing them costs a conversation. 2. Put the **repeatable measurable** checks as late and as often as possible — in the build, where they run for free forever. 3. Put the **per-control guarantees** at the boundary of the shared library, where one fix propagates. 4. Put the **whole-task judgement** on a cadence, and size the cadence to how fast the product changes rather than to a calendar habit. ## The failure modes to name in an interview - **One gate at the end.** Everything is found when it is most expensive, so the finding gets deferred and the gate gets a reputation for blocking releases. - **A gate with no owner for its output.** Needs-review items and pre-existing failures accumulate until the whole gate is switched to warn-only. - **Audit as substitute.** A quarterly audit with no per-change protection means every audit re-finds defects that re-entered the week after the last one. - **Component acceptance mistaken for screen coverage.** A team with a spotless component library and no whole-screen testing is the classic case of clean parts and an unusable product. ## A worked case A maintenance console for farm machinery ships a 6-step application form. Design review caught 2 defects that would have been expensive later: step 2 distinguished the required machine class using colour alone, and step 6 offered only a drag to reorder attachments. Component acceptance caught 5 controls with no accessible name in the shared library, fixing them once for 41 screens. The build gate has since blocked 3 regressions in 9 weeks, all of them measurable criteria. The quarterly audit found the thing none of them could: on the legacy screen at step 4, the whole task is completable in principle but nobody without sight can tell which of the two confirmation controls commits the application. That is a judgement about meaning, made by meeting the task end to end — which is the audit earning its cost.