Catering Company Website Accessibility Guide 2026 | ADA, EAA, Online Menus, Event-Quote Forms, Allergen Disclosures, WCAG 2.2 AA

Last updated: 2026-06-04

Catering companies, private-event and wedding caterers, corporate and office-lunch caterers, drop-off and full-service caterers, food-truck and pop-up caterers, kosher and halal caterers, and ghost-kitchen catering brands run the bulk of their lead generation and ordering through a website that bundles an online menu or menu PDF, an event-quote or 'request a proposal' form, a per-head package configurator (passed appetizers, plated dinner, buffet, family-style, grazing table, bar packages), a tasting-appointment booker, a dietary-restriction and allergen selector, and increasingly an online-ordering and payment flow for drop-off catering. Catering is an information-dense, decision-heavy purchase—guest counts, dietary restrictions across an entire event, allergen safety, budget per head, service style, and date availability all have to be communicated through the site—which makes accessibility failures especially costly. A blind event planner comparing per-head package pricing, a parent of a child with a severe peanut allergy trying to confirm allergen handling, a low-vision bride reading a tasting menu rendered as a flat image, or a keyboard-only corporate-admin building a 60-person office-lunch order are routinely blocked by menu PDFs, image-only price tiers, and unlabeled quantity steppers. Caterers are places of public accommodation under ADA Title III, face California Unruh exposure on every interaction with a California resident, fall under the European Accessibility Act once they serve EU-resident clients or sell online, and carry an additional FDA / FALCPA allergen-disclosure overlay that requires the major food allergens to be communicated in a way every customer—including those using assistive technology—can perceive. This guide covers the legal framework, the catering-specific failure patterns, and a concrete compliance checklist.

Legal Requirements

Law / Standard Effective Date Summary Penalty
ADA Title III In effect Catering companies are places of public accommodation under ADA Title III (food-service establishments are expressly enumerated in the statute). The website is the primary menu, event-quote, package-configuration, tasting-booking, and online-ordering channel, putting it within Title III scope in every U.S. circuit. WCAG 2.1 AA is the de-facto conformance standard, and DOJ has signaled WCAG 2.2 AA will become the reference standard in the next regulatory cycle. Restaurants and food-service businesses have been among the most frequently targeted categories in website-accessibility litigation, and caterers share the same risk profile. Injunctive relief plus attorneys' fees. California Unruh statutory damages of $4,000 per visit. New York State Human Rights Law damages of $1,000-$25,000 plus attorneys' fees. Plaintiff-firm settlements for food-service websites typically range $5,000-$25,000 plus remediation costs.
California Unruh Civil Rights Act In effect California Unruh provides a private right of action for any denial of full and equal access to a business establishment, with statutory damages of $4,000 per visit, and California serial-filer plaintiff firms have aggressively targeted food-service websites. Caterers whose online menus are inaccessible PDFs, whose event-quote forms have unlabeled fields and inaccessible date pickers, or whose allergen information is conveyed only through color-coded icons are common targets. Because each visit can be pleaded as a separate violation, exposure compounds quickly. $4,000 per visit in statutory damages plus attorneys' fees and costs, injunctive relief mandating WCAG conformance, and treble damages available in some circumstances.
FDA Food Allergen Labeling (FALCPA) and Menu Allergen Disclosure In effect The Food Allergen Labeling and Consumer Protection Act (FALCPA) and the FASTER Act require disclosure of the nine major food allergens (milk, eggs, fish, crustacean shellfish, tree nuts, peanuts, wheat, soybeans, and sesame). While menu-level allergen disclosure rules vary, caterers that publish allergen information, ingredient lists, or 'free-from' claims online must make that information perceivable to all customers, including those using assistive technology. Communicating allergen status only through color-coded icons, image legends, or untagged PDFs means a blind or color-blind customer with a life-threatening allergy cannot reliably determine whether a dish is safe—an accessibility failure with direct safety consequences. FDA enforcement for allergen mislabeling and undeclared allergens (warning letters, recalls, and in severe cases seizure or injunction), plus civil liability if an inaccessible or inaccurate allergen disclosure contributes to an allergic reaction. Layered with ADA/Unruh disability-access findings, exposure compounds.
European Accessibility Act (EAA) 2025-06-28 Catering companies located in the European Union, or non-EU caterers that serve EU-resident clients (destination weddings, corporate events for EU-based companies) or sell online to EU buyers, must conform their consumer-facing digital services to EN 301 549 / WCAG 2.1 AA. Online-ordering and e-commerce flows are independently in scope under the EAA's e-commerce provisions, and EU food-information rules (Regulation 1169/2011) require allergen information to be provided in an accessible format. Member-state fines up to EUR 1,000,000 per non-conforming service, and regulator-ordered withdrawal of non-conforming digital services from the EU market.

Key Accessibility Issues in Catering Services & Private-Event Caterers

Menus and Package Pricing Published Only as Flat Image or Untagged PDF

The catering menu is the heart of the site, and it is overwhelmingly published as a designer-made PDF or a flat JPEG/PNG exported from a layout tool. These files have no real text, no tagged reading order, no headings, and no alternative text, so a screen reader announces nothing more than 'image' or a filename. Per-head package tiers (Silver, Gold, Platinum) and bar packages are frequently rendered the same way—as image price tables. A blind or low-vision customer cannot read the menu, compare package inclusions, or determine pricing, which blocks them from the core purchasing decision.

How to fix:

Publish menus and package pricing as real, structured HTML: use semantic headings for menu sections (Appetizers, Plated Entrees, Buffet, Desserts), descriptive list or table markup for items and prices, and a semantic <table> with <caption> and <th scope=> for package-comparison tiers. Where a downloadable PDF is also offered, provide a properly-tagged accessible PDF with reading order, tagged headings, and alternative text—never a flat image as the only source of menu information.

