Estimated reading time : 7 min · Published
Show the actual status of a booking
The journey depends on availability data and approval arrangements. This is a reading framework; it does not assume every website can confirm immediately.
- Selection
Dates, capacity and the requested service are identified.
- Verification
The source used confirms or rejects the requested availability.
- Conditions
People can check the offer before proceeding.
- Final status
Enquiry received, provisional hold or confirmed booking are clearly distinguished.
Fictional teaching scenarios to adapt to your system. This page performs no operation on your website.
Open the situation you want to check
The form only sends an enquiry
- What is known
- Availability has not necessarily been validated.
- The next check
- Use enquiry wording in the button, summary and message, then explain what happens before confirmation.
The return from a provider is interrupted
- What is known
- The browser shows no certain outcome.
- The next check
- Check status in the booking system before asking someone to repeat the attempt; retain any reference available.
Dates change during the journey
- What is known
- The earlier offer may no longer describe the requested stay or slot.
- The next check
- Recheck availability, conditions and the summary against the new dates.
Two tests request the last place
- What is known
- The fictional scenario has one place, requested almost simultaneously by BOOK-A and BOOK-B.
- The next check
- Check the availability source’s decision and both messages. This test contract does not allow two confirmations for that single place.
- Evidence to retain
- Initial capacity of one, BOOK-A and BOOK-B, recorded states and messages; restore the test copy’s initial state afterwards.
Technical reference : W3C WAI · User Notification · Consulted .
Define what can be booked
List services, duration, required people or resources, breaks and buffers between slots. A displayed opening must correspond to real capacity. Check exceptional hours, relevant time zones and the point at which a slot is held during entry.
Prepare a small matrix: ordinary booking, last free slot, two people attempting the same slot, unavailable service and an out-of-hours request. For each, write the expected result for the visitor and in the team calendar. The form guide helps keep requested information proportionate.
- Capacity and duration documented.
- Slot conflicts tested.
- Named owner for hours and closures.
Follow the request through confirmation
Start from a service page and complete a booking on a phone, then with keyboard navigation. Check slot selection, summary, any fees, required fields and the message after submission. If payment is required, test acceptance, refusal and abandonment separately; a success screen alone does not prove payment was received.
Compare the customer confirmation, the booking saved for the team and internal notifications. They should describe the same service, date, status and route to correct a mistake. Do not call a booking confirmed if human approval is still required.
- Matching status across the three places.
- Understandable confirmation.
- Failure without a falsely confirmed slot.
Plan for changes, cancellations and absence
Test a change that releases the old slot and occupies the new one, then a cancellation that returns capacity according to stated rules. A request arriving by phone or email must also reach the calendar. Check what both parties see when a change fails halfway through.
Use wording approved by the organisation for its commercial terms and show it before the decision. Do not imply that a cancellation message automatically means a refund. Provide an alternative contact route when the booking service is unavailable.
- Old and new slots stay consistent.
- Terms visible before confirmation.
- Fallback route known to the team.
Accept the daily operating work
Ask appointment managers to carry out ordinary tasks: open hours, close an absence, move an appointment, find an enquiry and review a busy day. Record any double entry or dependence on another tool; these are common sources of mistakes.
Before launch, assign monitoring for confirmations and failures, keep repeatable test scenarios and verify the first live booking with an authorised person. The prelaunch checklist covers the rest of the site.
- Manager trained with real cases.
- Failures visible and actionable.
- First production booking verified.
Check dates before and after acceptance
Test entered date, selected slot and accepted booking as distinct states. Compare date and time context in summary and email. Availability may change before confirmation; preserve the other details while offering a new choice.
Include closing a dialog during waiting. Do not describe that as guaranteed cancellation if the service may already have accepted the booking. Keep the outcome verifiable to avoid creating a second booking by retrying.
Design date input and a booking calendar · Write and announce interface status messages · Design and test a modal dialog
Review a booking using a concrete summary
Fictional example: one person chooses a 30-minute consultation on 18 November 2026 at 10:00, Europe/Paris time zone. The displayed slot remains a proposal until the responsible system accepts it. Distinguish this selection from the final commitment in the summary.
Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.
| Stage | Information shown | Offered action |
|---|---|---|
| Before submission | Consultation · 18 November 2026 · 10:00 · Europe/Paris · 30 min · 1 person. | Also review the applicable price and conditions, then allow corrections. |
| Availability needs checking | The chosen slot cannot yet be confirmed. | Retain useful information and offer another slot or a way to check progress. |
| Booking accepted | Confirmation DEMO-208 with the same date, time, time zone and service. | Provide the actual method for retrieving or changing the booking. |
- W3C WAI · WCAG 2.2 · 3.3.4
For actions covered by WCAG 3.3.4, W3C explains correction, checking or reversibility options. This model establishes no price, availability or commercial cancellation rule.
Keep the booking journey continuous
Follow a single booking from contact details to review, including any payment-provider step. A back action should retain information that remains valid; changed dates may require availability checks without requiring the user to retype their name.
Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.
| Situation | Expected result | Check boundary |
|---|---|---|
| Back from review | Previously entered contact details remain available. | Change dates and check availability again. |
| Billing address | Offer selection of an already supplied address when appropriate. | Make the choice reversible before confirmation. |
| Login required | Check password-manager support and code pasting. | Test the route after expiry and recovery. |
- W3C WAI · WCAG 3.3.7
Read the criterion’s scope and exceptions; this scenario is a practical interpretation, not a compliance certificate.
Cancel one place in a group booking
Fictional example: DEMO-G3 covers three people, and only one asks to cancel. Distinguish the change request from its acceptance. In this proposed scenario, all three places remain active during review; only two remain after the partial cancellation has been confirmed.
Compare the customer summary with the team’s system: remaining participants, released capacity and reference must agree. A notification must not describe the entire group as cancelled. Any fees or refunds remain separate decisions under the terms that actually apply.
Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.
| State | Active places | Check |
|---|---|---|
| Initial booking | 3 | All three people appear in the booking. |
| Change awaiting review | 3 | Show a pending request without claiming a place has been released. |
| Partial cancellation accepted | 2 | Release one place and retain the other two participants. |
- Prepare status messages
Announce results to assistive technology.
Check the copy added to a calendar too
If adding to a calendar is offered, identify whether it provides a file copy, subscription or invitation. iCalendar describes the event format; iTIP describes scheduling exchanges. These mechanisms alone do not establish that every calendar in use will receive changes. The booking system remains the reference for the request’s status.
Fictional exercise: move DEMO-C1 from 18 November at 10:00 to 19 November at 11:00, Europe/Paris time. After confirmation in the booking system, compare the email, summary and test calendar. Look for an old appointment still shown as active; explain how to correct it if updates are not automatic.
- Read back the date, time, time zone and duration after import.
- Test changes and cancellations in the calendar apps actually used.
- Keep internal notes out of shared event titles and descriptions.
- RFC 5545 : iCalendar
Event data format.
- RFC 5546 : iTIP
Update and cancellation exchanges.
Reference documents
- W3C WAI · User Notification · Source consulted
- W3C WAI : Forms Tutorial
- W3C WAI · WCAG 2.2 · 3.3.4 · Source consulted
- RFC 5545 : iCalendar · Source consulted
- RFC 5546 : iTIP · Source consulted
- W3C : Understanding Status Messages · Source consulted
Further reading
For tourism bookings, this checklist illustrates information travellers need before confirming: services, travellers, price and terms. It can inform review of enquiry and summary stages, with content validated by the responsible travel professional.
Content updated on
Documented reference points for this topic
| Reference | Value or syntax | Scope |
|---|---|---|
| RFC 3339 · Date-time | 2026-10-22T09:00:00+02:00 | The explicit offset relates local time to UTC; this example is not an appointment. |
| WCAG 2.2 · 3.3.7 | A · same process | Within one process, previously supplied information must be auto-populated or available to select, subject to the criterion’s exceptions. Browser autocomplete alone is insufficient; the site must offer the information already received or avoid requesting it again. |
| WCAG 2.2 · 3.3.8 | AA · authentication | An authentication step requiring recall or transcription needs assistance or an alternative route, subject to the criterion’s exceptions. Test password managers and code pasting; an audio alternative requiring transcription does not by itself remove the cognitive burden. |
Dates indicate when references were consulted. These facts are neither a site audit nor an overall compliance statement.