Accessibility Acceptance Criteria in User Stories: Making A11y Shippable in Agile Teams

Why accessibility dies in the backlog

Most teams do not oppose accessibility. They postpone it. The pattern is familiar: an audit produces a spreadsheet of violations, the spreadsheet becomes a backlog epic, and the epic sits untouched while feature work ships every sprint. Accessibility becomes something the team will get to after the roadmap, which means never, because the roadmap never ends.

The root cause is structural. Backlog epics compete with features for sprint capacity, and features have owners, revenue projections, and deadlines. Accessibility has a spreadsheet. The fix is to stop treating accessibility as a separate workstream and start treating it as part of done. That happens in exactly one place: the acceptance criteria of ordinary user stories.

What good acceptance criteria look like

Bad accessibility criteria are vague: "must be accessible" or "follow WCAG." Nobody knows what done means, so nothing is verifiable, so it gets skipped. Good criteria are specific, testable, and scoped to the story. For a story adding a modal dialog, the criteria might read: focus moves into the dialog on open and returns to the trigger on close; the dialog is fully operable by keyboard including Escape to close; screen readers announce the dialog title on open; background content is hidden from assistive technology while the dialog is open.

Notice what these have in common. Each one names a behavior, not a standard. Each is verifiable by a developer or QA engineer without specialized training. And each is scoped to what the story built, which means the work is proportional. The team is not being asked to fix the whole site. They are being asked to ship this dialog correctly.

Building the criteria library

Writing fresh criteria for every story is unsustainable, so build a library of reusable criteria blocks organized by component type. Forms get one block: labels, error association, required-field indication, error summary behavior. Data tables get another: header association, caption or summary, sortable-column announcements. Navigation, modals, carousels, accordions, tabs, each gets a block that product managers can paste into stories.

The library compounds. The first month is slow, because every story needs new criteria written. By the third month, most stories reuse existing blocks, and the marginal cost of accessible acceptance criteria approaches zero. The team is not doing extra work anymore. They are doing the same work with better definitions of done.

Making it stick in the process

Criteria only work if the process enforces them. Three integration points matter. First, story refinement: the team reviews accessibility criteria alongside functional criteria, and a story without applicable criteria gets them added before it enters the sprint. Second, definition of done: the team's shared checklist includes the accessibility criteria, so a story is not done when the code works, it is done when the criteria pass. Third, QA: testers verify the criteria the same way they verify functional behavior, not as a separate accessibility pass.

The definition of done is the load-bearing piece. As long as accessibility is a separate checklist reviewed separately, it will be skipped under pressure. When it is part of done, skipping it means the story is not done, which the process already knows how to handle. You are not adding a new gate. You are widening the existing one.

Measuring the shift

The metric that matters is violations per release, trending down. Audit each release with the same automated scan plus a rotating manual check, and track the count. Early on the number drops fast as the easy component-level issues disappear. Later it plateaus at the hard stuff: complex interactions, third-party widgets, legacy pages. That plateau is fine. It means the sprint process is holding the line and the remaining work is genuinely backlog-shaped.

Also track where violations originate. If most new violations come from a specific team or component type, the criteria library has a gap. Fill it. The acceptance-criteria approach is a feedback loop: the criteria prevent the violations you foresaw, and the violations you did not foresee become new criteria. Run the loop for a year and accessibility stops being a project. It is just how the team ships.