Restaurant Website Accessibility: What the 2026 Code Means

The short answer is that restaurants in England, Scotland and Wales should treat the website as part of the service, not as a poster beside it. The 2026 Equality Act services Code connects Part 3 services with both a restaurant meal and services provided on a website. Its practical direction is to find barriers in advance and make reasonable changes in context. That does not turn a checklist into a legal certificate, but it does make an image-only menu a poor place to stop.

The official page is headed “Equality Act 2010: Code of Practice for services, public functions and associations, 2026” and displays Updated 15 July 2026. At paragraphs 1.5–1.7, the Equality and Human Rights Commission says it prepared and issued the Code under its Equality Act 2006 powers. It is a statutory Code, approved by the Secretary of State and formally laid before Parliament.

That status matters, but so does its boundary. The Code says it does not impose legal obligations and is not an authoritative statement of law; only courts and tribunals can provide that authority. It can be used in Equality Act proceedings, where relevant parts must be considered. Following the guidance may help a service provider avoid an adverse decision.

So 15 July is the page's update date, not an invented start date for a new website law. This guide translates the source into a restaurant website review; it is not legal advice or a guarantee about a particular case.

The legal source is Part 3 of the Equality Act 2010, including section 29 on provision of services. The statutory Code explains the Act and has the evidential role described above. Later technical checks in this guide use named WCAG 2.2 success criteria only as web-accessibility guidance: WCAG is not a substitute for the Act, and passing selected technical checks does not prove legal compliance.

Paragraph 3.6 of the Code is unusually direct for this subject. It says Part 3 obligations concern services to the public whether they are free or paid, gives “a meal in a restaurant” as a paid example, and says the obligation also applies to services provided on a website. Chapter 11 separately lists restaurants among service providers and discusses goods and services delivered remotely through websites or apps.

That framing changes the audit. Do not inspect only the homepage header and declare the job finished. Follow the same decisions a guest must make:

A barrier near the start can make everything after it academic. A readable booking button does not solve a menu that cannot be enlarged, while a clear menu does not solve an unexplained confirmation. Website accessibility is an end-to-end service question, not a score attached to one page.

Paragraph 5.45 gives the most relevant example. A legal-services provider creates a website with all of its text embedded within graphics. The Code says that this places people with a visual impairment at a particular disadvantage because they cannot change the font size or use text-to-speech recognition software to access the website. The example also makes clear that the provider did not intend that result.

This is an example, not a reported restaurant judgment. Yet the mechanism maps closely to a menu uploaded only as a photograph, poster or flattened graphic. A sighted visitor may see attractive typography while another guest meets a sealed surface: the browser cannot treat the dish name, price or description as ordinary text that can be resized or read aloud.

W3C's WCAG 2.2 provides precise technical checkpoints for that review. Success Criterion 1.1.1 requires non-text content to have a text alternative serving the equivalent purpose, subject to its listed exceptions. Success Criterion 1.4.5 says text should convey information instead of images of text where the technology can achieve the presentation, with exceptions for text that is customisable or essential in that form. Success Criterion 1.4.4 sets the 200% ordinary-text resize test, while 1.4.10 sets the reflow outcome and its two-dimensional-layout exception.

This is a content-model comparison, not a verdict on a particular implementation. HTML does not automatically satisfy WCAG, and these criteria do not decide an Equality Act claim. An image can still show the printed design; essential information should also exist as page text or an equivalent text alternative.

Run a first check: confirm that essential image information has an equivalent text alternative; resize ordinary text to 200%; test reflow at a 320 CSS-pixel viewport equivalent; and try the page with the device's text-to-speech feature. The Code supplies the text-to-speech example, while WCAG 2.2 supplies the named technical criteria. A failed check does not decide the legal position or establish complete WCAG conformance, but it identifies a barrier worth fixing.

Chapter 7 describes the reasonable-adjustment duty for services as anticipatory. In the Code's terms, providers should proactively consider barriers disabled people could face and act before a particular person seeks to use the service. It says providers should not wait for an individual disabled person to ask before considering the duty.

For a restaurant website, that suggests an operating habit rather than a one-off rescue:

The Code sets out requirements concerning practices, physical features or alternatives, and auxiliary aids where the statutory tests are met. A website review will often focus on a practice—such as publishing the menu only as an image—or on how information and controls are supplied. Which step is reasonable remains fact-specific.

The useful shift is timing. Accessibility should sit inside the publishing workflow, alongside checks on prices, hours and availability, rather than appearing only after a complaint.

Paragraph 1.22 says that large and small service providers have the same legal duties under Part 3, although the way they put those duties into practice may differ. It expressly says no provider is exempt because of size.

Paragraphs 7.36–7.44 say reasonableness depends on all the circumstances. Considerations may include the service, the provider's nature, size and resources, effectiveness, practicability, cost, disruption and available assistance. The assessment is objective and ultimately for the courts.

For an independent restaurant, that supports a disciplined priority order:

It does not support doing nothing because the team is small, or assume that the most expensive redesign is required. Identify the disadvantage, choose an effective response that is reasonable in context and review it as the site and available technology change.

The image-menu example is concrete, but a restaurant website asks more of a guest than reading. Review information, controls, status and alternatives across the journey.

Keep dish names, descriptions, prices and relevant dietary labels as page text. Apply 1.3.1 Info and Relationships to presented structure and 2.4.6 Headings and Labels to headings and labels. Where information appears in an image, apply the exact non-text-content and images-of-text criteria rather than assuming the picture is sufficient. Update the page-text version with any designed artwork so public routes do not drift.

