Before accepting an online ordering provider, test the whole transaction with a screen reader: find an item, select its options, add it to the cart, correct an error, review the total, reach the payment screen and understand the confirmation. A menu that sounds clear can still lead to a checkout a guest cannot complete.
Ask the provider for a safe demonstration or sandbox that covers its ordering flow and payment handoff. Include a person who regularly uses a screen reader if possible, and let that person navigate without being coached through each screen. Record what they hear, where they get stuck and whether they can recover.
Prepare a realistic menu and test setup
Choose a common order with enough choices to exercise the system. The restaurant supplies the menu details: item names, prices, required choices, optional extras, pickup or delivery rules, and the information a guest must enter. The provider should explain how to access its test environment, which parts of checkout it controls and which parts belong to a payment provider.
Hypothetical test: A guest orders one sandwich for pickup. The sandwich costs $12, a side choice is required, and avocado is an optional $2 extra. The expected item total with avocado is $14. This is a navigation example, not a quote or a full order cost: it includes the item and selected extra, but excludes fixed charges, other variable charges and exception costs such as an order change. The checkout should identify any actual fees or other charges separately.
Pick a browser and screen reader the tester knows. Note their names, versions and device type so the provider can reproduce a problem. If many of your guests order on phones, include a mobile screen reader in your evaluation as well as a desktop setup. One combination cannot establish that every device and browser will work.
Use a sandbox or another provider-approved simulation. Do not enter real card details, send a real guest message or dispatch a courier. Ask how the simulation handles order notifications and payment before starting. If the provider cannot simulate part of the flow, mark that part untested rather than guessing what would happen.
The test applies whether guests start on your restaurant website or enter the ordering page directly. Ask the provider to identify the actual starting link a guest will use, including any transition from the website into a separate ordering application.
Test menu choices and cart changes
Start from the guest-facing entry point. Have the tester find the sandwich using the screen reader and keyboard or the device's usual screen-reader gestures. Listen for a useful item name and price, then open the item. The tester should be able to tell which controls belong to that item without relying on the location of a picture or color.
At the option screen, check that the required side is identified as required and that each choice has a recognizable name. Select avocado and listen for its name, extra price and selected state. Then remove and reselect it. A guest should not have to remember an unlabeled visual position to know what was chosen.
Try to add the sandwich without selecting a side. The important question is not simply whether an error appears. Can the tester find the error, understand what needs to change and return to the side choices? After choosing a side, add the item and check whether the screen reader communicates the result. If the page changes, the tester should be able to find the next relevant place without hunting through the entire page.
Open the cart and review the item, side, avocado and $14 item total. Change the quantity or remove the extra, then check that the changed selection and amount are available to the screen reader. For example, removing avocado should leave one $12 sandwich before any other order charges. Also try removing the item and returning to the menu. A cart update that is visible but not discoverable by the screen reader can leave the guest unsure whether it worked.
Do not coach the tester by pointing to the right button. If assistance is needed, note exactly what you said and whether it allowed the tester to continue. That distinction helps separate an independently usable flow from one that works only with staff help.
Follow the payment handoff and confirmation
Continue to checkout using the simulated order. Check that the tester can identify pickup, enter any required contact details and review the order before payment. Deliberately leave one required field empty. Listen for an error that identifies the field and gives enough direction to fix it. Then correct the entry and confirm the guest can proceed without losing the cart.
At the payment handoff, ask the provider which screen or embedded form the guest will encounter and who operates it. The tester should be able to find the payment fields, understand their labels and identify any instructions or error messages. If the provider offers test payment credentials for its sandbox, use only those credentials; never use a real card for practice. Do not treat a simulated approval as evidence that a live payment was processed.
Follow the simulation through its final available step. Can the tester tell whether the order was submitted, whether payment was simulated successfully, and what happens next? Look for a confirmation with understandable order details and a way to find any reference or pickup information presented. If the simulation stops before confirmation, record confirmation as untested and ask for a safe way to inspect it.
A payment page can be maintained by a different company from the ordering page. That does not make a broken handoff less important to the guest. Ask both parties who owns the issue, how it will be fixed and how they will demonstrate the fix across the handoff.
Record blockers and make the buying decision
Use the script below for each provider you evaluate. The expected result describes what the tester needs to discover; it is not a claim that a particular product provides it. Record the actual words announced when practical, along with the action immediately before the problem.
| Step | Tester action | Useful result to check | Record if blocked |
|---|---|---|---|
| Menu | Find and open the sandwich | Item and price are identifiable | Control or announcement that prevented selection |
| Options | Skip the required side, then correct it and select avocado | Requirement, error, choice and extra price are understandable | Error text, location and recovery attempt |
| Cart | Add the item, remove avocado and review the cart | Selection and changed item total can be found | What was announced after the update |
| Checkout | Leave a required field empty, fix it and continue | Error identifies the correction; cart remains available | Field, message and whether the tester could proceed |
| Payment and confirmation | Complete the available sandbox flow | Payment fields and simulated outcome are understandable | Handoff owner and any untested final step |
For each blocker, add the device, browser, screen reader and version, plus whether the tester could recover without help. Separate a minor inconvenience from a failure that prevents an order. For example, an extra navigation step may be frustrating; an inaccessible required side or payment field can stop the transaction altogether.
Send the results to the provider and ask for a written response: who will fix each blocker, what the proposed remedy is, when it can be demonstrated and whether the same tester can retest it. Ask how menu changes, checkout updates and third-party payment changes are handled after launch. A demonstration of a fix is more useful than a broad assurance that the product is accessible.
Use the findings alongside the other buying questions in the online ordering buying guide. If a provider cannot demonstrate a critical checkout step, do not mark it as passed. Compare the remaining risk with your operating needs, and consult a qualified adviser if you need guidance on contract terms or legal obligations. This script helps find transaction barriers; it does not establish legal compliance.
Run the checklist against your current setup first. Then ask Fleksa about its restaurant online ordering, request a safe transaction demonstration and confirm US availability for your location.
Frequently asked questions
Is checking the menu enough?
No. Test required options, cart updates, errors, checkout, the payment handoff and confirmation too. A guest needs to understand and complete the transaction, not just browse items.
Should we place a real order during practice?
Use a sandbox or provider-approved simulation first. Practice must not trigger a real card payment, guest message or courier dispatch. Mark any step the simulation cannot cover as untested.
Does a successful script prove compliance?
No. It provides evidence about the specific flow, devices and screen readers tested. Retest changes and seek qualified advice about any legal requirements that apply to your restaurant.
