Skip to main content
Built by Pine
Back to Journal
Accessibility 10 min read May 11, 2026
By Built by Pine

Restaurant Website Accessibility: A WCAG 2.2 AA Baseline

WCAG 2.2 AA is the practical compliance threshold US courts treat as the floor for ADA Title III. This is the operator-grade baseline restaurants should ship every site against.

WCAG 2.2 AA is the practical accessibility baseline US courts treat as the threshold for ADA Title III on restaurant websites. It covers keyboard navigation, alt text, color contrast, accessible forms, captioned video, and a handful of new mobile-interaction criteria added in 2023. Ship every project against it.

Most restaurant operators hear “accessibility” and think one of two things: an overlay widget bolted onto the footer, or a lawsuit risk to insure against. Neither is the right starting frame. The right frame is the building code analogy. Cities have a building code so restaurants don’t collapse and burn down. The web has WCAG 2.2 AA so the same rooms work for the diners who use a screen reader, move through pages with a keyboard, or zoom the text to 200%. It’s the digital building code. Shipping against it isn’t a moral upgrade, it’s professional practice.

We’ve already covered the legal side in our companion piece on restaurant website ADA compliance. This one is the operator-grade baseline — the practical work, in order, that every restaurant site should pass before it goes live.

The four pillars of WCAG 2.2 AA

WCAG organizes everything around four principles. The acronym is POUR. Every success criterion in the spec rolls up under one of these four.

Perceivable

Information has to reach the user, whatever channel they’re using. For a restaurant site, that means three concrete things. Every food photo needs alt text that describes what’s actually on the plate, not just “food” or “image.” Body copy and pricing need a contrast ratio of at least 4.5:1 against their background — that pale-cream menu price on a pale-cream card almost certainly fails. Hero video either has captions or a transcript, and motion has a prefers-reduced-motion fallback for the diners whose vestibular system reacts badly to parallax and autoplay.

The mistake we see most often here is mood-driven design that prioritizes the photograph over the readable text on top of it. A hero image with white text and no overlay can drop to a 2:1 contrast ratio on the wrong photo crop. It looks fine to the designer on a calibrated monitor in a dark room. It’s unreadable to a diner squinting at their phone in afternoon sun.

Operable

Every interactive element on the page has to work without a mouse. That’s not a fringe case — keyboard navigation is also how screen readers traverse a page, how switch users with limited dexterity interact, and how power users move quickly. Tab order has to be logical. Focus has to be visible. Skip-to-main-content links belong in the header so screen reader users don’t tab through the nav on every page.

The operable principle also bans timing-dependent interactions that can’t be paused. The auto-dismissing reservation popup that vanishes after eight seconds is an accessibility violation for any diner who reads slower than that. And anything that flashes more than three times per second is a seizure risk and gets removed, period.

Understandable

The content and the interface both have to be predictable. The <html> element needs a lang attribute set to the right language so screen readers pronounce words correctly. Form inputs need real labels, not placeholder-only labels that vanish the moment the user starts typing. Error messages need to explain what went wrong and how to fix it — “invalid date” is not enough; “reservations require at least 2 hours’ notice” is.

Restaurants get this wrong most often on reservation and contact forms, where the design team strips labels for visual cleanliness and leaves the form unusable for any assistive tech user. The fix is small — a visible label above each input — and it almost always improves conversion for sighted users too.

Robust

This is the WCAG principle name for “works with assistive technology.” Valid HTML, semantic markup, ARIA only where native semantics fall short. A button is a <button>, not a <div> with a click handler. A heading is an <h2>, not a paragraph with bigger font. Get the markup right and assistive tech inherits the meaning for free.

The most common violation here is custom components built without the underlying semantics — a “select your party size” dropdown that’s actually six divs with JavaScript, no role="combobox", no keyboard support, no announced state changes. It looks identical to a native select. It’s invisible to a screen reader.

The 12 things to fix first on a restaurant website

If a restaurant site already exists and the team is auditing it, this is the order to work through. These are the most-violated criteria specific to restaurant sites, ranked by impact-to-effort.

  1. Replace PDF menus with HTML. A PDF menu is the single biggest accessibility hit on a restaurant site. Most are scanned images of printed menus, which means zero text for a screen reader and a 6pt font on a phone. HTML menus also load faster, rank in search, and update without re-exporting Illustrator.
  2. Add alt text to every food photo. “Bowl of tonkotsu ramen with chashu and soft-boiled egg” beats “ramen.jpg” or empty alt. Describe the dish, not the mood. Decorative-only images get alt="" so screen readers skip them entirely.
  3. Pass color contrast 4.5:1 on body text and pricing. Run every text-on-background pair through a contrast checker. Brand colors that read as elegant often fail — that’s the gap to fix before launch, not after.
  4. Make every interactive element keyboard-reachable. Tab through the homepage. If the reservation button can’t be reached, or the mobile menu trap is impossible to escape, that’s a P0 fix.
  5. Ensure focus indicators are visible. Designers often add outline: none to clean up the look and forget to add a replacement. The result: a keyboard user has no idea where they are on the page. Add a visible focus ring on every interactive element.
  6. Label reservation form inputs. No placeholder-only labels. Every <input> gets a real <label> element wired with for/id, or an aria-label if the visual design can’t accommodate one.
  7. Caption hero video or provide a prefers-reduced-motion fallback. Either burn captions into the video or supply a CC track. For motion-sensitive users, swap the autoplaying video for a static poster when their OS preference asks for reduced motion.
  8. Add a skip-to-main-content link in the header. First focusable element on every page. Visually hidden until focused, then visible. Lets keyboard and screen-reader users skip the nav without tabbing through 14 menu items per page load.
  9. Set the lang attribute on <html>. <html lang="en"> — one line, often missing on themes that were forked from a template. Screen readers default to the wrong pronunciation engine without it.
  10. Get heading hierarchy semantic. One <h1> per page. Headings descend in order — no <h1> followed by <h4>, no <h2> jammed inside an <h3>. Screen reader users jump from heading to heading; broken hierarchy breaks their map of the page.
  11. Avoid timing-dependent CTAs. That auto-dismissing reservation widget? Make it persistent until the user closes it. The same goes for hero carousels that auto-rotate every four seconds — pause on focus and on hover, give the user a way to stop the rotation entirely.
  12. Test on real assistive tech. VoiceOver on iOS, NVDA on Windows. Walk the five critical paths — find a location, view the menu, make a reservation, place an order, find hours — with the screen reader on and the screen off. Lighthouse doesn’t catch what real-tech testing does.

