Good Accessibility Requirements Prevent Rework

Accessibility requirements do not need to be complicated.

They need to be useful.

That sounds obvious, but a lot of accessibility rework starts with requirements that were technically agreeable and practically unclear.

Everyone nods at something like:

The application must be accessible.

No one wants to argue with that sentence.

• But it does not tell the designer what needs to appear on the screen.
• It does not tell the developer what behavior to build.
• It does not tell QA what to test.
• It does not tell the product owner what evidence would make the work acceptable.
• It does not tell a vendor what they need to demonstrate.

It expresses a goal, but it does not create enough shared understanding to reach that goal reliably.

That is where rework begins.

A team may build the happy path and assume accessibility can be checked later.

Then review finds missing labels, unclear errors, keyboard blockers, color-only indicators, inaccessible documents, or a custom component that does not expose the right name, role, or state.

None of those issues came out of nowhere.

They were hiding in the requirement.

Not because someone wrote a bad requirement on purpose.

Because the requirement did not make the accessibility decision visible early enough.

Good requirements help teams see the work before the work gets expensive.

They answer practical questions:

• What does the user need to do?
• What information does the user need before they act?
• What happens if they make a mistake?
• What happens if they cannot use a mouse?
• What happens if they cannot rely on color, layout, or visual position alone?
• What documents, downloads, or third-party pieces are part of the task?
• What does the team need to test before review?

Those questions are not extra paperwork.

They are how accessibility becomes part of the work instead of a late discovery process.

A better accessibility requirement does not need to quote every WCAG criterion.

Sometimes it should connect to WCAG, especially when the team needs a standard or evidence trail.

But the requirement itself should still describe the behavior in plain language.

For example, instead of only saying:

The form must be accessible.

A stronger requirement might say:

Each form field has a visible label programmatically associated with the input. Required fields and validation errors are communicated in text and available to assistive technology.

That gives people something to design, build, test, and review.

Instead of only saying:

The modal must be accessible.

A stronger requirement might say:

The modal can be opened, used, and dismissed with a keyboard. Focus moves into the modal when it opens, remains within the modal while it is active, and returns to the triggering control when it closes.

That is more useful than a general promise.

Instead of only saying:

Status must be clear.

A stronger requirement might say:

Status is communicated with text and not by color alone. Any status change that affects the user’s next step is announced or made available in a way assistive technology can detect.

The point is not to make every requirement long.

The point is to make the important accessibility behavior hard to miss.

Good accessibility requirements also help with accountability.

When a requirement is vague, accessibility becomes easy to pass around.

• Design assumes development will handle it.
• Development assumes QA will catch it.
• QA assumes review will identify it.
• Review sends it back when the fix is more disruptive.

Clear requirements make ownership easier to see.

• A label belongs in design and content.
• Programmatic association belongs in implementation.
• Error recovery belongs in requirements, design, content, development, and QA.
• Keyboard behavior belongs in interaction design, component behavior, development, and testing.
• Documents and vendor tools belong in scope conversations before they become surprises.

Accessibility is shared work, but shared work still needs clear handoffs.

That is what good requirements provide.

They do not guarantee the work will be perfect.

They do reduce the chance that the team reaches review and discovers that nobody ever defined what accessible meant for this feature.

If you are writing requirements, do not start with the broadest possible sentence and hope the details appear later.

Start with the user task.

Then ask where the task could break for someone using a keyboard, screen reader, zoom, captions, clear language, predictable structure, or non-visual cues.

Write down the parts that matter.

That one habit can prevent a surprising amount of rework.

Not because the requirement became more formal.

Because the team became more specific about what people need in order to use the thing being built.

Previous note

Start with the Path, Not the Checklist sets up the path-first framing this note applies to requirements and acceptance criteria.