This site is used by people looking for a table, often on a phone and in a hurry. For it to work for everyone, some things matter that you cannot see by looking at a page: that it can be used without a mouse, that text can be enlarged without breaking the layout, that colours can be told apart, that someone using a screen reader knows where they are.
This page says what we actually checked, with which tools, and what we did not.
What we measured, and how
- Automated checks — axe-core on twenty-six pages of the site, in both languages: home, search, city page, a restaurant listing, both forms — booking and table request — the report form, a booking page, the review form, the blog, an article, the frequently asked questions, the information pages, the legal pages, this statement, the personal area and the rewards page. Each page as it opens, in a real browser, at 390px wide.
- Keyboard — every Tab stop walked on five pages (thirty-one to forty-eight each), checking that every control can be reached and that the focus is visible.
- Reflow — nine pages at 320px wide, the width WCAG asks for: none may scroll horizontally. One of them is a blog article, the page with the most text on the site.
- Contrast — computed on the theme colours, pair by pair, against the 4.5:1 threshold for normal text.
- Without JavaScript — the site opened with scripts turned off.
What came out, and what we fixed
On the first run the automated checks found forty-four failing points. Zero are left, and this is what was there:
- The brand green did not reach the minimum contrast. It was #059669, which on white gives 3.77:1 — below the required 4.5:1. It was not one page's detail: that green is the colour of links and the background of the main button, so it failed on every page. It is now #047857, one step darker: 5.48:1 on white.
- Keyboard focus had been switched off on seven fields. A stylesheet utility removed the outline, leaving only a border colour change — on a date field, invisible.
- A description list with no described terms, on a booking page: a screen reader announced «list» and then did not say of what.
- A skipped heading level on four pages, between the page title and the restaurant names. Someone navigating by headings finds a gap and thinks they missed something.
What the site does, today
- It works without JavaScript: searching, opening a listing, booking, cancelling, requesting a table, reporting an error and writing a review. The only page that needs it is «My bookings», because the list lives in the browser's storage — and when it is missing it says so, instead of sitting there empty.
- Keyboard focus is always visible: a two-pixel outline on every control. The thirty stops of two pages were walked one by one.
- Nothing moves by itself, and anyone who asked their system to reduce motion sees it still.
- Text enlarges: down to 320px wide no page scrolls horizontally.
- Every page declares its language, and the two versions name each other.
- Review stars carry the rating in words for anyone who cannot see the drawing.
What we did NOT check
This is the part missing from almost every such statement, and without it the rest is worth nothing.
- No testing with a real screen reader — NVDA, VoiceOver, JAWS. Automated checks find about a third of the problems: the rest is found by a person using those tools.
- No testing with disabled people. No third-party audit, no certification.
- The pages behind sign-in were examined in one configuration only.
- We do not claim a conformance level (A, AA, AAA): saying it without an audit would be a claim nobody has verified.
One limit we know about
- In the date and time fields the little picker button — the calendar, the clock — is drawn by the browser, not by us: the focus indicator on that button is the browser's, and we cannot change it. The rest of the field has ours.
Until 12 September 2026 there was a second one here: error messages from our own system appeared in Italian even on the English pages. That has been fixed, and this line stays to say it was there — not to leave it written as though it still were.
How to repeat this measurement
It is not a judgement, it is a command. npm run accessibilita re-runs all three checks — axe-core on the pages, the Tab walk, the reflow at 320px — and prints what it finds. If this page and that command disagree, the command is right.
If you hit an obstacle
Tell us: it is the fastest way to get it fixed, and reports about this come before almost anything else. The contacts are in who to ask.