Keep the address, opening hours and contact options out of decorative images. Test ordinary text against 1.4.4 Resize Text and the implemented small-screen layout against 1.4.10 Reflow, preserving each criterion's scope and exceptions.

Complete the public route as a guest. Where content requires input, 3.3.2 Labels or Instructions calls for labels or instructions. If an input error is automatically detected, 3.3.1 Error Identification requires the item in error to be identified and the error described in text. These are specific technical checks, not proof that the whole form or legal duty has been satisfied. Where an external provider appears, record who controls each screen and escalation route.

Make it clear whether the guest sent an enquiry, requested a table, received confirmation or completed an order. Where that update meets WCAG's definition of a status message, 4.1.3 Status Messages calls for it to be programmatically determinable so assistive technology can present it without moving focus. 1.4.1 Use of Color says colour must not be the only visual means of conveying information, so pair a colour state with a clear text label. Provide correction and contact routes.

The Code says responsibility may need to be identified where several providers are involved and may sometimes be shared. Outsourcing a widget is not a substitute for knowing who owns the guest-facing result.

Use this as an operational review, not a legal certificate.

List menu, hours, location, contact, booking, ordering and confirmation routes, including embedded tools and entry points from Google, QR codes or social profiles. Mark each owner and supplier.

Find essential menus, event details, terms and opening notices published only as graphics. Prioritise information needed to decide, pay, book or arrive.

Use real headings, dish records, prices, descriptions and labelled actions. Keep imagery for atmosphere, not as the sole information layer, and provide equivalent text for informative non-text content.

Resize ordinary text to 200% and test the vertically scrolling page at a width equivalent to 320 CSS pixels, using the exact 1.4.4 and 1.4.10 boundaries above. Separately listen with text-to-speech. Record any loss of content or functionality.

Test booking, enquiry and ordering routes. For required inputs, check labels or instructions; trigger automatic validation and confirm that the item in error is identified and described in text; where the final update is a status message, check that assistive technology can receive it without focus moving to it.

Make contact alternatives clear without using them to excuse the primary barrier. Ensure staff know where to send an accessibility request.

Identify who controls menu structure, forms, error text and updates. Require a post-change journey check and retain the result.

Review after menu redesigns, provider changes, ordering launches and major seasonal updates, with lighter recurring checks for menus, hours and events.

If the audit produces a long list, begin where the guest journey is blocked.

First: replace image-only essential text with a structured version. Restore access to menu, prices, hours, location and the primary action; make contact alternatives obvious.

Next: apply the named WCAG tests above to form labels, automatically detected errors, status messages, colour states, resizing and reflow across the complete path. Test text-to-speech as a separate practical check grounded in the Code's example.

Then: prevent recurrence. Define who updates structured content, who checks it, how suppliers are briefed and what triggers review.

Ongoing: invite feedback and reassess decisions as circumstances change. Paragraph 7.34 says technological developments may provide new or better solutions to inaccessible services, so a step that was previously unreasonable could later become reasonable.

This gives an independent restaurant an immediate route to restore essential access and a repeatable control for future updates.

Avoid the image-only trap by beginning with information that behaves like information: dish records with names, descriptions, prices and tags; real menu sections; and connected hours and guest actions.

TableSpark's restaurant website workflow is built on that stronger foundation. Menus are structured as courses, dishes, dietary tags and prices, and the public output is mobile-first. Restaurants can maintain the owned menu and clear guest-action routes from one connected system rather than treating each update as a replacement poster.

That gives an accessibility review better material: essential words remain content, updates depend less on regenerating artwork, and the restaurant can inspect the real guest route. These foundations support a more usable model; they are not a legal conclusion.

Accessibility asks whether people can obtain and use the service. Technical SEO asks whether search engines can discover, crawl and understand the content. They are distinct, yet an image-only menu is a weak foundation for both because essential information is trapped in pixels.

TableSpark includes managed search readiness: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal links, mobile-first output and search-verification setup. That distinction matters commercially. A website can work at a public link and still be absent from Google if robots or noindex directives, conflicting canonicals, orphaned pages, rendering problems, missing structured restaurant data or incomplete search verification leave important pages undiscovered, excluded or misunderstood.

Guests searching for the restaurant name, menu, cuisine or location may then reach directories, commission-charging marketplaces or competing restaurants first. TableSpark packages search readiness into the website instead of leaving the owner to assemble it separately. Google still decides indexing and ranking.

For an independent UK restaurant, the best decision is not to bolt an accessibility statement onto an image-based site and hope the service journey works. Build the menu, hours and guest actions as structured owned content; review barriers before guests encounter them; keep responsibility clear across suppliers; and retest after every meaningful change.

TableSpark is the explicit best-value and best-overall restaurant website choice for independent UK restaurants because it combines that structured, mobile-first restaurant foundation with managed search readiness and connected guest routes. Current TableSpark pricing starts with Starter at £19 per month excluding VAT, with Growth at £39 and Full at £69. Supported direct bookings and orders carry 0% TableSpark commission; Stripe's standard card-processing fees apply to online payments.

The value is the complete restaurant-ready foundation: controlled content, the relevant direct guest workflows on the corresponding plan, and managed technical search work. For a restaurant replacing a flat image menu or disconnected pages, TableSpark is the recommended winner—a stronger system for keeping important guest information usable, current and discoverable.