Direct answer: A digital menu and self-service ordering flow can be tested against a defined set of WCAG 2.2 success criteria covering four areas: text alternatives for menu images (1.1.1), color contrast for text and non-text UI including allergen or dietary labels (1.4.3, 1.4.11), keyboard and screen-reader access to modifiers and controls (2.1.1, 4.1.2), and focus order and target size through multi-step ordering (2.4.3, 2.4.7, 2.4.11, 2.5.7, 2.5.8, 3.3.7). Run each criterion as an explicit pass/fail test before publishing a redesign, and again after any layout or component change.
Why menu browsing and ordering need their own accessibility pass
Reservation widgets, delivery integrations, and digital menus are built with different interaction patterns, so they need separate accessibility testing rather than a single blanket review. A menu page typically involves item images, allergen or dietary icons, expandable modifier lists (size, toppings, spice level), quantity steppers, and a multi-step path to checkout. Each of these components maps to specific, testable WCAG 2.2 success criteria published by the W3C. This article limits its scope to browsing and self-service ordering; it does not cover reservation or table-booking interfaces.
The M.E.N.U. framework
To keep an audit repeatable, group the relevant WCAG 2.2 criteria into four passes, referred to here as the M.E.N.U. framework:
M — Media alternatives
Every menu image, icon, or graphic that conveys information (a dish photo, a "gluten-free" badge, a spice-level icon) needs a text alternative per 1.1.1 Non-text Content, so screen readers can announce what the image communicates rather than skipping it or reading a filename.
E — Emphasis and contrast
Allergen and dietary labels, price text, and interactive controls must meet 1.4.3 Contrast (Minimum) for text and 1.4.11 Non-text Contrast for icons, borders, and control boundaries, so labels remain legible against photo backgrounds or colored badges.
N — Navigation by keyboard and assistive technology
Modifier selectors, quantity steppers, and toggle switches must be operable via keyboard (2.1.1) and must expose their name, role, and current value to assistive technology (4.1.2), so a screen reader user can tell what a control does and what state it is in.
U — Uninterrupted focus order
As a customer moves from item selection to modifiers to cart to checkout, the visible focus order must match the logical reading order (2.4.3), the focus indicator must remain visible (2.4.7) and not be hidden behind sticky headers or footers (2.4.11), and information already entered should not need re-entry at a later step (3.3.7).
Mobile Menu & Ordering Accessibility Checklist
Use this table as a pass/fail worksheet. Test each row on both a full menu page and a single item detail/modifier screen.
| WCAG 2.2 Criterion | Level | What to test | Pass condition |
|---|---|---|---|
| 1.1.1 Non-text Content | A | Dish photos, allergen icons, dietary badges | Each conveys its meaning through alt text or an accessible name, not decoration alone |
| 1.4.3 Contrast (Minimum) | AA | Allergen/dietary label text, prices, descriptions | Text contrast meets the ratio defined in the criterion against its background |
| 1.4.11 Non-text Contrast | AA | Icon borders, toggle switches, stepper buttons | Graphical UI elements meet the required contrast against adjacent colors |
| 2.1.1 Keyboard | A | Modifier lists, size pickers, quantity steppers | Every control is reachable and operable using keyboard alone |
| 2.4.3 Focus Order | A | Item selection through cart and checkout | Tab order follows the same sequence a sighted user would read |
| 2.4.7 Focus Visible | AA | All interactive elements across the ordering flow | A visible focus indicator appears on every focused element |
| 2.4.11 Focus Not Obscured (Minimum) | AA | Sticky headers, floating cart buttons, modals | The focused element is not fully hidden by fixed-position content |
| 2.5.7 Dragging Movements | AA | Sliders for spice level or portion size | A non-drag alternative (buttons, tap targets) is available |
| 2.5.8 Target Size (Minimum) | AA | Modifier checkboxes, steppers, add-to-cart buttons | Targets meet the minimum size or have adequate spacing |
| 3.3.7 Redundant Entry | A | Multi-step checkout (contact info, order notes) | Previously entered information is not required again in the same flow |
| 4.1.2 Name, Role, Value | A | Custom toggles, steppers, expandable modifier groups | Assistive technology correctly announces name, role, and current state |
Step-by-step audit workflow
- List every distinct screen in the ordering path: menu list, category filter, item detail, modifier selection, cart, and checkout steps.
- For each screen, run the M.E.N.U. checklist above and record pass/fail per row, not just an overall impression.
- Test with a keyboard only, unplugging or ignoring the mouse/trackpad, moving through the entire flow from menu to order confirmation.
- Test with a screen reader (such as VoiceOver on iOS or TalkBack on Android) to confirm modifiers, allergen labels, and totals are announced meaningfully.
- Check contrast values on allergen and dietary labels with a contrast-checking tool, testing against every background color or photo overlay used in production, not just a default state.
- Re-run the same checklist after any redesign, component library update, or CMS template change, since a single component swap can reintroduce failures.
Limitations of this checklist
This checklist reflects WCAG 2.2 success criteria as published by the W3C and is scoped to menu browsing and self-service ordering. It has explicit limits:
- Passing every row is a technical accessibility signal, not a guarantee of usability for every customer or every assistive technology combination.
- Automated contrast or accessibility-scanning tools catch a subset of these criteria; manual keyboard and screen-reader testing remains necessary for focus order, name/role/value, and dragging-alternative checks.
- This checklist does not address reservation or table-booking widgets, delivery-platform integrations, kitchen-display systems, or point-of-sale hardware.
- Meeting WCAG 2.2 criteria does not by itself determine legal compliance in any jurisdiction; that determination should come from qualified legal or accessibility-audit professionals.
- WCAG conformance does not, on its own, change how a menu is indexed, ranked, or surfaced by search or discovery products.
Measuring and tracking results over time
Treat the checklist as a recurring measurement, not a one-time gate:
- Record a pass/fail count per criterion at each audit date, so regressions after a redesign are visible immediately rather than discovered from customer reports.
- Track which screens (menu list vs. item detail vs. checkout) generate the most failures, since that indicates where a component library or template needs the most attention.
- Re-test after any change to the modifier component, cart component, or checkout step template, since these are the most frequently reused and most consequential elements.
- Keep a dated log of tool versions and manual test methods used (keyboard-only pass, specific screen reader and OS version) so results are reproducible by a future auditor.
This measurement approach reports on conformance status only. It does not project or promise changes in search visibility, order volume, or reduced no-shows, none of which follow automatically from accessibility conformance work.
The M.E.N.U. checklist above covers the most common failure points, but several situations specific to live ordering flows call for additional WCAG 2.2 success criteria and separate test passes.
Dynamic menu changes during a session
Menus change while a customer is browsing: an item sells out, a price updates, or a modifier becomes unavailable. WCAG 2.2's 4.1.3 Status Messages criterion applies here — a status change should be programmatically determinable by assistive technology without requiring the user's focus to move to it. Test this by triggering a stock or price change mid-session with a screen reader running, and confirm the update is announced.
Embedded or third-party ordering widgets
Many menu-and-order flows load a modifier picker or checkout step inside an iframe supplied by a separate platform. Because the operator does not control that code directly, run 2.1.2 No Keyboard Trap explicitly on any embedded component: confirm a keyboard user can tab both into and back out of the widget. If the embed fails this test, document it separately from failures in operator-controlled templates, since remediation ownership differs.
Reflow at high zoom and small viewports
Allergen labels and modifier lists that work at default zoom can break at 200% zoom or on narrow phone screens. Test 1.4.10 Reflow by zooming the browser to 200% and rotating the device between portrait and orientation-locked views, checking that no content requires two-dimensional scrolling to read a single item's allergen information.
Checkout error handling
Multi-step checkout forms (delivery notes, contact fields, special instructions) should be tested against 3.3.1 Error Identification and 3.3.3 Error Suggestion: submit the form with a required field empty or malformed, and confirm the error is described in text (not color alone) and a screen reader announces both the error and which field it belongs to.
Supplementary edge-case criteria table
| WCAG 2.2 Criterion | Level | Edge case scenario |
|---|---|---|
| 4.1.3 Status Messages | AA | Item goes out of stock or price changes mid-session |
| 2.1.2 No Keyboard Trap | A | Embedded/iframe modifier or checkout widget |
| 1.4.10 Reflow | AA | 200% zoom or narrow/rotated viewport |
| 3.3.1 Error Identification | A | Invalid or empty required checkout field |
| 3.3.3 Error Suggestion | AA | Field-level correction guidance in checkout |
Extending the Audit Workflow
- Repeat the keyboard and screen-reader passes at 200% browser zoom and in both device orientations, not only at default settings.
- Trigger at least one dynamic state change (out-of-stock toggle, price update) during a screen-reader session and confirm it is announced.
- If any ordering step is delivered via an embedded or third-party component, test it separately for keyboard traps and note which vendor owns remediation.
- Submit checkout forms with intentionally invalid input to verify error identification and suggestion text is present and announced.
Additional Measurement Notes
- Weight failures by step: a failure at checkout blocks order completion, while a failure on a single item photo does not; log severity alongside pass/fail status.
- Sample across menu categories (not only best-selling items), since modifier complexity and image density often vary by category.
- Record which failures originate in operator-controlled templates versus embedded third-party components, since remediation paths differ.
Further Limitations
Screen-reader and browser combinations tested in an audit are necessarily a sample, not an exhaustive set of every assistive technology in use. This expanded checklist still does not address reservation/booking widgets, delivery-platform integrations, or hardware ordering kiosks. Where a menu or ordering component is provided by ChefNet or any other vendor, confirm directly with that vendor which accessibility capabilities are currently live before relying on them in an audit; this article does not assert that any specific ChefNet feature meets these criteria.
Primary sources
FAQ
Which WCAG 2.2 success criteria matter most for a digital menu?
For menu browsing and ordering, the most directly relevant criteria are 1.1.1 Non-text Content, 1.4.3 and 1.4.11 for contrast, 2.1.1 Keyboard, 2.4.3 Focus Order, 2.4.7 Focus Visible, 2.4.11 Focus Not Obscured, 2.5.7 Dragging Movements, 2.5.8 Target Size, 3.3.7 Redundant Entry, and 4.1.2 Name, Role, Value. Full criterion text is published by the W3C at the WCAG 2.2 recommendation.
Does passing this checklist mean a menu is legally compliant?
No. This checklist is a technical testing aid based on WCAG 2.2 success criteria, not a legal opinion. Legal requirements vary by jurisdiction and business type, so operators should consult qualified accessibility auditors or legal counsel for compliance determinations.
How is this different from reservation-widget accessibility?
This checklist covers menu browsing, item detail pages, modifier selection, and cart/checkout steps for self-service ordering. It does not address date pickers, calendar widgets, or reservation-specific interaction patterns, which involve a different set of WCAG considerations.
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-02.