Website Accessibility for Restaurants: What's Required

Short answer: restaurant websites must be usable by people with disabilities — keyboard navigation, readable contrast, menus as real text (not just PDFs), and booking and ordering forms that work with screen readers. In the EU, the European Accessibility Act (in force since 28 June 2025) points to WCAG 2.1 AA for covered services; in the US, ADA lawsuits use WCAG 2.2 AA as the practical benchmark. Most fixes are simple and cheap — and they win you customers, not just fewer complaints.

A blind customer trying to read your menu before visiting. A regular with Parkinson's who can't tap your tiny booking buttons. An older guest whose browser zooms to 200% and breaks your layout. These are not edge cases — across the Nordics, a large share of your potential guests live with a disability that affects how they use the web, and in Norway alone around 18% of the population lives with a disability.

This article covers what's actually required of restaurant websites in 2026: the European Accessibility Act, Nordic national rules, the US ADA situation, the WCAG 2.2 AA standard in restaurant terms, the ten failures that appear on almost every restaurant site, how to audit your own site properly, and what fixes cost. It's written for owners, not lawyers or developers — but it's honest about the law, so let's start with why restaurants specifically are being watched.

Why restaurants are in the spotlight

Restaurants are a natural focus of accessibility enforcement because a restaurant website is not a brochure — it's a service. Your guests use it to read the menu, book a table, order food and buy gift cards. When any of those flows is unusable with a keyboard or a screen reader, the guest hasn't just had a bad experience; in legal terms, they've been denied access to the service itself.

In the United States, this logic has played out in thousands of lawsuits. Federal courts have repeatedly treated restaurant websites as part of the restaurant's public accommodation, and in 2023 more than 4,000 ADA web-accessibility lawsuits were filed in federal court, continuing a multi-year trend. Hospitality, food and retail businesses are among the most frequent targets — demand letters and settlements typically reference WCAG 2.1 or 2.2 AA as the remediation standard, even though no regulation names a specific version for private businesses.

Europe is catching up. The European Accessibility Act has been in force since 28 June 2025, and the digital-services and hospitality press is full of warnings that operators underestimate it: many assume they have until 2030, or that the rules only apply to large companies. Both assumptions are wrong. The 2030 date only extends pre-existing service contracts; new services must comply now. And the microenterprise exemption covers businesses with fewer than 10 employees and turnover or balance sheet under €2 million — which excludes most restaurants with a busy dining room and delivery operation.

There is also a quieter business reason that matters more than any statute. The same fixes that make your site accessible make it faster, easier to use on a phone in bright sunlight, and better understood by Google. Alt text on food photos doubles as image SEO. Real-text menus feed search engines. Labelled forms reduce booking abandonment. Accessibility work overlaps heavily with the conversion work you would do anyway — which is why it usually pays for itself.

The European Accessibility Act, in plain English

The European Accessibility Act (EAA), formally Directive (EU) 2019/882, is the EU's harmonised accessibility law for products and services. It has applied since 28 June 2025 and is enforced through each member state's own national law. For websites and apps, the practical requirement is conforming to WCAG 2.1 Level AA — the technical standard referenced by the European harmonised standard EN 301 549. Meeting EN 301 549 gives you a presumption of conformity with the law.

Who the EAA actually covers

The Act covers a defined list of consumer-facing products and services: e-commerce, banking, passenger transport booking, audiovisual media, telecommunications and more. For restaurants, the relevant trigger is e-commerce — any online sale to EU consumers. If your website takes online orders, sells gift cards or vouchers, or processes any paid transaction, you are operating an e-commerce service in the Act's terms, regardless of where your business is headquartered. Selling to EU consumers puts you in scope even if your company is based outside the EU.

The microenterprise exemption — and its limits

Microenterprises providing services — defined as fewer than 10 employees AND annual turnover or balance sheet total of €2 million or less — are exempt from the EAA's service requirements. Many small cafés and bistros fall under this threshold and genuinely are exempt from the EAA itself.

But treat this exemption as a legal detail, not a strategy, for three reasons. First, national law can still apply: Finland's Non-Discrimination Act requires reasonable accommodations, and Norway's universal-design rules apply to private websites regardless of business size. Second, exemption thresholds are easy to cross as you grow — a restaurant with delivery staff, a catering arm and a busy terrace can drift over 10 employees without noticing. Third, your suppliers and partners may demand accessibility anyway: delivery platforms, booking systems and corporate clients increasingly require it contractually.

What the EAA expects from a website

The Act doesn't name HTML attributes — legislation that named tags would age badly. Instead, Annex I requires that non-textual content has an alternative presentation, and that websites are perceivable, operable, understandable and robust. Annex II gives the practical example: providing text descriptions of pictures. For an informative image on a web page, the HTML way to provide that is alt text — so "add alt text to your food photos" is the correct practical instruction even though the law never uses the phrase. The rest of the expectations map directly onto WCAG: keyboard navigability, readable content, assistive-technology compatibility, and clear, labelled forms.

What applies in Finland, Sweden and Norway

The EAA is an EU directive, so it applies in Finland and Sweden (EU members), enforced through national legislation. Norway is not in the EU — but it has its own regime that is, in some ways, stricter. Here's the country-by-country picture.

Finland

Finland implements the EAA through national legislation, and two older acts also matter. The Act on the Provision of Digital Services (306/2019) implements the EU's Web Accessibility Directive and requires accessibility — largely WCAG-aligned — primarily for public-sector digital services, with some private entities deemed essential also covered. The Non-Discrimination Act (yhdenvertaisuuslaki) prohibits discrimination on grounds including disability across public life and requires businesses to make reasonable accommodations for specific needs. If your website is the only way to book a table or order, and it is unusable for a disabled customer, you could be seen as failing that duty. In practice: Finnish restaurants with online sales fall under the EAA; every Finnish restaurant should take the Non-Discrimination Act's reasonable-accommodation duty seriously.

Sweden

Sweden is an EU member, so the EAA applies as transposed into Swedish law, with the same e-commerce scope and the same microenterprise exemption. The older Swedish accessibility act (lag 2018:1937 om tillgänglighet till digital offentlig service) covers public-sector digital services. Private restaurants fall under the EAA where they sell online, plus general anti-discrimination law. The Swedish market also has a strong procurement culture: if you ever cater for municipalities or sell to public-sector clients, accessibility conformance reports (typically WCAG 2.2 AA) are increasingly asked for in tenders.

Norway — the strictest of the three

Norway adopted its regulation on universal design of ICT solutions back in 2013, and it is unusually broad: it applies to ICT solutions intended for use by the general public in Norway, covering enterprises that inform and offer their services to the public through ICT — explicitly including websites. That means a private restaurant website in Norway is covered by a universal-design duty with no small-business exemption. The Authority for Universal Design of ICT (the national supervisory body) tests websites and apps serving users in Norway, and organisations are expected to publish an accessibility declaration. Norway is among the most digitalised countries in the world, and compliance checklists alone don't guarantee lived accessibility — but the legal expectation is unambiguous.

The practical takeaway: if you run a restaurant in the Nordics, "we're too small for this to apply" is not a safe assumption. Norway covers you regardless of size; Finland and Sweden cover you as soon as you sell anything online; and US-style private enforcement is the direction of travel everywhere.

What "accessible" technically means: WCAG 2.2 AA

WCAG — the Web Content Accessibility Guidelines, published by the W3C — is the international technical standard every regime points to. Version 2.2 at conformance Level AA is the level to target: it satisfies the EU's 2.1 AA requirement (content conforming to 2.2 also conforms to 2.1 and 2.0) and it's the level used in US settlements and procurement. You don't need to read all 80+ success criteria. What you need is the shape of the standard, organised around four principles: perceivable, operable, understandable, robust.

Perceivable: people must be able to sense the content

Every image that carries information needs a text alternative — in HTML, the alt attribute. A photo of your signature dish gets alt text like "Wood-fired margherita pizza with basil, served on a ceramic plate"; a decorative background texture gets empty alt text so screen readers skip it. Videos need captions; audio needs transcripts. Text must have enough contrast against its background — the AA bar is a contrast ratio of 4.5:1 for normal text (3:1 for large text). That elegant light-grey-on-white menu typography many designers love fails this instantly.

Operable: everything must work without a mouse

Every link, button, menu item and form field must be reachable and usable with a keyboard alone, in a logical order, with a visible focus indicator so keyboard users can see where they are. No keyboard traps — a popup or date-picker that grabs focus and won't let it go with Escape is a classic failure. Touch targets matter too: WCAG 2.2 added minimum target sizes, which is directly relevant to your booking widget's tiny "confirm" button.

Understandable: the site must behave predictably

Navigation that appears in the same order on every page. Form fields with visible labels — not just placeholder text inside the box that vanishes when you type. Error messages that say what went wrong and how to fix it, announced to screen readers. And since WCAG 2.2: no cognitive function tests to log in — blocking paste in a one-time-code field, for example, is a failure. If your loyalty programme or staff area requires a puzzle to sign in, rethink it.

Robust: it must work with assistive technology

Proper HTML structure — one clear H1 per page, logical heading order, identified header/nav/main/footer regions, a "skip to main content" link. Screen readers navigate by headings and landmarks; a site with five H1s and skipped heading levels is slow and confusing to use. Three criteria added in WCAG 2.2 land directly on restaurant ordering: don't ask for information twice (redundant entry), keep authentication simple (accessible authentication), and don't let sticky bars cover the focused element (focus not obscured — that sticky "Your order: €42.50" bar is a repeat offender).

The 10 failures found on almost every restaurant site

Auditors see the same defects on restaurant websites over and over. Run through this list — if you recognise five or more, your site needs work.

1. The menu is a PDF (or an image)

The single most common restaurant failure. A scanned or exported PDF menu is usually an untagged image of text — a screen reader sees nothing. Covered in detail in the next section.

2. Food photos with no alt text — or alt text stuffed with keywords

Every gallery image either has no description or has something like "best pizza Helsinki restaurant cheap". Screen readers need a short, honest description of what's in the photo. Keyword-stuffed alt text is worse than none.

3. Low-contrast text

Light grey body text on white, gold script on cream, white text over busy food photography without a scrim. Check your menu page and your booking widget first — they're the highest-traffic spots.

4. The booking form isn't keyboard-accessible

Date pickers, time-slot grids and party-size dropdowns built as custom JavaScript widgets are the usual suspects. If you can't complete a booking using only Tab, Enter and arrow keys, neither can a keyboard-only guest.

5. Popups and cookie banners that trap users

Newsletter modals, "book now" slide-ins and cookie consent banners that can't be closed with Escape, steal focus, or hide the page from screen readers. Your cookie banner is legally required in the EU — it must also be navigable.

6. Video without captions

Chef interviews, atmosphere reels, embedded TikToks — any video with meaningful audio needs captions. Auto-generated captions are a start; corrected captions are the standard.

7. "Click here" links

Screen reader users often navigate by pulling up a list of all links on a page. A list that reads "click here, click here, click here" is useless. Use descriptive anchors: "View the dinner menu", "Book a table for Friday". This also helps your SEO — descriptive anchors are a ranking signal.

8. Inaccessible third-party widgets

Chat bubbles, review carousels, Instagram feeds, loyalty popups. Each third-party script is a new surface for failures — and the legal obligation stays with you, not the vendor.

9. No visible focus indicator

Designers often remove the browser's default focus outline because it looks ugly. Keyboard users then have no idea where they are. Style the focus ring to match your brand instead of deleting it.

10. Text that breaks at 200% zoom

Many older guests browse with text enlarged. Fixed-height boxes, overlapping columns and cut-off buttons at zoom are a failure of the "resize text" criterion — and a daily annoyance for a large part of your audience.

Menus, PDFs and third-party ordering traps

Three issues deserve their own section because they're restaurant-specific, extremely common, and each one carries legal weight beyond the general criteria.

The PDF menu problem

Most restaurant PDF menus are exported from design software as flat images of text — no tags, no reading order, no language metadata. A screen reader encountering one hears nothing, or at best a jumble of characters in random order. Accessibility rules call for "effective communication," and a flat PDF does not provide it.

The reliable fix is an HTML menu: real text on a real web page, readable on phones, usable with keyboards and screen readers, indexable by Google, and editable in minutes when a dish changes. A properly tagged, tested PDF alongside the HTML menu is fine — some guests like to download it — but the PDF alone is not enough. This is also a pure business win: the menu page is your most-visited page, and an HTML menu loads faster, ranks better and converts better than a PDF download.

Online ordering and the "it's our vendor's problem" myth

Many restaurants embed a third-party ordering system — an iframe or a redirect to a delivery platform. When that checkout is inaccessible, owners assume the liability sits with the platform. It doesn't. US courts have been explicit: the anti-discrimination duty covers discrimination "directly, or through contractual, licensing, or other arrangements." Your vendor-run checkout on your site is still your customer's experience of your restaurant.

Practical consequences: when choosing an ordering or booking provider, ask for their accessibility conformance report (a VPAT or equivalent against WCAG 2.2 AA) before signing. Test the checkout flow with a keyboard yourself. And if the platform can't provide a conformance statement, factor remediation into your decision — a cheap ordering system that excludes disabled customers is not cheap.

Gift cards, vouchers and loyalty

The same logic covers gift-card shops, voucher checkouts and loyalty sign-ups. These are e-commerce services under the EAA, so they're squarely in scope. They're also the flows owners forget: the main site gets rebuilt accessibly, and the gift-card page stays an ancient form with unlabeled fields. Audit every transactional flow, not just the homepage.

How to check your own website (properly)

There are three levels of checking, and you need to understand what each one can and can't tell you — because "we ran a scan and it passed" is the most common false comfort in this field.

Level 1: automated scans

Free tools (browser extensions like axe or WAVE, or online checkers) crawl your pages and flag machine-detectable issues: missing alt text, low contrast, missing form labels, bad heading structure. They're fast and free, and they're the right starting point. But automated tools catch only roughly 30% to 57% of issues, depending on how you count (Deque's widely cited research). They can't judge whether alt text is meaningful, whether the keyboard order makes sense, or whether your booking flow is usable. Use scanners to find the easy wins, never as proof of compliance.

Level 2: manual keyboard and screen-reader test

This is the test that matters most for restaurants, and anyone can do it in twenty minutes:

1. Put your mouse aside. Using only Tab, Shift+Tab, Enter, Space and arrow keys, try to read your menu, find your opening hours, and complete a booking.
2. Watch for: invisible focus (you can't tell where you are), keyboard traps (you can't get out of the date picker), and dead ends (a button that does nothing via keyboard).
3. Zoom your browser to 200% and repeat the menu page. Does anything overlap or get cut off?
4. If you want to go further, turn on your operating system's built-in screen reader (Narrator on Windows, VoiceOver on Mac) and listen to your homepage. It takes ten minutes to learn the basics, and it's eye-opening.

If you can complete a booking by keyboard alone and the menu reads sensibly at 200% zoom, you've cleared the bar most restaurant sites fail at.

Level 3: a professional audit

From a legal-risk standpoint, a defensible position usually includes a manual audit by a specialist: automated scan plus keyboard and screen-reader testing of your key flows (menu, booking, ordering, contact), documented against WCAG 2.2 AA with screenshots and code references. This is what demand letters and settlements are measured against — "we ran an automated scan" rarely holds up. For a typical restaurant site, a professional audit runs an estimated €300–€1,500 depending on the number of page templates and transactional flows.

What about accessibility overlays?

You will be pitched widgets that promise to make your site accessible with one line of JavaScript. Don't buy it. Overlays are widely criticised by disabled users and accessibility professionals: they don't fix the underlying code that standards like EN 301 549 are judged against, and most overlay features simply duplicate settings that browsers and operating systems already offer. The European Disability Forum and the International Association of Accessibility Professionals have said plainly that overlays don't make a website accessible or compliant. Fix the content first; a toolbar is, at best, an optional extra.

Fixing your site: priorities and costs

You don't have to fix everything at once. Accessibility remediation works best in priority order: fix the things that block core tasks first, then the things that affect many pages, then the polish.

Priority 1: unblock the money flows (week 1)

• Replace or supplement the PDF menu with an HTML menu.
• Make the booking form keyboard-completable: labels on every field, a working focus order, errors that explain themselves.
• Check the ordering/checkout flow — including any third-party widget — for keyboard and screen-reader usability.

Priority 2: site-wide basics (weeks 2–3)

• Add meaningful alt text to informative images; mark decorative images as decorative.
• Fix contrast on body text, buttons and the menu page.
• Make popups, cookie banners and chat widgets closable by keyboard with proper focus handling.
• Replace "click here" links with descriptive anchors — which also lifts your SEO.
• Add a visible focus indicator and a "skip to main content" link.

Priority 3: polish and documentation (week 4)

• Caption videos; provide transcripts for longer ones.
• Verify the site at 200% zoom and on small screens.
• Publish an accessibility statement (next section) and set up a maintenance routine.

Indicative costs for a typical restaurant site in 2026 — treat these as estimates, not quotes:

The cheapest moment to get accessibility right is during a build or redesign — which is exactly what to discuss when you're evaluating mobile and speed work or planning a performance pass. Many of the same developers handle both, and the overlap is large: semantic HTML, fast pages and clean structure serve accessibility, SEO and conversion at once. If you're comparing providers, a subscription model that includes ongoing maintenance keeps the site accessible as menus change — which is where one-off builds quietly decay.

The accessibility statement and staying compliant

Under the EAA framework, businesses are expected to publish an accessibility statement — and even where it isn't strictly required, it's good practice and good evidence. A restaurant accessibility statement should include:

• A commitment to accessibility and the standard you target (WCAG 2.2 AA).
• The current conformance status of the site — be honest. "Partially conformant" with a list of known issues beats a false claim of full compliance.
• Known limitations (e.g. "our third-party booking widget is being remediated with the vendor") and any alternatives you offer (phone booking, email).
• A feedback channel: an email address or phone number where users can report barriers. Monitor it — an unanswered accessibility contact is worse than none.
• The date of the statement and of your last review.

Then make accessibility part of routine maintenance, not a one-off project. Restaurant sites change constantly — seasonal menus, new photos, event pages, popups for Valentine's Day. Every change is a chance to reintroduce a failure. The practical routine: whoever updates the menu knows the alt-text and heading rules; new pages get a quick keyboard check before publishing; a full review happens annually or after any redesign. Train the team once, and compliance becomes a habit rather than a project.

Frequently asked questions