Accessible Digital Menus: What the EU Accessibility Act Changes
Most restaurants discovered accessibility the same way: a guest at table six holds the phone at arm's length, squints, and hands it to the person opposite to read out loud. Nothing about that is unusual. What is new is that for a growing set of businesses it is now also a legal question.
This guide covers what the European Accessibility Act actually requires, who is genuinely in scope, why the standard PDF-behind-a-QR-code fails badly, and what an accessible menu looks like in practice.
What the Act is, and who it covers
The European Accessibility Act is Directive (EU) 2019/882. It has applied since 28 June 2025, and Spain transposed it through Ley 11/2023.
It does not cover every business with a website. It lists specific products and services, and the one that matters here is e-commerce services — commercial transactions concluded online. A menu that only displays dishes sits outside that description. A menu that takes an order and a payment starts to look very much like the thing the directive names.
Then comes the exemption that most restaurants land in. Microenterprises providing services are excluded: fewer than ten people and annual turnover or balance sheet total of no more than two million euros. That is the majority of independent restaurants, and it would be dishonest to tell you otherwise.
So the honest picture is this. A single family-run bar is very probably exempt. A hotel group, a chain of twelve venues, a beach club company with fifty staff — those are not, and if their menu takes orders it is in scope. If you are somewhere near the line, this is a question for your advisor, not for a blog post.
The rest of this article is written on the assumption that most readers are exempt, because the interesting part is what happens next.
Being exempt does not make it not a problem
The directive is a floor, not the reason to care.
Roughly one in five people in Europe has some form of disability, and the share climbs sharply with age. Look at who eats at three in the afternoon on a Tuesday on this coast. Presbyopia — the ordinary loss of near focus that starts in the forties — is not classed as a disability, and it is the single most common reason a guest cannot read your menu.
Then add the conditions that are not about the guest at all. Direct sunlight on a terrace destroys low-contrast text. One hand is holding a child. The phone is old and the screen is cracked. A guest is reading in their fourth language.
Every one of those is the same engineering problem as a screen reader, and fixing it fixes all of them at once. Which is why the useful framing is not "do we have to" but "how many people at how many tables are currently unable to order what they want".
Why the PDF menu fails
The PDF behind a QR code is the format that fails every one of these tests simultaneously, and it is worth being precise about why.
It cannot be enlarged usefully. Zooming a PDF on a phone magnifies a fixed page, so the guest ends up panning a document sideways to read a line. Real text reflows; a picture of a page does not.
A screen reader cannot read it. Most restaurant PDFs are exported from a design tool with no tag structure at all. To assistive technology the menu is an image with some scattered characters, and the reading order is whatever the layout engine produced.
Contrast is frozen. Cream text on a dark photograph looks superb in the design file and disappears on a terrace at two in the afternoon. The guest cannot switch it, because there is nothing to switch.
Nothing is tappable. No filtering, no jumping to a section, no search. A guest who avoids gluten reads all six pages.
A QR code pointing at a PDF is not a digital menu. It is a printed menu with an extra step, and the extra step is where accessibility goes to die.
What an accessible menu actually needs
The technical reference behind the directive is EN 301 549, which for web content points at WCAG 2.1 level AA. That is a long document. For a restaurant menu it comes down to a short list.
Real text, not images of text. If the dish name is baked into a JPEG, it cannot be enlarged, translated, read aloud or searched. This one rule eliminates most of the problem.
Contrast that survives your brand. WCAG asks for 4.5:1 on body text. Brand palettes routinely fail this, especially the fashionable ones. The fix is not to abandon the brand: it is to compute the text colour from the background rather than fixing it in the design. Disho does exactly that for the accent colour — the label colour on an active tab is derived from the luminance of whatever accent the restaurant picked, so a pale gold and a deep burgundy both end up with readable text on top.
Text that scales with the phone's own setting. A guest who has set their device to large text should get large text. This is free if the menu is built as a web page and impossible if it is a PDF.
Tap targets big enough for an unsteady hand. Roughly a fingertip, not a design flourish.
A visible structure. Headings that are actually headings, so a screen reader can jump between sections instead of reading two hundred dishes in order.
Language declared correctly. A page that says it is Spanish while showing English gets read aloud in a Spanish accent, which is unintelligible. If your menu offers twelve languages, each one has to announce itself properly.
Video that does not require sound. Dish video is a sales tool and it should carry no essential information in audio. Autoplaying muted loops are fine; a clip whose point is a voiceover is not.
What to ask a vendor
Three questions separate a real digital menu from a PDF host.
Is the menu HTML text, or an image? Ask them to send a link and try selecting a dish name with your finger. If nothing highlights, it is a picture.
Can I set the brand colours to something with poor contrast? The right answer is that the system will keep the text readable anyway. A system that lets you ship unreadable text and calls it your choice has handed you the liability.
What does the menu do at 200% text size? Open their demo, set your phone to the largest accessibility text size, and look. This one test finds most of the problems in about fifteen seconds.
What this does not fix
Accessibility of the menu is not accessibility of the restaurant. A guest who can read your carte perfectly still needs a way in through the door and a table they can reach. The menu is the part software can solve; the step at the entrance is not.
It also does not remove the human. Some guests will not use a phone, and the correct response is to keep a printed large-print card behind the bar and offer it without making it a production. Accessibility that requires the guest to announce a disability to a waiter is worse than it sounds.
Frequently asked questions
Is my restaurant covered by the European Accessibility Act? Probably not, if you have fewer than ten staff and turnover under two million euros, because service microenterprises are exempt. Groups, chains and hotel operators above that threshold whose menu takes orders and payments are a different matter. The exemption is about the business, not the menu, so a small venue owned by a large company does not inherit it. Check with your advisor if you are near the line.
We only display the menu, we do not take orders. Are we in scope? A display-only menu is a weaker fit for the e-commerce service the directive names, and many operators reasonably conclude they are outside it. That does not make an unreadable menu a good idea, and adding online ordering later changes the analysis, so it is worth building on a foundation that would pass rather than retrofitting one that would not.
Does a QR menu make us more accessible or less? It depends entirely on what the code opens. A PDF makes things worse than paper, because at least paper can be held at whatever distance suits the reader. A real web menu makes things substantially better than paper: text scales, contrast adapts, the guest reads in their own language and can filter to what they can eat.
What about guests with no smartphone? Keep printed cards. The point of an accessible digital menu is to widen the number of people who can order independently, not to force a device on anyone. A venue with both covers more guests than a venue with either.
Do we need an accessibility statement on the menu? For in-scope businesses, information about how the service meets the requirements is part of the obligation. For everyone else it is optional and still worth a line: telling guests that large text and twelve languages are available means somebody actually uses them.
Build your QR video menu in minutes
Try Disho free during the beta, no card required.
Get started free