Date pickers get all the attention in booking audits, and they deserve some of it. But the calendar is one screen in a lifecycle that runs from searching for availability through holding a slot, paying, being confirmed, changing your mind, and cancelling. Most of those steps happen on different pages, some happen in a different system, and a good half of them run on a timer.
The timer is where this gets interesting, because two wrong answers circulate freely. One says an inventory hold is exempt because it is essential. The other says a countdown a user cannot extend is an automatic failure. W3C publishes two ticket-purchase examples that both pass, by different routes, which is the tidiest possible refutation of both positions.
The Six Ways to Satisfy the Timing Rule
Timing Adjustable is satisfied if any one of six things is true, and only three of them are things you have to build.
- Turn it off. The user can switch the limit off before meeting it.
- Adjust it. The user can adjust it before meeting it, over a range at least ten times the default.
- Extend it. The user is warned at least 20 seconds before it expires, can extend with a simple action, and is allowed to extend at least ten times.
- Real-time event. The limit is a required part of a real-time event, such as an auction, and no alternative is possible.
- Essential. The limit is essential and extending it would invalidate the activity.
- Longer than 20 hours. A limit over 20 hours satisfies the criterion with nothing else required.
The numbers on the extend branch are exact and they are the ones teams get wrong. Twenty seconds of warning is a floor, not a target, and ten extensions means ten, not one. W3C's stated reason for the multiple of ten is clinical experience, which is a more careful basis than most interface numbers have.
The Two Ticket Examples, and Why Both Pass
W3C's own explanation of this criterion works through a ticketing site twice, and the pair is worth reading closely because it settles arguments.
In the first, a site gives two minutes to confirm a purchase before the seats return to the general pool. W3C says that because tickets can sell out quickly, holding one longer may invalidate the nature of the site, so the timing is essential and cannot be extended without invalidating the activity. It passes. But look at the sentence that follows, because it is the part people quote least and need most. The site moves as much of the process out of the time-critical period as possible, letting users provide their name and payment method before entering the timed stage.
In the second, a site gives the same two minutes, warns the user when time is nearly up, and lets them extend it. That passes too, by a completely different route.
The word that does the work here
Essential is defined, and it has two halves. Removing the limit would have to fundamentally change the information or functionality of the content, and the information and functionality could not be achieved in another way that would conform. An inventory hold clears the first half easily. The second half is where the argument lives, because the alternative route W3C describes in its own passing example is to shrink the timed window rather than to defend it. A hold that covers form-filling, address entry and payment details is a hold that could be shorter.
The Booking Lifecycle Matrix
This is the artifact. Ten states, and the questions that decide whether each is testable and what rule it answers to.
| State | What the tester needs | What is in play |
|---|---|---|
| Search for availability | Nothing | Announced result counts, and filters that keep the reader's place |
| No availability | A date with nothing free | Whether the empty state says anything useful |
| Select a slot | Nothing | Date pickers, and a text input alongside the calendar |
| Slot held, timer running | A hold that can be triggered safely | The six routes above, and whether the countdown is announced at all |
| Hold expires | Patience, or a shortened test timer | What the reader is told, and whether their data survived |
| Payment | A sandbox | A complete process, covered on our payments page |
| Confirmation | Nothing | Whether the confirmation is reachable again later |
| Find an existing booking | A test booking, and the email or link that reaches it | Often a different system, often a magic link |
| Change a booking | A changeable test booking | Error Prevention, and whether old values are prefilled |
| Cancel a booking | A cancellable test booking | The confirmation step, and what is announced afterwards |
Look at the setup column and you can see why booking audits stall. Half the states need a booking that already exists, in a system that will let somebody change it, without holding real inventory or cancelling a real customer. That is a conversation to have before the engagement, not during it.
The Change Journey Usually Lives Somewhere Else
Managing a booking is rarely the same application as making one. It is often reached from a link in a confirmation email, sometimes on a different domain, sometimes behind a code rather than an account. That does not put it outside the audit. It puts it inside the same process.
Redundant Entry is instructive here, because its scope term is process rather than session, and W3C is explicit that a process can cross domains. So information the customer gave when booking should not be demanded again when changing, even though the change happened three weeks later on a different subdomain. The criterion has three exceptions and none of them is it is a different system.
One more detail from that criterion is worth carrying into any booking review. Browser autofill does not satisfy it. The obligation sits on the content rather than the user agent, so the browser will remember it is not an answer.
What Error Prevention Asks of a Cancellation
A booking change or cancellation is a financial transaction in most businesses, so Error Prevention (Legal, Financial, Data) applies. It asks for at least one of three safeguards, and one is enough.
The transaction is reversible, meaning the cancellation can be undone. Or the data is checked, meaning input errors are caught and the user gets to correct them. Or the submission is confirmed, meaning there is a review step with a chance to change or cancel it.
Almost every booking system already meets the third. An are you sure you want to cancel screen with the booking details on it satisfies the criterion, and nothing in WCAG requires the cancellation to be free, refundable or reversible. That is a commercial policy question, and it is not this rule's business.
The Alternative-Route Escape Nobody Uses
There is a sixth answer hiding in the Understanding document, and it is often the cheapest one. Content on a timer does not need to be adjustable if the same information or function is reachable another way that is not timed.
W3C works it through with a notification example. A message announcing new mail that vanishes after five seconds sets no time limit, because the mail is still in the inbox. The information was available another way. Apply that to booking and you get a real design option. If somebody misses the hold, does the journey put them back where they were with their details intact, or does it dump them at the search page? The first is an alternative route. The second is a wall.
One honest limit
We audit and never repair, so nothing here is an offer to change your booking engine. We also will not hold live inventory or cancel real bookings to produce an example, which means the states above need test bookings arranged with you first, and the ones we cannot reach are named in the report as unevaluated rather than passed. Scope it at contact or read what the booking flow audit covers.