Accessibility on Your Ordering Site: Settings and Best Practices

Making your ordering site usable by every guest is both the right thing to do and a practical protection for your business. Under the ADA, your ordering site is treated as an extension of your restaurant, and WCAG 2.1 Level AA is the standard courts and regulators most commonly referenced.

This article covers the accessibility settings you control in Admin, how to configure them well, and how to check your own site.

Accessibility on your site is a partnership. These are the capabilities the platform provides, so you know what you're starting from before you configure anything.

Your site is built against WCAG 2.1 Level A and AA. That's the standard courts and regulators reference under the ADA, and it's the target our platform accessibility work is specified, tested and reviewed against, including the criteria covering keyboard operation, focus order, focus visibility, and how components report themselves to screen readers.

Your site declares its language. Every page sets lang="en", which is what tells a screen reader to pronounce your menu in English rather than guessing. It sounds small; it's the difference between "quinoa" and an unintelligible string of phonemes.

Guests can skip repeated navigation. A "Skip to main content" link is the first thing in the tab order, so keyboard and screen reader users can jump straight to your menu instead of tabbing through the header on every page.

Every screen has a clear heading structure. Each screen has one main heading, with section headings below it in order and no skipped levels. On your menu, item names are the headings and prices are plain text, so a guest who navigates by heading hears "Grilled Chicken Bowl," not a list of dollar amounts.

Keyboard focus is always visible. Every interactive control (buttons, option selectors, text fields, menu cards, quantity editors and dialog controls) shows a clear focus outline when a guest tabs to it. The outline color is calculated from your palette so it stays visible against your Primary, Background and Gray colors, whatever brand colors you use.

Order dialogs identify themselves properly. When the service type and time selector opens, it's announced as a dialog and carries its heading as its name, so a screen reader user knows what just opened and why. Every control inside it has a proper accessible name, with no unlabeled buttons.

Dialogs handle focus the way guests expect. When a dialog opens, such as the service type and time selector, item customization, the cart or checkout, focus moves into it. Tab and Shift+Tab stay inside the dialog, Escape closes it, and when it closes, focus returns to the button that opened it, so guests pick up exactly where they left off.

The page behind an open dialog is set aside. While a dialog is open, the content behind it can't be reached by the keyboard or by a screen reader, so a guest is never unsure whether they're inside the dialog or on the page beneath it. Background scrolling is also locked, so guests using magnification don't lose their place behind the overlay.

The order dialog has a defined, logical focus sequence. Close, then service type, then location, then day, then time, then start order. Focus follows the visual layout rather than jumping around the screen.

Option groups behave the way screen reader users expect. Pickup, Delivery, Dine-In and your catering options are grouped as a single control: Tab moves past the whole set, Arrow keys move within it, and the selected option reports its state. This is the standard pattern, and it keeps long option lists from flooding the tab order.

Core ordering steps work from the keyboard. Menu items open with Enter. Service type options move under the Arrow keys. Scrollable areas of the menu can be reached and scrolled from the keyboard, so no part of your menu requires a mouse.

The location finder is fully labeled. Each map marker is named for the store it represents, so a screen reader announces your locations rather than an unlabeled image. The city, state or zip search field has a proper label that screen readers announce, not just placeholder text that disappears when a guest starts typing.

Platform default colors meet contrast requirements. The default colors Lunchbox ships with, including the gray used for phone numbers and pickup times, meet WCAG AA contrast on the default background. Text on controls such as the selected service type is chosen against the surface it actually sits on, so it stays readable.

Item customization, cart and checkout are part of our testing. These steps are tested against the same standard as the rest of the site, including how the page reflows on a narrow 320px screen and how it holds up when a guest enlarges text to 200%.

Menu images support alt text. Your item photography can carry a text description that screen readers read aloud, and it's worth populating. See the menu content guidance below.

Admin blocks some non-compliant color choices. Success Text Color on the Rewards page is applied only when it meets contrast requirements. If a value you set doesn't appear, that's the guardrail working.

NOTE: Accessibility is an ongoing engineering program. Improvements to the ordering site are tracked continuously against WCAG 2.1 Level A and AA, not treated as a one-time project, and releases roll out to every Lunchbox ordering site automatically, with no action needed on your end. If you report something, it goes into that queue.

Go to Design → Web → Colors. Six values drive your ordering site, and each affects contrast: the measurable difference in lightness between text and the surface behind it. Contrast is the most common accessibility issue on restaurant sites. Lunchbox's default colors meet the targets below, so once you replace them with brand colors, keeping your site compliant is in your hands.

Two rules cover most of it.

If a brand color won't meet the target, you rarely need to abandon it. Darkening or lightening the same hue usually clears the threshold while keeping the color recognizably yours, and you can keep the original shade for large text, icons and fills.

Use the Ordering Site Color Check tool to test a palette before launch. Enter your 6 hex codes and it reports every pairing your site actually renders, the specific screen elements affected, and the nearest passing shade at the same hue.

Under the Others tab, Success Text Color is applied only when it meets contrast requirements. If a value you set doesn't appear on the Rewards page, that's why. Choose a darker or lighter version of the same color.

Dark Mode inverts the surface your palette sits on, which changes every contrast relationship on the site. If you enable it, set a genuinely dark Background Color, update your logo and icons for the dark surface, and re-check your palette. A color that passed on white will often fail on near-black, and vice versa.

Your menu copy is read aloud verbatim by screen readers, and it is the part of the experience you write yourself.

If guests reach your ordering site from a separate restaurant website (for example, one built on Squarespace, Wix or WordPress), that site is yours to maintain and is held to the same standard. The most common issues we see there:

Accessibility is a shared responsibility: Lunchbox builds the platform, you configure and populate it. These checks cover your half and take about thirty minutes.

Your Implementation Manager can review your palette with you before launch and walk through the checklist above. If a guest reports difficulty using your site, or you receive an accessibility complaint, contact Support & your Technical Account Manager promptly. The specifics of what the guest encountered matter, and early information gives us the best chance to help.