Make Your Direct Ordering Page Accessible With a Simple WCAG 2.2 Checklist
Your direct ordering page works for guests only if every guest can finish an order on it. You can check this yourself in about 30 minutes with no special software. This post gives you a short test based on the W3C's WCAG 2.2 and the U.S. Justice Department's web guidance.
The Justice Department states that businesses open to the public must give people with disabilities full and equal enjoyment of their goods and services. Its web guidance lists food establishments and names online ordering systems as an example. The checklist below turns that principle into steps a manager can run.
Why this matters for a restaurant's own ordering page
When a guest orders through your own website, you control the whole experience. That also means the accessibility of the page is your responsibility, even when a vendor supplies the ordering tool. A guest who cannot finish checkout simply leaves, and you never learn why.
Accessibility also helps guests you might not expect. People ordering one-handed, on a small phone, in bright sunlight or with a cracked screen all benefit from the same fixes.
What WCAG 2.2 is
The Web Content Accessibility Guidelines are published by the W3C, the main standards body for the web. Version 2.2 added new success criteria, and several of them fit an ordering page closely. Each criterion has a level: A, AA or AAA. Most business checklists aim for A and AA.
The 30-minute test
Open your ordering page on a phone and on a computer. Place a test order with a pickup item, a modifier and a tip, and stop before payment. Use the steps below as you go.
1. Use the keyboard only
Put your mouse aside and press the Tab key to move through the page. You should be able to reach every menu item, modifier, quantity button, the cart and the checkout button. You should also always see where you are on the page.
WCAG 2.2 adds a rule called Focus Not Obscured (Minimum), at level AA. It says that when an item gets keyboard focus, it must be at least partially visible. A sticky cart bar or cookie banner that covers the highlighted button fails this test.
2. Check tap target size
Small plus and minus buttons for quantity are a common problem. WCAG 2.2 criterion 2.5.8, Target Size (Minimum), at level AA, asks for targets of at least 24 by 24 CSS pixels, or enough spacing around smaller ones.
Try tapping each control with your thumb on a real phone. If you hit the wrong item twice, your guests will too.
3. Remove dragging as the only option
Some pages use sliders or drag handles, for example to set a tip amount or reorder a cart. Criterion 2.5.7, Dragging Movements, at level AA, says any action that involves dragging needs a simple pointer alternative. A set of tip buttons or a typed amount meets that need.
4. Do not make guests type the same thing twice
Criterion 3.3.7, Redundant Entry, at level A, says information a guest already entered should be filled in or available to select. If your page asks for a name and phone number for pickup and then again for payment, that is a barrier. Check the delivery address and billing address as well.
5. Read every error message
Leave the phone number blank, type letters into the number field, and enter an expired card date. Each error should name the field and describe the problem in text. This follows criterion 3.3.1, Error Identification, at level A.
A red outline alone does not meet the rule. The Justice Department guidance gives the same example: when color carries meaning, add a text cue such as the word "required."
6. Check labels and instructions
Every form field needs a visible label that stays on screen while the guest types. Screen reader users depend on those labels to know what each field asks for. Gray placeholder text that disappears is not a label.
Also check pickup instructions. Say plainly what the guest will do on arrival, such as which door to use or how to reach curbside staff.
7. Check contrast and images
The Justice Department says sufficient color contrast between text and background helps people with limited vision or color blindness. Look at your price text, the sold-out label and the disabled buttons. Light gray on white is the usual failure.
Menu photos need short, descriptive alt text. Write "Grilled chicken sandwich with pickles" rather than "IMG_2041." If a photo is purely decorative, a developer can mark it so screen readers skip it.
8. Put help in the same place
Criterion 3.2.6, Consistent Help, at level A, says to place help in the same spot when it appears on multiple pages. If guests can call or message the restaurant about an order, put that option in the same place on the menu, cart and checkout pages. Do not add a phone number to your ordering page unless it is accurate and answered during open hours.
9. Check any sign-in step
If guests can create an account, test the login. Criterion 3.3.8, Accessible Authentication (Minimum), at level AA, says a login cannot require a cognitive function test unless an alternative or help is offered. In practice, let guests paste a password, use a password manager, or check out as a guest without an account.
Record what you find
Keep a simple log with the page, the problem, a screenshot, the date and who is responsible for the fix. Sort it into three groups.
- Blocks an order: a guest cannot finish checkout. Fix this first.
- Slows an order: unclear errors, tiny buttons or repeated fields.
- Looks rough: contrast, labels and alt text that need cleanup.
If another company hosts your ordering tool, send the log to them in writing and ask for a fix date. Keep your request on file.
Offer a backup path
Even a well-tested page can fail for one guest on one device. Give guests a clear second way to order or ask for help during your open hours, and make sure staff know how to take that order. Train the team to treat an accessibility request like any other order, with the same speed and the same respect.
Repeat the test on a schedule
Each menu change, new modifier or tool update can break something that worked last month. Run the keyboard and error checks every time you publish a large menu update. Run the full list at least twice a year.
Accessibility is not a one-time project. It is part of keeping your own ordering page ready for every guest who wants to buy from you directly.
Quick checklist
- Tab through the full order without a mouse.
- Tap every button on a real phone.
- Offer buttons or typed amounts instead of sliders.
- Avoid asking for the same information twice.
- Describe every error in text.
- Use visible labels on every field.
- Check text contrast and write useful alt text.
- Keep help in the same place on every page.
- Allow guest checkout and password managers.
Frequently asked questions
Does my restaurant ordering page have to follow WCAG 2.2?
WCAG is a voluntary standard from the W3C, not a law by itself. The U.S. Justice Department says businesses open to the public must make online services, including ordering systems, usable by people with disabilities. WCAG 2.2 gives you a clear, testable way to check your page.
Can I test my ordering page without a developer?
Yes. You can unplug your mouse, tab through the whole order, zoom the page, and read every error message. These checks catch many of the most common barriers. Send what you find to whoever manages your site.
What should I do if my ordering tool is run by another company?
Run the same checks on the live page, write down each problem with a screenshot, and send the list to the provider in writing. Ask for a fix date. Keep a copy of your request so you have a record.
Sources
See how direct ordering works end to end. Read the full walkthrough or see AppWT Relay.