A useful restaurant website accessibility statement tells guests what your restaurant knows, where problems remain, and how to get help. Say which parts of the site were reviewed, when that review happened, and how someone can report a barrier. Avoid declaring the whole site accessible just because a few pages look good on a phone.
The statement is a public explanation, not a substitute for fixing problems. Before publishing it, gather the people who control your website, menu, ordering flow, and guest communications. Their answers will determine what you can honestly say.
Describe the actual scope reviewed
Start with an inventory of the places a guest might use. Your homepage and menu may live on your main domain, while ordering, reservations, gift cards, or delivery may open a separate service. A statement that covers the entire guest journey needs information about each part, not just the homepage.
Ask your website provider which pages and features it controls. Ask the ordering or reservation provider the same question if those services sit elsewhere. Your manager can identify the links guests actually use, including links from social profiles and business listings. Someone who updates menus should identify downloadable files and images that contain menu information.
Then describe the review in ordinary language. For example, if someone reviewed the homepage, a text menu, and the contact page, name those pages. If the ordering checkout was not reviewed, say so rather than treating it as covered. A provider’s description of its product is useful background, but it does not establish what happened on your particular site.
Be precise about what “reviewed” means. A staff member reading pages on a phone is different from a review that includes keyboard navigation and screen-reader use. You do not need to publish every technical step, but the statement should not imply that a broader assessment happened when it did not.
Changes matter too. A new menu PDF, reservation widget, or ordering link can change the guest experience after a review. Keep a dated record of the pages and services included so you can tell whether the statement still describes the current site. If you are considering a new restaurant website, ask who can edit the statement and who will tell you when a connected service changes.
Provide a contact path that someone monitors
A guest who cannot use a menu or checkout needs a way to reach a person. Publish a contact method that your team can actually handle, such as a staffed phone number and an email address. Explain what guests can ask for: a menu in another format, help placing an order, or a way to report a problem.
Each channel has limits. A phone line may be convenient during service but unavailable after closing. Email lets guests describe a problem without calling, but only helps if someone checks the inbox. Give the hours when the phone is staffed and a realistic email response target only if your team can meet it. If a message arrives outside those hours, make the next staffed period clear.
Do not make guests use the same feature that may be causing trouble. For example, if the only contact option is a form on the website, a guest who cannot complete that form has no alternative. Two different channels give guests a choice, though neither removes the need to fix the barrier.
Decide what happens after a message arrives. A shift lead might answer menu questions, while a website manager sends technical reports to the provider. Give staff a simple handoff: record the page or link, what the guest was trying to do, and a safe way to follow up. Do not ask guests to send payment card details by email or leave them in a voicemail.
Consider a hypothetical restaurant where the ordering page is difficult for a guest to use. Its statement could offer a staffed phone number for help placing an order and an email address for reporting the issue. The manager would need to make sure the phone team can take the request and explain any differences in ordering options. A contact promise that nobody can carry out is not much help.
If online ordering is provided by another company, ask it how accessibility issues are reported and who responds. Your restaurant should still tell guests where to start; the guest should not have to work out which vendor owns the checkout.
Record known limitations without unsupported claims
Name a barrier when you have enough information to describe it usefully. Say where it occurs, what a guest may be unable to do, and what help is available. Do not guess at a repair date. If a provider has agreed to investigate, you can say that, but distinguish an investigation from a completed fix.
Here is a hypothetical statement excerpt. It illustrates wording, not a finding about any particular restaurant or product:
“We reviewed our homepage, text menu, and contact page in March 2026. We have not reviewed the separate online ordering checkout. We know that our downloadable catering menu is available only as a PDF and may be difficult for some guests to use. Please call us during our posted phone hours or email us if you need the catering menu in another format or want to report a problem. We are asking our website provider about a text version.”
That example tells a guest what was covered and what was not. It also separates a known limitation from a request for a possible improvement. Before using wording like it, replace every detail with your own verified information, including working contact details and the actual status of the request.
Avoid phrases such as “fully accessible” or “works for everyone” unless you have a sound basis for them and understand their scope. A review can miss barriers, and a connected service can change. Likewise, a single complaint does not establish that every guest will encounter the same problem. Describe the reported or observed issue without turning it into a broader claim.
If you mention a standard or a legal status, ask the person who assessed the site exactly what the finding covers. A qualified adviser can help with questions about how legal requirements apply to your business. The practical goal for the statement is clear communication, not a badge or a promise.
Use an evidence checklist and assign an owner
Keep a short private record behind the public statement. It gives the person updating the page a way to check each claim and helps the next manager understand what needs another look. The table below shows what to collect and who can usually supply it; the responsible person may be different in your restaurant.
| Statement item | Evidence to keep | Who can provide it |
|---|---|---|
| Scope and date | List of pages and connected services reviewed, with the review date and methods used | Website manager or reviewer |
| Known limitations | Issue description, affected page, current workaround, and status of any fix request | Staff member handling reports and the relevant provider |
| Contact options | Working phone and email details, staffed hours, inbox owner, and response target if used | Restaurant manager |
| Next review | Named owner, planned review date, and events that trigger an earlier update | Restaurant owner or assigned manager |
The checklist is not a public claim that every page passed an assessment. It is a way to connect each sentence in your statement to a person or record. If you cannot find support for a sentence, narrow it, remove it, or ask the relevant provider for an answer.
Assign one person to own the statement, even if several people supply information. That owner should check the contact details, follow up on open issues, and update the page when a menu, ordering provider, or reservation service changes. Choose a review date your team can keep. Put it on the operating calendar rather than relying on memory.
Before publishing, make sure the statement itself is easy to find from the website and that the contact details match the channels staff monitor. Ask your website provider how to edit it without rebuilding the site. Your domain ownership arrangements are also worth checking, because access to the site and its address affects who can make updates.
Next step: Use the checklist to review your current pages, contact channels, and connected services. Bring any unanswered questions to your providers, or ask Fleksa about its restaurant website and verified US availability.
Frequently asked questions
Can I publish a statement before reviewing the whole website?
Yes. Describe only the work completed, identify important areas not yet reviewed, and give guests a usable way to ask for help. Update the statement as the scope changes.
Should the statement include third-party ordering and reservations?
It should help guests understand where those services fit. Identify whether they were included in your review and provide a contact route for problems, even if another company operates them.
How often should I update the statement?
Set a review date your team can maintain, and revisit it sooner when contact details, menus, site features, or connected providers change. Update known-issue descriptions when their status changes.
