WCAG 2.2 Audit Checklist for Restaurant Site Navigation and Search

Why Navigation and Search Deserve a Separate Review

Most restaurant accessibility discussions jump straight to online ordering or table reservations because those are the pages tied to revenue. But primary navigation, footer links, and site search are present on nearly every page and are usually the first interactive elements a visitor encounters. If a visitor using a keyboard or screen reader cannot move through the header menu, cannot find a way past a "skip to content" gap, or cannot tell why a search returned nothing, they may never reach the ordering or booking flow at all. This checklist treats navigation and search as their own audit surface, evaluated against the relevant WCAG 2.2 success criteria published by the W3C.

The Three-Pass Navigation Audit

This is a practical framework for organizing the review into three passes, each mapped to a cluster of WCAG 2.2 success criteria. It does not replace a full-site conformance audit; it is a way to structure a focused review of navigation, footer, and search components.

Pass 1: Keyboard Operability

• 2.1.1 Keyboard — Confirm every navigation link, dropdown submenu, footer link, and the search input and submit control can be reached and activated using only Tab, Shift+Tab, Enter, and arrow keys where applicable.
• 2.1.2 No Keyboard Trap — Confirm that opening a dropdown menu, mobile hamburger menu, or search autocomplete list does not trap keyboard focus inside it with no way to exit.
• 2.5.7 Dragging Movements — If any navigation element requires a drag gesture (for example, a horizontally scrolling category bar), confirm an equivalent single-click or keyboard alternative exists.
• 2.5.8 Target Size (Minimum) — Check that clickable nav items and search icons meet the minimum target size, or have sufficient spacing, so they are not difficult to activate precisely.

Pass 2: Focus Order and Visibility

• 2.4.3 Focus Order — Tab through the header, then the footer, then the search results page, and confirm the order matches the visual and logical reading order rather than jumping unpredictably.
• 2.4.7 Focus Visible — Confirm every focusable navigation and search element shows a visible focus indicator when tabbed to, not just on mouse hover.
• 2.4.11 Focus Not Obscured (Minimum) — Check that sticky headers, cookie banners, or promotional overlays do not hide the focused element from view.
• 2.4.13 Focus Appearance — Where feasible, confirm the focus indicator has adequate size and contrast against adjacent colors, particularly on dark-themed navigation bars.

Pass 3: Error Identification in Site Search

• 3.3.1 Error Identification — Submit an empty search and a search with no matching results; confirm the resulting message is presented as text (not only an icon or color change) and is announced to screen readers.
• 3.3.7 Redundant Entry — If the search interface asks for the same information twice within a single process (for example, a location filter repeated on a refined search), confirm previously entered information is carried forward rather than re-requested.
• 3.2.6 Consistent Help — If a help or contact link appears near the search bar on one page, confirm it appears in the same relative location across other pages that include search.

Step-by-Step Workflow

1. List every interactive element in the header navigation, footer, and search component: links, buttons, dropdown toggles, and form fields.
2. Disconnect or ignore the mouse. Using only the keyboard, tab from the top of the page through the entire header navigation, noting any element that cannot receive focus.
3. Continue tabbing into the page body and down to the footer, recording any point where focus order jumps unexpectedly or skips visible elements.
4. Open the site search, submit an empty query, then submit a query with no expected matches. Read the resulting message aloud or use a screen reader to confirm it is announced.
5. Check whether any overlay, sticky banner, or cookie notice obscures the currently focused element at any point in the tab sequence.
6. Document each finding against the specific WCAG 2.2 success criterion it relates to, then re-test after each fix is applied.

Audit Reference Table

Explicit Limitations

• This checklist covers navigation, footer, and search only. It does not evaluate menu browsing, online ordering carts, or reservation forms, which require separate reviews.
• Automated scanning tools can catch some coding-level issues but cannot reliably judge focus order logic or the clarity of error text; manual keyboard testing is necessary.
• Passing these checks is not a legal conclusion about compliance with any accessibility law or regulation. Consult qualified legal counsel for regulatory questions.
• Testing with one screen reader and browser combination does not guarantee identical behavior across all assistive technology and browser pairings.
• WCAG 2.2 conformance claims are self-assessed unless verified by an independent accessibility review; this checklist supports self-assessment but does not constitute one.

Measuring Progress

Track findings using simple, repeatable counts rather than subjective impressions:

