Guests can complete a QR order with a screen reader or keyboard only if every step of the ordering flow supports the controls they use. A menu that reads aloud is not enough. Guests also need to open the ordering page, choose items and modifiers, understand the total, correct errors, and reach an understandable confirmation.
Before you buy, ask the vendor to demonstrate the complete flow in a safe practice environment. Check both screen-reader use and keyboard-only navigation. If a required step cannot be completed independently, treat that as a buying issue, not a minor menu problem. Keep a staffed ordering option available while you assess the software and after launch.
Map the full journey before the demonstration
Start with the way a guest reaches the ordering page. Scanning a code may be straightforward for some guests but difficult for others. Ask whether staff can provide a direct link or another way to open the same table-specific ordering flow. A keyboard user needs a usable route into the page, too; do not assume everyone can aim a phone camera at a code.
Once the page opens, check how it identifies the table. A guest should be able to understand which table is associated with the order and what to do if it is wrong. If staff must correct table identity, establish how the guest requests help and how the correction reaches the team.
Map the rest of the journey in order:
- Find and choose an item. Can a guest move through categories, hear or read item names and prices, and select the intended item?
- Choose modifiers. Can the guest find required choices, understand which options are selected, and recognize any extra charge?
- Review the cart. Can the guest change a quantity, remove an item, and identify the updated total?
- Pay or submit. Can the guest understand the required fields, correct a mistake, and tell when the order has been submitted?
- Receive confirmation. Can the guest find a clear status and know whether staff have received the order or further action is needed?
Check the actual payment step, not just the restaurant menu. A separate payment screen can introduce new controls, focus problems, or errors. Ask the vendor how its practice environment represents that step without charging a real card.
Fleksa's QR ordering software lets guests scan, order, and pay at the table in a browser without downloading an app. Ask Fleksa to demonstrate the accessibility of the specific flow and setup you would use; browser ordering alone does not establish that every step is accessible.
Use a task-based acceptance script
Use the same tasks for each product, and record the device, browser, screen reader, and keyboard setup. Include at least one screen-reader session and one keyboard-only session. Where possible, involve people who regularly use those tools and pay them for their time. One person's experience is useful, but it cannot represent every device or access need.
The following is a hypothetical acceptance test, not a reported customer result. Assume a restaurant sells a $12 bowl with a required choice of base and an optional $2 topping. The practice order contains one bowl and the topping, for a $14 item total before any other charges. The test uses a simulated checkout that creates no real payment, guest message, or kitchen order. The figures demonstrate price announcements; they are not a quote or an estimate of operating cost.
Give the tester the destination rather than instructions for each control: open the table's ordering page, order the bowl with a base and the topping, review the total, and reach simulated confirmation. Let the tester say what they expect to happen. Avoid taking the device and fixing a problem for them; that can hide a barrier a guest would encounter alone.
Use this worksheet to record whether each task can be completed independently. A pass requires an understandable result as well as a working control.
| Task | What to check | Acceptance boundary |
|---|---|---|
| Open the order | Direct link or scan leads to the correct table flow; table identity is understandable. | Pass if the tester can enter and identify the table without staff navigating for them. |
| Choose the bowl | Item name, $12 price, required base, and selected state are available through the input method. | Pass if the tester can select the item and a base and verify both choices. |
| Add the topping | The $2 charge and selected state are clear; the cart reflects the change. | Pass if the tester can find the $14 item total and remove or change the topping. |
| Submit and confirm | Payment fields, errors, submission control, and simulated status are accessible. | Pass if the tester can correct an intentional error and identify the final simulated status independently. |
Run the tasks at a normal pace, then repeat a few changes: remove the topping, add it back, and change the base. Check whether the cart remains understandable after each change. If the tester gets stuck, note where and what assistance was needed. A completed order after an employee takes over is useful service recovery, but it is not an independent pass.
For a keyboard-only check, use the available keys to move forward and backward through controls, activate choices, and dismiss any dialog. The visible focus indicator should make it clear where the user is. For the screen-reader check, listen for control names, roles, selected states, instructions, and changes. If the tester must guess what an unlabeled button does, record the task as blocked.
Record barriers that change the buying decision
Write down the exact step, action, expected result, actual result, and whether the guest could continue independently. A short screen recording or written sequence can help the vendor reproduce a problem, provided the practice session contains no real guest or payment information.
Focus and navigation
Watch what happens when an item opens, an error appears, or a dialog closes. Does focus move somewhere useful? Can the guest return to the item or cart? A screen-reader user may hear a different part of the page while a keyboard user may see focus disappear. Record those as separate observations when they affect different inputs.
Labels and choices
Controls need names that explain their purpose. “Add topping” is more useful than an unlabeled icon. Required and optional choices should be distinguishable, and the user should be able to tell what is selected. Ask the vendor to show how instructions and choice limits are communicated without relying only on color or position.
Errors and price changes
Intentionally leave the required base unselected in the simulation. A useful error identifies the problem and helps the guest find the field to correct it. Check whether the error is available to the screen reader and whether keyboard focus makes the next step apparent.
For the topping, check both the option's extra charge and the changed cart total. The guest should not have to discover an added charge only at final submission. Also check any fees shown in the actual checkout separately; the $14 practice item total does not include them.
Give each barrier an owner and a next step. For example, a missing item label may be a configuration issue, while a focus trap in checkout may need a software change. Ask who can fix each issue, whether the fix applies to your setup, and when you can retest it. Avoid accepting a general accessibility statement as a substitute for a working order flow.
Set a decision boundary and a staffed alternative
For the hypothetical test, a sensible acceptance boundary is independent completion of all four worksheet tasks using both evaluated input methods, including recovery from the intentional error and a clear simulated confirmation. If one required step fails, do not count the product as meeting that boundary merely because the menu itself is readable.
A failure does not automatically rule out a vendor forever. It does mean you need a written remediation commitment, a date or milestone for a retest, and a service plan for guests in the meantime. If the vendor cannot demonstrate a fix or offer a credible path to one, compare another ordering flow rather than making accessibility depend on staff intervention.
Staffed ordering remains important even when the test passes. Decide how a guest can ask for help without scanning, who takes the order, and how that order reaches the kitchen and the correct table. Train staff to offer the same menu choices and explain prices without assuming why a guest prefers assistance. Confirm how payment works for the staffed route and how staff recognize whether a QR order is pending, paid, or submitted before taking another order.
A simulation is not a live service pilot. Once the safe checks are complete and any fixes have been retested, a separately planned live pilot can reveal handoff issues during service. Tell participating staff what is live, use normal safeguards for actual orders and payments, and keep the staffed route available. Do not use real card payments or send guest messages during the practice scenario.
Consider the wider service workflow as well. Your restaurant management setup and staff handoff matter when an order moves beyond the guest's screen. For a broader look at where self-ordering fits alongside table service, read the guide to QR ordering in table service.
Next step: Bring this worksheet to a vendor demonstration and ask to complete the same simulated order with your chosen devices and assistive tools. You can also discuss the workflow and current product fit with Fleksa.
Frequently asked questions
Does an accessible QR menu mean guests can place an accessible order?
No. Ordering adds item controls, modifiers, a cart, checkout, and confirmation. Each step needs to work with the guest's input method, including any separate payment screen.
Should we test with a screen reader or a keyboard?
Test both. Screen-reader users need understandable names, states, and announcements; keyboard-only users also need visible focus and a way to operate every required control without a pointer.
What if a guest cannot scan the QR code?
Offer a staffed ordering route and ask the vendor whether a direct link can open the correct table-specific flow. Check that staff can handle table identity, payment status, and kitchen handoff without relying on the guest to scan.
