Guests should be able to enlarge an online menu and still choose food, check the total, and reach payment without losing controls or essential information. The only reliable way to judge your setup is to follow the ordering path at several zoom levels, including the payment handoff, and record what happens.
Start with a practice environment or a vendor-provided test mode. A useful check covers more than whether the menu text gets bigger: look for options hidden behind buttons, totals cut off at the edge of the screen, and error messages that appear outside the visible area. This is a magnification and layout check; a separate keyboard-only check is still worth doing.
Set up a repeatable zoom and viewport test
Pick a representative ordering path before changing the zoom. Include an item with required choices, an optional extra, a cart edit, a fulfillment choice, and a payment handoff. If your restaurant offers both pickup and delivery, check both paths because their fields and charges may differ.
Ask whoever manages the ordering site for a safe test environment, the supported browsers and devices, and a way to inspect the payment handoff without making a real payment. Confirm that the test cannot send a guest message, dispatch a courier, or create a live order for the kitchen. If a safe version of a step is unavailable, stop before that step and ask the vendor to demonstrate it safely.
Record the browser, device, starting window size, zoom setting, and ordering link for each run. A viewport is the visible area of the browser page. Keep the browser window at the same size when comparing zoom levels on a computer; otherwise, you will not know which change caused a layout problem. Record the window dimensions where practical.
On a phone, run a separate check with the device and browser identified. Browser zoom and device text-size settings can affect a page differently, so record which setting you changed. Do not treat a desktop zoom run as proof that the phone layout works, or a phone text-size check as proof that browser zoom works.
The matrix below is a starting worksheet, not a promise that any particular ordering system passes. Use the same order path in each row. Mark a step as blocked when a guest cannot proceed or understand a necessary choice; note lesser friction separately.
| Run | Setup | Check along the order path | Record |
|---|---|---|---|
| Baseline | Desktop browser, 100% zoom | Complete the safe practice path and note the normal layout | Browser, window size, and any existing issues |
| Enlarged | Same browser and window, 200% zoom | Find item choices, cart controls, totals, and errors | Clipped content, overlap, and extra scrolling |
| Further enlarged | Same browser and window, 400% zoom | Repeat the path; check whether required controls remain reachable | Any blocking step and how to reproduce it |
| Phone | Named phone and browser; record text-size or zoom setting | Repeat the path and inspect the payment handoff safely | Device, setting, and differences from desktop |
Some scrolling is expected on a smaller visible area. The important question is whether guests can find and use what they need without a control covering it or a required instruction disappearing. If the page requires scrolling sideways, check whether the guest can still connect labels, choices, and prices without losing their place.
Check menu choices and cart totals
Start at the point a guest actually uses, such as the menu link on your restaurant website. At each zoom setting, find an item, open its details, make every required selection, and add it to the cart. Check that the item name, option labels, prices, and add button remain visible and understandable.
Watch what happens when a panel or pop-up opens. Can you see its heading and the required choices? Does a fixed header, cart bar, or cookie notice cover the last option? If the panel has its own scroll area, check that you can reach the bottom and return to the menu. A button that looks visible but cannot be reached or used is a blocker.
Hypothetical practice example: A guest selects a $12 sandwich, adds a $2 extra, and includes a $5 side. The assumed delivery charge is $3, making the displayed total $22: $12 + $2 + $5 + $3. This example includes those item and delivery amounts only; it assumes no other charges and excludes tax. It is not a quote or a claim about Fleksa pricing.
At each zoom level, check that the cart shows the extra and its price, then change the quantity or remove the side. With the side removed, the assumed total should be $17. Restore it and check that the total returns to $22. The point is not just to verify arithmetic. A guest also needs to see what changed and understand which charges are included.
Compare the item price, any option price, fulfillment charge, and final total at the relevant stages. If a line is truncated, try to find whether its full label is available without guessing. If a real checkout calculates additional charges later, make sure the final review displays them before a guest commits. Do not assume an earlier subtotal is the final amount.
For a broader purchase decision, the online ordering buying guide covers questions beyond magnification. Keep this exercise focused on whether the actual ordering path remains usable when enlarged.
Inspect errors and the payment handoff
In the safe environment, deliberately leave a required item choice blank and try to continue. Then try an invalid value in a required checkout field. The page should make the problem understandable and show the guest where to correct it. Check whether the message appears near the field, whether it is cut off, and whether a sticky element covers it at higher zoom.
After correcting the entry, confirm that the guest can continue without rebuilding the cart. Check whether the entered values and selected items remain visible. If the page moves to the error, make sure the relevant instruction is still on screen; if it does not, check whether the guest has a clear way to find the field that needs attention.
Payment deserves its own pass because the handoff may open another page or an embedded form with a different layout. In test mode, follow the path to the point the provider permits and inspect the order summary, payment fields, and next-step controls at each setting. Never enter a real card or submit a real payment for practice. Do not trigger a guest message or courier dispatch.
If the safe environment stops before the final confirmation, record that boundary rather than marking the whole flow as passed. Ask the ordering vendor and payment provider how they can demonstrate the remaining screens without a real transaction. A simulated check can reveal a layout problem; it does not prove that every live payment or fulfillment event will work.
A live service pilot is a separate decision. If you plan one, agree on its scope and safeguards with the vendors first. Do not call a simulated run a live pilot, and do not use a guest's order as an unannounced test.
Log blockers, compare fixes, and retest
Write one issue per record so the person fixing it can reproduce it. Include the ordering link or test environment, device, browser, window size, zoom or text-size setting, item selected, and exact steps. Describe what you expected to see and what appeared instead. Capture a screenshot showing the problem and enough surrounding page to identify the step, while leaving out personal and payment information.
For example, a useful report might say: “At 200% zoom on the recorded desktop window, open the sandwich, select the required option, and scroll to the bottom. The add button overlaps the last choice, so I cannot select it.” Avoid a report such as “zoom is broken”; it leaves the vendor to guess where to start.
Sort findings by effect on an order. A hidden required option, unreadable error, inaccessible total, or unreachable payment control can stop a guest from completing the flow. Awkward scrolling or a label that wraps but remains clear may be less urgent. Ask the vendor for a proposed fix and a safe way to verify it across the affected steps.
Retest the original failure using the same setup, then repeat the full order path at the other recorded settings. A change to a sticky cart bar, for example, might clear one menu panel but cover an error elsewhere. Mark the issue resolved only when the original step works and the relevant surrounding path still makes sense. Keep unresolved or untested payment steps visible in the record.
Use this checklist on your current setup, then ask Fleksa about restaurant online ordering and verified US availability if it is relevant to your search. Bring your matrix and ask how the ordering and payment steps can be checked safely before you decide.
Frequently asked questions
Is enlarging the menu enough to pass the test?
No. Follow the order through item choices, cart changes, errors, and the safe payment handoff. Text can enlarge while a required control or total becomes hard to reach.
Should I test zoom on both a computer and a phone?
Yes. Record each device and setting separately. Desktop browser zoom and a phone's text-size or zoom settings can produce different layouts.
What if I cannot safely test the final payment screen?
Stop before any real transaction and mark the remaining step untested. Ask the vendor or payment provider for a test mode or a safe demonstration; do not use a real card for practice.
