The European Accessibility Act: What Every Website Owner Must Do Before Enforcement Hits

TL;DR

The European Accessibility Act (Directive 2019/882) requires most digital products and services sold in the EU to meet WCAG 2.1 Level AA. Enforcement began June 28, 2025. France, Norway, and Germany have already taken action. Fines range from 30,000 EUR to 1,000,000 EUR depending on the member state. 96% of websites currently fail basic accessibility checks. Compliance requires technical changes, process changes, and a published accessibility statement.

The Numbers

The WebAIM Million report^[1] analyzed 1,000,000 homepages in February 2025. It detected an average of 56.8 WCAG failures per page. 96.1% of pages had at least one automatically detectable failure. Automated tools catch only 30 to 40% of real accessibility issues, so the true failure rate is higher.

The EU estimates that 87 million people in Europe have a disability.^[2] Globally, 16% of the population (approximately 1.3 billion people) experiences significant disability.^[3] These numbers grow every year as populations age.

What the European Accessibility Act Actually Requires

The European Accessibility Act (EAA), formally Directive (EU) 2019/882, was adopted on April 17, 2019. Member states transposed it into national law by June 28, 2022. Enforcement began on June 28, 2025.^[4]

Scope: Products and Services Covered

The EAA covers products and services placed on the EU market after June 28, 2025. The scope is broad:

• E-commerce websites and apps: any site that sells products or services to EU consumers
• Banking services: online banking, ATMs, payment terminals
• Telecommunications: phone services, messaging apps, VoIP
• Transport services: airline, rail, bus, and ferry booking websites and self-service terminals
• E-books and e-readers: all digital publishing platforms
• Streaming and audiovisual media: video-on-demand, audio platforms
• Operating systems and hardware: computers, smartphones, tablets, self-service kiosks

SaaS products fall within scope when they deliver any of these services. A project management tool used internally does not fall under the EAA. A SaaS billing platform used by EU consumers does.

The Technical Standard: EN 301 549 and WCAG 2.1 AA

The EAA does not directly reference WCAG. It references the harmonized European standard EN 301 549, which incorporates WCAG 2.1 Level AA in its entirety for web content (Section 9), mobile apps (Section 11), and documentation (Section 12).^[5]

EN 301 549 goes beyond WCAG in some areas. It includes requirements for two-way voice communication, video conferencing with sign language, hardware interfaces, and real-time text. For websites and web applications, meeting WCAG 2.1 AA satisfies the web content portion of EN 301 549.

Who Must Comply

The EAA applies to economic operators that place products or provide services on the EU internal market. This includes manufacturers, importers, distributors, and service providers. Physical location of the company does not matter. A US-based SaaS company selling subscriptions to EU customers falls within scope.

Sectors with Immediate Exposure

• E-commerce: all online shops targeting EU consumers
• Financial services: banks, insurers, payment providers, fintech platforms
• SaaS and cloud services: consumer-facing software delivered via the web
• Streaming platforms: video, audio, and gaming services
• Travel and transport: booking engines, ticketing systems
• Telecommunications: messaging, email, VoIP providers
• Publishing: e-book platforms, digital news outlets

The Micro-Enterprise Exemption

The EAA exempts micro-enterprises that provide services. The EU defines a micro-enterprise as a business with fewer than 10 employees and an annual turnover or balance sheet total not exceeding 2 million EUR.^[4]

The disproportionate burden clause offers an additional safety valve. Organizations can claim that a specific accessibility requirement would impose a disproportionate burden based on net cost, organizational size, and estimated benefit to people with disabilities. This claim must be documented, reassessed every five years, and reported to the relevant authority on request. It does not exempt the entire product; it applies per requirement.

The Enforcement Reality

The EAA became enforceable on June 28, 2025. Within months, regulators in multiple countries moved from guidance to enforcement.

France: First Lawsuits Filed

