A diner with low vision wants to read tonight's specials. A wheelchair user wants to confirm step-free access before booking. A regular with a hand tremor wants to order delivery without fighting a fiddly date picker. For all three, your website is the front door, and if it does not work, they go somewhere else. Restaurant website accessibility is not a compliance checkbox; it decides whether a paying customer can actually reach a table or place an order.
Since 28 June 2025 it is also a legal expectation across much of the EU. This guide covers the four things that trip up hospitality sites most: image-only menus, reservation and ordering forms, colour contrast, and where the European Accessibility Act fits in.
The image-only menu problem
The most common accessibility failure on restaurant sites is the menu published as a flat image or a designed PDF. To a screen reader, a JPG of your menu is a blank rectangle. Even with alt text, you cannot reasonably cram thirty dishes, prices, and allergen notes into one alt attribute, and nobody should have to hear that as a single run-on sentence.
The fix is to publish the menu as real HTML text. Use proper headings for each course (an <h2> for Starters, Mains, Desserts), list items for dishes, and actual text for prices and descriptions. That gives screen reader users a structure they can navigate, lets everyone enlarge the text to 200% without it blurring, and makes your dishes indexable by search engines. A PDF can only be accessible if it is genuinely tagged and structured, not an exported picture; for a menu that changes often, HTML is almost always the cheaper, better choice.
Where you do use images, such as a hero photo of a dish, write alt text that conveys purpose. A purely decorative background image can take an empty alt (alt="") so screen readers skip it rather than announcing a filename.
Reservation and ordering forms that actually work
Bookings and online ordering are where money changes hands, and where accessibility failures cost you directly. A few concrete requirements:
- Every field needs a visible, programmatically associated
<label>. Placeholder text alone is not a label; it vanishes once the user starts typing and often fails contrast. - The whole flow must be operable by keyboard alone. A diner should be able to Tab to the date field, pick a time, set party size, and submit with no mouse. Custom date and time pickers are where this most often breaks, so test it yourself.
- Errors must be announced and specific. 'Invalid input' is useless; 'Please choose a date in the future' tells the user what to fix. Tie the message to its field with
aria-describedbyso a screen reader reads it in context. - Tap targets must be at least 24 by 24 CSS pixels (WCAG 2.2, 2.5.8 Target Size Minimum), which matters on the phones most diners book from. Cramped time-slot buttons fail this routinely.
WCAG 2.2 added criteria that hit booking flows squarely. Redundant Entry (3.3.7, Level A) means you should not force someone to retype an email or address they already gave a step earlier. Accessible Authentication (3.3.8, Level AA) means an account login must not block password managers or demand the user solve a memory puzzle. And Consistent Help (3.2.6, Level A) expects your 'contact us' or phone link to appear in the same place across pages.
Colour contrast for menus and status labels
Restaurant branding loves light grey on cream, gold on white, and muted tone-on-tone menus. They look elegant and often fail. Body text needs a contrast ratio of at least 4.5:1 against its background (WCAG 1.4.3); large text, meaning 18pt or 14pt bold and up, needs 3:1. Interface components and meaningful graphics, such as the border of an input field or a focus outline, need 3:1 too (1.4.11).
Two patterns to watch. First, prices and dish names set in thin, low-contrast type are the most-read content on the page, so they are exactly where you cannot afford to fail. Second, never rely on colour alone to carry meaning: a 'Sold out' dish shown only by greying it, or 'vegan' indicated only by a green dot, leaves out anyone who cannot perceive that colour. Pair the colour with text or a labelled icon. You can check any foreground and background pair in seconds with our contrast checker.
Where the EAA comes in
The European Accessibility Act, Directive (EU) 2019/882, has applied since 28 June 2025. It covers a defined set of products and services, and the relevant trigger for hospitality is e-commerce: if customers can book, pre-order, or pay through your site, you are providing a covered service. A static page of opening hours is lower risk; a transactional ordering or reservation system is squarely the kind of thing the Act is about.
The technical baseline is WCAG 2.2 Level A and AA, brought into European law through the harmonised standard EN 301 549. That is the same yardstick used throughout this article. Note the microenterprise exemption for service providers (fewer than 10 employees and under EUR 2 million annual turnover), which covers many independent single-site restaurants, though multi-location groups and chains often exceed it.
A sensible order of work: fix the menu (HTML, not images), make booking and ordering keyboard-operable with labelled fields and clear errors, correct contrast, then publish an accessibility statement describing your conformance and how to report problems. To find the issues on your own pages first, run a free scan with AccessScan.