“Make It Accessible” Is Not a Requirement

“The application must be accessible.”

That sentence sounds reasonable.

• Most teams would agree with it.
• Most vendors would agree with it.
• Most project plans would be comfortable including it somewhere.

But as a requirement, it does not do enough work.

• It does not tell the designer what needs to be visible.
• It does not tell the developer what behavior needs to exist.
• It does not tell QA what to test.
• It does not tell the product owner what to accept.
• It does not tell the vendor what to demonstrate.
• It does not tell a reviewer what evidence the team considered before review.

“Make it accessible” is a goal.

A useful requirement tells the team what accessible behavior needs to exist, how it will be checked, and what evidence will show it is ready.

That difference matters because vague accessibility requirements create vague accountability.

When the requirement only says “accessible,” everyone can agree in principle while still leaving the practical decisions for later.

Later is usually when the work is harder to change.

• The design is approved.
• The code exists.
• The vendor configuration is already in place.
• The release date is close.
• The review finding now feels like a surprise.

But the issue was often visible much earlier.

It just was not named clearly enough in the requirement.

What a useful accessibility requirement does

A useful accessibility requirement does not need to sound complicated or legalistic.

It needs to help the team answer a few practical questions:

• What does the user need to do?
• What could block someone from completing that task?
• What information, instruction, or feedback does the user need?
• What needs to work without a mouse?
• What needs to make sense without color, position, or visual layout alone?
• What documents, downloads, media, or vendor tools are part of the experience?
• What can the team test before review?
• What evidence would show the expectation was met?

That is the job.

A good requirement makes the important behavior visible early enough to shape design, development, QA, vendor conversations, and review readiness.

It does not replace WCAG.

It helps the team turn WCAG-related risk into something concrete enough to build and check.

A practical pattern

When an accessibility requirement feels too vague, try rewriting it with this pattern:

Users can [complete task or interaction] with [accessibility condition], so that [barrier avoided or outcome supported].

That pattern is not magic.

It is just a way to force the requirement to describe behavior instead of intention.

Examples:

• Users can complete the search form using only a keyboard, with visible focus indicators and logical tab order, so that the interaction is operable without a mouse.
• Users can identify and correct form errors, with each error tied to the relevant field and described in plain language, so that errors do not block completion without explanation.
• Users can understand status changes from text and programmatic feedback, not color alone, so that priority, success, warning, or failure states are available to more than visual scanning.

You can shorten the language later.

But first, make the expected behavior clear.

Examples: vague vs. useful

Form fields

Vague:

The form must be accessible.

More useful:

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.

Why it helps:

The stronger version gives design, development, and QA something specific to check.

It names labels, required fields, errors, text, and assistive technology instead of leaving “accessible” as a broad promise.

Keyboard behavior

Vague:

The modal must be accessible.

More useful:

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.

Why it helps:

The stronger version describes the actual interaction.

It helps the team test the behavior before review instead of waiting for someone else to discover a keyboard trap or focus problem.

Error handling

Vague:

Errors must be clear.

More useful:

Error messages identify the field or step with the problem, explain what needs to be fixed, and are available to assistive technology when the error appears.

Why it helps:

The stronger version treats errors as part of the user flow, not just red text near a field.

It also makes recovery part of the requirement.

Color and status

Vague:

Status indicators must be accessible.

More useful:

Status is communicated with text and not by color alone. If the status changes what the user should do next, the change is also available in a way assistive technology can detect.

Why it helps:

The stronger version names the risk: color-only meaning and missed status changes.

It gives the team a way to check whether the status works beyond visual scanning.

Link and button text

Vague:

Links and buttons must be accessible.

More useful:

Link and button text describes the action or destination clearly enough to make sense out of context where possible. Repeated links with different destinations have distinguishable names.

Why it helps:

The stronger version helps content, design, and development avoid generic labels like “click here,” “learn more,” or repeated buttons that sound identical to assistive technology users.

Documents and downloads

Vague:

Documents must be accessible.

More useful:

Documents required to complete the task are identified before release, checked for accessibility, and either remediated or paired with an accessible alternative before users depend on them.

Why it helps:

The stronger version brings documents into scope early. It also avoids treating PDFs, downloads, and attachments as someone else’s problem at the end.

Vendor tools

Vague:

The vendor solution must meet accessibility standards.

More useful:

The vendor demonstrates keyboard operation, screen reader-compatible labels and controls, visible focus, error handling, and any known accessibility limitations for the configured experience the team will actually use.

Why it helps:

The stronger version asks for evidence tied to the real implementation, not just a general claim.

Questions to ask earlier

If you are a BA, product owner, PM, designer, or anyone shaping the work, you do not need to become an accessibility expert to improve the requirement.

Start with questions like these:

• What is the main task the user needs to complete?
• What parts of the task involve forms, errors, documents, media, tables, custom components, or third-party tools?
• What needs to work with a keyboard?
• What needs a clear label, instruction, heading, or status message?
• What states need to be described: loading, empty, disabled, selected, expanded, collapsed, error, success?
• What could be misunderstood if someone cannot rely on layout, color, or icon shape alone?
• What should QA be able to check before formal review?
• What known limits, assumptions, or vendor claims need evidence?

Those questions do not make the requirement heavier.

They make the hidden work visible.

What not to do

A few common traps make accessibility requirements look complete while leaving the team exposed.

Do not only copy broad WCAG language into the requirement without connecting it to the feature.

WCAG references can be useful, but they should support the requirement, not replace the explanation of the behavior.

Do not treat “accessible” as a single yes/no property.

A feature may be strong in one area and weak in another.

• A form can have good labels and still have poor error recovery.
• A modal can have good visual design and still fail keyboard use.

Do not wait for review to define the expectation.

Review should validate and identify what the team missed.

It should not be the first place the team discovers what the requirement should have said.

Do not accept vendor claims without asking how they apply to your configured experience.

A product may have accessibility documentation and still create issues depending on configuration, implementation, content, or workflow.

A simple requirement check

Before a requirement moves forward, ask:

• Can someone build from this?
• Can someone test this?
• Can someone accept or reject the work based on this?
• Does it name the user task or behavior?
• Does it include the relevant states, errors, documents, or third-party pieces?
• Does it help the team prepare for review instead of waiting for review to explain the work back to them?

If the answer is no, the requirement may not need to be longer.

It needs to be clearer.

Closing

“Make it accessible” is a good intention.

But good intentions do not tell a team what to build, test, accept, or prove.

A useful accessibility requirement makes the expected behavior visible early enough for the team to act on it.

That is how requirements prevent rework.

Not by making accessibility feel more formal.

By making it harder for important decisions to hide until the end.

Previous note

Good Accessibility Requirements Prevent Rework is the shorter companion note that explains why vague accessibility requirements create avoidable rework.