Before sign-off, ask for a complete task
A supplier shows you a polished booking screen. It looks ready. Before signing it off, ask for a second demonstration: complete the same booking without a mouse, correct an invalid entry, and find out whether the request was saved without relying on a brief visual notification.
For a business buying a web application, this is a useful starting question: what should a developer demonstrate before you accept an important workflow's accessibility? Start with a named journey, agreed expected behavior, recorded test conditions and someone responsible for unresolved findings.
The checklist below covers keyboard operation, form labels and status messages. It is a bounded acceptance aid, not a complete accessibility audit, WCAG conformance assessment or legal determination. Passing these checks does not certify an application.
Define the journey and the evidence
Choose a task that matters to your users: request an appointment, edit an order or submit an expense. Write down its starting point, necessary inputs and final observable result. Include a recoverable mistake rather than demonstrating only the happy path.
For a first acceptance session, keep the journey small enough to follow from beginning to end. A fictional appointment request might involve choosing a service, entering contact details, selecting a date, reviewing the request and submitting it. Authentication, payment or document steps need their own agreed coverage when they are part of the real workflow.
Before the demonstration, agree:
- Which candidate revision and complete journey are being checked.
- Who performs the checks and which browser, operating system and assistive-technology combinations they use.
- What result is expected at each step, including an invalid entry and recovery.
- Which findings block acceptance, who corrects them and who verifies the correction.
Record observations rather than assuming that a feature exists because the interface looks finished. Use synthetic information, not real customer records.
1. Keyboard access: complete the journey without a mouse
WCAG 2.2 Success Criterion 2.1.1, Keyboard, requires functionality to be operable through a keyboard interface without specific timing for individual keystrokes. Its exception concerns underlying functions that depend on the path of movement rather than just the endpoints.[1]
For the appointment journey, ask the developer to demonstrate all required actions without switching to the mouse. Follow the date picker, service selector, review controls and final action—not just the first text field. If a custom control has keyboard instructions, include them in the demonstration.
The important result is access to the functionality. This criterion does not require every visible pointer-operated control to be individually focusable if an equivalent keyboard route provides the same or comparable action.[1] Record which route was used and whether a user can reasonably find it.
A useful finding says, 'The date picker opens, but no date can be selected using the documented keyboard controls.' 'Keyboard support needs improvement' is much harder to reproduce.
As additional acceptance checks, ask whether the current focus is visible, whether its order is understandable and whether a user can leave an opened widget. These questions go beyond the single Keyboard criterion cited here; they are not a complete list of keyboard-related requirements.
2. Form labels: explain what to enter
WCAG 2.2 Success Criterion 3.3.2, Labels or Instructions, requires labels or instructions when content requires user input. It applies to optional as well as required fields. W3C distinguishes this guidance from separate requirements for programmatic association and accessible names.[2]
Write the field requirements in everyday terms before discussing implementation. Does 'Appointment date' mean the visitor's preferred date or a confirmed booking? Which contact method is needed? Is a reference number optional? If a particular format is necessary, explain it where the person needs it. Avoid an instruction so long that the essential rule disappears inside it.
Ask to see the form with realistic synthetic values. Check that the field's purpose remains understandable after text has been entered. Then request a separate assistive-technology demonstration of how the control is identified.
Keep those observations separate. A visible label alone is not proof of correct programmatic association; an accessible name exposed only to assistive technology is not proof that instructions are adequately presented to all users.[2] 'Labels pass' hides which of these questions was actually checked.
3. Status messages: discover what happened
WCAG 2.2 Success Criterion 4.1.3, Status Messages, addresses qualifying status updates in markup-based content that can be presented by assistive technologies without receiving focus. Its defined scope excludes changes of context, such as a dialog receiving focus or a page navigation.[3]
In the fictional appointment journey, consider an inline message saying 'Request saved for review.' If the page adds that message without moving focus or changing context, ask the developer to demonstrate how it is exposed to a screen reader. Include a waiting state and an unsuccessful attempt where those are part of the design. Record the actual announcement, not simply the presence of an ARIA attribute.
Do not demand that every update interrupt the user or that every message receive focus. W3C frames this criterion around awareness of important changes without unnecessary interruption; it does not require authors to invent new status messages for every content change.[3]
Accessibility and operational truth are separate checks. A clearly announced 'Booking confirmed' is still misleading if the system has only saved a request. Agree the underlying business states before approving the message.
Accessibility acceptance worksheet
This original worksheet is a proposed review aid, not an executed test report or a complete WCAG checklist. Replace the fictional appointment journey and agree the expected results for your own application before testing.
| Check | Demonstration and expected result to agree | Evidence to retain |
|---|---|---|
| Complete journey | Start a request, review it and reach its final state using only the keyboard | Steps, keyboard route, controls used and any point that prevented progress |
| Custom selector | Choose and change a date with the agreed keyboard route | Instructions, observed behavior and exact reproduction steps for a failure |
| Field meaning | Identify purpose, required status and any necessary format before entry | Field text and instructions in the tested revision |
| Accessible identification | Use the same fields with the agreed assistive technology | Control name and relevant announced context |
| Waiting state | Trigger an agreed synthetic pending scenario and discover its state | Visible message and observed announcement, where applicable |
| Result | Complete the request and discover its actual recorded state | Result text, observed announcement and evidence for the underlying state |
| Correction | Enter an invalid synthetic value, identify the problem and correct it | Error behavior, recovery steps and whether the journey can continue |
For every row, record the candidate revision, test date, browser, operating system, assistive technology and versions where used, tester, expected result, observed result, remaining finding, correction owner and retest outcome. Use 'not run' where no observation exists. Keep these distinctions visible rather than treating an untested row as a pass.
A recording or screenshot may help explain a finding, but it should not expose real customer data. A screenshot alone also cannot demonstrate a keyboard sequence or what a screen reader announced; retain evidence appropriate to the check.
Close findings before accepting the work
Agree which journeys and accessibility requirements are in scope, what blocks acceptance, and who checks a correction. A changed shared control is a reason to consider other journeys that use it, not just the screen where the first problem appeared.
For example, if the date picker prevents keyboard completion, retain the reproduction steps, assign the correction and repeat the affected journey on the corrected revision. Do not close the finding merely because a code change was made. This is a proposed acceptance process, not a report of a test we performed.
If you need a broader conformance assessment or a legal determination, commission that scope explicitly with appropriately qualified help. The three cited criteria do not cover the full accessibility of a web application.
To define the journey before commissioning work, use Before you build an internal tool. If it ends with an inquiry, distinguish the delivery states in Why a contact form can look successful without delivering an inquiry.
Bring one journey to the project discussion
For a web or application project discussion, prepare one important journey, its users, known barriers and the evidence you want before sign-off. The CodeDrawn Digital project brief can help you request an email draft. It does not confirm that an email app opened, that a message was sent or that an inquiry was received. Scope, specialist assessment and delivery commitments need a separate discussion.
Scope and source notes
All examples are fictional planning examples. No application, keyboard journey, screen reader, accessibility scanner, booking backend or email delivery was tested for this article. The worksheet is an original planning aid. No conformance certification, legal compliance, client result or ranking outcome is claimed.
W3C Web Accessibility Initiative publishes the three Understanding pages below. They were retrieved successfully over HTTPS on 29 October 2026. These are informative explanations of WCAG criteria, not a substitute for the complete standard. The keyboard explanation preserves the path-dependent-function exception; labels and instructions remain distinct from programmatic relationships and accessible names; status messages remain distinct from changes of context. External guidance is paraphrased; no third-party code, images or datasets are reproduced.
Sources
[1] https:
[2] https:
[3] https: