EAA compliance checklist for websites and online shops

This checklist walks you through the most important points your website needs to meet for the European Accessibility Act (EAA). It is ordered by the four principles of the WCAG — the technical standard the EAA refers to via EN 301 549 — and ends with the legal accessibility statement.

An honest note up front: this list is a structured working basis, not a free pass. Ticking every box does not automatically mean “legally compliant”. Some points can only be checked manually — with a keyboard and a screen reader — and the EN 301 549 standard goes beyond the WCAG in places. So treat the checklist as a reliable thread to follow, not a guarantee.

Who this checklist is for

It is aimed at operators of websites and online shops that fall under the EAA as private providers. The benchmark is WCAG 2.1, conformance Level AA — the legally relevant level through the harmonised EN 301 549 standard. What the levels mean in detail is explained in the WCAG guide.

Before you start: am I even covered by the EAA?

Before working through the points, settle the basic question. Roughly: if you offer consumers a digital service (online shop, booking, interactive forms) and you are not a microenterprise exempt for services, you are likely covered. The full check with all edge cases is in Who must comply with the EAA?

Part 1: Perceivable

• All informative images have meaningful alternative text; purely decorative images are marked as such (empty alt attribute).
• Colour contrasts meet the minimums: 4.5:1 for normal text, 3:1 for large text and graphical interface elements.
• No information is conveyed through colour alone (e.g. a “required field marked in red” also has a text label).
• Videos have captions; audio-only content has a transcript.
• The heading structure is logical and hierarchical (exactly one H1, sensibly nested H2/H3).
• The page stays usable when text is enlarged to 200% without content being lost.

Part 2: Operable

• Everything is reachable and operable by keyboard alone — links, buttons, forms, menus, sliders.
• The keyboard focus is clearly visible at all times.
• The focus order is logical and follows the visual layout.
• There are no “keyboard traps” — you can leave every element again by keyboard.
• A skip link (“skip to content”) bypasses repeated navigation.
• No flashing or rapidly blinking content (seizure risk).
• Click and tap targets are large enough and not too close together.

Part 3: Understandable and robust

Understandable:

• The language of the page is marked in the code (lang attribute), as are passages in other languages.
• Form fields have clear, associated labels.
• Error messages name the problem concretely and say how to fix it.
• Navigation and recurring elements are consistent across all pages.

Robust:

• The page uses semantic HTML (e.g. real buttons instead of clickable divs).
• Interactive components have accessible names and roles; ARIA is used only where needed, and correctly.
• The page has been tested with at least one screen reader (e.g. NVDA or VoiceOver).

Part 4: The accessibility statement

• An accessibility statement is published and easy to find.
• It is not confused with the public-sector accessibility statement format, which is not the right one in the private-sector EAA context.

What exactly belongs in the statement and how to create it is shown in the accessibility statement guide.

Check your status, don’t just tick boxes

This list helps you find the obvious gaps. But — and here the circle closes back to the note at the start — a ticked checklist is not proof of conformance. Automated tools can quickly check some of the points (roughly a third of the criteria); the rest require manual checking: a keyboard test, a screen reader, a look at how understandable things are. How this fits together is described in the practical guide on how to make your website accessible.

The honest path is a cycle rather than a one-off list: test, fix in the source code, test again — until the demonstrable result improves. Welcoma’s upcoming WCAG scanner is built for exactly this: it shows you the real issues in the code instead of covering them up, so that “ticked” becomes a provable “fixed”.

This guide is not legal advice. For a binding assessment of your specific case, consult a qualified professional.