In November 2025, French disability rights organizations filed the first EAA-related lawsuits against four major retailers: Auchan, Carrefour, E.Leclerc, and Picard.^[6] The lawsuits target inaccessible e-commerce platforms. France's DGCCRF (consumer protection authority) had published enforcement guidelines in July 2025, setting clear expectations. The lawsuits seek injunctive relief and fines under French transposition law, which permits penalties up to 50,000 EUR per infraction.

Norway: Daily Fines

Norway's Universal Design Authority (Tilsynet for universell utforming, UU-tilsynet) began issuing daily penalties of NOK 50,000 (approximately 4,300 EUR) for non-compliant websites.^[7] Norway, while not an EU member, adopted equivalent accessibility legislation through the EEA Agreement. The daily penalty model creates compounding financial pressure; a website that remains non-compliant for 30 days accumulates NOK 1,500,000 (approximately 129,000 EUR) in fines.

Germany: Private Warning Letters

Germany transposed the EAA through the Barrierefreiheitsstarkungsgesetz (BFSG), effective June 28, 2025. The Federal Network Agency (Bundesnetzagentur) handles market surveillance. A parallel enforcement path exists through German competition law: competitors and consumer protection associations can send private Abmahnungen (cease-and-desist letters) to non-compliant businesses. These letters typically demand compliance within a set deadline and payment of legal fees. By early 2026, law firms specializing in competition law had begun sending these letters to e-commerce operators.^[8]

Other Member States

Sweden's Agency for Digital Government (DIGG) launched a monitoring program in late 2025, conducting automated scans of public-facing commercial websites. The Netherlands' Logius agency expanded its accessibility monitoring from government sites to commercial services. Ireland, Italy, and Spain have appointed enforcement bodies and published compliance timelines.

Fines by Country

Each EU member state sets its own penalties. The EAA requires penalties to be "effective, proportionate, and dissuasive." The variation across countries is significant.

US Requirements Too

Companies operating in both the EU and the United States face accessibility requirements from multiple legal frameworks. The US has no single equivalent of the EAA, but several overlapping regulations apply.

ADA Title II: State and Local Government Websites

The Department of Justice published its final rule under Title II of the Americans with Disabilities Act on April 24, 2024. It requires state and local government websites and mobile apps to conform to WCAG 2.1 Level AA. Compliance deadlines: April 24, 2026 for entities serving populations of 50,000 or more; April 24, 2027 for smaller entities.^[9]

Section 508 and the Rehabilitation Act

Section 508 of the Rehabilitation Act requires federal agencies and their contractors to make electronic and information technology accessible. The 2017 refresh aligned Section 508 with WCAG 2.0 Level AA. Federal procurement contracts routinely include accessibility requirements that flow down to vendors.

HHS Section 1557 Rule

The Department of Health and Human Services finalized its Section 1557 non-discrimination rule in 2024, requiring healthcare entities receiving federal funding to make their websites and patient portals accessible to WCAG 2.1 Level AA.

ADA Title III: Private Sector Litigation

Title III of the ADA prohibits discrimination in "places of public accommodation." Federal courts have increasingly interpreted this to include websites and mobile apps. There is no explicit WCAG mandate under Title III, but courts routinely use WCAG 2.1 AA as the benchmark. First-offense civil penalties: $55,000 USD. Subsequent offenses: $110,000 USD. Over 4,000 ADA web accessibility lawsuits were filed in 2024.^[10]

The WCAG 2.1 AA Checklist

WCAG 2.1 Level AA contains 50 success criteria organized under four principles: Perceivable, Operable, Understandable, and Robust (POUR).^[11] Below are the most operationally significant criteria for web development teams.

Perceivable

Users must be able to perceive all content through at least one sense.

• 1.1.1 Non-text Content: all images, icons, and charts must have text alternatives (alt text) that serve the equivalent purpose
• 1.2.2 Captions (Prerecorded): all prerecorded audio in video must have synchronized captions
• 1.2.5 Audio Description (Prerecorded): prerecorded video must have audio descriptions of visual content
• 1.3.1 Info and Relationships: structure conveyed visually (headings, lists, tables) must be programmatically determinable
• 1.3.4 Orientation: content must not restrict display to a single orientation (portrait or landscape)
• 1.4.3 Contrast (Minimum): text must have a contrast ratio of at least 4.5:1 against its background; large text (18pt or 14pt bold) requires 3:1
• 1.4.4 Resize Text: text must be resizable up to 200% without loss of content or functionality
• 1.4.10 Reflow: content must reflow at 320px CSS width (equivalent to 400% zoom) without horizontal scrolling
• 1.4.11 Non-text Contrast: UI components and graphical objects must have at least 3:1 contrast against adjacent colors

