Restaurant Website Accessibility in the Netherlands: EAA Requirements

The European Accessibility Act (Directive 2019/882) has been in force since June 28, 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?

This guide focuses on the specific accessibility challenges of restaurant websites.

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+ employees OR turnover of €2 million+. 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 June 28, 2025. New digital ordering services are subject to immediate compliance.

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

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 — ensure they have 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 Checklist for Restaurant Websites

• Reservation form fields all have visible labels
• Date picker is keyboard-accessible
• 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 4.5:1 for body text
• Focus indicator is visible throughout

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

---

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