Accessibility Acceptance Criteria That a Product Team Can Actually Test

An acceptance criterion such as “the feature is accessible” has the reassuring sound of a requirement and the practical value of a shrug.

It does not say which people or tasks matter, which barriers the change may create, what anyone should test, or what evidence would justify release.

Copying “WCAG 2.2 AA” into every ticket is not much better. WCAG defines testable requirements for web content. It does not turn a feature brief into a test plan.

The useful question is narrower: for this change, which barriers are plausible, which WCAG success criteria are relevant, and what evidence would expose a failure?

That turns accessibility from a ceremonial line in the Definition of Done into ordinary product work.

Start with the task, not the checklist

Accessibility acceptance begins with a person trying to complete something under real constraints. The ticket describes the change; the criteria must protect the task.

Write one sentence before opening WCAG:

A person who uses [interaction or adaptation] can [complete the task] and understand [the result or error] without [the likely barrier].

“A keyboard user can invite a colleague and recover from an invalid email without losing context” is useful. “The modal meets WCAG” is not.

The first statement gives the team a task, an interaction mode, a failure state and an outcome. It also leaves room to find more than one implementation.

This is the same discipline behind inclusive design: understand exclusion before discussing interface polish.

Do not write one imagined “disabled user”. Consider different ways the task may be approached:

• keyboard without a pointer;
• screen reader with speech or braille output;
• magnification and a small effective viewport;
• voice control or switch input;
• increased text spacing or browser zoom;
• reduced concentration, memory or dexterity.

You will not test every combination on every ticket. You should still know which combinations the change can disturb.

Name the new failure surface

Take the proposed interaction apart. What appears, disappears, moves, updates or becomes required because of this change?

A short change-impact scan is usually enough:

1. What can receive focus?
2. What changes without a page load?
3. What information is conveyed by position, shape, colour or sound?
4. What errors can occur?
5. What happens at narrow width or high zoom?
6. What new time limit, gesture or drag action exists?

This is not an audit of the whole product. It is a search for barriers introduced or exposed by the work in hand.

An old defect may appear during the scan. Record it honestly. Decide whether it blocks this release, belongs in the same change, or needs a separate owner and date.

Map barriers to relevant WCAG criteria

Only now should the team use the WCAG 2.2 quick reference. Filter it by the interaction and likely barriers.

A success criterion is not the acceptance test. It is the stable requirement that the test is intended to examine.

For example, “2.1.1 Keyboard” does not tell a tester which controls exist, the order in which to reach them, or what completing the task looks like.

Keep a traceable chain:

user task → plausible barrier → WCAG criterion → observable product behaviour → test evidence

Traceability prevents two common mistakes. One is testing favourite tools rather than the change. The other is claiming broad conformance from a narrow check.

The W3C describes WCAG success criteria as testable statements. Its supporting techniques are informative ways to meet them, not mandatory implementations.

That distinction matters. A ticket should protect the outcome without needlessly prescribing the code.

Worked change: invite a project member

Consider a hypothetical B2B product. A team is replacing an inline invite form with a dialog containing an email field, a role selector, Cancel and Send invite.

After submission, the dialog closes and a confirmation appears. An invalid address produces an inline error. The role selector opens a custom listbox.

The product need is legitimate: administrators want to add someone without leaving the project. The interaction also creates a concentrated set of risks.

The team identifies these relevant areas:

• structure, labels and relationships;
• keyboard operation and focus movement;
• visible and unobscured focus;
• error identification and recovery;
• control name, role, value and state;
• announcement of the successful update;
• reflow when the viewport is narrow.

Those areas point to WCAG 2.2 criteria including 1.3.1, 1.4.10, 2.1.1, 2.1.2, 2.4.3, 2.4.7, 2.4.11, 3.3.1, 3.3.2, 4.1.2 and 4.1.3.

That is a starting map, not a claim that no other criterion applies.

Turn the map into acceptance criteria

The team writes criteria around observable behaviour:

Entry and exit

• Opening this simple dialog moves focus to the email field and exposes the dialog’s accessible name.
• Tab and Shift+Tab reach every interactive control in a logical order.
• No keyboard action traps focus in the role selector or dialog.
• Escape closes an unchanged dialog. After an edit, it opens the product’s discard-confirmation step. Closing returns focus to the control that opened it.

Meaning and state

• The email field and role control expose a programmatic name.
• The role control exposes its role, current value, expanded state and available options to assistive technology.
• Required status is conveyed in text and programmatically, not by colour alone.
• Instructions remain available while the person enters data.