What changed in WCAG 2.2

WCAG 2.2 superseded WCAG 2.1 in October 2023. It added nine new success criteria, most of which target mobile and touch interaction patterns that 2.1 didn’t fully address. Four of them matter especially for restaurant sites:

  • Focus Appearance (2.4.11) — focus indicators must have minimum size and contrast, not just be present. A 1px outline in a faint gray no longer passes.
  • Dragging Movements (2.5.7) — anything that requires a drag (a draggable map, a slider) must have an alternative single-tap or single-click path. Diners using head-tracking or switch control can’t drag.
  • Target Size Minimum (2.5.8) — interactive controls need to be at least 24×24 CSS pixels (with exceptions). The tiny “X” on a popup, the cramped reservation date picker — both common failures.
  • Accessible Authentication (3.3.7) — login or reservation flows can’t require a cognitive function test (remembering a code, solving a puzzle) without an alternative. Affects any restaurant running gated loyalty or member sections.

Sites built against 2.1 are not automatically compliant with 2.2. The gap is small but real, and worth auditing during any redesign.

Tools we run on every project

Three layers of testing, applied in order. Each catches what the layer above misses.

Automated. Lighthouse, axe DevTools, and Pa11y in CI. These run on every pull request and block deploys when new violations are introduced. Automated scans catch roughly 30% of WCAG issues — the easy structural ones — and they catch regressions fast. That’s their job. They’re not the whole audit.

Manual. A human walks the five critical paths with a keyboard only, then again with VoiceOver or NVDA. The five paths on a restaurant site are: find a location, view the menu, make a reservation, place an order, and find hours. If any of those break with a keyboard or under a screen reader, the site isn’t shipping. This catches the 70% of issues automated tools miss — focus traps, illogical reading order, broken live regions, ARIA used incorrectly.

Real-user feedback. A published feedback channel — an email address, a form — with a real person reading it. Most real accessibility issues surface from users who can’t use the site, not from scans. Saying “email us if you hit a barrier” and actually replying within a business day is the difference between a site that gets fixed and one that doesn’t.

The cost of bolting accessibility on after launch

Bolting accessibility onto a finished site costs meaningfully more than building accessibly from the wireframe stage. It usually means revisiting the design system, rewriting the form components, swapping the menu PDF for an HTML build, recropping every food photo for contrast, and re-shooting hero video with captions. That’s a separate retrofit project on top of the original build, often with the same project-management overhead. Accessibility built in from day one is a small line inside the build. See our restaurant website cost in 2026 breakdown for how this decision shows up on the invoice.

Wrapping up

Every Built by Pine engagement closes with an automated and manual accessibility pass before DNS cutover. Lighthouse and axe-core in CI on every deploy. A keyboard-only walkthrough and a screen-reader walkthrough of the five critical paths the week of launch. A published feedback channel that a real human reads. The work isn’t glamorous and it doesn’t sell on the homepage — but it’s the floor we build every restaurant website design project against.

If you’re running a multi-location operation, the accessibility baseline applies to every location page, every location switcher, and every per-location reservation flow. Same standard, more surface area. Worth knowing before the build starts, not after.

FAQ

What’s the difference between WCAG AA and AAA?

AA is the practical compliance threshold US courts treat as the floor for ADA Title III on public-accommodation websites. AAA is a stricter standard most operators don’t need to hit. Build against AA, document any gaps honestly, and the legal exposure stays manageable.

Does WCAG 2.2 replace WCAG 2.1?

Yes — WCAG 2.2 superseded 2.1 in October 2023. It adds nine new success criteria most of which affect mobile interaction patterns. Sites built against 2.1 are not automatically compliant with 2.2; the gap is small but real and worth auditing.

Do overlay widgets like accessiBe or UserWay count as compliance?

No. Federal courts have ruled multiple times in 2023 and 2024 that overlay widgets do not satisfy ADA Title III. The disability community has pushed back publicly. They can complement a compliant site but they don’t replace one.

How often should we re-audit accessibility?

After any significant content or layout change, and at minimum twice a year. Automated scans catch about 30% of issues. The other 70% — keyboard nav, screen-reader flow, focus traps — need a real manual pass.

Does Google Lighthouse cover WCAG 2.2 AA?

Partially. Lighthouse runs axe-core checks that cover roughly the same automated subset both tools catch. It’s a starting point, not a complete audit. Pair it with manual keyboard and screen-reader testing for a real picture.

Ready to act on this?

Get a site that works as hard as you do.

Built by Pine designs and builds websites for restaurants and local brands that need stronger first impressions and cleaner paths to the next step.

Start the conversation See a recent case study