PDF Menu Accessibility Audit Workflow: A Four-Pass Method for WCAG 2.2

Why a PDF menu needs its own audit

A restaurant's main website may already follow reasonable accessibility practices, but a linked PDF menu is a separate file with its own internal structure, generated by whatever software exported it — a word processor, a design tool, or a scanned image saved as PDF. None of the styling, headings, or navigation choices made on the website carry over automatically. A PDF can look identical to a well-structured web page while containing no tags at all, which is why it needs a distinct, document-level check rather than being folded into a general site review.

The Four-Pass PDF Menu Audit

This workflow breaks the review into four passes, each focused on a different layer of the file. Running them in order avoids wasted effort — for example, checking text alternatives before confirming the document is even tagged tends to produce unreliable results.

Pass 1: Structural tagging check

Open the tags panel in your PDF tool. Confirm that the document has a tag tree at all, and that major elements — headings, paragraphs, lists, and tables — are tagged with the correct roles rather than generic containers. A menu with sections like "Starters," "Mains," and "Desserts" should have those as heading tags, not just larger or bold text with no underlying structure. This relates to how content relationships are conveyed programmatically, addressed under WCAG 2.2's information and relationships criterion.

Pass 2: Reading order verification

Use the reading-order tool or a screen reader to step through the document and confirm the order items are announced in matches the order a sighted reader would follow: section heading, then dish name, then description, then price. Multi-column menu layouts are a common source of scrambled reading order, where a screen reader may jump across columns instead of down them. This maps to the meaningful sequence concept in WCAG 2.2.

Pass 3: Text alternatives and contrast

Check every image, logo, icon (such as a chili symbol for spice level or an allergen icon), and any text that has been flattened into an image. Each should have a text alternative describing its meaning, or be explicitly marked as decorative if it carries no information. Where menu text is presented as an image rather than selectable text, also check color contrast between text and background, since flattened text bypasses normal text-rendering contrast handling. These checks connect to the non-text content and contrast provisions in WCAG 2.2.

Pass 4: Navigation and metadata

Confirm the file has a descriptive title (visible in the PDF reader's title bar or tab, not just the filename), a set document language, and — for longer menus — bookmarks or a tagged heading structure that lets a user jump between sections instead of scrolling through everything linearly. This addresses the kind of page-titling and heading-based navigation concepts described in WCAG 2.2.

Checklist mapped to WCAG 2.2 concepts

Step-by-step workflow to run the audit

1. Export or download the current live PDF menu, not an old working file, so the audit reflects what customers actually receive.
2. Open it in a PDF tool with a tags and reading-order panel.
3. Run Pass 1 through Pass 4 in order, recording a pass/fail note for each item in the checklist table above.
4. Where an item fails, note the specific location (page, section, or element) rather than a general description, so remediation is targeted.
5. Re-export the corrected file and repeat the relevant pass to confirm the fix, rather than assuming it worked.
6. Test the final file with an actual screen reader pass, since automated tag checks do not fully substitute for hearing how the document is announced.

Limitations of this workflow

WCAG 2.2, as published, is written for web content, and applying its success criteria to a static PDF is a common practice rather than a formally defined conformance path within the guidelines themselves. This workflow uses WCAG 2.2 concepts as a structured reference point for a document audit, not as a claim that a PDF is "WCAG 2.2 conformant" in the same sense a web page might be. Automated tag checkers can confirm that tags exist without confirming they are used correctly, and contrast tools may not reliably measure text that has been flattened into a raster image. Manual screen reader testing remains necessary, and results can vary between screen reader and PDF reader combinations. This workflow also does not cover legal or regulatory conformance requirements, which vary by jurisdiction and require independent verification.

Measuring and tracking audit results

Keep a simple log rather than a one-time checklist. For each PDF menu file, record: file name and version, audit date, pass/fail status for each of the four passes, the specific issue location for any failure, the remediation action taken, and the date of re-verification. Reviewing this log on a fixed schedule — for example, whenever the menu content changes — helps ensure that a new export doesn't quietly reintroduce a tagging or reading-order problem that was previously fixed. Tracking failures by pass number, rather than by page, also makes it easier to see whether a particular authoring tool or template is producing recurring structural issues.

Where ChefNet fits

ChefNet is developing restaurant discovery and operations products, and menu-related tooling may be part of that direction. Any specific capability for auditing, tagging, or replacing PDF menu files should be verified directly with ChefNet's current product documentation before an operator relies on it, since this article describes a general audit method rather than a description of a specific ChefNet feature.

Edge cases that standard tag checks miss

The four-pass workflow assumes a document that at least attempts tagging. Several common menu formats behave differently and need a modified approach before Pass 1 can even begin.

Scanned or image-only menus

A menu exported as a photograph or scan of a printed page has no text layer at all — every word is part of one large image. Running an OCR (optical character recognition) pass in the PDF tool first is a prerequisite, not an optional step, since without it there is no text for a screen reader to reach regardless of tagging. After OCR, re-check recognition accuracy manually against the printed menu; OCR errors on dish names, prices, or allergen terms can silently misinform a customer relying on assistive technology, which is a different failure mode than a tagging or reading-order problem.

Allergen and nutrition tables with merged cells

Menus that present allergens as a grid (dishes down one axis, allergen icons across the top) often use merged or spanning cells when exported from spreadsheet or design tools. Confirm in the tags panel that header cells are marked as table headers and associated with their data cells, since a visually clear grid can still read as an undifferentiated block of text to a screen reader if header associations are missing. This is a structural concern distinct from the icon-level text alternatives covered in Pass 3.

Multi-language menus

Where a menu includes sections in more than one language, check whether the document language is set at the section level, not only once for the whole file. A single document-wide language tag will cause a screen reader to mispronounce the other-language sections.

Interactive fields in order-ahead PDFs

Some downloadable menus include fillable fields, such as an order form or a reservation request field embedded in the PDF. Each field needs an associated label read aloud when the field receives focus, and the tab order through the fields should be checked separately from the reading order of the surrounding menu text, since form field order and content reading order are controlled independently in most PDF tools.

Pre-publication sign-off workflow

Before a new or revised PDF menu replaces the version linked on the website, run this short sign-off sequence in addition to the four-pass audit:

1. Confirm the file passed all four audit passes on the exact file being published, not an earlier draft.
2. Confirm OCR and merged-cell checks were completed if the menu contains scanned content or grid-style allergen tables.
3. Confirm document language is set correctly for every language section present.
4. Have a second person, separate from whoever built the file, perform the screen reader listen-through before publishing.
5. Record the sign-off date and the name of the person confirming it in the audit log described in the main workflow.

Documenting your testing environment

Because results can vary between screen reader and PDF reader combinations, log which pairing was used for each audit rather than assuming one test covers all readers customers might use.

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