Before buying reservation software, compare the complete guest booking flow using a keyboard and a screen reader. Start at the restaurant website, choose a date and party size, handle an error, and reach a clear confirmation. Record where each flow stops, then ask the vendor who will fix it and how you can retest.
A quick demonstration is not enough. A calendar may look straightforward with a mouse but be difficult to navigate without one. A screen reader may announce a button without explaining what it does. The useful buying question is whether a guest can complete the same essential booking tasks independently, without guessing or relying on staff.
This check concerns access to the booking interface. It is separate from collecting a guest's accessible seating needs, although a special-request field should also be usable if your restaurant offers one.
Set up a fair comparison
Ask each vendor for a demonstration environment that follows the actual route a guest would use: your website link, booking form, availability choices and confirmation. If you expect bookings through Google where available, ask to see that route too. A direct website booking and a discovery-network booking can take guests through different screens, so record which route you checked.
OpenTable offers restaurant reservations and a diner discovery network; a direct booking tool focuses your comparison on the route from your own site. Ask each provider about booking-channel attribution, permissions, exports and fees rather than assuming those terms are the same.
Use the same guest task for every option. For example, ask the tester to find a dinner time, choose a party size, enter required details and identify whether the reservation is confirmed. Include a special request only if that field is part of the flow you are considering.
Have someone familiar with keyboard navigation and screen readers conduct or assist with the comparison. Ask vendors which browser and screen-reader combinations they support, then record the combination used. One combination is a useful starting point, not proof that every guest's device will work.
Run practice checks in a test environment with sample details. Confirm in advance that the exercise will not create a real booking, charge a card or send a guest message. If a vendor cannot provide a safe way to simulate the final step, stop before submission and note that confirmation remains untested. A later live service pilot is a separate, controlled decision; it is not needed for this practice exercise.
Follow the booking flow without a mouse
Put the mouse aside and use the keyboard to move from the website's reservation link through the form. The focus indicator should make it possible to tell which control is currently selected. Check that the focus moves in a sensible order and does not become trapped in a calendar or pop-up.
Try the controls a guest needs, not just the first few fields:
- Open booking: Can the guest reach and activate the reservation link? If a booking window opens, is it clear where focus has moved?
- Choose a date: Can the guest open the date picker, move between dates and select one without a mouse? Can they identify the selected date?
- Set party size: Can the guest find the party-size control, change its value and tell what value is selected?
- Choose a time: Are available times reachable and distinguishable? If a time is unavailable, can the guest return and choose another?
- Enter details: Can the guest identify required fields and reach any special-request field offered?
- Finish or go back: Can the guest review the booking, change an entry and reach the final action without losing their place?
Repeat the task with a screen reader. Listen for useful control names, field labels and instructions. A guest needs to hear more than “button” or “edit”: they need enough context to know whether they are choosing a date, entering a phone number or submitting the booking.
Also listen when the page changes. If selecting a date reveals times, does the guest receive a useful indication that choices are available? Can they find those choices without exploring the whole page again? Note the exact screen and action when the answer is no.
Check errors, changes and confirmation
A clean booking path is only half the job. In the practice environment, leave a required field empty and attempt to continue. The guest should be able to find which field needs attention and understand how to correct it. A red border alone is not a useful message for someone who cannot see it.
Try an unavailable date or time, if the demo allows it. Check whether the flow explains the problem and offers a way back to the relevant choices. Then change the party size and see whether the guest can tell if the available times have changed. Do not assume a quiet screen update has been announced.
At the final step, look for a confirmation that distinguishes a completed reservation from a request that still needs a response. The guest should be able to identify the date, local time and party size, and know what to do if something is wrong. With a screen reader, check whether the confirmation can be found and understood after submission.
Ask how the provider handles confirmation outside the booking page as well. Can the guest find a phone number for help? What information appears in any confirmation message? In a simulation, use only a safe preview or test mechanism that does not send a real message.
Use a worksheet to make the decision
The following is a hypothetical comparison. Both options are fictional, and the results describe only the stated practice conditions. The table records the task, the outcome for each alternative and the acceptance rule the owner will use before signing.
| Task | Option A | Option B | Acceptance rule |
|---|---|---|---|
| Choose date and time by keyboard | Tester selects both and can see focus. | Focus becomes trapped in the date picker. | Complete selection and leave the picker without a mouse. |
| Correct a missing required field | Screen reader identifies the field and the error. | Error appears visually but is not announced. | Find the error and correct it without sighted help. |
| Review confirmation | Test confirmation gives date, time and party size. | Final step cannot be safely simulated. | Independently find and understand a simulated confirmation. |
In this example, Option A meets the three recorded rules in the tested setup. Option B does not: its date picker blocks the keyboard task, its error is not announced, and its final step remains untested. If these rules are conditions of purchase, the owner should proceed with A over B on this evidence, while checking the rest of A's workflow and commercial terms. B could become a candidate after fixes and a safe confirmation retest.
Keep the worksheet specific. Record the page or route, browser and assistive technology, task, result and date. Add the steps needed to reproduce a failure and whether the tester found a workaround. Avoid marking an item as a pass simply because a staff member could explain where to click.
Classify a failure by its effect on the guest. A blocking failure prevents completion, such as an unreachable submit control. A serious obstacle may permit completion only with substantial difficulty or assistance. A minor issue does not stop the task but still causes confusion. Agree on which unresolved issues prevent purchase, and distinguish a failed check from one you could not safely perform.
Agree on fixes, support and a retest
For every material failure, ask the vendor who owns the fix. The problem may sit in a booking widget, your website template or a third-party booking route. Ask for a named contact, the expected next step and a target date in writing. A statement that accessibility matters does not tell you when a trapped calendar will be repaired.
Ask the vendor to show the corrected task in the same browser and screen-reader combination, then repeat it yourself or with your tester. Include the original failed action and the steps around it: a repaired date picker is not enough if focus disappears when available times load. Record the retest result alongside the original failure.
Also plan an assisted route. Publish a phone number or another staffed contact method that guests can use to request a booking. Tell staff what details to collect, how to confirm the local date and time, and when to respond. Check that the contact route is easy to find from the booking page. Assistance is valuable, but it should not be used to mark an inaccessible online task as passed.
Compare written quotes as well as test results. Ask about setup, ongoing charges, booking-channel fees and any cost for changes or support. A cheaper quote may be poor value if a blocking issue has no owner or a workable assisted route requires staffing you cannot provide. For contract or legal questions, consult a qualified adviser.
If the booking tool must fit into wider operations, ask how reservation details reach staff and what permissions and exports are available. Consider that workflow alongside your restaurant management software. For a separate view of reservation operating costs, see the guide to measuring no-show costs.
Next step: Write down your must-pass tasks and request a safe demonstration. Compare those requirements with the workflows available from Fleksa's restaurant reservation system.
Frequently asked questions
Is a keyboard-only check enough?
No. It can reveal focus and navigation problems, but it does not show what a screen reader announces. Run both checks through the same essential booking tasks.
Should a phone booking option replace an accessible online flow?
No. A staffed alternative can help when someone needs assistance, but it does not show that a guest can book independently online. Record the online failure and ask for a fix.
What if the vendor cannot simulate confirmation?
Mark confirmation as untested, not passed. Ask for a safe preview or test method, then retest before accepting that part of the flow. Do not use a real payment or send a guest message for practice.
