How to Make Your Restaurant Menu Accessible to More Guests
A guest should be able to explore the whole menu, understand the prices, and make their own choice. Here is how to remove the reading and navigation barriers that get in the way, on a phone and at the table.
Menu accessibility · 10 min read · Published 5 September 2026 · By MenuSmart
What makes a restaurant menu accessible?
- Guests can reach and understand the full offer: Provide an easy-to-find menu link, clear categories, readable descriptions, and prices that stay with the right dish or drink. Include specials, sizes, supplements, and service hours in the same usable format.
- The menu works with different ways of reading: Use text that can enlarge, a layout that adapts to the screen, and controls that work with assistive technology. A design that looks clear to its author still needs practical testing.
- A QR code is one route to the menu: Offer a direct web link and an up-to-date paper option too. Someone without a usable phone, a steady camera, or a connection should still be able to browse and choose.
- Test a guest decision from start to finish: Ask someone to find a dish, read its description, establish the price for their chosen portion, and return to another category. Record where they lose information or need help, then fix those points first.
The problem: the menu opens, but the guest still cannot choose
Picture a hotel guest arriving late and opening the bar menu. The drink names are legible, but the small grey line with the serving size disappears against the background. Enlarging the page hides the prices. A companion takes the phone and starts reading aloud. The venue has a digital menu, yet the guest has lost something basic: the freedom to compare the options at their own pace.
Menu accessibility means making the information and the act of browsing usable for people with different visual, motor, and cognitive needs. W3C also identifies overlap between accessibility needs and changes that can accompany ageing; age alone does not tell you which format someone prefers. Restaurants, bars, and hotels can start by asking a concrete question: can a guest discover the same complete offer without depending on someone else to navigate it?
This guide applies selected checks from the Web Content Accessibility Guidelines (WCAG) 2.2 to menu service. The service routine and worked example are practical suggestions, not a full accessibility audit or a statement of legal compliance. Use the linked standards with your website provider for technical assessment, and involve people who use assistive technology when evaluating the result.
Barriers worth checking on your next shift
- The only entrance to the menu is a QR code
- Guests enlarge dish names but lose prices or portion details
- Categories or filters use unexplained icons
- A screen reader announces buttons without useful names
- The paper alternative omits drinks, specials, or current prices
Nine practical checks for a more accessible menu
1. Give guests a choice of ways to reach the menu
Place a clearly labelled menu link on the venue website and a readable web address beside the table QR code. Make the paper option easy to request. In 2019, RNIB Scotland announced an audio-menu initiative at The Huxley in Edinburgh, offering guests with sight loss a choice of listening on a tablet or their own smartphone. The useful lesson for a manager is to ask which route works for the guest. At a hotel, reception and the bar should be able to offer the same options without sending someone to another desk. RNIB: Food for thought (2019)
2. Keep dish names, descriptions, and prices in meaningful order
Use real page text, with headings and groups that reflect the menu. W3C explains that meaningful structure helps screen-reader users navigate to relevant sections. Give your provider a specific check: when a person reads a wine entry, do they encounter its name, glass or bottle size, and corresponding price together? A beautiful three-column layout can conceal a confusing reading sequence. Ask a regular screen-reader user to find one drink and one main course, including every option needed to understand the price. W3C: Page structure W3C: Images of text
3. Measure contrast, including the quiet details
WCAG 2.2 criterion 1.4.3 sets a minimum contrast ratio of 4.5:1 for normal text and 3:1 for qualifying large text. Have your provider measure the actual colours. Check descriptions, prices, supplements, and unavailable-item messages as carefully as headings. A pale-gold title may look appealing on a bar tablet while the smaller grey prices are hard to read. Repeat the practical reading check at the dimmest table and on the brightest terrace; a measured ratio does not describe every lighting condition. W3C: Minimum contrast
4. Let the guest enlarge the text
For ordinary menu text, criterion 1.4.4 requires enlargement up to 200% without losing content or functionality. Check intermediate sizes too. Open a long description and a dish with a supplement, increase the browser text size or zoom, and make sure the complete price is still reachable. If a language selector expands over the description, record the exact device, browser, language, and item. Send that reproducible example to the provider instead of reporting only that the menu looks too small. W3C: Resize text
5. Check that enlarged content still fits the reading area
Reflow is a separate check. Criterion 1.4.10 covers vertically scrolling content at a width equivalent to 320 CSS pixels, without lost information or two-direction scrolling, with exceptions for content that needs a two-dimensional layout. Ask your provider to test that condition. As a manager, follow a complete menu entry on a narrow phone: do you keep swiping sideways between its description and price? Include the longest translated item and the room-service charge. A desktop layout shrinking into miniature is a reason to investigate. W3C: Reflow
6. Make category and filter controls forgiving
Criterion 2.5.8 sets a 24 by 24 CSS pixel minimum for pointer targets, with defined exceptions including spacing. Larger, separated controls are a useful design aim. Check the close button, language picker, and any dietary filters, not just the main category buttons. Try moving from starters to desserts with one hand and changing a filter without hitting its neighbour. If the active category disappears into a crowded row, ask the designer to simplify the navigation before adding more categories to it. W3C: Minimum target size
7. Test navigation without a mouse
The menu's functions should be operable by keyboard, and the focused control should be visible; WCAG addresses these in criteria 2.1.1 and 2.4.7. On a computer, move through controls with Tab and Shift+Tab and use the relevant activation keys. Open and close a dish panel, switch language, and return to the menu. If focus gets stuck or becomes impossible to locate, capture where it happens. Ask the provider to check that sticky headers and cookie notices do not obstruct the controls either. W3C: Keyboard access W3C: Visible focus
8. Make labels carry the meaning
W3C says colour must not be the only way information is conveyed, and controls need names and states that assistive technology can determine. In a menu, pair icons with clear wording and make selected filters understandable. A leaf alone leaves the guest to guess its meaning. Keep any verified dietary or allergen explanation readable alongside the item, and provide a clear route to ask staff. A readable label improves access to information; it does not establish whether a dish is safe for a particular guest. W3C: Use of colour W3C: Name, role, value
9. Treat language switching as part of the same journey
W3C's language-of-page guidance explains that identifying the page language helps screen readers apply appropriate pronunciation. Ask your provider to check that each version declares the correct page language, and test pronunciation after switching with a screen reader that supports that language. Check the service details yourself: does a French-speaking guest find the same portion, supplement, and closing time as an English-speaking guest? Longer wording must remain usable. In a hotel, test breakfast, the lobby bar, and room service separately; successfully opening one translated section tells you little about the others. W3C: Language of page
A worked example: a hotel bar's wine list
Consider a hypothetical hotel bar with a wine list displayed as a scanned page. Its Sauvignon Blanc entry has three prices under distant column headings. Reception can share the file, but a guest enlarging it sees either the wine name or the prices. The large-print copy behind the bar includes only bottles. These are different failures: the digital format is awkward, the relationship between size and price is unclear, and the alternative offers less choice.
The manager rewrites the entry as explicit text: “Sauvignon Blanc — 125 ml glass €6; 175 ml glass €8; 750 ml bottle €30.” The designer keeps each size beside its price and gives Wines a proper section heading. Staff prepare a complete large-print version with the same sizes, then check both versions against the approved bar list. The prices are illustrative; the point is to preserve the guest's ability to compare the same options.
The team asks a tester to open the public link, find the wine, identify the 175 ml price, and move to an alcohol-free option. They repeat the journey with enlarged text and with a regular screen-reader user, then check it in each offered language. If a control remains inaccessible, the manager provides a usable alternative during service and assigns the digital repair to the provider. The paper copy is kept in the opening checklist so a later price change does not recreate the mismatch.
- Offer help without taking over: Address the guest directly and ask what would help. If they want the menu read aloud, include prices and relevant options and let them set the pace. Do not assume their companion should choose for them.
- Keep the full offer available on paper: Use a clear typeface, comfortable spacing, strong contrast, and a size the guest can actually read. Prepare more pages if needed. Test the physical copy under service lighting instead of shrinking it to fit an existing holder.
Accessible restaurant menus: common questions
These answers help you decide what to check and what to ask your menu or website provider.
Is a QR-code menu accessible?
It can lead to an accessible page, but that depends on the page and the guest's ability to reach it. Test the complete journey and offer a direct link and paper option. Scanning successfully is only the first step.
Can a PDF menu be accessible?
Yes, but it needs appropriate preparation and testing. W3C's PDF techniques cover real text, tags, and logical reading order. A scan or a PDF that prints neatly does not demonstrate those properties. Check the exported file itself if you offer it as a digital reading option.
What font size should a restaurant menu use?
There is no single size that makes every menu accessible. Typeface, contrast, spacing, viewing distance, and the reader's needs all matter. Use the enlargement checks above for the web version and test an actual large-print copy with the people it is intended to serve.
Can an automated accessibility score approve the menu?
Use automated checks to find some problems, then test real tasks with people. W3C explains that tools cannot check every accessibility requirement automatically and that human judgement is needed. A score cannot tell you whether your guest understood which price belongs to the portion they wanted.
Does accessibility also help search engines and AI answers?
Clear headings and visible text can serve both readers and retrieval systems. Google advises keeping important content in textual form for its AI search features. That shared foundation is useful, but passing accessibility checks does not guarantee indexing, rankings, or an AI citation.
What should a small team fix first?
Start with barriers that prevent someone reaching the menu, comparing the full offer, or establishing the right price. Provide an immediate usable alternative, assign content fixes to the menu owner and technical fixes to the provider, and retest the same task after each change.
A menu accessibility checklist for this week
Choose real tasks
Use three: find a main course and its price; compare two drink sizes; locate the relevant service hours and a way to ask for help. Include any special or supplement that changes the decision.
Cover every route
Try the website link, a table QR code, and the paper copy. At a hotel, include links sent by reception and menus in rooms. List any missing category or different price.
Test reading and navigation
Check enlarged text, narrow-screen layout, controls, keyboard use, and a screen-reader journey. Include the longest translations and the real lighting conditions. Ask the provider to measure the technical criteria.
Record failures precisely
Keep a simple log: menu URL or paper version; language; device and browser; task; observed barrier; interim option; repair owner; retest date. Describe the obstacle, without recording a guest's medical details.
Retest and maintain the alternatives
Repeat the failed tasks after repairs and after significant template, language, or content changes. In shift briefings, check that staff can find the complete current paper menu and offer assistance. Track unresolved barriers and completed repairs; a falling number of requests for help alone is not proof of success.
Research basis and further reading
- W3C: Web Content Accessibility Guidelines (WCAG) 2.2
- W3C: Older users and web accessibility
- W3C: Choosing accessibility evaluation tools
- W3C: PDF tab and reading order
- W3C: Real text in scanned PDFs
- Google Search Central: AI features and your website
- MenuSmart: Replacing a static QR menu
- MenuSmart: Keeping every menu version up to date
Keeping the improvements manageable
Once you know what needs to change, MenuSmart can help with the menu content: edit descriptions and prices, prepare multilingual versions, share a public menu URL or QR code, and generate printable PDFs. Keep checking the actual guest view and printed output: a printable PDF still needs separate checks for large-print readability and digital accessibility. The aim is a menu your team can maintain and more guests can use on their own terms.