Operable

Users must be able to operate all interface components and navigation.

• 2.1.1 Keyboard: all functionality must be operable through a keyboard interface
• 2.1.2 No Keyboard Trap: keyboard focus must never become trapped in a component with no way to exit via keyboard
• 2.4.1 Bypass Blocks: provide a mechanism (skip link) to bypass repeated blocks of content
• 2.4.3 Focus Order: focusable components must receive focus in a sequence that preserves meaning and operability
• 2.4.6 Headings and Labels: headings and labels must describe topic or purpose
• 2.4.7 Focus Visible: keyboard focus indicator must be visible on all interactive elements
• 2.2.1 Timing Adjustable: if a time limit exists, users must be able to extend, adjust, or disable it
• 2.5.3 Label in Name: for components with visible text labels, the accessible name must contain the visible text

Understandable

Users must be able to understand the content and interface operation.

• 3.1.1 Language of Page: the default human language of each page must be programmatically determinable (lang attribute on html element)
• 3.1.2 Language of Parts: the language of each passage or phrase must be programmatically determinable when it differs from the page language
• 3.2.3 Consistent Navigation: navigation mechanisms repeated across pages must occur in the same relative order
• 3.2.4 Consistent Identification: components with the same functionality must be identified consistently
• 3.3.1 Error Identification: input errors must be automatically detected and described to the user in text
• 3.3.2 Labels or Instructions: labels or instructions must be provided for user input
• 3.3.3 Error Suggestion: if an input error is detected, suggestions for correction must be provided (when possible)

Robust

Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies.

• 4.1.2 Name, Role, Value: all UI components must have programmatically determinable names and roles; states, properties, and values must be settable and available to assistive technologies
• 4.1.3 Status Messages: status messages must be programmatically determinable through roles or properties so assistive technologies can present them without receiving focus

The 10 Most Common Failures

The WebAIM Million study^[1] provides a data-driven ranking of the most prevalent accessibility failures across 1,000,000 homepages. These 10 issues account for the vast majority of detectable failures.

1. Low contrast text (83.6% of pages): text that fails the 4.5:1 contrast ratio requirement. The single most common failure, present on over 836,000 of 1,000,000 homepages.
2. Missing alternative text for images (54.5% of pages): images without alt attributes, or with empty alt on images that convey information.
3. Missing form input labels (48.6% of pages): form fields (inputs, selects, textareas) without programmatically associated labels. Screen reader users cannot determine the purpose of the field.
4. Empty links (44.6% of pages): links with no discernible text. Common with icon-only links that lack aria-label or visually hidden text.
5. Empty buttons (28.2% of pages): buttons without accessible names. Same issue as empty links, frequent with icon buttons.
6. Missing document language (17.1% of pages): pages without a lang attribute on the html element. Screen readers cannot determine pronunciation rules.
7. Broken ARIA: ARIA attributes used incorrectly, referencing non-existent IDs, or applied to elements where they conflict with the native role. ARIA misuse creates worse experiences than no ARIA at all.
8. No skip navigation: pages without a mechanism to bypass the header and navigation. Keyboard users must tab through every navigation link on every page load.
9. Missing focus indicators: interactive elements with outline: none or outline: 0 and no replacement focus style. Keyboard users cannot see which element has focus.
10. Inaccessible PDFs: PDF documents without tags, reading order, or alternative text. Common in government, finance, and legal sectors. Users of screen readers cannot parse untagged PDFs.

How to Audit Your Website

A credible accessibility audit combines three methods. No single method is sufficient.

1. Automated Testing

