Can everyone book a table? A 10-minute accessibility check for your restaurant website

Have you ever tried to book a table on your own website the way a different customer might? Someone who can't use a mouse. Someone who uses a screen reader. Someone with low vision.

You can learn a lot in ten minutes with no tools. This is a practical usability check, not legal advice, and Mobius is not a law firm. We won't tell you whether your site meets any law. We will help you spot problems real customers run into, and tell you what to ask your web person to fix.

Open your site on a computer and work through these seven checks.

1. Put the mouse away

Try to book a table using only the Tab, Enter and Escape keys. Escape should close any pop-up.

Can you reach every link, button and form field? And can you always see where you are? A visible outline should move as you tab. If it vanishes, you are tabbing blind.

Why it matters: many people can't use a mouse. If the keyboard can't finish the booking, they can't book.

Ask your web person: "Can a visitor complete a reservation using only the keyboard, with a visible focus outline the whole way?"

2. Is the reservation button a real button?

Is your "Book a table" button real text on a button, or a picture of one? Screen readers announce real buttons by name, such as "Reserve a table, button." A picture with no description is announced as "image," or not at all. A quick test: try to select the button's words with your cursor. If you can't, it may be an image.

Why it matters: someone using a screen reader finds the way to book by listening. A button with no clear name is a closed door.

Ask your web person: "Is the reservation button a real button or link with a clear name? If it comes from our booking vendor, what name does it announce?"

3. Is your menu real text?

Is your menu typed text on the page, or a photo of a printed menu, or a PDF made from a scan? Try the same select test. If you can't highlight a dish name, a screen reader can't read it either.

Why it matters: a guest who is blind can't read a picture, and a guest with an allergy can't check a menu they can't read.

Ask your web person: "Can the menu be real text on the page, with dishes and allergen notes written out?"

4. Do the form fields have visible labels?

Click into the name, date and party-size fields. Does each have a label that stays visible while you type, or is the label gray hint text inside the box that disappears when you start? Then submit with a mistake, such as a blank phone number. Does the page say what went wrong, next to the field, in words?

Why it matters: disappearing hints are hard on anyone who loses their place, and screen readers may not announce them at all.

Ask your web person: "Does every field have a label that stays visible, and do error messages say what to fix?"

5. Can you read the colors?

Gold, cream and light gray on a dark photo can look elegant. It can also be unreadable in sunlight or for someone with low vision. Turn your screen brightness down. Can you still read the hours, the address and the button text? Check text laid over photos especially.

Why it matters: your hours and address are the most-used information on the site. If they fade into the background, people leave.

Ask your web person: "Can you check the contrast of our text against its background and darken anything hard to read?" WCAG, the common technical standard for web accessibility, sets specific contrast ratios, and free checkers exist.

6. What if someone can't use a phone?

Plenty of restaurants say "call us for large parties" or "call for special requests." Some customers are deaf or hard of hearing, and some find calls hard for other reasons.

Why it matters: if a phone call is the only route to a big-party booking, you may turn away your biggest tables.

Ask your web person: "Can we add a simple request form or email option for large parties and special requests, with a reply time we can keep?"

7. Does your accessibility statement match reality?

If your site has an accessibility statement, read it as a customer would. A statement that promises "full accessibility" when your menu is a photo does more harm than having none. An honest one says what you've done, what is still hard, and how to reach a person who can help.

Why it matters: it sets honest expectations. An empty promise loses a guest's trust.

Ask your web person: "Is every sentence in our statement something we can back up today?"

What to do with what you found

Write down each check as a pass, a fail, or "not sure." Fix the cheap ones first, such as typed menu text and clearer labels. For the rest, such as a booking widget from a vendor, send the vendor a clear written request.

If you would rather have someone else do this, our Free Tech Checkup includes an accessibility scan of your key pages and a test of your booking flow from start to finish, with a plain-English list of what to fix first. You can also see how our fixed-price packages work.