Errors and completion

• Invalid submission identifies the affected field and explains how to correct it.
• Focus moves only when that move helps the person find or understand the error.
• On success, the new member appears in the list and the confirmation is announced without forcing focus to it.
• A failed request preserves the entered email and selected role unless doing so would create a security risk.

Zoom and layout

• At the agreed reflow test width, content is readable without two-dimensional scrolling except for content that genuinely requires it.
• Focused controls are not fully hidden by sticky headers, footers or the on-screen keyboard.
• Enlarged text does not overlap labels, actions or errors.

These criteria are change-specific. A longer, descriptive dialog may need initial focus on a heading or static element. That would be a separate, explicit choice to test.

Decide what evidence is enough

Evidence should be layered because each method catches a different class of defect.

Automated checks

Run component tests and an accessibility rules engine against the closed dialog, open dialog, validation error and success state.

Automation is good at finding some missing names, invalid relationships, contrast failures and markup errors. It cannot establish that the interaction makes sense.

The W3C guidance on selecting evaluation tools is explicit that tools assist evaluation; they do not determine accessibility on their own.

Keyboard checks

Complete the task without a pointer. Record the focus sequence, how the listbox operates, whether focus is visible and where focus lands after every exit.

Do this in the rendered product, not only in an isolated component. Sticky navigation, embedded widgets and page-level shortcuts can change the result.

Assistive-technology checks

Use the combinations supported by the product’s test policy. For this change, listen for the dialog name, field labels, role state, error association and success message.

One screen reader and browser combination is evidence for that combination. It is not proof that every assistive technology behaves identically.

Visual and responsive checks

Inspect browser zoom, text spacing and the agreed narrow viewport. Check opening, error and success states, not only the pristine default.

Evidence can be compact: test name, environment, state, expected behaviour, observed result, defect link and tester. A screenshot alone rarely captures reading or focus order.

Put the work in the delivery path

Accessibility criteria fail when they arrive at the end as a specialist inspection. They become cheaper when product, design, engineering and quality shape them together.

During refinement, agree the task and likely barriers. During design handoff, include names, states, focus behaviour, errors and responsive intent.

During implementation, test semantic structure and interaction before visual polish hides awkward foundations. During review, attach evidence to the ticket.

During release, distinguish three statements:

• this change passed its defined acceptance checks;
• known accessibility defects remain elsewhere;
• the product has or has not undergone a broader conformance evaluation.

Never turn the first statement into the third.

Keep the residual limitation visible

In the invite example, suppose the custom role selector works with the tested keyboard and screen-reader combination, but voice-control testing is not available in the sprint.

The honest release note is not “accessible”. It records the untested interaction, why it matters, who owns the follow-up and when the result will be reviewed.

The team might also replace the custom listbox with a native select. That can reduce interaction risk, but it is still a product decision to test, not a magical exemption.

Known limits need a decision rule. A serious barrier to the core task should block release. A bounded evidence gap may be accepted by a named owner with a short review date.

The severity depends on harm and exclusion, not merely on how difficult the defect is to code.

A compact ticket pattern

Use this pattern when the change is small enough for ticket-level acceptance:

1. Task: what a person needs to complete.
2. Change surface: new controls, states, content and movement.
3. Likely barriers: who may be excluded and how.
4. Relevant WCAG: success criteria that anchor the requirement.
5. Observable behaviour: what the product must do.
6. Evidence: automated, keyboard, assistive-technology and visual checks.
7. Known limits: untested combinations and existing defects.
8. Decision: pass, block, narrow the scope or accept a bounded risk.

The pattern complements usability work rather than replacing it. A feature can satisfy a technical criterion and still confuse people in a usability study.

Likewise, a participant completing a task once does not show that the implementation satisfies all relevant accessibility requirements.

Good accessibility acceptance is neither a giant checklist nor a promise of perfection. It is a precise account of the barrier the team intends to prevent and the evidence it will inspect.

That is enough to make the requirement discussable in backlog refinement, testable before release and honest afterwards.

Sources

• W3C Web Content Accessibility Guidelines overview
• W3C How to Meet WCAG 2.2 quick reference
• GOV.UK Service Standard, point 5: Make sure everyone can use the service
• W3C Selecting Web Accessibility Evaluation Tools

Read next

• A Practical Guide to Inclusive Design
• Best Practices in Design Handoffs
• How Great Teams Approach Usability Studies
• Lessons Learned in Backlog Refinement