Automated tools detect approximately 30 to 40% of WCAG 2.1 AA issues.^[12] They excel at finding low contrast, missing alt text, missing labels, broken ARIA, and missing language attributes. They cannot assess whether alt text is meaningful, whether content is logically ordered, or whether custom components are truly operable.

• axe DevTools (Deque): browser extension and CI integration. The industry standard for automated testing. Free tier available. The axe-core engine powers most other tools.
• Lighthouse (Google): built into Chrome DevTools. Runs a subset of axe rules. Good for quick checks; insufficient as a sole testing tool.
• WAVE (WebAIM): browser extension that visually overlays issues on the page. Useful for non-technical stakeholders to see problems in context.
• Pa11y: open-source command-line tool. Integrates into CI/CD pipelines for automated regression testing.

2. Manual Testing

Manual testing catches the 60 to 70% of issues that automated tools miss.

• Keyboard-only navigation: unplug your mouse. Navigate the entire site using Tab, Shift+Tab, Enter, Space, Escape, and arrow keys. Verify that every interactive element is reachable, operable, and has a visible focus indicator.
• Screen reader testing: test with at least one screen reader. VoiceOver (macOS/iOS), NVDA (Windows, free), or JAWS (Windows). Listen to how the page reads. Verify that headings, landmarks, forms, and dynamic content are announced correctly.
• Zoom testing: zoom to 200% and 400%. Verify that all content remains visible, no text is clipped, and no horizontal scrolling is required at 320px equivalent width.
• Color and contrast: check that information is never conveyed by color alone. Verify contrast with a tool like the Colour Contrast Analyser (TPGi).

3. User Testing

Testing with people who have disabilities reveals issues that neither automated nor manual expert testing can find. Recruit participants who use screen readers, switch devices, voice control, screen magnification, or keyboard-only navigation. Five participants typically uncover the majority of critical usability issues.

Quick Wins You Can Ship This Week

These fixes require minimal effort and address the most common failures. Each one can be implemented and deployed within hours.

1. Set the Language Attribute

17.1% of pages are missing this. It takes 10 seconds to fix.

<!-- Before: screen readers guess the language -->
<html>

<!-- After: screen readers use correct pronunciation rules -->
<html lang="en">

<!-- For German pages -->
<html lang="de">

2. Add a Skip Link

A skip link lets keyboard users jump past the navigation to the main content. Place it as the first focusable element in the DOM.

<body>
  <a href="#main-content" class="skip-link">
    Skip to main content
  </a>
  <nav><!-- navigation --></nav>
  <main id="main-content">
    <!-- page content -->
  </main>
</body>

.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  padding: 8px 16px;
  background: #000;
  color: #fff;
  z-index: 100;
  transition: top 0.2s;
}

.skip-link:focus {
  top: 0;
}

3. Add Alt Text to All Informative Images

Describe the function of the image, not its appearance. Decorative images should have empty alt (alt="").

<!-- Informative image: describe what it communicates -->
<img src="chart-q4-revenue.png" alt="Q4 revenue: 2.4 million EUR, up 18% from Q3">

<!-- Decorative image: empty alt, no description needed -->
<img src="decorative-border.png" alt="">

<!-- Linked image: alt describes the link destination -->
<a href="/products">
  <img src="product-icon.png" alt="View all products">
</a>

4. Fix Focus Styles

Never remove focus outlines without providing a replacement. Modern CSS makes this straightforward.

/* Remove the default outline only when a visible replacement exists */
:focus-visible {
  outline: 2px solid #005fcc;
  outline-offset: 2px;
}

/* For older browser support */
:focus {
  outline: 2px solid #005fcc;
  outline-offset: 2px;
}

/* Never do this without a replacement: */
/* :focus { outline: none; } */

5. Fix Color Contrast

Use a contrast checker to verify all text meets the 4.5:1 ratio (3:1 for large text). Common offenders: light gray text on white backgrounds, placeholder text, disabled state text that still needs to be readable.

