Are QR menus accessible? Older guests, low vision and guests without a phone

A QR menu is not accessible to every guest on its own. Guests with low vision, guests who use screen readers, many older guests and anyone whose phone is dead or missing can be shut out of a QR-only menu. The fix isn’t to drop QR codes; it’s to treat the code as one way to order. Keep the printed menu on offer, make the table card easy to read, test the digital menu with a screen reader, and make sure a member of staff will take an order the usual way.

This post covers who has trouble with QR menus and why, a checklist for the card and the menu page, how to test with a screen reader in ten minutes, and what the human path looks like in WaiterPilot. It isn’t legal advice: if you need to know what accessibility law requires where you operate, ask a lawyer.

Who has trouble with QR menus?

Short answer: older guests most of all, plus guests with low vision or limited dexterity, screen-reader users, and anyone without a working phone at that moment.

The survey data is clear about age. In the National Restaurant Association’s 2024 survey of full-service diners, 59% would open a menu by QR code and 48% would order with one. By generation, 69% of millennials would order by QR code, against 21% of baby boomers (NRA, 2024).

Table: share of full-service diners who would order by QR code, by generation (NRA Restaurant Technology Landscape Report, 2024)

Other surveys point the same way. A William Blair survey reported by Restaurant Dive found “over 45% of consumers” uncomfortable using QR codes to view menus, order and pay, rising to 65% among consumers over 60 (Restaurant Dive, 2023; the sample size wasn’t stated). A Cornell study of tabletop devices found that “about one-quarter of all guests do not like to use the technology” (Susskind and Curry, 2016).

Age is only part of it. The barriers are specific:

What makes a QR table card accessible?

Short answer: big, plain, high-contrast, placed where a seated guest sees it, and honest that paper is available.

The card is the first thing every guest meets, and the easiest part to fix. Most problems come from cards designed to look nice rather than to be read across a table in dim light.

1. One code per table, upright and facing the seats. Flat cards under glasses and plates get missed. Each WaiterPilot table has its own QR code, and the table cards print in three sizes; use the largest your tables allow.
2. Large type and strong contrast. Dark text on a light background, no thin script fonts, no text over a photo.
3. Say what the code does. “Scan to see the menu and order from your phone.”
4. Say no app is needed. With WaiterPilot the menu opens in the phone’s browser, with no app to download and no sign-up.
5. Say paper is available. “Prefer a printed menu? Just ask.” This one line matters most for the guests in the table above.
6. Put the table name on the card. It helps staff and guests talk about the same table.
7. Keep the code clear of glare and scratches. Glossy laminate under a pendant light can stop a scan. Test each card from a seated position.
8. Check every card weekly. A card that doesn’t scan is worse than no card.

Our QR code table cards guide goes into placement, sizes and upkeep.

What makes the menu page itself accessible?

Short answer: real text instead of an image, labelled buttons, readable sizes, and as few steps as possible to order.

You may not control how a vendor builds its menu page, but you can test it and you can choose. Look for these, and ask any vendor about each:

• Text, not a picture of a menu. A menu uploaded as a photo or image-only PDF is hard to zoom cleanly and screen readers often can’t read it. A web page with the dishes as text works far better.
• It follows the phone’s text size. Turn up the text size in the phone’s settings and reload. Does the menu get bigger, or stay tiny?
• Buttons with names. A screen reader should announce “Add”, “Confirm” or “Call waiter”, not “button, button, button”.
• Big enough tap targets. Buttons you can hit with a thumb on the first try.
• No time limits. A guest who reads slowly shouldn’t lose their cart.
• Few steps. Every extra screen is a place to give up.

Then ask the vendor directly: “Do you publish an accessibility conformance report, and against which standard?” The common reference is the Web Content Accessibility Guidelines (WCAG), published by the W3C. A vendor that has tested against it can say so and show you the report.

We don’t publish a WCAG or other accessibility conformance claim for WaiterPilot. What we can describe is how the guest side works. Guests can type questions in their own words instead of hunting through categories, and the chat answers from your menu. A dish name in the chat opens the dish photo. Test it with your own phones and guests, using the method below, before you rely on it.

How do you test a QR menu with a screen reader?

Short answer: turn on VoiceOver or TalkBack, close your eyes, and try to order one drink. It takes ten minutes.

You don’t need an expert for a first pass. You need two phones and a little patience.

1. Turn on the screen reader. On an iPhone: Settings, Accessibility, VoiceOver. On Android: Settings, Accessibility, TalkBack (the path varies a little by phone). Learn the basic gesture first (swipe right to move to the next item, double-tap to activate).
2. Open the menu from the table card. Can you open the camera and scan with the screen reader on? Many blind guests will ask staff for help here, so note how your staff would help.
3. Find one drink. Does the screen reader read dish names and prices? Or does it say “image”?
4. Add it and open the cart. Are the buttons announced with names?
5. Confirm the order. Can you tell that it went through?
6. Call a waiter. Can you find the button?
7. Turn the text size up to the largest setting and repeat steps 3 to 5 with the screen reader off.
8. Write down every place you got stuck. Send the list to your vendor and ask what they will fix and when.

If you get stuck at step 3 every time, that guest will need a person, and that’s fine, as long as your staff know it.

What is the human path in WaiterPilot?

Short answer: your staff, with two tools that keep a paper order and a phone order on the same table.

WaiterPilot is built to sit alongside your printed menu and your servers, not in place of them. For guests who can’t or won’t use the phone:

Table: how a guest who doesn’t use the phone is served at a WaiterPilot table

Every phone at the table sees the same live bill, and guests can split it evenly or see just their own share. Payment still happens with your staff; WaiterPilot takes no payments. More on the waiter call and live bill page.

A worked example: one Saturday lunch at Casa Olivo

Casa Olivo is a fictional restaurant (an example, not a customer). The table mix below is an assumption to show the routine, not a measurement.

Casa Olivo has 20 tables. Over a Saturday lunch, the owner expects tables like these:

The routine that makes it work is one sentence in the pre-shift briefing: “Offer a printed menu to every table that hasn’t picked up a phone within a minute or two of sitting down.” No guest has to ask for paper, and no guest is left staring at a card.

Is a tablet or kiosk more accessible than a guest’s phone?

Short answer: it solves the “no phone” problem, but not the others.

A tablet on the table means every guest has a screen, whatever their phone. It doesn’t make small text bigger or add labels for a screen reader, and the guest’s own phone already has their text size and screen-reader settings switched on. Compare the hardware costs in kiosks, table tablets or guests’ phones. For most table-service restaurants, a printed menu plus a server is the cheapest accessible fallback there is.

The accessibility checklist

1. The printed menu stays, and staff offer it without being asked.
2. A large-print copy of the menu is kept at the host stand.
3. Table cards: large type, strong contrast, plain words, “printed menu available”, table name.
4. Every card scans from a seated position, checked weekly.
5. The menu page is text, not an image, and follows the phone’s text size.
6. You have tested ordering one drink with VoiceOver and TalkBack.
7. Staff can add dishes for a table that ordered on paper.
8. Staff know the waiter-call screen and answer calls quickly.
9. You’ve asked your vendor for an accessibility conformance report.

What to do next

Run the ten-minute screen-reader test on whatever QR menu you use today, and add “printed menu available” to your table cards. If you’re comparing ordering tools, read do customers like QR code menus? for the survey picture, and see the restaurant QR buyer’s checklist for the questions to ask every vendor. To test WaiterPilot’s guest screen on your own phone, try a sample order. It costs $200 per location per month after 30 days free; see pricing.