A booking process may look like part of your website while being controlled entirely by a third-party vendor. Accessibility must therefore be tested and agreed before purchase—not after customers start getting stuck.
A typical booking page feels well organised until the visitor selects “Book”. A calendar then opens in an iframe, a new tab, or an external domain where focus disappears, error messages are not announced, and the button for continuing is cut off when text is enlarged. To the user, this is still the same service, even if the technology comes from several vendors. Booking system accessibility requirements must therefore be assessed throughout the entire customer journey, not only on the website that the web agency can modify.
The consequences extend beyond a technical non-conformance. A person who cannot select a date with a keyboard, understand a form error, or return from the payment stage cannot complete their purchase. The organisation therefore risks abandoned bookings, more support requests, and dependence on a vendor that may lack an effective remediation process.
The right approach is to begin by mapping who owns each technical step, then test a real booking, and finally agree on how defects will progress from observation to a verified fix. The web agency can improve the transition, information, and alternative route on the organisation’s own website, but it normally cannot repair HTML, focus order, or error handling inside an external component.
Booking system accessibility requirements: map the entire customer journey
A booking process is rarely a single system. It may begin on a WordPress or React website, continue in an embedded booking module, switch domains for payment, and end with an email containing links for rescheduling or cancellation. Each transition can change the page title, language, focus, keyboard order, and the information conveyed to a screen reader.
Start by mapping the entire journey from selecting a service to receiving confirmation. Include identification, cookie panels, payment, receipts, reminders, and features for changing or cancelling a booking. Beside each step, record which domain is used, which vendor owns the code, who can publish a fix, and who can respond when a critical barrier is discovered. The map makes the boundaries of responsibility visible without confusing technical control with the user’s experience of the service as a whole.
The transitions require particularly careful review. If a button opens a new tab, the user should receive clear information about it. If the booking module loads on the same page, focus should move to where the task continues rather than remain on the button or move to the beginning of the page. Once payment is complete, the return to the booking must also be clear to someone who cannot interpret colour, position, or visual icons alone.
An iframe creates a clear technical limitation. When content is delivered from another domain, the browser’s security model normally prevents the website’s scripts and style sheets from reading or modifying content inside the frame. This same-origin policy is explained in more detail by MDN. The web agency can often control the frame’s position, title, height, and surrounding instructions, but it cannot repair the calendar’s HTML, change internal error messages, or move controls within its keyboard order.
This does not mean that an iframe cannot be evaluated. The visible process can and should be tested manually with a keyboard, screen reader, magnification, and different screen sizes. The limitation primarily concerns who can implement the code change itself. Make this distinction clear during procurement: the web agency can document and reproduce the defect, while the booking vendor or its subcontractor needs to fix the component.
Data from the process can provide additional signals. For example, track how many people begin a booking, reach payment, and receive confirmation, provided that the vendor offers reliable events or reports. However, a clear drop-off at a particular view does not automatically show that accessibility is the cause; pricing, available times, and technical errors can produce the same pattern. Combine behavioural data with reproducible tests and support cases rather than drawing conclusions from a single data point.
Accessibility may involve legal requirements, but the legal assessment must be made for the specific organisation and service. This article provides practical guidance, not legal advice. Check current official guidance from Digg and relevant legal information through EUR-Lex.
Test a real booking—not just the vendor’s homepage
The homepage is the least revealing part of a booking service. Difficult problems often appear only when the calendar changes month, a selected time becomes unavailable, the form displays errors, or the payment stage sends the user to yet another vendor. A relevant acceptance test must therefore follow the same task that a customer is actually trying to complete.
Select a representative service and proceed from the first click to a saved confirmation without using a mouse. Use Tab and Shift+Tab to move forwards and backwards, Enter and Space to activate controls, and Escape where a dialog, menu, or calendar should be closable. The focus indicator should remain visible at all times, the order should follow the task, and no control should trap the user and make it impossible to continue or go back.
The calendar component deserves extra attention. Check whether dates can be reached and selected with a keyboard, whether the current month and selected date are communicated clearly, and whether instructions can be found without requiring the user to guess a special command. Also try changing an earlier selection. A process that works only when every choice is correct from the outset is fragile, because real bookings involve changes, misunderstandings, and time slots that may become unavailable.
Next, deliberately trigger errors. Leave required fields empty, enter a format the system does not accept, and try to select a time that is no longer available. A good error message explains what needs to be corrected, is associated with the correct field, and can be detected when it appears. If a screen-reader user has to search through the entire page to understand why the button did not work, the process has effectively stopped, even if the error is clearly displayed in red on the screen.
Also test what happens when content changes without a full page load. Modern booking systems often update prices, times, and forms with JavaScript. The visual change may be obvious but remain unknown to assistive technology if focus stays in the wrong place or the status lacks a programmatic signal. The commercial consequence is the same as with a visible system error: the user does not know whether the selection was registered and may abandon or submit the booking several times.
Large text and mobile magnification reveal another type of failure. An embedded module may have a fixed height, hidden scrolling areas, or buttons positioned outside the visible area. Check every step with significantly enlarged text and a narrow mobile viewport, not only the initial calendar. Look for overlapping labels, horizontal scrolling, clipped error messages, and buttons that can no longer be reached.
Then complete the same task with at least one common screen-reader and browser combination, such as NVDA with Firefox or VoiceOver with Safari. Listen for the names, roles, states, and instructions of controls. A button visually labelled “Continue to payment” but announced only as “button” leaves the user without enough information to make a decision. A successful test with one combination does not guarantee universal compatibility, but a blocking defect clearly shows that the solution is not ready for acceptance.
A WCAG evaluation of the booking process should use the current version of the standard and combine automated and manual checks. WCAG 2.2 from W3C is the official technical reference, but a report still needs to be translated into real user tasks. Tools such as axe DevTools and WAVE can identify common code problems, while focus movement, calendar logic, understandable errors, and recovery from mistakes require human review.
Document the test so the vendor can repeat it. Record the product version, web address, date, browser, assistive technology, test steps, expected result, observed result, and a relevant screenshot or short recording. Above all, classify whether the defect blocks the booking, makes it unreasonably difficult, or presents a minor barrier. The number of automated warnings is rarely the most commercially relevant metric; the ability to complete the task, understand errors, and resume the process provides far more useful information.
Repeat the same test cases after major updates. A vendor may fix the calendar while introducing a new problem in the form or payment transition. Version-specific test evidence makes it possible to see whether quality is improving, whether blocking defects recur, and how long it takes to move from a defect report to a verified fix without relying on general assurances.
Agree on the remediation process, not just that the system is accessible
The words “WCAG compliant” are not enough to support a decision. The statement says nothing about which product version was tested, whether the test included the calendar, whether the payment stage came from another vendor, or whether the evaluation covered only the marketing website. Request evidence that can be linked to the module and user journeys you are actually planning to purchase.
Ask the vendor to explain which areas have been evaluated, which manual test activities were used, and which known defects remain. The administration interface, customer booking module, payment stage, and confirmation messages are separate interfaces and may have very different levels of quality. An up-to-date list of non-conformances is often more useful than an undated certificate because it shows whether the vendor understands its limitations and has a process for addressing them.
Link acceptance to named tasks. “Book using only a keyboard”, “correct a form error with a screen reader”, “change a previously selected date”, and “complete the process with large text on mobile” can all be tested and approved. A general statement about accessibility, by contrast, is difficult to use when the parties disagree about whether a defect is critical.
The remediation process needs a clear owner. Specify where defects are submitted, what information the report must contain, how blocking barriers are prioritised, how the vendor provides updates, and how the customer can test the fix before the case is closed. If the defect is with a payment partner or another subcontractor, the main vendor should still be able to explain who will move the issue forwards. Otherwise, the case may circulate between support teams while bookings continue to be lost.
The following evaluation matrix shows how requirements can be linked to specific processes. The rows are illustrative test examples and should be replaced or supplemented with observations from the product version you are evaluating.
| Process step | Test scenario | System owner | Example defect to document | Remediation responsibility | Verification method | Status |
|---|---|---|---|---|---|---|
| Calendar | Select a date, change the week, and modify the selection without a mouse | Booking vendor | Focus leaves the calendar after changing the week, and the user cannot find their way back | Booking vendor’s product team | Keyboard testing and NVDA with Firefox or VoiceOver with Safari | Blocking if a date cannot be selected |
| Customer form | Submit the form with empty and incorrectly formatted fields | Booking vendor | The error is shown visually but is not announced when it occurs and is not associated with the correct field | Booking vendor’s product team | Manual error testing with a screen reader and inspection in Chrome DevTools | Must be fixed before approval |
| Payment | Proceed to external payment, cancel, and return to the booking | Payment partner and booking vendor | The return lacks a clear status, and previous selections appear to have been lost | The designated main vendor coordinates the fix | Complete cross-domain test with a keyboard and screen reader | Requires a named owner |
| Confirmation | Read the confirmation, find the booking details, and open the link for making changes | The organisation and booking vendor | Essential information appears only in a difficult-to-read image or uses unclear link names | Owner of the message template | Testing in common email clients with magnification and a screen reader | Verify before publication |
| Rescheduling and cancellation | Open an existing booking and select a new time without a mouse | Booking vendor | The feature requires a mouse action or provides no confirmation that the change was completed | Booking vendor’s product team | Task-based test from the confirmation link to the saved change | Included in standard acceptance |
The matrix makes it easier to separate technical findings from contractual issues. A reproducible defect can be assigned to the correct system owner, while the status column shows what must be resolved before launch and what can be monitored during ongoing management. It also provides a shared language for the web agency, organisation, booking vendor, and payment partner.
Plan for changes at the same time. The vendor should provide advance notice of major interface changes and access to a test environment where core processes can be reviewed before the new version reaches customers. Also ask how regression defects are handled—that is, when a feature that previously worked stops working after an update. Do not measure only whether the case has been marked as resolved; measure whether the original user task can once again be completed.
Export capability is also part of the accessibility strategy. If booking data, integrations, customer messages, and settings are difficult to move, switching vendors becomes expensive even when a critical barrier remains unresolved. Document which data and templates can be exported, the usable format in which they are provided, and which dependencies must be rebuilt. Have legal professionals adapt binding contractual terms to your organisation; the guidance here describes the practical process and does not constitute legal advice.
Build an effective alternative route when the vendor cannot provide an immediate fix
An alternative route is not an anonymous support link at the bottom of the page. It should allow users to book, change, or cancel the same core range of services when the standard process contains a known barrier. Place the option before or directly beside the transition to the external system so users do not first have to get stuck and then search for help.
Explain specifically what users can do. A telephone number may work if it is staffed and employees can complete the entire booking. An accessible contact form may be better when telephone contact is unsuitable, but the form needs to collect the correct information, reach a monitored inbox, and result in an actual calendar reservation. Avoid a general instruction to “contact support”, as this transfers the entire burden of solving the problem to the user.
The alternative route should not require the person to disclose a disability or provide medical information. Ask only for the details needed to select the service and time, make contact, and complete the booking. The same principle applies internally: record the reason for manual handling at a sufficiently general level to improve the process without collecting unnecessarily sensitive information.
The web agency can make the alternative route visible, explain that the booking continues with an external vendor, and display current service information when available. It can also measure how often the link to the external process and the alternative option are used. However, this does not repair the accessibility of the third-party widget. The alternative solution reduces harm while the vendor works on the issue, but it must not become an excuse for leaving the technical barrier unresolved.
The procedure must also work behind the scenes. Assign responsibility for monitoring incoming requests, checking available times, preventing duplicate bookings, and sending confirmation. The confirmation should be readable, savable, and usable for making later changes. Monitor cases handled through the alternative route as an operational signal: recurring needs at the same process step indicate where a technical fix would deliver the greatest benefit to customers and staff.
Five criteria that determine whether the booking system works in practice
Assess the entire booking journey, the division of responsibility, and the vendor’s ability to handle defects—not just what appears on a requirements list. Accessibility regulations may affect the decision, but this is not legal advice. Check current requirements with Digg and use EUR-Lex for relevant official legal information.
Map the entire user journey and every boundary of responsibility
Document every step from your website to confirmation, rescheduling, and cancellation. Include embedded components, external domains, payment, identification, and messages. State who can technically modify each step and who manages contact with any subcontractors. The user’s problem does not disappear when the defect lies in a service you do not develop yourselves, but the responsibility map shows who can actually implement a fix.
Signal: A good vendor can show which components it is responsible for, which subcontractors are involved, and who manages a defect at every step. Be cautious if the answers go no further than saying that the module is “external” or that payment sits outside the vendor’s own product.
Complete an end-to-end booking based on real accessibility needs
Test a realistic process from service selection to confirmation using only a keyboard, significant magnification, and at least one common screen reader. Review date pickers, form fields, dynamic status messages, time limits, payment, and the ability to change a selection. The goal is not to collect the greatest number of technical findings, but to determine whether a person can understand and complete the task and recover from mistakes.
Signal: Treat it as a warning sign if the vendor demonstrates only the homepage, refers to the result of an automated tool, or does not allow you to test the entire process before signing a contract. An accessible booking system should withstand a real task-based test.
Require verifiable answers instead of general accessibility promises
Ask the vendor to describe how the system was evaluated, which product version was included, which user journeys were tested, and which defects remain. Check that the documentation applies to the customer-facing booking module rather than only the vendor’s marketing website or administration interface. Known non-conformances do not necessarily disqualify the system, but they must be visible, assessed, and linked to a remediation plan.
Signal: A credible report includes a current scope, manual test activities, and specific non-conformances. An undated certificate, badge, or automated scan result alone provides too little information for a well-informed decision.
Agree on an effective route from defect report to verified fix
Describe how accessibility defects are reported, prioritised, communicated, fixed, and retested after an update. Clarify the contact route, responsible role, handling of blocking barriers, and what happens when the problem lies with a subcontractor. The customer should be able to verify the original task in a test environment before the case is considered closed.
Signal: The vendor should accept reproducible defect reports, appoint an owner, and return with a clear plan. A support response that refers only to future product development without an owner or verification process represents a risk.
Provide an equivalent alternative route that staff can operate
Plan how a person can book, change, or cancel when the standard system does not work and the vendor cannot provide an immediate fix. The alternative should be easy to find, offer the same core options, and result in a completed booking without requiring the user to explain their disability. Establish the procedure with the staff responsible for receiving, recording, and confirming the request.
Signal: Treat it as a warning sign if the alternative consists only of an unclear telephone number or an inbox without an owner, instructions, or a procedure for completing the booking. An alternative route works only when it is both visible to customers and operational internally.
Start here: prioritise accessibility before contracts and integration
-
Map the entire booking process before requesting a quote
List every step the user must complete, from selecting a service and time to forms, payment, confirmation, rescheduling, and cancellation. Document the process in Miro, FigJam, or a spreadsheet, and mark which components belong to the system vendor, web agency, or payment partner. Add domain changes, embedded components, and contact people. The result is a responsibility map that reveals hidden third-party steps before technical and commercial dependencies become locked in.
-
Require verifiable evidence from every vendor
Request a current accessibility statement, relevant test reports, known defects, planned fixes, and information about how new versions are quality-assured. Collect the answers in a comparison matrix in Excel or Google Sheets, with columns for keyboard support, screen-reader support, error messages, focus order, contrast, magnification, and the support process. Also record the product version and processes covered by each item of evidence. This allows you to distinguish documented capability from general promises.
-
Test a live demo with a keyboard and screen reader
Complete the entire booking without a mouse, using Tab, Shift+Tab, Enter, Space, and Escape. Repeat the process with NVDA and Firefox or VoiceOver and Safari, for example. Record stopping points, unclear announcements, lost focus, difficult error messages, and steps that cannot be completed in Jira, Trello, or GitHub Issues. Always include clear reproduction steps and the expected result so the vendor can fix the problem rather than trying to interpret a vague description.
-
Combine automated checks with manual evaluation
Run axe DevTools or WAVE on the different views in the booking process, and use Chrome DevTools to inspect structure, accessible names, and focus. The tools can identify common code problems but cannot determine whether the calendar is understandable, whether an error is announced at the right moment, or whether the user can complete payment. Verify automated findings in the actual process and prioritise defects according to their effect on the task.
-
Include acceptance criteria and responsibilities in the delivery
Make effective keyboard navigation, understandable screen-reader output, clear form errors, and successful booking with magnification explicit acceptance criteria in the contract, quotation appendix, or project tool. Specify who fixes defects in external components, how they are reported, and that the same core processes must be evaluated after major updates. Also include a test environment, export capability, and an alternative route. The result is a manageable ongoing process rather than a one-off check before launch.
Do not select a system based solely on a badge or the vendor’s own assurances. Let real booking tasks, documented acceptance criteria, and a verifiable remediation process guide your booking system accessibility requirements. Start with blocking barriers, then establish recurring checks whenever the website, integrations, or booking platform changes. This is practical guidance, not legal advice; check current legal requirements with Digg and, where necessary, EUR-Lex. A practical next step with FLAR AB could be to map the process and carry out an independent acceptance test before committing to the vendor or building the integration.
