Before accepting a restaurant website, test whether a guest using a screen reader can find the menu, understand its contents, start an order, and locate or use the reservation and contact options you offer. Test the full journey, not just the menu page. A guest also needs to navigate the site, choose items, understand form fields and recover from mistakes.
Agree with the vendor on the tasks, devices and acceptance criteria before the handoff. A screen reader speaks or presents information from the page, but it does not make every control understandable by itself. The useful question is whether a person can complete each task without guessing what a button, link or field does.
Choose pages and tasks that match your restaurant
Start with the journeys guests actually need. The owner or manager should supply the current menu, service details and common ordering or booking scenarios. The vendor should identify the pages and any connected ordering or reservation services, provide access to a safe test environment, and explain which parts its team can change.
Include a person who regularly uses a screen reader if possible. Their feedback can reveal problems a first-time tester may miss. A quick owner check is still useful, but it is not a substitute for feedback from experienced users.
Choose at least one supported phone and one computer setup with their screen readers and browsers. Ask the vendor which combinations it supports, then record the exact combinations used. Test both keyboard navigation on the computer and the screen reader’s touch navigation on the phone. Do not assume a successful desktop check covers mobile.
The table turns common guest needs into observable tasks. Adjust it to the services you actually offer; a restaurant without reservations should still test how guests find its contact details.
| Guest task | What to check | Accept when |
|---|---|---|
| Find hours and contact details | Navigate from the home page to the current location, hours and phone number. | The guest can identify the correct information and return to the site navigation. |
| Explore the menu | Find a category, an item, its price and relevant description. | The information is announced in a meaningful order without relying on a picture. |
| Build an order | Find an item, choose required options, change quantity and review the cart. | Controls and choices are understandable, and the cart reflects the selections. |
| Find a table or contact the restaurant | Find the booking option, enter sample details if available, or locate the phone number. | The guest can understand the next step and any required fields or errors. |
For ordering and reservations, agree on a stopping point in a test environment. Use sample details and simulated checks that do not charge a card, send a guest message or dispatch a courier. Do not press a final submission control unless the vendor has confirmed that the test environment prevents those real-world actions. A separate live service pilot, if you choose to run one, needs its own authorization and operating plan.
Check headings, links, labels and feedback
Begin at the home page without using the mouse. Can the tester reach the main navigation, understand where it leads and move to the page content? Listen to the headings as well as the text in sequence. Headings should help a guest understand the page’s structure and find sections such as menu categories.
Listen to links and buttons on their own. “View dinner menu” gives more context than several controls all announced as “click here.” If a control opens an ordering service or a reservation form, the guest should be able to understand that destination. The restaurant website and the connected service should feel navigable as one journey, even if different vendors maintain them.
On the menu, check more than whether item names are read aloud. Can the tester connect each price and description to the right dish? If important information is presented in an image, ask how a screen-reader user receives the equivalent information. Check any category filters or expandable sections: the tester needs to know what the control does and whether its content is open.
Forms deserve extra attention. Each field should have a meaningful label, and required choices should be understandable before the guest tries to continue. For an ordering flow, check item options, quantity, pickup or delivery choices where offered, and the cart. For a reservation flow, check fields such as date, time and party size where they appear. Make a deliberate mistake in the safe test environment and listen for an explanation of what needs correcting.
Also check what happens after an action. If adding an item changes the cart, can the tester find out that it changed? If an error appears, can the tester find it and return to the affected field? A page can have labeled controls and still leave a guest uncertain about the result.
Some third-party services may be outside the website vendor’s direct control. That does not make the barrier disappear for the guest. Ask who owns the fix, what alternative is available and whether that alternative lets guests accomplish the same task. For example, a phone number may help some guests, but it is not an equivalent ordering path for everyone.
Record barriers so someone can reproduce them
Give the vendor a separate report for each barrier. Include the page or step, the device, operating system, browser and screen reader, with version numbers. Describe what the tester did, what was announced or otherwise presented, what they expected and whether they could continue. Note the time and test account or environment when relevant; do not include real guest or payment details.
Hypothetical example: A tester on a phone opens the sample lunch menu, selects a sandwich and reaches a required bread choice. The screen reader announces two controls as “button” without distinguishing the choices. The tester cannot confidently select the requested bread and stops before adding the item to the cart.
A useful report for that example would look like this:
- Task and location: Add the sample sandwich to the cart; bread choice in the item dialog.
- Setup: Record the phone model, operating system version, browser version and screen reader version used.
- Steps: Open the lunch menu, select the sandwich and move through the bread controls with the screen reader.
- Actual result: Both choices are announced as “button,” with no distinct bread name.
- Expected result: Each choice has a distinguishable name, and the selected state is understandable.
- Impact: The tester cannot reliably complete the required choice.
Add a screenshot or recording only if it helps the vendor reproduce the issue and does not expose private information. A recording can supplement the written steps, but it should not replace the device details or expected result. Ask for a named owner and a proposed fix date for each issue, particularly when the problem sits in a connected online ordering flow.
One test session cannot prove that every guest can use every page. It can, however, establish whether the agreed tasks work on the setups you tested and give the vendor clear work to do when they do not.
Retest fixes before accepting the site
When the vendor says a problem is fixed, repeat the original steps on the same device and browser combination. Then continue the whole task. A better label on the bread choice is not enough if the guest still cannot tell whether the selection was saved or review it in the cart.
Retest related controls, too. A change to one item dialog may affect other items or option groups. If the vendor changes shared navigation, revisit the menu, ordering and contact journeys on both agreed setups. Record the new result against the original report: resolved, still blocked or changed in a way that needs another fix.
Use the acceptance criteria from the checklist rather than a count of issues alone. A remaining barrier that prevents an order or hides the phone number needs a clear decision before signoff. Ask the vendor to explain the impact, the owner of the fix, its target date and any usable interim route. If the agreed critical tasks remain blocked and there is no workable alternative, delay acceptance or agree in writing on the outstanding work before proceeding.
Keep the task list and issue reports after launch. Recheck the affected journeys when the menu, ordering connection or booking flow changes. When comparing vendors, pair this checklist with the restaurant website builder comparison and ask who will handle accessibility fixes after handoff.
Use the checklist on your current setup, then ask Fleksa about its restaurant website and verified US availability if it fits your search. Share your required tasks and ask how the proposed setup can be tested before acceptance.
Frequently asked questions
Is checking the menu enough?
No. Test how guests reach the menu and what happens next, including item choices, the cart, reservation options and contact details. A readable menu does not establish that the rest of the journey works.
Can an owner perform the screen-reader check?
Yes. An owner can follow the task list and document obvious barriers. Include experienced screen-reader users where possible, and agree with the vendor on the devices and browsers to cover.
Should we place a real order during practice?
No. Use a safe test environment and stop before any action that could charge a card, send a guest message or dispatch a courier. Treat any authorized live service pilot as a separate activity.
