TL;DR
A booking form can work for a person tapping straight through it and still break when they switch to speech input, need spoken feedback or ask someone to help. Test those transitions deliberately. Record what the person had already chosen, what changes during assistance and who authorizes the final submission.
Choose the interaction to test
Begin with a booking path that already reaches the correct office. This review asks a narrower question: can someone continue that same task when the way they interact changes?
W3C’s input-modalities guidance recognizes that people may switch between touch, keyboard and speech input. Use that as the starting point for a proposed acceptance exercise with your accessibility reviewer. It is not evidence that the current scheduler supports those interactions.
Agree on a test device, browser and assistive technology where applicable. Use synthetic contact details and an approved test calendar or request destination. Record the intended office, service, outcome and initial selections before introducing a change. Arrange cleanup of any test submission in advance.
Use a before-and-after worksheet
Ask the tester to pause at the stated point, make the transition and explain what remains understandable and operable.
| Starting point and change | Acceptance evidence to collect | Owner to involve |
|---|---|---|
| Office chosen by touch; continue using speech input | The tester can identify and activate the next control using its visible label; the office choice remains clear | Accessibility reviewer and form developer |
| Partly completed form; correct an error with a screen reader | The affected field and correction are understandable; valid entries are still available where the process requires them | Form developer |
| Person asks a helper to type | The chosen service, office and contact destination can be reviewed without giving the helper unrelated access | Practice operations and privacy reviewer |
| Helper finishes typing; the person resumes control | Both can distinguish editing from submission; the person can review or correct the summary before authorizing the next step | Practice operations and tester |
| Submission finishes while the person relies on spoken feedback | The actual request or booking result is perceivable and matches the scheduler’s recorded outcome | Accessibility reviewer and scheduling owner |
For each row, record the setup, expected state, observed result, defect owner and retest evidence. Mark an untested combination as untested. One successful phone/browser combination does not establish behavior on every device.
Check labels and feedback at the transition
A speech-input user may say the words they see on a button. W3C’s Label in Name explanation says that a control’s accessible name must contain its visible text label where that criterion applies. Have the reviewer inspect that relationship and test it. A button visibly labeled “Continue” should not require the person to guess an unrelated hidden name.
An error should identify the field and explain correction; use W3C’s form-notification guidance for implementation detail. Also test the result of correcting it. A visible success message alone is insufficient evidence for someone relying on a screen reader.
W3C’s Status Messages explanation addresses status messages that do not move focus or change context. The criterion requires programmatic identification so assistive technology can present those messages. It does not require every update to interrupt the person. Ask the specialist to test the actual feedback mechanism, including whether a request receipt could be mistaken for a confirmed appointment.
Preserve useful state without promising universal persistence
W3C’s Redundant Entry explanation addresses information needed again within the same process: it should be filled in or available to select, with exceptions for essential re-entry, security and information that is no longer valid. It does not require storing information between sessions.
That distinction matters when the practice offers a resume link or someone moves to another device. Test only the continuation method the system actually supports. Have privacy and security reviewers approve what it retains, who can access it and when it expires. Do not invent a saved-booking promise or copy personal details into an ordinary email to work around a broken transition.
Make help optional and keep the final choice visible
Use a synthetic acceptance test: select an office, ask an authorized tester acting as a helper to type a test contact address, then return control to the original tester. Before submission, the person should be able to review the chosen office and the destination for confirmation. The helper’s address should not silently replace the person’s chosen address, and typing assistance should not silently become authority to submit.
This is a proposed workflow safeguard, not a legal rule about who can act for someone else. If the practice permits proxy booking, use its verified authorization process; a helper’s presence alone does not establish that authority. Provide an approved alternative when the person cannot complete the web flow, and describe accurately whether that alternative submits a request or confirms an appointment.
Close the review only after the failing transition has been retested with the same setup. Keep performance work in the website-speed review and automated action permissions in the agent-booking brief. This worksheet establishes evidence about a specific human interaction, with any untested combinations still visible.
Frequently asked questions
Does this worksheet establish WCAG or legal compliance?
No. It samples selected interactions. A qualified accessibility review must determine the applicable criteria and test the complete experience; legal obligations depend on the practice’s jurisdiction.
Must every scheduler support moving a booking between devices?
Do not promise that capability unless it exists. Check any advertised continuation feature and its privacy controls. If restarting is necessary, explain the actual behavior and offer the approved support route.