What must an accessibility line in a Definition of Done say to be able to fail?

## Why most accessibility acceptance lines are decorative Almost every team has a line in its Definition of Done that mentions accessibility, and almost none of those lines has ever blocked a story. The reason is structural, not cultural: the line is written as an **aspiration** rather than as a **check**. "The feature is accessible to all users" cannot fail, because nobody can say what evidence would falsify it. So it gets ticked, and the tick becomes the team's evidence. A line that can fail has three parts: 1. **A check** — something a named person actually performs, or a gate that actually runs. 2. **A scope** — what the check applies to, bounded to this change rather than the whole product. 3. **A result** — the observable outcome that counts as failing. Drop any one and the line reverts to decoration. Drop the scope in particular and you get the opposite failure: an unpassable line, because it demands the whole product conform before this story can close. ## Turning aspiration into acceptance | Aspirational line | Why it cannot fail | Checkable replacement | |---|---|---| | "The feature is accessible" | Names no check, no scope, no result | "The task this change touches completes end to end with no pointing device" | | "We considered accessibility" | Consideration leaves no artefact | "A manual pass over the changed task is recorded with its findings" | | "No accessibility violations" | Names no check that produces violations | "The automated rule check in the build reports no new violations on the changed surface" | | "Follows the standard" | The standard has dozens of applicable criteria | "Every new or changed control announces a name matching its visible label" | | "Works with assistive technology" | Friendliness is not observable | "One assistive-technology pass over the changed task, findings logged with the step" | Notice what the right-hand column has in common: each entry produces a **result somebody can point at** — a completed task, a recorded pass, a gate outcome, a logged finding. ## What to include, and what to leave out Include: - The **keyboard-only completion** of the task the change touches. It is the highest-yield single line, it needs no extra software, and it maps onto the criterion requiring functionality to be operable from a keyboard (2.1.1 Keyboard, level A). - The **accessible name** of every new or changed control, checked against its visible label. This is where the naming criterion (4.1.2 Name, Role, Value, level A) is actually enforced, one control at a time. - The **automated gate result**, scoped to the changed surface so unrelated pre-existing failures do not block the story. - A rule for **needs-review** output: an owner and a recorded decision, never a bulk close. - A **manual pass** whose findings are logged even when they are not fixed in this story. Leave out: - Any wording that asks a story to establish product-wide conformance. - Any criterion the team has no way to evaluate — a line you cannot run is worse than no line, because it teaches everyone that the list is theatre. - Counts as targets. "Fewer than 5 violations" rewards suppressing findings rather than fixing them. ## The exception clause, and why it is not a loophole The fastest way to kill an accessibility line is to make it unpassable. A maintenance console for farm machinery has a 6-step application form, and step 4 is a legacy screen nobody is willing to touch. If the Definition of Done says the whole task must pass keyboard-only, then every story in that area fails on somebody else's defect, and within two iterations the line is suspended "temporarily". So write the exception into the line itself: *a pre-existing failure on a screen this change does not touch is recorded against that screen with a severity and an owner, and does not block this story.* That keeps three properties at once — the story can close, the defect stays visible, and the team accumulates a real list rather than a suspended rule. ## How it holds up over time - **Review the line against real failures.** If it has never failed a story in 6 months, either the team is exceptional or the line is decorative. Find out which by testing a story you already know is defective. - **Keep it short.** Five entries somebody performs beat twenty nobody reads. - **Name the owner of each entry.** An entry with no owner is performed by nobody in the week the release is late. - **Do not let the automated entry crowd out the manual one.** A gate result is easy to point at, which is exactly why it drifts into being the only entry anyone checks — and it covers only the measurable criteria.