Restaurant Website Accessibility: Menus, Maps, Booking

Opening answer

A restaurant visitor needs three things from a website: what is on the menu, where the place is, and how to book a table. When any one of those three lives only in a scanned image, only inside a map, or only inside a widget that needs a mouse, that visitor is stuck before dinner starts. Restaurant website accessibility means putting the menu in real HTML text, putting the address, hours, and directions in text beside the map, and making booking work with a keyboard, with clear labels, and with error messages in words. Start with the menu page, then the contact page, then the booking flow, and test each one on a phone.

Put the menu in HTML first

A menu posted as a single image of text cannot be read aloud by a screen reader, cannot be searched, and cannot be enlarged cleanly. A menu posted as a PDF has a second problem: a PDF needs tags and a correct reading order to make sense to assistive technology, and a scanned PDF with no tags gives a screen reader little to work with. W3C technique PDF3 explains that reading order in a tagged PDF follows tag order, and that an untagged two column layout can be read straight across both columns, which turns a menu into nonsense: W3C PDF reading order technique

The practical fix is plain. Publish the menu as HTML text on the site, with headings for starters, mains, desserts, and drinks, and with dish names, descriptions, and prices as text. Keep a PDF only as an extra download, never as the only menu. When a dish changes, change the HTML first. That habit also helps search, helps a visitor on a slow phone connection, and helps a visitor who enlarges text to 200 percent. If a menu item carries an allergy note or a dietary mark, put that note in text beside the dish, not only as a coloured dot or a small symbol. Colour alone does not carry meaning for a visitor who cannot tell the colours apart, a point the Department of Justice guidance makes when it lists use of colour alone as a barrier: ADA guidance on web accessibility

PDF menus and the honest limit

Axeazy does not scan PDFs. Say that plainly when planning menu work, so a PDF menu is never counted as checked. A scan can look at the HTML pages around the PDF, at the link that points to the PDF, and at the text that describes it, but it cannot reach inside the PDF file itself. That limit matters for restaurants, because menus are the file most often left as a PDF. The answer is not to hide the PDF. The answer is to make the HTML menu the main menu, and to treat any PDF as a convenience copy that must match the HTML version. When the two versions drift apart, a visitor who relies on the HTML menu gets old prices, and a visitor who relies on the PDF gets a file no scan has checked. Pick one source of truth, the HTML page, and update the PDF from it, or drop the PDF and keep one menu only.

Maps and directions in text beside the map

An embedded map is useful for a sighted visitor, and it can be a dead end for anyone else. A map frame needs a title that says what it shows, such as "Map showing the restaurant location", so a screen reader user hears a purpose instead of a bare frame name. More important than the frame title is the text beside it. Put the street address, the nearest cross street or landmark in words, parking notes, public transport notes, opening hours, and a phone number as plain text on the same page. A visitor who cannot use the map can still find the place, call, or plan a route from that text.

Booking widgets need labels, focus, and room to tap

Reservation widgets are where restaurant sites most often break for keyboard users and phone users. A date picker, a time picker, and a party size control each need a visible label that a screen reader can announce, not only placeholder text that vanishes when typing starts. The Department of Justice guidance lists labels, clear instructions, and error indicators as parts of an accessible online form: ADA guidance on web accessibility

Check four things on a booking widget. First, can a visitor reach every field, change every value, and submit, using only the tab key, enter, and space? Second, does a visible focus outline stay in view as focus moves, rather than sliding under a sticky header? Third, are error messages written in words, such as "Pick a date after today", and tied to the field in error, rather than shown only as a red border? Fourth, are tap targets large enough on a phone, and spaced apart, so a visitor does not tap the wrong time slot? WCAG 2.2 success criterion 2.5.8 asks for pointer targets of at least 24 by 24 CSS pixels, or enough spacing for undersized targets: W3C target size guidance

Colour and text on menu pages

Menu pages tempt designers toward light grey text on white, script fonts over food photos, and price lists in pale colour. Those choices look soft and read badly. WCAG success criterion 1.4.3 asks for a contrast ratio of at least 4.5:1 for normal text, and at least 3:1 for large text: W3C contrast guidance Check menu body text, prices, allergy notes, and footer text against that bar, not only headings. Check text placed over a photo as well, because a busy photo behind pale text can drop contrast even when the same colours pass on a plain background.

Controls need contrast too. WCAG success criterion 1.4.11 asks for at least 3:1 for visual information needed to identify user interface components and their states, such as a field border or a focus outline: W3C non-text contrast guidance A booking button, a date field border, and a selected time slot should each stand out from the background next to them. Try the contrast quiz to train an eye for text against background before judging a new menu design: Contrast quiz

What a scan can check on a restaurant site

Axeazy starts with a free homepage scan that takes about 60 seconds, with no signup and no card, and paid plans show price at checkout with annual saving of 20 to 25 percent: Axeazy pricing That scan is a useful first pass for a restaurant site, because it can surface missing alt text on food photos, missing form labels on a contact form, unclear link names, and heading order problems on a menu page. Those findings map to the 14 fix categories listed on the capabilities page, which cover alt text, skip navigation, language attributes, form labels, link names, button names, ARIA labels on custom widgets, ARIA attribute validity, keyboard tab order, pinch to zoom restrictions, iframe titles, table header structure, landmark structure, and heading structure: Axeazy capabilities A related guide for small business tool choice can help set the order of that work: Best accessibility tools for small business

FAQ

Should a restaurant keep a PDF menu at all?

Only as an extra copy beside a full HTML menu. When the HTML menu is complete and current, a PDF adds little, and when it drifts out of date, it adds confusion. Drop the PDF if keeping two versions current is too much work.

What should the text beside a map include?

Street address, hours, phone number in text, parking notes, and public transport notes in words. That text lets a visitor who cannot use the map still reach the restaurant, and it gives a screen reader user the same facts the map shows visually.

What if a booking widget cannot be used with a keyboard?

Keep a phone link and a contact form link on the same page, log the widget failure with a date, and ask the widget provider or the site developer for a keyboard fix. Do not leave booking only inside the broken widget while waiting.

Does this article give legal advice about restaurant websites?

This is general information, not legal advice. If you received a demand letter or were sued, talk to a qualified attorney, and take the scan report and any fix log to that meeting.

Last checked: October 31, 2026

Sources

• W3C contrast guidance
• W3C non-text contrast guidance
• W3C target size guidance
• W3C PDF reading order technique
• ADA guidance on web accessibility
• Axeazy pricing page
• Axeazy capabilities page

Run a free homepage scan first, then fix the menu, map, and booking flow in that order, starting at Axeazy

Related reading

• Medical Practice Website Accessibility Basics