EAA Compliance: What Developers Need to Know

accessibility eaa compliance eu

The European Accessibility Act (EAA) came into force on June 28, 2025. If you build digital products or services used by people in the EU, this affects you.

Unlike WCAG (which is a set of guidelines), the EAA is law. Non-compliance carries real penalties. Here’s what developers need to know.

What Is the EAA?

The European Accessibility Act (Directive 2019/882) requires that certain products and services be accessible to people with disabilities. For digital products, this means compliance with EN 301 549 — the European accessibility standard.

EN 301 549 references WCAG 2.1 Level AA but goes further, covering:

  • Mobile applications
  • E-readers and e-books
  • E-commerce platforms
  • Banking services
  • Transport services
  • Telecommunications

Who Does It Apply To?

The EAA applies to businesses selling to EU consumers, regardless of where the business is located. If EU residents use your product, you’re in scope.

In scope:

  • E-commerce websites and apps
  • Banking and financial services
  • Streaming services
  • E-books and e-readers
  • Telecommunications services
  • Transport information services
  • Any “service delivered through websites” in the EU

Microenterprise exemption: Companies with fewer than 10 employees AND annual turnover under €2 million may be exempt, but only for services (not products).

EAA vs WCAG vs ADA

EAAWCAGADA
TypeLawGuidelinesLaw
RegionEUGlobalUS
StandardEN 301 549WCAG 2.1/2.2WCAG 2.1 AA
ScopeDigital + physicalWeb onlyAll public accommodations
PenaltiesPer member stateN/ALawsuits
EnforcementJune 2025N/AOngoing

The Technical Requirements

EN 301 549 maps closely to WCAG 2.1 Level AA for web content. Here are the most impactful requirements for developers:

Perceivable

  • All images have meaningful alt text
  • Videos have captions and audio descriptions
  • Color is never the sole means of conveying information
  • Text can be resized to 200% without loss of content
  • Contrast ratios meet minimum thresholds (4.5:1 for text)

Operable

  • All functionality available via keyboard
  • No keyboard traps
  • Users can pause, stop, or hide moving content
  • No content that flashes more than 3 times per second
  • Skip navigation mechanisms

Understandable

  • Page language declared in HTML
  • Form inputs have visible labels
  • Error messages are descriptive and suggest corrections
  • Consistent navigation across pages

Robust

  • Valid HTML
  • Proper ARIA usage (or better: semantic HTML that doesn’t need ARIA)
  • Name, role, and value available for all UI components

Practical Steps for Compliance

1. Audit Your Current State

Run an automated scan to find the low-hanging fruit:

  • axe DevTools browser extension (free)
  • Lighthouse accessibility audit (built into Chrome)
  • Our Accessibility Scanning API for continuous monitoring

Automated tools catch about 50% of issues. Manual testing catches the rest.

2. Fix the Critical Issues First

Priority order:

  1. Keyboard accessibility (can users navigate without a mouse?)
  2. Screen reader compatibility (semantic HTML, proper headings)
  3. Color contrast (affects the most users)
  4. Form accessibility (labels, error messages)
  5. Image alt text

3. Implement Accessibility in Your Development Process

  • Add accessibility linting to CI/CD (eslint-plugin-jsx-a11y, axe-linter)
  • Include keyboard testing in QA
  • Test with at least one screen reader (VoiceOver on Mac is free)
  • Add accessibility to your definition of done

4. Document Your Conformity

The EAA requires an accessibility statement on your website declaring:

  • Which standard you conform to (EN 301 549)
  • Known non-conformities
  • Contact information for accessibility issues
  • Date of last assessment

Common Developer Mistakes

  1. Relying only on automated scanning — Automated tools miss contextual issues. A button labeled “Click here” passes automated checks but fails for screen reader users.

  2. Using div and span for everything — Semantic HTML (button, nav, main, article) provides accessibility for free.

  3. Hiding content visually but not from assistive tech — display: none hides from everyone. Use .sr-only CSS class when content should be screen-reader-only.

  4. Custom components without ARIA — If you build a custom dropdown, you need role, aria-expanded, aria-controls, and keyboard handlers. Or just use a native select.

  5. Assuming compliance = checking a box — Accessibility is ongoing. Sites change, content updates, new features launch. Continuous monitoring beats annual audits.

The Business Case

Beyond legal compliance:

  • 15-20% of the global population has a disability
  • Accessible sites have better SEO (search engines are screen readers)
  • Accessible sites are typically faster and more usable for everyone
  • Many accessibility improvements benefit mobile users

Timeline

  • June 28, 2025: EAA enforcement begins
  • June 28, 2027: Existing products/services must comply (transition period)
  • 2028+: EU ViDA reforms add more digital reporting requirements

If you’re building new features today, build them accessibly from the start. It’s dramatically cheaper than retrofitting.

Need continuous accessibility monitoring? The Accessibility Scanning API provides automated EAA compliance scanning with EN 301 549 mapping and CI/CD integration.