Allergen and Dietary Information Conveyed Only by Color-Coded Icons

Catering menus love compact allergen legends—small colored dots or icons next to each dish indicating gluten-free, dairy-free, nut-free, vegan, vegetarian, and so on. When that status is communicated only through color or through an icon with no text alternative, it fails WCAG 1.4.1 (Use of Color) and 1.1.1 (Non-text Content): a color-blind customer cannot distinguish the dots, and a screen-reader user gets no allergen information at all. For a customer with a severe, potentially anaphylactic allergy, this is not a cosmetic problem—it is a safety failure that can also create FDA/FALCPA and liability exposure.

How to fix:

Pair every allergen and dietary indicator with a text label or accessible name: provide alternative text on icons ('Contains tree nuts', 'Gluten-free'), include a visible text legend, and never rely on color alone to distinguish categories. Offer a filter or list view that lets customers see all dishes matching a dietary need with the allergen status spelled out in text. For high-risk allergies, include a clearly written cross-contact statement and an accessible way to contact the caterer to confirm handling.

Event-Quote and 'Request a Proposal' Forms With Unlabeled Fields and Inaccessible Date Pickers

The event-quote form is the caterer's primary lead-capture tool, asking for event date, guest count, service style, venue, budget, and dietary restrictions. These forms routinely use placeholder text instead of real <label> elements, custom JavaScript date pickers with no keyboard support, guest-count steppers built from <div>s, and budget or service-style selectors rendered as unlabeled button grids. Required-field errors are often shown only in red text with no programmatic association. A keyboard or screen-reader user cannot reliably complete the form, so the caterer loses the lead and the customer is locked out of the primary intake channel.

How to fix:

Use a persistent <label for=> on every field (placeholders are not labels), a native <input type='date'> or accessibility-tested keyboard-navigable date picker for the event date, and <input type='number'> with a label for guest count. Group service-style and budget choices as native radio buttons inside a <fieldset>/<legend>. Associate validation errors with their fields using aria-describedby and announce them through an aria-live region, and describe the error in text rather than by color alone.

Online-Ordering Package Configurator With Inaccessible Quantity Steppers and Hidden Running Totals

Drop-off and corporate caterers increasingly offer an online configurator where the customer builds an order by choosing dishes and quantities (often 'serves 10' trays), selecting add-ons, and reaching a per-head or total price. The plus/minus quantity steppers are commonly built from unlabeled <span>s or <div>s with click handlers and no <input type='number'>; the running order total updates visually but is not announced through aria-live; and the minimum-order or lead-time warnings appear as transient visual messages. A screen-reader user cannot tell how many trays they have selected or what the order totals, and a motor-impaired user struggles with tiny stepper targets.

How to fix:

Implement quantity controls as <input type='number' min=> with a visible <label> (or accessible buttons with clear accessible names like 'Increase quantity of Caesar salad tray'), and ensure touch targets meet the WCAG 2.5.8 minimum target size. Announce running-total and per-head price updates through an aria-live='polite' region. Surface minimum-order, lead-time, and delivery-radius constraints as persistent, programmatically associated messages rather than transient toasts, and provide an accessible order-summary review before checkout.

Tasting-Appointment Booking and Venue Maps That Block Assistive-Technology Users

Full-service caterers book tasting appointments through an embedded scheduler and often display a service-area map or venue-partner list. The scheduler frequently has the same calendar and time-slot failures seen across booking widgets—color-only availability, non-keyboard-navigable date grids, unlabeled time buttons—while the service-area map is an embedded interactive map with no text alternative listing the areas served. A screen-reader user cannot book a tasting or determine whether their event location is within the service area.

How to fix:

Use an accessibility-tested scheduler with keyboard-navigable date selection, time slots as real <button> elements with availability stated in the accessible name, and aria-live confirmation of the selected slot. Provide a text list of service areas or venue partners alongside any interactive map (the map can remain for sighted users as an enhancement), and make sure the 'book a tasting' call to action is a real, focusable button.

Compliance Checklist

  • Menus are published as structured HTML with semantic section headings and list or table markup, not as a flat image or untagged PDF
  • Package-tier and bar-package pricing uses a semantic <table> with <caption> and <th scope=>
  • Any downloadable menu PDF is a properly-tagged accessible PDF with reading order and alternative text
  • Allergen and dietary indicators include a text label or accessible name, never color or icon alone (WCAG 1.4.1, 1.1.1)
  • A text legend and a dietary-filter list view are provided, with allergen status spelled out in text
  • A written cross-contact statement and an accessible contact path for allergy questions are provided
  • Event-quote form fields use persistent <label for=> (not placeholder-only)
  • Event date uses native <input type='date'> or an accessibility-tested keyboard-navigable date picker
  • Guest count uses <input type='number'> with a label; service-style and budget use radio buttons in a <fieldset>/<legend>
  • Form validation errors are associated via aria-describedby, announced through aria-live, and described in text not color
  • Order-configurator quantity controls use <input type='number'> or accessible buttons with clear accessible names
  • Quantity stepper and add-to-order touch targets meet the WCAG 2.5.8 minimum target size
  • Running-total and per-head price updates are announced through aria-live='polite'
  • Minimum-order, lead-time, and delivery-radius constraints are persistent and programmatically associated, not transient toasts
  • An accessible order-summary review is presented before checkout
  • Tasting-appointment scheduler is keyboard-navigable with time slots as real <button> elements and aria-live confirmation
  • A text list of service areas or venue partners accompanies any interactive map
  • Checkout and payment flow meets WCAG 2.2 AA
  • Published accessibility statement documents phone-assisted ordering and allergen-confirmation alternatives

Further Reading

Other Industry Guides