Restaurant website design in Orange County: the menu is the product

What the menu has to be made of

Two counters can serve the same food and have websites that perform nothing alike, and the difference is rarely the photography. It is what the menu is made of. One site publishes a picture of words. The other publishes words.

You can settle where the menu ranks on your own site in about a minute: open your analytics and sort pages by visits. Design to that ordering rather than to a guess.

A picture of words has two jobs it cannot do. On a small screen it opens as a document rather than a page, so the reader gets a fixed layout to zoom into and drag around, hunting for a price set in nine-point type for paper. And to a search engine the dish names are not page content but cargo inside a file. The words smash burger and Santa Ana can sit in your menu and still leave nothing on your site for a search to match.

A photograph of the printed board is the same object at worse resolution, and so is a menu exported as one long image because somebody liked the typeface. The test is not how it looks. It is whether you can select a price with a cursor. If you cannot, neither can anything else.

So the first line of the specification is the dull one: the menu is text, structured, in the page. Nothing below works without it.

A menu a screen reader can speak out loud

A screen reader is a program that walks a page and says it. It can say text. It cannot say a picture of text, so a menu shipped as a PDF or a photograph is not hard to use. It is silent.

In California that has a specific history. Thurston v. Midvale turned on a restaurant menu a plaintiff could not read, and the Unruh Act carries a statutory minimum of $4,000 per violation. We are not lawyers and none of this is legal advice — if it concerns you, ask one, before a demand letter rather than after.

We raise it early because the compliant version is the version you wanted anyway. The structure that lets a screen reader announce a section, step through the items and read a name with its price is the structure a search engine reads. One decision pays twice.

Structure means something concrete, and it is worth knowing what to ask for. Sections are real headings, not bold paragraphs. Each item is a row whose name and price are read together, so a price is never announced adrift from its dish. Marks like vegetarian and picante are words as well as icons. A sold-out item says sold out in text, because a row that has only gone grey has said nothing to somebody who cannot see grey.

That last one is the common failure: not a missing menu, but a menu whose state lives entirely in color.

Every row carries two numbers

Paper has room for one price. A menu in code has room for two: what an item costs at your counter, and what your own listed price is on the delivery apps.

That gap is the whole argument for ordering direct. Unpublished, it looks like something you would rather nobody noticed. Published, in the same type as everything else, it is an explanation. One sentence in your own voice underneath is enough: the apps take a cut, so the number on that side is higher, and the counter price is the one you get by walking in.

Notice what is deliberately absent. No figure attributed to a named marketplace, no commission rate, no fee schedule. Those are claims about another company that neither of us can check, and a page that invents one has just taught the reader how much to trust every other number on it. Your two prices are yours to publish. Side by side, they make the case without borrowing anybody's.

Ordering follows the same rule: pickup times computed from your real hours and your real prep time, stopping at last order instead of offering a slot the kitchen has already shut. A time the page can honor beats a longer list of times it cannot.

The menu has to change while somebody is reading it

A printed board's defining property is that it is fixed. So the question for the coded version is what a kitchen knows during service that paper can never say.

It knows what is running out. If a batch is made once in the morning, the rows tied to it can count down through the day, then strike through with the hour it went and the time it is back. Do that rather than deleting the row. A menu that quietly loses items teaches a regular that it is not describing today. A menu that says an item went at 7:10 and returns at eight is telling the truth about a kitchen with one grind in it, and that reads as confidence rather than shortage.

It knows what day it is. An item that runs Thursday to Sunday belongs on the page on Tuesday, stated, rather than discovered at the register by somebody who drove over for it. It knows when the till stops: last order is not closing time, and the gap is where the worst review of the month comes from.

And it knows one price per item, which should hold everywhere that price appears — the board, the range in the first screen, the listing a search engine quotes back. Derive them from one source instead of retyping them and nothing drifts the first time somebody edits a number. Menus rot for an unglamorous reason: updating them is nobody's favorite job. Make it a thirty-second job and it gets done.