Dutch Restaurant Accessibility: EAA Booking Rules

The European Accessibility Act (Directive 2019/882) has been in force since 28 June 2025. For restaurant websites, the key question is: if a guest with a disability visits your website to make a reservation, view the menu, or find your location, can they complete that task without help?

This guide covers the specific accessibility challenges of restaurant websites and what WCAG 2.1 AA means in practice for your booking flows, menus and contact pages.

Not sure where your site stands right now? Run a free accessibility scan to get a risk score before reading further.

Does the EAA Apply to Your Restaurant?

Exempt (micro-enterprise): Fewer than 10 employees AND annual turnover below €2 million. Most cafes, bars and small restaurants fall here.

Must comply: 10 or more employees OR turnover of €2 million or more. Mid-size restaurants, restaurant chains and hospitality groups are typically not micro-enterprises.

Special case (online ordering): If your website or app enables online food ordering (pay-per-order or subscriptions), this is explicitly covered by the EAA regardless of whether it existed before 28 June 2025. New digital ordering services are subject to immediate compliance.

Even if you're exempt, accessibility improvements make your website usable by more potential guests, including older adults and users with temporary impairments.

The Standard: WCAG 2.1 AA

The EAA requires compliance with WCAG 2.1 Level AA, the international web content accessibility standard. For restaurant websites, the most relevant criteria break down into four areas.

Colour contrast (criterion 1.4.3): Body text needs a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) needs 3:1. Many restaurant sites fail this with light grey menu text on white backgrounds or white text over food photography.

Keyboard navigation (criteria 2.1.1 and 2.4.7): Every interactive element (reservation forms, date pickers, dropdown menus, buttons) must be reachable and operable using only a keyboard. The currently focused element must have a visible focus indicator at all times.

Images and alt text (criterion 1.1.1): Every meaningful image needs a text alternative. Decorative images should use alt="" so screen readers skip them.

Form labels (criterion 1.3.1): Every form field must have a programmatically associated label. Placeholder text alone does not satisfy this requirement.

Digitoegankelijk.nl, the Dutch government's digital accessibility resource, explains how WCAG 2.1 maps to the European standard EN 301 549 that the EAA references.

Enforcement in the Netherlands

The ACM (Autoriteit Consument en Markt) is the designated enforcement authority for the EAA in the Netherlands. It began mandatory accessibility reporting requirements in October 2025 and has contacted companies offering covered services in the Dutch market, including e-commerce platforms. Active enforcement is expected from mid-2026 onward.

If you receive a complaint or an ACM inquiry, having documented accessibility testing on file helps demonstrate good faith. A free scan gives you a starting point.

The Reservation Booking Flow

The reservation flow is the most critical accessibility journey on a restaurant website. If a user cannot complete a reservation without assistance, that is a serious EAA violation.

Form field labels

Every field in your reservation form must have a visible, associated label:

<!-- Bad: no label, placeholder disappears on input -->
<input type="text" placeholder="Your name">

<!-- Good -->
<label for="guest-name">Name <span aria-hidden="true">*</span></label>
<input type="text" id="guest-name" name="name" required 
       aria-required="true" autocomplete="name">

For Formitable, OpenTable, and similar embedded booking systems: these are third-party tools. Check whether the embedded widget is accessible. If it is not, the inaccessibility falls on you as the website operator who chose to embed it.

Date and time selectors

Custom date pickers, used in almost every reservation system, are notoriously difficult for keyboard and screen reader users. Test yours by:

1. Tab to the date selector
2. Try to enter a date using only the keyboard
3. Check whether a screen reader announces the selected date

If the calendar widget is not keyboard-accessible, add a text input as an alternative:

<label for="reservation-date">Reservation date</label>
<input type="date" id="reservation-date" name="date" min="2026-01-01">

The browser's native <input type="date"> is more accessible than most custom date pickers.

Party size

Dropdown menus for party size must be keyboard-accessible. A native <select> element is accessible by default. Custom dropdowns (styled divs) often are not, so they need appropriate ARIA roles.

Dietary requirements

If you collect dietary requirements or allergy information, label these fields clearly. Because this is health data (sensitive under GDPR Article 9), also make it visually clear that the field is optional:

<label for="dietary">Dietary requirements or allergies (optional)</label>
<input type="text" id="dietary" name="dietary" 
       placeholder="e.g. nut allergy, vegetarian">

Confirmation messages

After a reservation is submitted, the confirmation message must be:

• Announced to screen readers (use role="alert" or aria-live="polite")
• Include all relevant booking details
• Linked to a printable confirmation or offer to send email confirmation

Menus and Food Information

PDF menus are an accessibility failure

Many restaurants publish their menu as a PDF. PDFs are often inaccessible:

• Scanned PDFs are images. Screen readers read nothing
• Even text PDFs are difficult to navigate without heading structure
• PDFs do not reflow well for users who need to zoom or adjust text size

