Who cannot scan, and roughly how many
It helps to be concrete rather than to talk about accessibility in the abstract. In a full dining room on a normal evening, the people your code does not serve are these.
- Someone whose phone is dead, or nearly, and who is rationing it for the journey home.
- Someone with no mobile data allowance left, in a room where the wifi is weak or the login is a captive portal nobody can get through.
- An older guest with a phone whose camera does not detect codes automatically, and who does not know a scanning app is needed.
- A guest with low vision, for whom the question is not scanning but whether the page that opens can be read aloud or enlarged.
- A guest with a tremor or limited hand mobility, holding a phone steady enough to focus on a 4cm square at arm's length.
- A guest who has left their phone in a bag on purpose and would like dinner without a screen.
That last group is not an accessibility need and it is worth counting anyway, because the operational answer is identical and the number of people involved is not small.
Screen readers, and why the format decides this
A guest with low vision typically uses their phone's built-in screen reader, which reads the page aloud, or the system text-size setting, which enlarges it.
Whether either works is decided entirely by what sits behind the code.
| Menu format | Read aloud | Enlarges with system text size | Reflows on a phone |
|---|---|---|---|
| HTML page with real text | Yes | Yes | Yes |
| Partially, often badly | No — it zooms, it does not reflow | No | |
| Photograph of a printed menu | No | No | No |
The photograph row is worth sitting with. A menu published as an image contains no text at all as far as any assistive technology is concerned. It is a picture of words, and a guest using a screen reader gets silence.
This is the same property that decides whether a search engine can read your menu, which is a useful thing to know when arguing for the budget — see restaurant menu SEO.
Making the page itself workable
Assuming the menu is real HTML, a handful of things separate a usable page from a technically-accessible one.
- Do not disable zoom. Some sites lock pinch-zoom to make the layout behave; on a menu it removes the main tool a low-vision guest has.
- Respect the system text size rather than fixing text in pixels. A guest who set their phone to large text set it for a reason.
- Keep contrast strong. A menu designed to look moody at full brightness is unreadable at the brightness people actually use in a restaurant.
- Put the menu first. A cookie banner, a language picker, or a table-number prompt in front of the content is an obstacle for everyone and a barrier for some.
- Make it work without JavaScript succeeding. A menu that renders nothing on a slow connection has failed the guest with the worst signal, who is usually the guest with the oldest phone.
- Do not convey dietary information with colour alone. An icon that is only distinguishable by being green is invisible to a colourblind guest.
None of these are exotic. They are the ordinary properties of a well-built page, which is the point: accessibility here is mostly a consequence of not doing unusual things.
The physical code is part of the problem
Some of the difficulty is not on the phone at all.
- A code that is too small forces the guest closer, which is exactly the movement a guest with limited mobility cannot easily make.
- A code on a wall or a window can be unreachable from a wheelchair. If a code is the only route to the menu, its position is an access route.
- A gloss laminate under a downlight requires the guest to tilt the card to defeat the reflection — a two-handed operation.
- A tent card that must be picked up and held steady is harder than a flat sticker on the table.
Sizing generously helps all four, and costs nothing. The print guide has the numbers.
The staff brief, which matters more than any feature
Most of the bad experiences in this area are not caused by the menu. They are caused by two minutes of awkwardness at the table when something does not work.
What a brief needs to establish:
- Paper menus exist, everyone knows where they are, and offering one is normal rather than a concession.
- Offer without diagnosing. "Would you like a printed menu?" beats troubleshooting a guest's phone in front of their table.
- Never ask a guest to explain why they cannot scan. It is not information the restaurant needs.
- Know the answer to "is there an app?" — there is not, it opens in the browser.
- Be able to read the menu aloud, or bring the dish over. For a blind guest with no screen reader set up, a server reading the fish specials is the whole solution.
The second point is the one that gets missed and the one guests remember. A server who produces a paper menu in four seconds has solved the problem. A server who spends two minutes trying to make the guest's camera work has created one.
Print fallback, done properly
Common practice is a code on every table with a small number of printed menus in reserve. That is right, and there are two ways it goes wrong.
The first is that the printed copy drifts. The digital menu updates the moment someone changes a price; the laminated copies in the drawer do not, and nobody notices until a guest is charged something different from what they read. Reprint the paper copies on the same trigger that changes the menu, and destroy the old ones rather than leaving them in the drawer.
The second is quietly letting the reserve run out. Three copies that were adequate in February are not adequate for a coach party in August.
A ten-minute check on your own menu
You can run this yourself, today, with the phone in your pocket.
- Turn on your phone's screen reader and open your menu. If it reads dish names and prices aloud, you are in good shape. If it says nothing useful, your menu is an image or a PDF.
- Set the system text size to its largest and reload. The layout should reflow, not clip.
- Turn the screen brightness down to about a quarter and read it at arm's length.
- Turn off wifi and mobile data, then load the menu. You are checking what a guest with no signal sees — ideally a clear failure rather than a blank screen.
- Hand your phone to the oldest person you know and ask them to find the vegetarian dishes without help.
- Ask the floor staff where the paper menus are. If they hesitate, that is the finding.
Steps one and six catch most of what matters. Both are free.