/* Fails: #999 on #fff = 2.85:1 ratio */
.text-light { color: #999; }

/* Passes: #595959 on #fff = 7.0:1 ratio */
.text-light { color: #595959; }

/* Passes: #767676 on #fff = 4.54:1 ratio (minimum threshold) */
.text-muted { color: #767676; }

6. Associate Labels with Form Inputs

Every form input needs a programmatic label. The for attribute on the label must match the id on the input.

<!-- Correct: explicit label association -->
<label for="email">Email address</label>
<input type="email" id="email" name="email">

<!-- Also correct: implicit label wrapping -->
<label>
  Email address
  <input type="email" name="email">
</label>

<!-- Incorrect: no association -->
<span>Email address</span>
<input type="email" name="email">

7. Fix Heading Hierarchy

Headings must follow a logical hierarchy. Do not skip levels. Screen reader users navigate by headings to scan page structure.

<!-- Correct hierarchy -->
<h1>Page Title</h1>
  <h2>Section One</h2>
    <h3>Subsection</h3>
  <h2>Section Two</h2>

<!-- Incorrect: skips h2 -->
<h1>Page Title</h1>
  <h3>Section One</h3>

8. Add ARIA Landmarks

Semantic HTML elements create landmarks automatically. Prefer native elements over ARIA roles.

<!-- Semantic HTML creates landmarks automatically -->
<header>  <!-- role="banner" -->
<nav>     <!-- role="navigation" -->
<main>    <!-- role="main" -->
<aside>   <!-- role="complementary" -->
<footer>  <!-- role="contentinfo" -->

<!-- If you must use div, add the role explicitly -->
<div role="navigation" aria-label="Main navigation">
  <!-- nav items -->
</div>

9. Add Accessible Names to Icon Buttons

<!-- Incorrect: empty button -->
<button><svg><!-- icon --></svg></button>

<!-- Correct: aria-label provides the accessible name -->
<button aria-label="Close menu">
  <svg aria-hidden="true"><!-- icon --></svg>
</button>

<!-- Also correct: visually hidden text -->
<button>
  <svg aria-hidden="true"><!-- icon --></svg>
  <span class="sr-only">Close menu</span>
</button>

10. Make Error Messages Accessible

<!-- Use aria-describedby to link error to the input -->
<label for="email">Email address</label>
<input
  type="email"
  id="email"
  aria-invalid="true"
  aria-describedby="email-error"
>
<p id="email-error" role="alert">
  Enter a valid email address.
</p>

The Accessibility Statement

The EAA requires organizations to publish an accessibility statement. This document must be available on the website, easy to find, and kept up to date.

Required Contents

The European Commission provides a model accessibility statement.^[13] At minimum, the statement must include:

1. The conformance status: full conformance, partial conformance, or non-conformance with EN 301 549 / WCAG 2.1 AA
2. A description of any non-accessible content, with reasons (technical burden, disproportionate burden, or not covered by legislation)
3. The date of the last assessment and the method used (self-evaluation, external audit, automated testing)
4. A feedback mechanism: users must be able to report accessibility barriers and request information in an accessible format
5. Contact information for the accessibility feedback mechanism
6. A link to the national enforcement procedure for complaints

Template Structure

<h1>Accessibility Statement</h1>

<p>[Organization name] is committed to ensuring digital accessibility
for people with disabilities. We apply WCAG 2.1 Level AA as our
accessibility standard.</p>

<h2>Conformance Status</h2>
<p>This website is [fully / partially / not] conformant with
WCAG 2.1 Level AA.</p>

<h2>Non-accessible Content</h2>
<p>[Describe any known issues, organized by WCAG criterion.]</p>

<h2>Assessment Method</h2>
<p>This statement was last reviewed on [date] using
[self-evaluation / external audit by (name)].</p>

<h2>Feedback</h2>
<p>If you encounter accessibility barriers on this website,
contact us:</p>
<ul>
  <li>Email: [accessibility contact email]</li>
  <li>Phone: [phone number]</li>
</ul>
<p>We aim to respond within [X] business days.</p>

<h2>Enforcement Procedure</h2>
<p>If you are not satisfied with our response, you can file a
complaint with [national enforcement body + link].</p>

Sources