Accessibility belongs in requirements, not in the acceptance checklist

What it is

Accessibility written at the end of the acceptance checklist is opened only after the feature has already been built along the pointer path. Two moves remain: block the release, or log a debt. Accessibility in requirements means the story has testable conditions before it is accepted — this task can be finished from the keyboard, every input has a name, time limits can be turned off — rather than a tick in QA's last column. Acceptance testing still happens; it is not a substitute for the requirement.

Why it happens

Teams optimise what is specified. The requirements list decides what counts as done; the acceptance checklist decides what still scrapes through. Putting accessibility in the latter announces that it can be dropped in a scope negotiation. The second layer is that a gate only finds defects; it does not grow semantics. A tester can file “no headings,” but cannot invent a heading hierarchy inside an information structure already signed off. If defect-origin stats show almost every accessibility ticket as “found at acceptance,” it never entered the weeks when the feature was being made. Paying disabled participants only in a pre-release usability slot is the same misplacement.

Studying it

Code accessibility defects by the phase they were first found: requirements review, design review, implementation, acceptance, post-launch. Check whether the story template includes channel acceptance conditions. See whether the release gate blocks on missing features or missing accessibility, and how often the latter is waived.

Independent variables: whether the story carries its own keyboard / name / timing conditions. Dependent variables: phase of first discovery; share found at acceptance; gate waivers; iterations from discovery to fix.

A survey item that says “we value accessibility” is not evidence. Read the template and the gate log.

Where it stops holding

Writing it in still requires testing — presence on the list is not usability. Not every success criterion belongs on every story: items irrelevant to the feature (captions on a story with no video) turn the list into ritual. Regulatory audits and post-launch sampling remain; they catch drift the requirements did not cover, and they cannot become the only mechanism. A hot-fix may take a narrow gate, but the conditions must be written back into requirements in the next iteration or the hot-fix becomes permanent acceptance-ism.

Applying it

• Story templates lock three questions: can this be finished without a pointer, where does each operable control get its name, is there a time limit that cannot be turned off. No answers, no start.
• The definition of done includes the channel. Accessibility is not a last optional checkbox.
• Tests with disabled users sit in early design work, not only in the ship week.
• How to check: sample last iteration's stories and see whether accessibility conditions sit at the end of the acceptance column or inside the functional description. Sample defects for phase of first discovery. If more than four fifths come from acceptance or post-launch, change the template and compare the next iteration.

Related

• Same group: J1.09.1 Retrofitting costs far more than building accessibility in · J1.09.2 Structural problems cannot be patched later
• Nearby: J5.14 Testing with Disabled Users · J1.12 Accessibility Statements and Conformance Documentation
• Search terms: accessibility in requirements · definition of done · shift-left accessibility