Solution: Publish your menu in HTML. If you must also offer a PDF download, the PDF must also meet accessibility requirements (tagged PDF structure, alt text on images, reading order defined).

For a basic HTML menu, use heading structure:

<section aria-labelledby="starters-heading">
  <h2 id="starters-heading">Starters</h2>
  <ul>
    <li>
      <span class="dish-name">Tomato soup</span>
      <span class="dish-description">With house bread and herb crème fraîche</span>
      <span class="dish-price">€8.50</span>
    </li>
    <!-- ... -->
  </ul>
</section>

Food photography alt text

Restaurant websites are image-heavy: interior shots, dishes, ambiance photos. All meaningful images need alt text.

Good alt text for restaurant images:

• Dish photo: alt="Grilled salmon fillet on a bed of roasted vegetables with lemon butter sauce"
• Interior: alt="Restaurant interior with warm wooden furniture and candlelit tables"
• Exterior: alt="Restaurant entrance on Prinsengracht, with outdoor terrace seating"

Decorative images (background textures, dividers) should use alt="" to tell screen readers to skip them.

Allergen information

If you display allergen information online, it must be accessible (failing colour-only information violates WCAG 1.4.1 Use of Color). The most common failure: allergen icons that rely solely on colour (green dot = allergen free, red dot = contains allergen) without text labels.

<!-- Bad: colour-only information -->
<img src="gluten-icon-red.png" alt="">

<!-- Good: text alternative included -->
<img src="gluten-icon-red.png" alt="Contains gluten">
<!-- Or: -->
<span class="allergen" aria-label="Contains gluten">
  <img src="gluten-icon.png" aria-hidden="true">
  <span class="sr-only">Contains gluten</span>
</span>

Location and Contact Information

Google Maps alternative for screen reader users

A Google Maps embed on your contact page should be accompanied by a text address. Screen readers can read a street address. They cannot interpret an interactive map.

Always include:

<address>
  Restaurant Name<br>
  Keizersgracht 123<br>
  1015 CJ Amsterdam<br>
  <a href="tel:+31201234567">+31 20 123 45 67</a>
</address>

Then optionally add the map as a supplementary element with an appropriate label:

<figure>
  <figcaption>Map showing our location on Keizersgracht</figcaption>
  <!-- Map embed or static image here -->
</figure>

Opening hours

Opening hours presented in a table or list format are more accessible than text embedded in images or graphics. Use a clear structure:

<table>
  <caption>Opening hours</caption>
  <thead>
    <tr><th scope="col">Day</th><th scope="col">Hours</th></tr>
  </thead>
  <tbody>
    <tr><td>Monday</td><td>Closed</td></tr>
    <tr><td>Tuesday – Friday</td><td>12:00 – 22:00</td></tr>
    <tr><td>Saturday – Sunday</td><td>11:00 – 23:00</td></tr>
  </tbody>
</table>

Quick Wins: What to Fix First

If you're not sure where to start, these four fixes cover the most common failures on Dutch restaurant sites and take a day or less to implement.

1. Check colour contrast on menu text. Open your site and run it through the WebAIM Contrast Checker. If your body text fails 4.5:1, adjusting your colour palette is the fastest fix with the largest reach. Grey text on white backgrounds is the most common failure.

2. Add alt text to food images. Go through your homepage and menu page. Every <img> tag that shows a dish, interior or exterior needs a descriptive alt attribute. This takes minutes per image and immediately satisfies WCAG criterion 1.1.1.

3. Tab through your reservation form. Close your mouse and use only the Tab key to move through your booking form. If you can't reach a field, can't open the date picker, or can't submit the form, those are failures of WCAG 2.1.1. Note every step that breaks and fix them one by one.

4. Replace PDF menus with HTML. If your menu is a scanned PDF, a screen reader reads nothing. Convert it to an HTML page using heading structure. This also benefits mobile users and improves your Google indexing.

Quick Checklist for Restaurant Websites

• Reservation form fields all have visible labels (not just placeholders)
• Date picker is keyboard-accessible (or uses native <input type="date">)
• Menu is available in HTML format, not PDF only
• All food images have descriptive alt text
• Allergen information is not conveyed by colour alone
• Street address is present in text, not map only
• Opening hours are in text format
• Phone number and email are clickable links (tel: and mailto:)
• Booking confirmation is announced to screen readers
• Website is navigable by keyboard alone, no mouse required
• Colour contrast is at least 4.5:1 for body text
• Focus indicator is visible throughout the entire page

For the full EAA accessibility guide and the ACM enforcement context, read our EAA small business guide.

For practical implementation guidance in Dutch, Digitoegankelijk.nl covers EN 301 549 and WCAG 2.1 in detail.

---

This article is technical analysis, not legal advice. Consult a lawyer for advice specific to your situation.