Auditing Restaurant Menu Photography and Visual Content Against WCAG 2.2

What WCAG 2.2 Actually Covers for Menu Imagery

WCAG 2.2, published by the W3C, organizes requirements into success criteria grouped under principles such as Perceivable and Operable. For restaurant website visual content, the criteria that apply most directly are 1.1.1 Non-text Content, 1.4.3 Contrast (Minimum), 1.4.5 Images of Text, and 1.4.11 Non-text Contrast. These criteria describe what must be true of an image, banner, or graphic for it to be perceivable by someone using a screen reader, a screen magnifier, or a device with limited color perception. They do not describe how a booking widget should behave when a field is left blank, or how a reservation confirmation should be announced — those fall under different criteria entirely and require a separate audit pass.

It is worth being precise about what "compliance" means in this context. WCAG 2.2 sets out testable conditions. An auditor can check whether a condition is met or not met. The specification itself does not make legal determinations about a given jurisdiction's accessibility obligations, and this article does not attempt to draw legal conclusions — operators should confirm applicable requirements with qualified counsel if that matters for their business.

The SCAN Framework for Menu Visual Content Audits

To keep an audit repeatable, we use a four-part framework covering the categories of content most common on restaurant sites: dish photography, promotional banners, and PDF or image-based menus.

S — Semantic Alternative Text

• Every dish photo that conveys information (ingredients, plating, portion size implied visually) has alt text describing that information, not just the dish name if the name alone is already in adjacent visible text.
• Purely decorative images (background textures, generic stock photos of a dining room used only for atmosphere) use empty alt text so assistive technology does not announce redundant content, consistent with the guidance in 1.1.1 Non-text Content.
• Alt text avoids redundant phrases like "image of" or "photo of," since screen readers already identify the element as an image.

C — Contrast on Text-Bearing Graphics

• Any banner, coupon graphic, or promotional image containing text is checked against 1.4.3 Contrast (Minimum): 4.5:1 for normal text, 3:1 for large-scale text.
• Where a banner's text is purely stylistic and the same information exists as real text elsewhere on the page, note whether 1.4.5 Images of Text exceptions might apply, and record the reasoning rather than assuming it automatically qualifies.

A — Accessible Alternatives to Scanned PDFs

• Menu PDFs are checked for whether they contain actual text content versus being a flattened image of a menu with no underlying text layer.
• If a PDF is image-only, the audit records this as a finding requiring either a tagged PDF, an HTML equivalent, or another accessible alternative, since a screen reader cannot extract information from a flat image.

N — Non-text Element Contrast

• Icons, category dividers, allergen symbols, and graphical buttons overlaid on photography are checked against 1.4.11 Non-text Contrast (3:1 minimum against adjacent colors) for their visual boundaries and states.
• This check is distinct from text contrast — it applies to the graphical elements themselves, such as an icon's outline or a toggle's visible state.

Step-by-Step Audit Workflow

1. Inventory every image, banner, and PDF used on menu-facing pages, separating decorative from informative content.
2. For each informative image, record the current alt text (or its absence) and evaluate whether it conveys equivalent information to a sighted user.
3. For each banner or graphic containing text, measure contrast using the foreground and background color values against the thresholds in 1.4.3.
4. Open each PDF menu and attempt to select and copy text. If no text can be selected, flag it as image-only.
5. Identify all icons and graphical UI elements layered over photography and measure their contrast against 1.4.11 thresholds.
6. Document findings in a tracked list with the specific success criterion, current state, and remediation owner.
7. Re-test after fixes are applied, since remediation of one element (for example, replacing a PDF) can introduce new content requiring its own alt text or contrast check.

Content Type to Success Criteria Reference

Measurement and Verification

Contrast ratios under WCAG 2.2 are calculated from relative luminance values of foreground and background colors, using the formula defined in the specification: (L1 + 0.05) / (L2 + 0.05), where L1 is the lighter color's relative luminance and L2 is the darker one. Normal-size text requires at least 4.5:1; large-scale text requires at least 3:1 under 1.4.3. Non-text elements assessed under 1.4.11, such as icon outlines or interactive states layered on food photography, require at least 3:1 against adjacent colors. These ratios can be measured with any tool that samples pixel color values and applies this formula; the audit record should note the exact color values sampled, not just a pass/fail label, so remediation work has a concrete target.

Explicit Limitations

• This workflow addresses non-text content and contrast only. It does not evaluate keyboard navigation, focus order, form labeling, or other criteria that apply to booking widgets, ordering carts, or reservation confirmation flows — those require a separate audit against their own applicable success criteria.
• Automated contrast checkers measure color values accurately but cannot judge whether alt text is meaningful or whether a PDF's tag structure is correct; both require manual inspection.
• Meeting the specific criteria listed here does not by itself establish overall WCAG 2.2 conformance at any level, since conformance requires addressing all applicable criteria across a page or site, not a subset.
• This article draws only on the WCAG 2.2 specification itself and does not reference third-party prevalence statistics, legal case outcomes, or claims about how common any particular failure is across the restaurant industry.

Where ChefNet May Fit

ChefNet is developing restaurant discovery and operations products, which may eventually intersect with how menu content, imagery, and structured information are presented and managed. Any specific accessibility-related capability — such as tooling to flag missing alt text or to manage PDF menu alternatives — should be verified directly with ChefNet's current documentation before an operator relies on it, since product capabilities change and this article does not assert which features are live at any given time.

Edge Cases the Core Workflow Can Miss

Several presentation patterns common on restaurant sites do not fit neatly into a single-image, single-PDF audit pass. Reviewing these separately reduces false "pass" results.

Sampling Strategy for Large Menus

Auditing every dish photo on a large multi-page menu individually is not always practical in a first pass. A structured sampling approach keeps the audit useful without pretending full coverage was achieved:

1. Group images by template or component type (e.g., "dish card thumbnail," "hero banner," "PDF download link") rather than by menu section.
2. Fully review one representative instance of each template type against the SCAN checks described above.
3. If the template is generated from the same code across all instances, a passing or failing result for alt-text markup and contrast rules typically applies to the whole template — but confirm this by spot-checking at least a few additional instances, since individual content editors may have entered inconsistent alt text even where the template is identical.
4. Record the sample size and which items were spot-checked, so a later reviewer knows the finding was based on a sample rather than an exhaustive review.

Triggers for Re-Audit

Because menu content changes frequently, a one-time audit has a limited shelf life. Re-run at least the relevant SCAN checks whenever:

• A new promotional banner or seasonal menu graphic is published.
• A PDF menu is replaced or updated with new pricing or items.
• The site undergoes a visual redesign that changes color palettes, since contrast ratios calculated under 1.4.3 and 1.4.11 depend on the specific foreground/background values in use.
• A third-party ordering or menu-display widget is upgraded, since vendor-controlled markup can change independently of the restaurant's own site.

Additional Measurement Limitations

Beyond the tool limitations already noted, contrast measurement itself assumes a known, static foreground and background color pair. Text overlaid directly on a photograph — a common dish-photo treatment — often has no single background color, since the photo itself varies in luminance behind the text. In these cases, record the range of contrast values sampled across the busiest and least busy parts of the underlying image, rather than a single ratio, and treat any area falling below the 1.4.3 threshold as a finding.

Primary sources

• W3C: Web Content Accessibility Guidelines 2.2

FAQ

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-12.