Perceivable

Guides › EAA compliance checklist for websites

EAA compliance checklist for websites

9 min read Reviewed 2026-08-22

Ordered by risk removed per hour spent. If you only get through step three, you will have eliminated the majority of what an automated complaint would surface.

Step 1 — Confirm scope

  • Do you sell goods or services to consumers in the EU through a website or app?
  • Do you have 10 or more staff, or turnover above €2 million?
  • Are you in banking, transport, telecoms, e-books or audiovisual access services?

Yes to the first two, or yes to the third, and you should plan on being in scope. Do not spend three months on a scoping exercise — the technical work is the same either way, and most of it is work you should be doing regardless.

Step 2 — Baseline the real journeys

Test the pages a customer actually passes through, not the ones that are convenient to test:

  • Home and primary navigation
  • Category or search results
  • Product or service detail
  • Cart
  • Checkout, every step including payment
  • Account creation and sign-in
  • Contact and support
  • Any cookie or consent overlay — it is the first thing every user meets, and consent banners are among the most consistently inaccessible components on the web

Record the numbers. You need a before to demonstrate progress, and a documented baseline is useful evidence that you took the obligation seriously from a specific date.

Step 3 — The high-yield fixes

In roughly the order that removes the most risk per hour:

  1. Colour contrast. Body text at 4.5:1, large text at 3:1, interface components and focus indicators at 3:1. Usually a handful of token changes in one stylesheet that fixes hundreds of reported instances at once. Start here.
  2. Form labels. Every input gets a real <label>. Placeholder text is not a label. This is the failure most likely to stop a purchase outright.
  3. Accessible names on controls. Icon-only buttons and links need aria-label. Hamburger menus, close buttons, cart icons, social links.
  4. Image alternatives. Informative images get descriptive alt text; decorative images get alt="". A missing attribute is not the same as an empty one.
  5. Page language. One lang attribute on <html>.
  6. Zoom. Remove user-scalable=no from your viewport meta tag. One line, resolves a Level AA failure across your entire mobile experience.
  7. Keyboard operation. Tab through checkout without touching the mouse. Everything reachable, focus always visible, nothing trapping you. If you cannot complete a purchase by keyboard, nothing else on this list matters yet.
  8. Headings and landmarks. One <h1>, levels that descend without skipping, content inside <main>, and a skip link.
  9. Error messages. Identify the field, describe the problem in text, and move focus to it. Red borders alone fail.

Step 4 — What only a human can check

Automated tools cover roughly a third of WCAG success criteria. The rest needs judgement:

  • Is the alt text meaningful, or is it "image123"? A tool sees an attribute and passes it.
  • Does focus order follow the visual order?
  • Do custom components — date pickers, comboboxes, modals, carousels — actually work with a screen reader? This is where most real-world failures live and where no scanner will help you.
  • Does the page still work at 200% zoom and at 320 CSS pixels wide?
  • Are video captions accurate, or auto-generated nonsense?
  • Can someone complete checkout using only a keyboard and only a screen reader? Test it. Watch someone else test it.

Step 5 — Document and publish

  • Publish an accessibility statement with your conformance claim, known issues and a remediation timeline.
  • Give a monitored feedback address — not a black-hole form.
  • If you are relying on disproportionate burden, write the assessment down with figures and keep it.
  • Keep your audit reports. Dated evidence of a good-faith remediation programme is the most useful thing you can hand a regulator.

Step 6 — Stop it regressing

This is the step everyone skips and the reason sites that passed in June fail by September. A new component, a rebrand, a marketing landing page built outside the design system — any of these can reintroduce failures you already paid to fix.

  • Add automated accessibility checks to CI so a pull request fails on a new violation.
  • Re-audit the live site on a schedule — the live site is what a complainant tests, and it includes third-party widgets your CI never sees.
  • Make accessibility part of the design system, not a step at the end. A button component that is accessible once is accessible in every place it is used.

Last reviewed 2026-08-22. General information, not legal advice.

Check your own site against this

A free scan tests one page against the WCAG 2.1 AA rule set and returns a plain-language verdict. No account, about a minute.

Run a free scan