Restaurant Website Accessibility: A Guide for Irish Businesses

If your Dublin restaurant takes online bookings, if your Galway café has a menu on your website, if your Cork gastropub offers online ordering—your site needs to be accessible. As of 28 June 2025, the European Accessibility Act is now law in Ireland. The deadline has passed. If your restaurant website isn't accessible, you're in breach. This guide explains what you need to do, how to fix it, and why the Irish enforcement authority is paying attention.

What Is the Accessibility Requirement?

The European Accessibility Act was implemented in Ireland through S.I. No. 636 of 2024—the Accessibility of Products and Services Regulations 2024. The deadline was 28 June 2025. If your website is still inaccessible, compliance action may already be underway.

The regulation requires that websites and mobile apps for businesses be accessible to people with disabilities. Accessibility means:

• Blind or low-vision visitors can navigate using screen readers
• Deaf visitors can access audio and video content via captions
• Motor impairment visitors can use keyboard-only navigation (no mouse required)
• Cognitively impaired visitors can understand and navigate the content
• Everyone can use your site regardless of temporary disability (broken arm, eye surgery, loud environment where audio doesn't work)

The accessibility standard is WCAG 2.1 Level AA (Web Content Accessibility Guidelines, version 2.1, level AA). This is the international benchmark adopted by Ireland, the EU, and most developed countries.

Who Enforces This in Ireland?

The Competition and Consumer Protection Commission (CCPC) is Ireland's enforcement authority. The CCPC has authority to:

• Investigate complaints
• Issue compliance orders
• Fine non-compliant businesses
• Pursue court action if ignored

The CCPC views restaurant and hospitality websites as high-priority. Why? Because restaurants serve the public, they collect payment, and many visitors are tourists or older people who may have accessibility needs. A restaurant that can't be accessed online excludes customers.

Why It Matters for Restaurants Specifically

Restaurant websites have particular accessibility problems:

1. PDF Menus — The biggest issue. Most Irish restaurants still publish menus as PDF files. PDFs without proper tagging are impossible for screen readers to navigate. A blind visitor trying to see your menu gets nothing.

2. Booking Forms — OpenTable, Flipdish, and similar integrations sometimes lack proper labels. A screen reader user can't tell which field is for number of guests vs. date.

3. Food Photography — Nice photos of your dishes. But if the image is just an image with no alt text, visitors using screen readers don't know what you're serving.

4. Unstructured Layout — Some restaurant sites use tables for layout or have heading hierarchies that don't make sense. A screen reader user gets lost navigating the page.

5. Auto-Playing Media — Background music or video that plays when the page loads disorients screen reader users and is illegal under WCAG.

6. Third-Party Tools — If you use Just Eat, OpenTable, Flipdish, or similar platforms, those integrations must be accessible. If they're not, you're responsible for either fixing them or providing an accessible alternative.

The WCAG 2.1 AA Standard: What You Need to Do

WCAG 2.1 has four principles, abbreviated POUR:

1. Perceivable: Users Must Be Able to See/Hear Your Content

Images need alt text. Every image should have a text description. Not "image.jpg" or "pic123"—a real description.

Example alt text:

• Bad: "photo"
• Good: "Grilled sea bass with seasonal vegetables and lemon beurre blanc"

Videos need captions and transcripts. If your restaurant has a YouTube video of your chef or dining atmosphere, add captions. Deaf visitors can't hear your audio. Add a transcript for search engines too.

Audio needs transcripts. Any podcast, voiceover, or background audio must have a transcript.

Color isn't the only way to convey information. Don't say "click the red button to book" if there's no other way to identify the button. Color-blind visitors won't find it.

Contrast must be adequate. Text must have a contrast ratio of at least 4.5:1 against the background (for normal text) or 3:1 for large text. Pale gray on white fails. Dark gray on white passes. Use a contrast checker: webaim.org/resources/contrastchecker

2. Operable: Users Must Be Able to Navigate and Control

Keyboard navigation must work. Everything clickable should be accessible via Tab and Enter keys. If your booking button only works with a mouse, you fail. Motor-impaired users can't use a mouse.

Test: Unplug your mouse and navigate your site using only Tab, Shift+Tab, and Enter. Can you reach every booking, menu, contact link?

No keyboard traps. If you Tab into a popup, you shouldn't be stuck there. You must be able to Tab back out or close it with Escape.

Skip links. Add a "Skip to main content" link at the top of every page. Screen reader users shouldn't have to hear your entire navigation menu before getting to your menu.

Example HTML:

<a href="#main-content" class="skip-link">Skip to main content</a>
<!-- navigation menu here -->
<main id="main-content">
  <!-- Your menu and booking form -->
</main>

No auto-play media. Audio or video that plays when the page loads is illegal. If you have background ambiance music, pause it by default.

No flashing content. Nothing should flash more than three times per second (risk of seizures).

3. Understandable: Users Must Be Able to Comprehend Your Content

Headings must have a logical hierarchy. Use <h1> for page title, <h2> for sections, <h3> for subsections. Don't skip levels (e.g., h1 to h3). Screen readers use heading structure to navigate.

Forms must have labels. Every form field needs a label. Don't rely on placeholder text (which disappears when the user starts typing).

Bad:

<input type="text" placeholder="Phone number" />

Good:

<label for="phone">Phone number:</label>
<input type="text" id="phone" name="phone" />

Clear language. Use simple, direct language. "Make a reservation" is better than "Effectuate a dining engagement." Irish restaurants serving tourists and older diners should especially avoid jargon.

Error messages must be clear. If a booking form rejects the input, explain why in plain language. "Invalid email" is better than "Error 401."

4. Robust: Your Code Must Be Compatible with Assistive Technology

Valid HTML. Malformed HTML breaks screen readers. Use a validator: validator.w3.org

Proper ARIA roles (if needed). ARIA (Accessible Rich Internet Applications) adds extra information for screen readers. Most restaurant sites don't need ARIA, but if you have custom components, use ARIA properly.

Practical Steps to Make Your Restaurant Site Accessible

Step 1: Audit Your Current Site (1-2 hours)

Use free automated tools to identify problems:

WAVE (WebAIM): wave.webaim.org — Browser extension that highlights accessibility errors.

Axe DevTools: deque.com/axe/devtools — Free browser extension for Chrome/Firefox.

Lighthouse (Chrome DevTools): Built into Chrome. Open DevTools (F12), go to Lighthouse tab, run audit. Accessibility score is part of the report.

NVDA (Free Screen Reader): Download NVDA from NV Access. Use it to navigate your site like a blind visitor would. You'll immediately spot problems.

Audit checklist:

• Run WAVE, Axe, or Lighthouse; note errors
• Try navigating with Tab key only—can you reach every element?
• Test with NVDA or similar screen reader
• Check image alt text
• Verify form labels are present
• Check color contrast
• Test video captions
• Look for auto-play media

Step 2: Fix the Top Issues

Based on your audit, prioritise:

1. PDF Menus (Highest Priority)

If you have a PDF menu, you have two options:

Option A: Convert to HTML (Recommended) Create a web page with your menu:

<h1>Our Menu</h1>

<h2>Starters</h2>
<ul>
  <li>
    <strong>Smoked salmon</strong> — Irish smoked salmon with 
    wheaten bread and crème fraîche — €12
  </li>
  <li>
    <strong>Soup of the day</strong> — Ask your server — €7
  </li>
</ul>

<h2>Main Courses</h2>
<!-- etc -->

This is accessible, searchable, and faster than PDFs.

Option B: Make PDF Accessible If you must use PDF, ensure it's tagged. Adobe Acrobat (paid) can tag PDFs. Or use a service like PDFMaker or hire an accessibility consultant to tag your PDF properly.

Test: Open your PDF in a screen reader (NVDA) and confirm it reads all text.

2. Booking Forms (High Priority)

If you use OpenTable or Flipdish:

• Check if they have accessibility settings (many do now)
• If not, add clear labels to all fields
• Test with screen reader
• Provide an alternative: "Call us to book: 01 123 4567"

3. Images (Medium Priority)

Add alt text to all images:

<!-- Bad -->
<img src="food.jpg" />

<!-- Good -->
<img src="food.jpg" alt="Pan-seared scallops with asparagus and brown butter sauce" />

<!-- For decorative images (e.g., spacers) -->
<img src="spacer.gif" alt="" /> <!-- alt="" tells screen readers to skip it -->

4. Video (Medium Priority)

For any video (demo, ambiance, chef clip):

• Add captions (YouTube has auto-caption feature)
• Provide transcript in text below video

5. Forms and Input (Medium Priority)

Review all booking, contact, and reservation forms:

<!-- Before -->
<input type="text" placeholder="Date" />

<!-- After -->
<label for="booking-date">Booking date:</label>
<input type="text" id="booking-date" name="booking-date" required />

Step 3: Fix Color Contrast

Use WebAIM Contrast Checker:

• Test foreground vs. background color
• Aim for 4.5:1 ratio for normal text, 3:1 for large text
• If your site uses pale gray text on white, change to dark gray or darker

Step 4: Test Keyboard Navigation

Unplug your mouse (or disable it in settings). Navigate your site using:

• Tab: Move forward
• Shift+Tab: Move backward
• Enter: Click buttons/links
• Arrow keys: Scroll

Can you book a table? View the menu? Contact the restaurant? If not, neither can motor-impaired visitors.

Step 5: Test with a Screen Reader

Download and install NVDA (free, Windows/Linux) or JAWS (paid, Windows) or VoiceOver (built into Mac/iPhone).

Open your site. Put headphones on. Close your eyes. Can you:

• Understand the page structure?
• Navigate to the menu?
• Find the booking form?
• Submit a reservation?

If you're lost, so are blind visitors.

Step 6: Add a Publish Date and Language Tag (Technical)

Ensure your HTML includes:

<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Our Restaurant</title>
  </head>

The lang="en" tells screen readers to use English pronunciation. The viewport meta tag helps mobile users.

Step 7: Provide Accessible Alternatives

For any complex features, offer a non-digital alternative:

• "Book online or call 01 123 4567"
• "View our menu online or ask at the host stand"
• "Watch the video or read the transcript below"

This is your safety net if your digital version isn't perfect.

Common Restaurant Accessibility Mistakes

1. PDF menus without accessibility — Most common. Convert to HTML or tag properly.
2. No labels on booking forms — Especially with third-party integrations. Add labels anyway.
3. No alt text on food photos — People can't see the image; they need a description.
4. Light gray text on white — Beautiful design, but unreadable for low-vision users.
5. Auto-play background music — Startles screen reader users and violates WCAG.
6. Heading hierarchy all over the place — Skip levels or misuse headings. Use h1, h2, h3 logically.
7. "Click here" links — Screen reader users hear "Click here" without context. Use descriptive text: "Book a table," "View our menu."
8. Relying on color alone — "Our red button is the checkout" fails for color-blind users. Use text labels.
9. Third-party embed without checking accessibility — If you embed a reservation widget, chat, or review system, check if it's accessible.
10. No alt text for logo or icon buttons — A magnifying glass icon needs alt text: "Search" or "Search our menu."

Timeline and Enforcement

The deadline was 28 June 2025—already passed. The CCPC is now in enforcement mode. Businesses that haven't complied may face:

• Written notice asking for compliance
• Compliance order with a deadline
• Fine or court action if ignored

The CCPC prioritises high-traffic sites and complaints. A restaurant is a public-facing business, so compliance is important.

Cost to Comply

The good news: accessibility doesn't have to be expensive.

• Free: WAVE, Axe DevTools, NVDA, contrast checker, basic fixes (alt text, labels, heading structure)
• Low cost: Accessible WordPress theme, basic HTML edits, PDF tagging tools (€50-500)
• Higher cost: Hiring an accessibility consultant to audit and fix (€500-3,000 depending on site size)

For a small restaurant, likely under €1,000 to bring a site to WCAG 2.1 AA.

Compare that to: CCPC fines (potentially €5,000+), loss of customers who can't use your site, or being unable to book (losing reservations to competitors).

Special Considerations for Restaurant Platforms

Just Eat Ireland

Just Eat's listing pages are your responsibility. Review:

• Logo and images have alt text (you may need to edit in Just Eat admin)
• Booking/ordering flow is keyboard navigable
• Form labels are clear

OpenTable

OpenTable's widget is embedded on your site. You're responsible for the integration:

• Ensure the iframe is labelled (title="Book with OpenTable")
• Test keyboard navigation through the booking flow
• If OpenTable's form lacks labels, add a note on your site: "Call us to book"

Flipdish (Irish Company)

Flipdish has improved accessibility recently. Check:

• Menu is readable by screen readers
• Ordering form has labels
• Basket and checkout are keyboard navigable

Local Delivery Services

If you partner with local delivery services, they're handling their own site. You're responsible for links to them being clear and for mentioning alternatives (phone, in-person).

Documentation and Compliance

Keep a record:

• Accessibility audit date
• Issues found
• Fixes applied
• Testing dates and results
• Ongoing maintenance plan

If the CCPC asks, you can show you're compliant or in the process of complying.

Practical Checklist: Get Your Restaurant Site to WCAG 2.1 AA

• Run automated accessibility audit (WAVE, Axe, Lighthouse)
• Convert PDF menu to HTML, or tag PDF for accessibility
• Add alt text to all food photos and logo
• Add labels to all form fields (booking, contact, reviews)
• Test keyboard-only navigation
• Test with screen reader (NVDA)
• Check color contrast (4.5:1 minimum)
• Ensure heading hierarchy is logical
• Remove auto-play audio/video
• Test third-party integrations (OpenTable, Flipdish, etc.)
• Add "Skip to main content" link if site is complex
• Provide phone alternative to online booking
• Update privacy policy to mention accessibility
• Document compliance steps
• Re-test every 6 months

Summary

The European Accessibility Act deadline was 28 June 2025. It's now law in Ireland. The CCPC is enforcing it. A restaurant website that isn't accessible is breaking the law and losing customers.

WCAG 2.1 Level AA is the standard. The biggest wins are:

1. Accessible menu (HTML, not PDF)
2. Alt text on photos
3. Labels on forms
4. Keyboard navigation
5. Adequate color contrast

Start with an automated audit (free), fix the obvious issues, test with a screen reader, and iterate. Most small restaurant sites reach AA compliance in a few hours of work.

For guidance:

• Irish Authority: Competition and Consumer Protection Commission (CCPC) at www.ccpc.ie
• Web Standard: WCAG 2.1 at www.w3.org/WAI/WCAG21/quickref
• Free Tools: WebAIM WAVE, Axe DevTools, NVDA screen reader, Lighthouse

Make your restaurant accessible. You'll serve more customers, comply with the law, and do right by people with disabilities.