How to design an EAA compliant website

The European Accessibility Act came into force in June 2025. If your website sells products or services to EU customers, you’re now legally required to meet specific accessibility standards. Most site owners already know this. What they’re missing is a clear action plan. This guide covers exactly that: how to make your website EAA compliant, starting with an audit and ending with a system that keeps it that way.

Step 1 — Find out where your site stands right now

Before you change anything, you need to know what actually needs changing. Guessing means spending time on things that already pass while missing the failures that matter.

An automated accessibility scan identifies the most common EAA-related problems quickly: missing alt text, low colour contrast, unlabelled form fields, broken heading structure, keyboard navigation failures, and more. It gives you a concrete list of what needs attention before you touch a line of code or a design file.

If your site passes with no critical issues, you’re in reasonable shape. If it surfaces a list of failures, those are your starting point.

Run a free scan to see your current EAA compliance issues → app.scanluma.com/register

How do I check if my website is EAA compliant? Run an automated accessibility scan against your site. This will identify failures against WCAG 2.1 Level AA, the technical standard the EAA requires. No automated tool catches everything, but a scan covers a large proportion of common failures quickly and gives you a concrete list to work from.

What EAA actually requires from your website

The European Accessibility Act doesn’t define its own accessibility criteria. It requires compliance with WCAG 2.1 Level AA, the Web Content Accessibility Guidelines produced by the W3C and recognised internationally as the standard for web accessibility.

WCAG groups its criteria around four principles, often called POUR. Content must be perceivable, meaning users can access information through at least one sense (alt text, captions, sufficient contrast). It must be operable, meaning all functions work without a mouse. It must be understandable, with clear language, consistent navigation, and helpful error messages. And it must be robust, meaning it works reliably with screen readers and other assistive tools now and as technology evolves.

WCAG 2.1 Level AA includes around 50 specific success criteria across these four principles. Meeting those criteria is how you demonstrate EAA compliance for your website.

What level of WCAG does the EAA require? The EAA requires WCAG 2.1 Level AA. Level A covers the most basic requirements; Level AA adds further criteria around contrast, keyboard access, and error handling. Level AAA is optional and not required for EAA compliance.

For a full overview of who the EAA applies to and what it covers, see the European Accessibility Act compliance guide.

Design issues that affect EAA compliance

Most accessibility failures show up in the visual design. You don’t need to read the source code to spot them. These are the main areas to check on any existing site.

Colour contrast

Text needs a contrast ratio of at least 4.5:1 against its background for normal body text, and 3:1 for large text (18pt or 14pt bold and above) and interactive UI components such as buttons and form borders.

The most common failures are light grey text on white backgrounds, low-contrast placeholder text inside form fields, and disabled-state buttons that become nearly invisible. These are easy to miss in design tools, where screens are backlit and colours look more distinct than they will to someone with low vision.

For tools and techniques to check and address contrast issues, see colour contrast requirements explained.

Typography and text resizing

Users must be able to resize text up to 200% without losing content or functionality. If your layout breaks when text scales, or columns overlap, or buttons become unclickable, that’s a failure.

Use a base body font size of 16px or above, set font sizes in relative units (rem or em rather than fixed px), and test your layout at 200% browser zoom before signing off on a design.

 Navigation and interactive elements

Every interactive element — links, buttons, menus, dropdowns, modal dialogs — must be reachable and usable by keyboard alone, without a mouse or touchscreen.

Visible focus indicators are required. A very common failure is removing the browser’s default focus ring (the blue outline that appears around focused elements) without replacing it with something equally clear. If a keyboard user can’t see where they are on the page, they can’t use the site.

Touch targets should be at least 44×44 pixels for reliable interaction on touch devices.

Images and media

Informative images need descriptive alt text that conveys the meaning of the image to someone who can’t see it. Decorative images should be marked as decorative using alt="", so screen readers skip them entirely.

Videos need captions. Audio-only content needs a text transcript. If a video conveys meaningful information through visuals alone, it also needs an audio description.

Do images need alt text for EAA compliance? Yes, for informative images. If an image conveys information that isn’t available in surrounding text, it needs alt text. Purely decorative images should use alt="" so they’re skipped by screen readers.

For practical guidance on writing alt text well, see how to write alt text.

Forms

Every form field needs a visible, programmatically associated label, not just placeholder text. Placeholder text disappears when the user starts typing, which creates problems for anyone who needs to refer back to what a field is asking for.

Error messages must identify the specific field with a problem and explain what the user needs to do to correct it. “Invalid input” is not sufficient. “Please enter a valid email address” is.

Code-level issues that affect EAA compliance

A well-designed page can still fail accessibility checks if the underlying HTML isn’t correct. These are the implementation issues most commonly surfaced in automated scans.

Semantic HTML

Use the right HTML element for its intended purpose. Buttons should be <button> elements, not <div> or <span> elements styled to look like buttons. Headings should use <h1> through <h6> in a logical order, not bold text or visually large paragraphs. Lists should use <ul> or <ol>, not styled <p> tags.

Semantic HTML gives browsers and assistive technologies the structural information they need to describe page content to users who can’t see it. Visual styling is invisible to a screen reader; the underlying element is not.

ARIA — only where native HTML isn’t enough

ARIA (Accessible Rich Internet Applications) attributes let you add accessibility information that HTML alone can’t express, for custom components like autocomplete inputs, tab panels, or dynamic regions that update without a page reload.

The rule is to use ARIA to supplement correct HTML, never to replace it. A common mistake is adding role="button" to a <div>. This adds a role, but it doesn’t add keyboard focus or activation behaviour. A native <button> element handles all of that automatically.

For a practical guide to using ARIA correctly, see ARIA labels explained.

Keyboard navigation and skip links

Test keyboard navigation by pressing Tab to move through the page. Every interactive element should be reachable, receive focus in a logical order, and be activatable with Enter or Space.

Skip links let keyboard and screen reader users jump past repeated navigation to reach the main content directly. They’re typically a visually hidden link at the very top of the page that becomes visible when focused. Without skip links, keyboard users Tab through the full header navigation on every single page.

How to stay EAA compliant after launch

Making your site compliant once is only the beginning. Content updates, new features, A/B tests, and third-party scripts can all introduce new accessibility failures at any time, often without anyone noticing until a complaint or scan flags it.

Automated monitoring runs regular scans against your site and alerts you when new issues appear. This is what separates being compliant from staying compliant.

Set up automated monitoring to catch issues before they become problems → app.scanluma.com/register

Once your site is in good shape, the EAA compliance checklist for websites is a useful reference to return to when reviewing new pages or major updates.

Frequently asked questions

EAA compliance isn’t a design trend. It’s a legal requirement that also makes your site better for more people. The path forward is clear: scan first to understand where you stand, work through the design and code issues covered in this guide, and set up monitoring so your site stays compliant as it grows.

Start with a free scan → app.scanluma.com/register