• Keyboard operability rate: number of navigation and search elements successfully operated by keyboard divided by total interactive elements in that area, expressed as a percentage.
• Focus order deviations: count of points where tab order diverges from visual reading order, recorded per page template.
• Unlabeled error states: count of search or filter error conditions that do not produce announced text messages.
• Re-test interval: track how many previously logged issues remain open after each site update, to confirm fix

  Edge Cases the Three-Pass Audit Can Miss

  The three-pass structure covers the majority of navigation and search components, but several configurations common to restaurant sites need targeted checks that a generic run-through will not surface.

  Embedded and Third-Party Components

  • Iframe-embedded search or reservation widgets in the header: Tab into and out of the iframe boundary specifically. Focus can enter an iframe and never return to the parent page's tab sequence, or vice versa, which is a distinct failure from 2.1.2 within a single document.
  • Language switchers in the footer: Confirm the control is keyboard-reachable and that switching language updates the page's lang attribute so assistive technology announces content in the correct language.
  • Dynamically injected search results: If results load via AJAX without a page reload, check whether the update is announced. WCAG 2.2 carries forward 4.1.3 Status Messages, which applies here: a results count or "no matches" message that appears without moving focus should still be programmatically announced through a live region.

  Single-Page and App-Like Navigation

  Restaurant sites built as single-page applications change content without a full page reload when a visitor selects a nav item. In this pattern, focus does not automatically move to the new content, which can leave a screen reader user positioned on a link that no longer matches what is on screen. Test route changes specifically: after each in-page navigation event, confirm focus is deliberately moved to a logical starting point, such as the new section's heading.

  Sampling Across Templates

  Navigation and footer markup is often shared across a CMS theme, but restaurant groups with multiple locations frequently inject location-specific content — addresses, hours, embedded maps — into otherwise shared footer regions. Testing a single page template is not sufficient. A representative sample should include:

  1. The homepage.
  2. At least one individual location page, if the site has more than one.
  3. A page with a populated search-results state and a page with a zero-results state.
  4. Any page where a cookie or promotional banner is present, since these can alter focus order or obscure focus indicators only on first visit.

  Ownership and Regression Tracking

  Because header navigation, footer, and search components are typically shared assets rather than page-specific content, remediation should be tracked by component, not by page. A CMS theme update, plugin change, or vendor-supplied search widget update can silently reintroduce a previously fixed issue. Maintain a short record for each component listing: the WCAG 2.2 criterion tested, the date of last verification, the theme or widget version at that time, and who owns remediation if the component is maintained by a third-party vendor rather than in-house staff. Re-run the relevant pass after any update to shared navigation, footer, or search code, not only on a fixed calendar schedule.

  ChefNet Product Context

  The checklist and criteria above are general guidance based on the published WCAG 2.2 specification and apply to any restaurant website's navigation and search components, independent of the platform used to build them. ChefNet is developing restaurant discovery and operations products; this article does not assert that any specific ChefNet navigation, search, or footer component currently meets any WCAG 2.2 success criterion. Operators evaluating ChefNet or any other vendor's site components should request current, dated accessibility documentation directly from that vendor and verify which capabilities are live at the time of evaluation, since features under active development may change.

  Primary sources

  • W3C: Web Content Accessibility Guidelines 2.2

  FAQ

  Does WCAG 2.2 apply specifically to restaurant website navigation?

  WCAG 2.2 applies to all web content, including restaurant sites, and does not carve out navigation, footers, or search as exceptions. The success criteria for keyboard operability, focus order, and error identification apply the same way they would to any website with interactive menus and forms. Restaurant operators should treat their primary navigation and search bar as full-fledged interactive interfaces subject to the same criteria as ordering or booking widgets.

  How is auditing navigation different from auditing booking or ordering flows?

  Navigation, footer links, and site search are typically present on every page and used before a visitor ever reaches a menu, ordering cart, or reservation form. A visitor who cannot tab through the main menu or recover from a failed search may abandon the site before encountering booking or ordering interfaces at all. This checklist isolates those upstream surfaces rather than duplicating audits already aimed at transactional flows.

  Can automated scanners fully complete this kind of audit?

  Automated tools can flag some issues, such as missing focus indicators in code or duplicate link text, but they generally cannot reliably judge logical focus order, whether error messages are understandable, or whether keyboard traps exist in custom widgets. Manual keyboard-only testing and, where possible, testing with actual assistive technology remain necessary. Treat automated results as a starting point, not a conformance verdict.

  Editorial disclosure: ChefNet publishes this guide and develops products for restaurant discovery and operations. General operating guidance is separated from product claims. Capabilities can change as pilots progress. Published 2026-08-03.