Picture a regular of yours, seventy-one years old, who has ordered your Friday fish special for a decade. She has a tablet now and her granddaughter told her she can order online. She opens your site and finds a PDF that arrives as a wall of tiny type. She pinches to zoom, loses her place, scrolls sideways looking for the price, and gives up. She calls instead — and gets voicemail because it's 6:40 on a Friday. So she doesn't order at all.
Multiply that. Roughly one in four American adults reports a disability, and vision, dexterity, and cognitive differences all touch the act of reading a menu on a screen. Add the far larger group with situational limitations: reading glasses left at the office, a phone in bright sun, a broken wrist, holding a toddler with one arm. Then note that the demographic most likely to struggle with a badly built menu — older guests — overlaps heavily with your most loyal, highest-frequency customers. These aren't marginal users. They are the people who have been coming for years.
Now the good news, and it's substantial: nearly every fix here is cheap, permanent, and improves the page for every guest. There is no accessible version and a normal version. There's a well-built ordering page and a badly built one. What follows is what separates them, in the order that matters most.
The Four Barriers That Block the Most Orders
If you fix nothing else, fix these. They account for the overwhelming majority of real-world failures on restaurant ordering pages.
| Barrier | Who it blocks | The fix |
|---|---|---|
| Menu published as a PDF or image | Screen reader users, low vision, every phone user | Real HTML menu with orderable items |
| Low-contrast text (light grey on white) | Low vision, older eyes, anyone outdoors | 4.5:1 contrast minimum for body text |
| Tap targets under 44 pixels | Motor impairments, tremor, one-handed use | 44×44 px with 8 px separation |
| Images with no alt text | Screen reader users | One short descriptive sentence each |
Take the first row seriously, because it's the most common and the most damaging. A PDF menu made in a design program is effectively a photograph of text. A screen reader can't announce it reliably, the text won't reflow on a phone, nothing in it is searchable, and — the part that should get an owner's attention — nothing in it is orderable. Replacing it with an HTML menu improves accessibility, mobile usability, conversion, and search visibility in a single move. If you're rebuilding the menu anyway, our guide to structuring an online menu properly covers categories and item ordering while you're in there.
Contrast and Text: The Cheapest Wins Available
Designers love light grey type. It photographs well in a portfolio and it is genuinely hard to read. The commonly used benchmark is a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text — free contrast checkers will tell you your numbers in seconds if you paste in your two hex values.
Beyond raw contrast:
- Body text at 16 pixels minimum. Prices and item names are content, not fine print. If someone has to squint at the price, that's a conversion problem before it's an accessibility one.
- Never disable zoom. A viewport tag with user-scalable=no is one line of code that prevents a guest from enlarging your menu. Remove it.
- Respect the phone's text size setting. Layouts should stretch when a guest bumps system text up, not clip or overlap.
- Don't use color alone to carry meaning. A red dot for "spicy" or a green one for "vegan" means nothing to a color-blind guest. Pair every color cue with text or an icon plus a label.
- Left-align body text. Justified and centered blocks are measurably harder to read for people with dyslexia.
None of this requires a redesign. Most of it is a stylesheet edit an afternoon long, and the resulting page tends to look more confident, not less.
Structure: What a Screen Reader Actually Hears
A screen reader doesn't see your layout; it walks your page's structure and reads it aloud. If the structure is meaningful, the menu becomes navigable. If everything is a styled div, the guest hears an undifferentiated stream of words and leaves.
- Use real headings in order. One H1 for the page, H2 for each menu category, H3 for items. A screen reader user can then jump category to category the way a sighted guest scans.
- Label every form field. A visible label attached to its input. A placeholder is not a label — it disappears the moment someone types.
- Give buttons meaningful names. Twelve buttons all announced as "Add" tell the guest nothing. "Add Margherita Pizza to cart" tells them everything.
- Announce dynamic changes. When an item lands in the cart or a field fails validation, that change needs to be conveyed, not just shown in a corner badge.
- Include a skip link. Let keyboard users jump past the header straight to the menu instead of tabbing through navigation on every page.
Most of this is the platform's job rather than yours — which is exactly why it belongs on your evaluation checklist when you choose or renew an ordering system. Ask the vendor directly whether their checkout is operable by keyboard alone, and ask them to demonstrate it.
Checkout Without a Mouse
Checkout is where accessibility failures cost the most, because the guest has already chosen to spend money. Test the whole flow with the mouse pushed away, using only Tab, Shift+Tab, Enter, and the arrow keys:
- Can you reach every control? Custom dropdowns and modal dialogs are the usual traps — especially a modal you can open but can't escape.
- Can you always see where you are? A visible focus outline on the currently selected element. Designers remove these because they're "ugly." Removing them makes keyboard checkout impossible.
- Is the tab order sensible? Top to bottom, left to right, matching the visual order.
- Are errors described in text? A red border alone communicates nothing. "Phone number needs 10 digits" communicates a fix.
- Are timers generous or absent? A cart that expires in five minutes punishes anyone who works more slowly, and that includes a lot of people using assistive technology.
Every item on that list also helps guests with no disability at all — which is the recurring theme of this work, and the reason accessible checkouts tend to convert better across the board. The broader conversion mechanics are in our piece on optimizing menus for completed orders.
Descriptions That Do Two Jobs at Once
Here's where accessibility stops feeling like compliance and starts feeling like marketing. Alt text and item descriptions serve the same underlying purpose: telling someone what the food actually is when they can't see it.
For photos, write one plain sentence describing what's pictured — "Grilled salmon fillet on a bed of wild rice with roasted asparagus" — rather than "IMG_2841" or "food." That single line serves a screen reader user, appears if the image fails to load, and gives search engines something to index. The rules for image handling generally, including sizing and when a photo helps at all, are in our notes on using menu photos well.
For item descriptions, write for the guest who can't see the picture and doesn't know your regional terms. Say what's in it, how it's cooked, how big it is, and how hot it is. Flag common allergens in text rather than relying on a colored icon. This is the same craft as ordinary menu copywriting — the principles in this guide to writing menu descriptions that sell map almost one to one onto writing accessible ones, because clarity is the shared requirement.
Case Study: Lakeside Grill, a Neighborhood Restaurant
Lakeside's ordering page used 13-pixel light grey type, a downloadable PDF for the full menu, and Add buttons roughly 30 pixels tall. Older regulars kept phoning in orders, and staff spent the dinner rush taking calls. Over one weekend the owner had the menu rebuilt in HTML, raised body text to 16 pixels with darker type, enlarged buttons to 48 pixels with more spacing, and added alt text to every photo. Within two months online orders from guests aged 55 and over rose 34 percent, phone orders during the dinner rush dropped by about a third, and overall cart completion improved from 66 percent to 78 percent — roughly 90 additional completed orders a month. "We thought we were doing a compliance chore," the owner said. "It turned out to be the best conversion work we've ever done."
A One-Hour Self-Test, No Tools Required
You don't need an audit firm to find your first ten problems. Set aside an hour and run these six checks on your own ordering page.
- The sunlight test. Take your phone outside at midday and read your menu. If item names or prices wash out, your contrast is too low.
- The text-size test. Set your phone's text size to its largest setting and reload. Does the layout stretch, or does text overlap and get clipped?
- The keyboard test. On a laptop, place a complete order using only the keyboard. Note every point where you get stuck or lose track of focus.
- The screen reader test. Turn on VoiceOver or TalkBack — both are built into your phone — and try to add one item to the cart. Ten minutes here is worth more than an hour of reading about it.
- The thumb test. Order one-handed while walking. Every mis-tap is a target that's too small or too close to its neighbor.
- The PDF test. Search your own site for the word "PDF" or "download menu." Anything you find is a barrier and a missed ordering opportunity.
Write down what breaks, sort by how many guests each issue touches, and fix in that order. Most restaurants find three or four items, and most of those are stylesheet-level changes rather than rebuilds. For the in-restaurant side of the same subject — entrances, seating, service — this broader restaurant accessibility guide is the natural companion to the digital checklist above.
On the Legal Question
Web accessibility claims against businesses serving the public have been common in the United States for years, and WCAG 2.1 or 2.2 at Level AA is the standard most often referenced as the benchmark. This is practical guidance, not legal advice — obligations vary by jurisdiction and business type, so a qualified attorney is the right source for what applies to you.
Set that aside, though, and the operational case holds by itself. A guest who cannot read your menu does not file a complaint. She orders from someone else, and you never learn why.
Four Mistakes to Avoid
- Installing an accessibility overlay widget and calling it done. These bolt-on toolbars are widely criticized by disability advocates and do not fix underlying structure. Fix the page.
- Building a separate "accessible menu" page. A second, always-stale version of your menu is worse than one good version. Make the real page work.
- Testing only on your own new phone. Test with the text size cranked up, on cellular, outdoors, one-handed — and ideally with a real guest who uses assistive technology.
- Fixing it once and forgetting it. The next menu update, promo banner, or plugin can reintroduce a barrier. Add the six-check test to your quarterly routine.
What ties this together is a shift in how you think about the ordering page. It isn't a brochure that some people happen to find hard to use — it's the front door of your restaurant, and a step at that door turns paying customers away whether or not anyone ever tells you. Widening it costs an afternoon, and the guests who come through are the ones who wanted to buy from you all along. Mobile-first habits reinforce the same conclusions, as our overview of what mobile-first ordering changes lays out.
An Ordering Page Every Guest Can Use
Real HTML menus, readable type, generous tap targets, and a checkout that works with a keyboard or a screen reader — on a platform where the menu, ordering, and payments stay in one place. See how restaurants run accessible online ordering with KwickOS.
Get Started Free — Join 5,000+ Restaurants →Frequently Asked Questions
What makes an online ordering menu accessible?
Four things carry most of the weight: real HTML text instead of a PDF or an image of the menu, text and background colors with enough contrast to read in daylight, tap targets at least 44 by 44 pixels with space between them, and every meaningful image carrying a short alt description. A guest using a screen reader, a guest with low vision, and a guest with shaky hands should all be able to complete an order without help. Most restaurant sites fail on at least two of the four.
Why are PDF menus a problem for accessibility?
A PDF built in a design tool is usually a picture of a menu rather than structured text. Screen readers cannot reliably announce its items and prices, the text does not reflow on a phone so guests must pinch and pan, and nothing in it is orderable or searchable. It also cannot be indexed properly by search engines. Replacing a PDF with an HTML menu is one change that improves accessibility, mobile usability, ordering conversion, and search visibility at the same time.
How large should text and buttons be on a restaurant ordering page?
Body text should be at least 16 pixels and must scale when a guest increases the text size in their phone settings — never disable zoom. Item names and prices are content, not decoration, so keep them at readable weight and size rather than thin grey type. Interactive elements including Add, quantity steppers, and Place Order should be at least 44 by 44 pixels with at least 8 pixels of separation, so a mis-tap does not remove an item or double a quantity.
Do restaurants have a legal obligation to make ordering accessible?
Web accessibility claims against restaurants and other businesses that serve the public have been common in the United States for years, and WCAG 2.1 or 2.2 at Level AA is the standard most commonly referenced as the benchmark. This article is practical guidance rather than legal advice, and requirements vary by jurisdiction and business type, so talk to qualified counsel about your specific obligations. The operational case stands on its own regardless: an unusable ordering page loses orders from customers who wanted to buy.
Does making my ordering page accessible help sales?
Yes, and not only for guests with disabilities. Larger text and stronger contrast help everyone reading a phone in a sunny parking lot. Bigger tap targets reduce mis-taps for one-handed ordering. Clear item descriptions help every guest decide faster and reduce refund-generating surprises. Accessibility work overlaps almost completely with ordinary mobile usability work, which is why restaurants that do it usually see completion rates rise across the whole customer base.
KwickOS Ecosystem
© 2024-2026 KwickOS. All rights reserved.