Accessibility belongs in the acceptance conversation

A customer opens a dialog to change a booking. The page looks clear to the product team, but keyboard focus remains behind the dialog. The customer can neither follow the intended controls nor tell whether closing it will preserve the original reservation.

Accessibility acceptance criteria need to cover the task the person is trying to finish. Reviewing a screenshot cannot establish whether someone can enter, understand, change or safely leave an interaction.

Follow one booking change from start to finish

Use a fictional service where a customer can change the time of an existing reservation. The product team must first define the transaction: when is the new time committed, and what happens if the customer cancels? In this example, abandoning the unsubmitted change leaves the original reservation intact.

Write the acceptance evidence around that outcome. The test starts at the existing booking and ends with either a confirmed change or an explicit return to the unchanged reservation. Include validation and service errors inside that path.

This creates a more useful scope than an isolated requirement such as “the dialog is accessible.” It gives design, engineering and research a common task to observe.

Test the interaction pattern and the meaning

The W3C modal-dialog pattern describes focus moving into the dialog, keyboard focus remaining within it while open, Escape closing it, and appropriate focus placement after it closes. It also cautions that a modal declaration must match the actual interaction. This guidance informs the checks below; it is not a complete WCAG conformance assessment. W3C APG modal dialog pattern.

For this booking task, use an evidence worksheet:

The table is an original acceptance design. It does not claim that a product has passed these tests.

Record the environment as part of the result

A statement that “screen reader tested” is too vague to reproduce. Record the release, browser, operating system, assistive technology and relevant settings, alongside the steps and observed result. Use realistic task data without exposing a participant's private information.

Keyboard testing and screen-reader testing answer related but different questions. A focus sequence may be operable yet poorly described. A control may have an understandable name while its error recovery leaves the user stranded. Automated checks can find some defects, but cannot supply evidence of a person's understanding of this booking change.

Where appropriate, involve people with relevant access needs in task research. Do not infer a person's abilities from their appearance or treat one participant's success as coverage of every access need.

Examine the failure after confirmation too

A dialog can close before the service has accepted the change. If that happens, the next screen needs to distinguish a completed update from a pending or failed request. The UI state inventory can help the team define these outcomes before testing.

Check the assisted route as well. If support is the recovery option, the customer must be able to reach it and explain the affected booking without repeating an inaccessible task. The team should know which support process can verify the actual reservation.

A release decision should cite the observed task evidence, open defects and tested scope. A correct dialog pattern is a useful part of that record. The final question is whether a person can complete this booking change, understand what happened, and recover when the service refuses it.