Menus every guest can read.
A menu behind a QR code is a web page, and web pages have accessibility rules. This statement explains what Menu Author builds into every published menu, what stays in your hands, and where the limits are.
Scope and standard
This statement covers the menu pages Menu Author publishes for you: the public menu link, every translated variant, menus embedded on your own website, and the TV display mode. It does not cover PDF and image exports, which are print artefacts, or the editor you use to design menus.
Published menus are built to conform to the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA. That is the level referenced by EN 301 549, the European standard behind the European Accessibility Act, which has applied since 28 June 2025 and is the benchmark restaurants across the EU are being asked to meet for digital menus. It is also the level most commonly cited under the Americans with Disabilities Act.
What Menu Author builds in
- Real text, real structure. Your menu is published as HTML, never as a picture of a menu. The page has one level-one heading, a heading for every section, and item lists a screen reader can move through. If a design has no visible title, the menu name is still announced as the page heading.
- Keyboard first. A skip link jumps straight to the menu. The dietary filter and the language bar work with a keyboard, show a visible focus ring, and announce their state.
- Codes explained. Dietary and allergen codes such as "V" or "GL" are read out with their full names, not just the abbreviation.
- The right language. Every page declares its language, each translation has its own address, and a guest whose browser prefers one of your active languages lands on it automatically.
- Readable at any size. Text scales with the browser's zoom and text-size settings, and the layout reflows on a phone.
- Nothing tracks your guests. No advertising or cross-site cookies, so no consent banner stands between a guest and the menu.
- Tested on every release. Our test suite runs the axe-core accessibility engine against a set of reference menus, including translated variants, the filtered state, and TV display mode, at WCAG 2.1 AA. A change that introduces a violation does not ship.
What you control
Colors, fonts, and background images come from the theme you choose and the changes you make. Menu Author's own themes start from readable defaults, and the editor adjusts text tone against light and dark backgrounds, but a custom color or a busy photo can still push contrast below what guests with low vision need.
- Keep body text at a contrast ratio of at least 4.5:1 against its background. Check any pair in the free menu contrast checker.
- Add alt text to photos and logos in the editor so screen readers can describe them.
- Use the allergen legend so codes on items are explained on the page itself.
Known limitations
- Dietary and allergen chips inherit the theme's colors and a slight transparency, so their contrast depends on the theme.
- PDF exports are produced for print and are not tagged accessible PDFs.
- The dietary filter and automatic language selection need JavaScript. Without it the full menu still renders and every language stays reachable from the language bar.
- TV display mode rotates pages on a timer. It is meant for signage screens, not personal devices.
- Right-to-left languages are not supported.
Tell us what is not working
If you or a guest hit an accessibility problem on a published menu, send it through the contact form and mention accessibility in the message. We acknowledge reports within one business day and treat conformance defects in the renderer as bugs, not feature requests.
This statement was last reviewed on 15 September 2026.