← Blog
EAA 2025 · Checklist··7 min read

European Accessibility Act 2025: A Developer Checklist

The European Accessibility Act (EAA) enforcement deadline is June 28, 2025. For new products and services, this date has already passed. For existing services under long-term contracts, the deadline is June 28, 2030 — but planning should be underway now.

The EAA applies to a wide range of digital products: e-commerce websites, banking interfaces, transport ticketing, e-books, operating systems, and self-service terminals. If your product serves EU customers in these categories, you need to act.

This checklist is organized by category. Use it as a working document — tick each item as you verify or implement it.

Progress0 / 60 (0%)

1. Understand your obligations

  • Confirm if your product/service falls under EAA scope (e-commerce, banking, transport, telecoms, e-books, OS, terminals)
  • Identify the applicable deadline: June 28, 2025 for new products/services; June 28, 2030 for existing ones under contract
  • Determine the applicable national implementation law in your target EU member states
  • Note: micro-enterprises (<10 employees AND <€2M revenue) are exempt from most EAA requirements

2. Map your technical baseline

  • Identify all user-facing interfaces (web app, mobile app, desktop, kiosk/terminal)
  • Inventory which WCAG 2.1 AA criteria your current product meets (run axe-core, Lighthouse, or manual audit)
  • Map gaps to EN 301 549 v3.2.1 — this is the harmonized EU standard referenced by the EAA
  • For web: EN 301 549 references WCAG 2.1 AA + additional clauses (non-web software, support services)
  • For mobile: EN 301 549 adds specific requirements for native apps (iOS, Android)

3. Component-level accessibility

  • All interactive elements are keyboard-operable (Tab, Enter, Space, Escape, arrow keys as appropriate)
  • Focus order is logical and follows DOM/visual order
  • Focus is always visible — no outline:none without a visible replacement (WCAG 2.4.7, 2.4.13)
  • Focused elements are not hidden behind sticky headers or overlays (WCAG 2.4.11)
  • All touch targets are at least 24×24 CSS px; 44×44 recommended for comfortable use (WCAG 2.5.8)
  • Draggable interactions have a keyboard/click alternative (WCAG 2.5.7)
  • All form fields have visible, programmatically associated labels (WCAG 1.3.1, 3.3.2)
  • Error messages are specific, in text, associated to the field via aria-describedby (WCAG 3.3.1)
  • Authentication does not rely solely on CAPTCHAs or cognitive puzzles (WCAG 3.3.8)
  • Multi-step forms don't ask users to re-enter previously provided information (WCAG 3.3.7)
  • Color is not the only means of conveying information (WCAG 1.4.1)
  • Text contrast ratio ≥ 4.5:1 (normal text) or ≥ 3:1 (large text, WCAG 1.4.3)
  • UI component and focus indicator contrast ≥ 3:1 (WCAG 1.4.11)
  • Content reflows at 320px width without horizontal scrolling (WCAG 1.4.10)
  • Animated content can be paused/stopped; reduced motion respected (WCAG 2.2.2, prefers-reduced-motion)

4. Page structure and navigation

  • Each page has a unique, descriptive <title> element
  • Language is declared on the <html> element (lang attribute)
  • Heading hierarchy is logical and not skipped (h1 → h2 → h3, WCAG 1.3.1)
  • Landmark regions present: <header>, <main>, <nav>, <footer> (or role equivalents)
  • Skip navigation link is present and functional ('Skip to main content')
  • Navigation order is consistent across pages (WCAG 3.2.3)
  • Help mechanisms (contact, support) appear in consistent positions across pages (WCAG 3.2.6)
  • No keyboard traps — users can always Tab out of any component

5. Images and media

  • All meaningful images have descriptive alt text
  • Decorative images have empty alt text or aria-hidden='true'
  • Complex images (charts, diagrams) have a text alternative or long description
  • Pre-recorded video has captions (WCAG 1.2.2)
  • Pre-recorded audio-only content has a text transcript (WCAG 1.2.1)
  • Live audio/video has real-time captions if required (WCAG 1.2.4)
  • Videos with audio have audio descriptions if visual content conveys information (WCAG 1.2.5)

6. Dynamic content and single-page apps

  • Status messages are announced via aria-live regions or role='status'/'alert' (WCAG 4.1.3)
  • Page title updates on route changes (SPA navigation)
  • Focus is managed on route transitions — placed on a logical target (h1 or main content)
  • Modal dialogs trap focus while open; focus restores to trigger on close
  • Loading states communicate via aria-busy='true' or live region announcements
  • Dynamic content injected via AJAX does not break screen reader announcement order

7. Documentation and legal obligations

  • Publish an accessibility statement (déclaration d'accessibilité in France) at /accessibility or /accessibilite
  • Statement includes: conformance level, audit date, non-conformities, contact for users to report issues
  • Statement is updated after each audit or significant change
  • For FR public sector: submit accessibility statement to DINUM as required
  • For EAA products: maintain technical documentation demonstrating conformance to EN 301 549
  • Define an accessibility feedback mechanism — users must be able to report barriers
  • Identify who is responsible for accessibility in your organization (accessibility officer/lead)

8. Testing and validation

  • Run automated testing with axe-core, Lighthouse, or WAVE — catches ~30-40% of issues
  • Manual keyboard testing: navigate entire user flow with only keyboard
  • Screen reader testing: NVDA+Firefox (Windows), VoiceOver+Safari (macOS/iOS), TalkBack (Android)
  • Zoom to 200%: verify no content is cut off or breaks layout
  • Zoom to 400%: text-only zoom must not lose content or functionality (WCAG 1.4.4)
  • Test with Windows High Contrast Mode
  • Involve users with disabilities in testing when possible
  • Document all findings and remediation decisions for the technical file

Ship compliant components without starting from scratch

Konform provides React components with built-in WCAG 2.2 AA and RGAA 4.1.2 documentation — covering the component-level requirements in this checklist. Every component ships with a per-criterion audit table so your team knows exactly what's covered.

View pricing

Related articles

Build an EAA-ready implementation plan

EAA 2025 obligations for French e-commerce teams

Translate the general checklist into the private-sector commerce cases most exposed to the EAA.

WCAG 2.2 AA component guide for React developers

Map the EAA checklist to the concrete WCAG 2.2 criteria that affect component behavior.

RGAA 4 audit guide for product teams

Prepare for the audit methodology that will validate whether your checklist work is complete.

compare Konform vs AlignUI for EAA 2025 compliance

See how documentation depth changes when your team must prove EAA readiness instead of styling alone.

free RGAA audit tools and contrast checker

Use the free checklist and contrast checker to turn EAA planning into concrete review steps.