European Accessibility Act 2025: The Complete…

European Accessibility Act 2025: The Complete Checklist for UI/UX Designers Before June 28

June 28, 2025 is not a proposal or a guideline suggestion. It is a hard enforcement date. After that date, any business operating digital products or services in EU markets that fails to meet the accessibility requirements of the European Accessibility Act (EAA) is subject to regulatory enforcement — fines, market withdrawal orders, and reputational consequences that follow published non-compliance records.

This is fundamentally different from how accessibility has been handled in the United States. The ADA-based litigation model in the US creates risk through private lawsuits — unpredictable, expensive, and after the fact. The EAA is a coordinated regulatory framework with planned enforcement bodies in all 27 member states. The compliance requirement was known six years before the deadline. There is no "we didn't know" defense.

If you design or build digital products that are sold, distributed, or operated in the EU — websites, mobile apps, SaaS platforms, e-commerce stores — this affects your work directly. This guide gives you a complete, actionable checklist based on WCAG 2.1 Level AA, an explanation of what the EAA actually requires, an audit process you can run in a week, and the tools to make it happen. No fluff. Let's get into it.

What Is the European Accessibility Act?

Directive 2019/882 — commonly called the European Accessibility Act — was adopted by the European Parliament and Council in June 2019. Its purpose was straightforward: replace the patchwork of 27 different national accessibility standards across EU member states with a single, harmonized framework. Before the EAA, a company doing business across Germany, France, the Netherlands, and Sweden was navigating four different regulatory interpretations of "accessible." The EAA ends that.

Member states were required to transpose the directive into national law by June 28, 2022, and have until June 28, 2025 to enforce it. Most countries are on track. Germany has passed the Barrierefreiheitsstärkungsgesetz (BFSG), France has updated its RGAA framework, and the Netherlands has amended its Tijdelijk besluit digitale toegankelijkheid overheid.

The technical standard referenced by the EAA is EN 301 549, which is the European telecommunications standard for ICT accessibility. EN 301 549 maps directly to WCAG 2.1 Level AA for web and mobile content. When you meet WCAG 2.1 AA, you meet the EAA's technical requirements for digital interfaces.

The scope of the EAA is broad:

Websites and mobile applications used by consumers
E-commerce — product pages, checkout flows, account management
Online banking and financial services — login screens, account statements, transaction interfaces (see our fintech app design best practices for the money-movement, authentication and consent patterns)
Media streaming services — video players, captions, programme guides
E-readers and e-book software
Self-service terminals — ATMs, ticketing kiosks, check-in machines (important for physical product designers)
Operating systems that support other EAA-covered products
Digital documents provided as part of covered services

Microenterprises — defined as fewer than 10 employees AND annual turnover or balance sheet under €2 million — are explicitly exempt. If you run a small freelance portfolio or a two-person startup, you're likely outside scope. But if your client is a medium or large business serving EU consumers, they are not.

Who Must Comply — and What Exactly Must Be Accessible

The EAA uses a service-category approach. If your organization falls into one of the covered categories, the digital interfaces used to deliver that service must be accessible. Here is what that means across the most common sectors:

E-commerce: Every part of the shopping journey is in scope — not just the homepage. Product listing pages, product detail pages, search results, filtering interfaces, shopping cart, checkout (including payment screens), order confirmation, and account management pages all must meet WCAG 2.1 AA. If you're using a third-party payment provider's hosted iframe, you are still responsible for the overall user experience — though liability may shift partly to the provider.

Banking and financial services: Login flows, dashboard views, transaction history, statement downloads, fund transfer interfaces, investment account pages. Institutions that provide PDF statements must ensure those PDFs are tagged and accessible, not just scanned image files.

Streaming and media: The video player itself — play/pause controls, volume, captions toggle, subtitles selection, fullscreen — must be keyboard-operable and screen reader accessible. All pre-recorded video content must have synchronized captions. Content with significant audio (including background music that carries meaning) requires audio descriptions or a text alternative.

Transport services: Online ticket booking, seat selection interfaces, journey planning tools, real-time status displays. This matters significantly for rail, airline, and coach operators running digital sales channels.

B2B SaaS with consumer reach: This is where many teams are confused. If your SaaS product is used by an EU business to deliver services to end consumers — a customer support platform, a booking system, an e-commerce back-office — you likely need to comply. Your software becomes part of the delivery chain for a covered service.

The "disproportionate burden" exception exists but is narrow. A business can claim it if achieving compliance would require changes so extensive they fundamentally alter the nature of the product or impose costs that would threaten the business's financial viability. This exception must be documented, published, and periodically reviewed. It is not a blanket opt-out — it is a temporary, justified deferral for specific identified barriers, with a plan to address them over time.

The EAA Compliance Checklist for UI/UX Designers

This checklist follows the four WCAG 2.1 principles: Perceivable, Operable, Understandable, and Robust (POUR). Work through each section with your team. Items marked with complexity need developer collaboration — flag them early.

Perceivable

All users must be able to perceive the content and interface — regardless of whether they use sight, hearing, or another sense.

All meaningful images have descriptive alt text that conveys the same information as the image
Decorative images use empty alt="" so screen readers skip them
Text color contrast meets ≥ 4.5:1 against its background for normal text (under 18pt regular or 14pt bold)
Large text (18pt+ regular, or 14pt+ bold) meets ≥ 3:1 contrast ratio
UI component contrast — button outlines, form field borders, checkboxes, radio buttons, focus rings — meets ≥ 3:1 against adjacent colors
No information is conveyed by color alone; error states use an icon plus text message, not just a red border
All pre-recorded video has synchronized captions (auto-generated captions that haven't been reviewed do not count)
All pre-recorded audio-only content has a text transcript
Videos that contain important visual information not conveyed in the audio have audio descriptions
Content reflows correctly at 400% zoom (equivalent to 1280px viewport displayed at 320px width) without requiring horizontal scrolling to access content
Content remains intact when: letter-spacing is 0.12em, word-spacing is 0.16em, line-height is 1.5, and paragraph spacing is 2em — this is the WCAG 1.4.12 text spacing requirement
No content flashes more than 3 times per second (or stays below the general flash and red flash thresholds)

Operable

All interactive elements must be operable by users who cannot use a mouse.

All interactive elements — links, buttons, form controls, date pickers, carousels, menus — are reachable by Tab / Shift+Tab and activatable by Enter or Space
Arrow keys work for grouped controls: radio button groups, tab panels, listboxes, sliders
A visible focus indicator appears on every interactive element — minimum 2px solid outline with ≥ 3:1 contrast against both the element and its background
CSS does not suppress focus outlines with outline: none or outline: 0 without providing an equivalent custom indicator
No keyboard traps — users can navigate into any component and navigate out again with standard keys
Modal dialogs trap focus correctly — Tab cycles only within the dialog; Escape closes the dialog and returns focus to the trigger element
A skip navigation link appears as the first focusable element on every page, visible on focus, linking to the main content landmark (<main>)
Every page has a <title> element that accurately and uniquely describes the current page (not just the site name)
Link text is self-descriptive in context — "Download the Q1 2025 accessibility audit report (PDF)" not "click here" or "read more"
Session timeouts: if a session will expire, the user receives a warning at least 20 seconds in advance and has an option to extend or save their work
Animations and motion effects respect the prefers-reduced-motion media query — decorative animations pause or disable when users have set this system preference
All functionality that requires dragging, swiping, pinching, or path-based gestures has a single-pointer alternative (a tap-based equivalent)
Tappable targets are at least 24×24 CSS pixels, with adequate spacing between adjacent targets (WCAG 2.5.8 in 2.2, but best practice now)

Understandable

Users must be able to understand both the content and how the interface works.

The page's primary language is declared in the <html lang="en"> attribute (or the appropriate BCP 47 language tag)
Language changes within the page — a French quote in an English article — are marked with a lang attribute on the containing element
Navigation components (primary nav, breadcrumbs, footer links) appear in the same location and same order across all pages
Components that perform the same function have the same accessible name on every page (a search button should not be labeled "Go" on one page and "Find" on another)
Error messages identify the specific field by name and describe what went wrong: "Email address is required" — not "Please check your input"
For fields with known valid formats (phone numbers, dates, postal codes), the error message includes the expected format: "Enter your date of birth as DD/MM/YYYY"
Suggestions are offered for input errors where known — if a user types "englanf", suggesting "England" is valid
Legal, financial, or irreversible form submissions include a review-and-confirm step before final submission, or provide a mechanism to correct before execution
Every form input has a <label> that is programmatically associated via for/id or by wrapping the input — visual proximity is not sufficient
Required fields are indicated in a way that doesn't rely on color alone — asterisk with a legend, "Required" text, or aria-required="true"

Robust

Content must work reliably with current and future assistive technologies.

HTML is valid — no duplicate id attributes on a page, all tags properly opened and closed, no attribute conflicts
Every interactive component exposes name, role, and value to the accessibility tree — either through native HTML semantics or explicit ARIA attributes
aria-hidden="true" is never applied to an element that is focusable — this creates a ghost tab stop screen readers cannot announce
Status messages — "Your item has been added to your cart", "Form submitted successfully" — use role="status" or aria-live="polite" so screen reader users are informed without losing focus
Custom interactive widgets (custom dropdowns, date pickers, accordions, tab panels, sliders) follow the ARIA Authoring Practices Guide (APG) patterns precisely — the keyboard interactions must match documented expectations
role, aria-expanded, aria-selected, aria-checked, and similar state attributes are updated dynamically when UI state changes (an accordion that expands must update aria-expanded from false to true)
iframes have descriptive title attributes
Form validation errors are announced to screen readers — either by moving focus to the error summary or by using aria-describedby to associate the error message with the input field

The 5 Most Common EAA Violations in UI/UX Design

These are not edge cases. They appear in virtually every accessibility audit, including audits of products built by experienced teams who assumed accessibility was "handled."

1. Insufficient Color Contrast

This is the single most prevalent violation. The failure modes are consistent: placeholder text in form fields (typically grey-on-white at 2:1 or 3:1, well below the 4.5:1 requirement), disabled state styling (often rendered as grey text on grey background), ghost buttons (light outline on white background), and light brand-color text on white backgrounds used in marketing copy.

Who it impacts: Users with low vision, color vision deficiencies, and anyone using a screen in direct sunlight or a low-quality display.

The fix: Use a contrast checking tool — Colour Contrast Analyser or the axe browser extension — during design, not after. Set design token values that are contrast-verified from the start. If your disabled state doesn't meet 3:1, your design system documentation should note it as a known exception (disabled controls are not required to meet contrast under WCAG 2.1) — but check whether users can still identify the state clearly.

2. Missing or Removed Focus Indicators

This happens because focus rings are considered ugly. A common pattern in production CSS: * { outline: none; } or a:focus, button:focus { outline: none; } — applied globally to remove the browser's default focus ring, with no replacement provided. The result is that keyboard users have no visible indication of where they are on the page.

Who it impacts: Keyboard-only users, switch access users, motor-impaired users, power users who prefer keyboard navigation.

The fix: Never remove the focus outline without replacing it. Design a custom focus indicator for every interactive component in your design system. The 2024 WCAG 2.2 guidance specifies a minimum: the focus indicator should enclose the component, have a contrasting color, and meet 3:1 contrast against adjacent colors. A 2px solid #005FCC outline on most backgrounds achieves this.

3. Inaccessible Modal Dialogs

Modals are functionally broken for keyboard users more often than not. The failure pattern: a modal opens, focus stays on the button that triggered it (or lands on the modal container element, not the first interactive element inside), Tab key escapes the modal into the background page, background content is scrollable, and when the modal closes, focus goes to the top of the page instead of back to the trigger.

Who it impacts: Keyboard-only users, screen reader users (who can navigate out of the modal to the background), motor-impaired users.

The fix: On open — move focus to the first focusable element inside the modal (or the modal's heading if there are no immediate interactive elements). Constrain Tab/Shift+Tab to cycle within the modal only. Map Escape to close the modal. On close — return focus to the exact element that opened the modal. If the trigger no longer exists in the DOM, move focus to a logical predecessor. Make background content aria-hidden="true" and inert while the modal is open. This is exactly what the ARIA APG Dialog Pattern specifies.

Building a consistent design system means documenting these patterns once and applying them everywhere — the kind of scalable approach covered in depth in the design systems guide for building scalable UI/UX systems.

4. Form Errors Without Context

Red border appears on a field. No message. Or: "Error" message appears at the top of the page with no connection to the field. Or: an error message appears below the field but has no programmatic association — a sighted user can connect them visually, but a screen reader user navigating field-by-field hears the label and input but not the error.

Who it impacts: Screen reader users, users with cognitive disabilities, users who don't perceive the color red as signaling an error.

The fix: Three requirements work together. First, the error message must be adjacent to (or associated with) the input via aria-describedby. Second, the message must identify the field and describe the problem ("Email address — please enter a valid email address"). Third, error state must not be indicated by color alone — add an icon, change the label, or otherwise provide a non-color signal. When validation fires on submit, move focus to an error summary at the top of the form that lists all errors as links, so users can jump to each affected field.

5. Icon-Only Buttons Without Accessible Labels

Hamburger menus. Close buttons (×). Share icons. Heart/like buttons. Trash/delete icons. These appear throughout modern interfaces as icon-only controls with no visible text label — and frequently with no accessible label either. A screen reader announces "button" with no name, or worse, reads the SVG file name or the Unicode character name.

Who it impacts: Screen reader users who hear "button" with no context; users with cognitive disabilities who don't recognize icon conventions.

The fix: Every icon-only button needs an accessible name. The preferred approach: aria-label="Close dialog" on the <button> element directly. Alternatively, include a visually hidden text span using a .sr-only CSS class (position: absolute; width: 1px; height: 1px; overflow: hidden; clip: rect(0,0,0,0)). Never rely on title attributes as the accessible name — they are not reliably announced by all screen readers and create poor hover-tooltip UX on touch devices.

Accessibility Audit Process: Step-by-Step

Running a thorough accessibility audit before June 28 doesn't require a specialized agency. Here is a practical six-step process your team can execute in-house within a week for a typical site.

Step 1: Automated scan

Start with axe DevTools (Chrome/Firefox extension), Lighthouse (built into Chrome DevTools under the Audits tab), and WAVE (WebAIM's browser extension). Run each tool against your most critical pages: homepage, product/service pages, checkout or lead forms, login, and account management.

Automated tools catch approximately 30–40% of accessibility issues — primarily missing alt text, contrast failures, missing form labels, invalid HTML, and some ARIA misuse. They are fast and consistent but will not catch keyboard traps, focus order problems, or meaning-dependent color usage. Treat them as the first filter, not the complete answer.

Step 2: Keyboard-only navigation walkthrough

Unplug (or disable) your mouse. Tab through every page and every feature. Document:

Which elements receive focus in what order (is the order logical and consistent with visual layout?)
Which elements cannot be reached by keyboard
Any keyboard traps where Tab does not exit a component
Focus indicator visibility on every element
Whether modal dialogs behave correctly (focus trap, Escape to close, focus return)
Whether dropdown menus, accordions, tabs, and carousels respond correctly to keyboard interaction

This step usually surfaces 30–40% of issues not caught by automated tools.

Step 3: Screen reader testing

Test with at least two screen reader / browser combinations: NVDA + Firefox on Windows (free, widely used), and VoiceOver + Safari on macOS/iOS. For Android coverage, use TalkBack + Chrome. If your team has budget, JAWS + Chrome or IE Mode covers enterprise Windows users.

Navigate each page using screen reader browse mode (arrow keys through content) and form mode (Tab through interactive elements). Listen for: Are form labels announced correctly? Are error messages associated with inputs? Are custom components announcing their role and state? Are status messages like "added to cart" announced without requiring focus movement?

Step 4: Manual cognitive checklist

Review forms for clear label-input association. Check that every page title is unique and descriptive. Verify that navigation is consistent. Read through error messages for clarity and specificity. Review reading order by inspecting the DOM in DevTools — visual order and DOM order should match for two-dimensional layouts.

Step 5: Document results in an accessibility statement

This is not optional under the EAA — it is a legal requirement. The accessibility statement must be published on your site and declare your compliance status. See the next section for exact requirements.

Step 6: Prioritize and fix in sprints

Sort findings by user impact (blocking vs. degrading vs. minor), frequency (how many pages are affected), and fix complexity (CSS change vs. HTML restructure vs. component rebuild). High-impact, low-complexity fixes go into sprint 1. Component rebuilds and complex ARIA work get scoped as sprint 2 and 3. Document a realistic timeline — this matters if you need to claim a temporary "disproportionate burden" exception for specific items.

Measuring the impact of accessibility improvements — and communicating that impact to stakeholders — follows the same principles as any design metric. The frameworks in UX metrics: how to measure design impact apply directly here: task completion rate, error rate, and time-on-task across user groups.

EAA Accessibility Statement Requirements

Every digital product covered by the EAA must publish an accessibility statement. This is analogous to a privacy policy — it must exist, it must be current, and it must be findable. Here is what the statement must contain:

Compliance status declaration: One of three positions — fully compliant, partially compliant (with a list of known non-compliant elements), or non-compliant. Most organizations will legitimately be "partially compliant" during initial phases. That is acceptable as long as exceptions are documented with justification and a remediation plan.

Known accessibility barriers: For each identified issue that is not yet remediated, list: what the barrier is, which WCAG criterion it fails, and what workaround (if any) exists. For example: "The PDF annual report document is not fully tagged for screen readers. An accessible HTML version is available on request."

Contact mechanism: Users must have a way to report accessibility problems and request content in alternative formats. This typically means an email address, phone number, or accessible contact form. Response to requests must be timely — the standard recommendation is within 5 working days.

Enforcement contact: The statement must include a link to the relevant national enforcement authority (e.g., the German Market Surveillance Authority, the French DGCCRF) so users who don't receive satisfactory responses know where to escalate.

Where to publish: Create a dedicated /accessibility page. Link to it from the footer on every page — the same way you link your privacy policy and terms of service. The statement must itself be accessible.

Keep it updated: The EAA requires that the accessibility statement reflect your current compliance status. Every time you remediate issues or discover new ones, update the statement. Quarterly review is a reasonable cadence for most organizations.

Tools and Resources Every Designer Should Bookmark

Building accessibility awareness into your daily workflow starts with having the right tools immediately available.

Automated testing:

axe DevTools — browser extension for Chrome and Firefox; the most reliable automated scanner, integrates with CI/CD pipelines via axe-core
Lighthouse — built into Chrome DevTools; provides a scored accessibility audit alongside performance and SEO; good for quick checks
WAVE (WebAIM) — visualizes accessibility issues directly overlaid on the page; excellent for client presentations because the visual output is immediately understandable
IBM Equal Access Checker — browser extension with strong coverage of ARIA and dynamic content issues; useful as a second opinion alongside axe

Contrast and color:

Colour Contrast Analyser (TPGi) — desktop application for Windows and macOS; pick any color from the screen and get an instant ratio; handles text against complex backgrounds by letting you sample each color independently
Who Can Use (whocanuse.com) — shows how your color combination appears to users with 8 types of color vision deficiency; invaluable for understanding real-world impact
Accessible Palette (accessiblepalette.com) — generates entire color palettes with contrast ratios pre-calculated; speeds up design system token work significantly

Screen readers:

NVDA (NonVisual Desktop Access) — free, open source; the most widely used screen reader among blind Windows users; primary test target for web accessibility
JAWS — commercial; dominant in enterprise environments; annual license required for full testing
VoiceOver — built into macOS, iOS, and iPadOS; free; essential for Safari testing and all Apple device coverage
TalkBack — built into Android; free; primary mobile screen reader for Android testing

Reference and patterns:

ARIA Authoring Practices Guide (APG) at w3.org/WAI/ARIA/apg — the definitive reference for building custom interactive widgets with correct keyboard interactions and ARIA patterns; bookmark the individual pattern pages for accordions, dialogs, tabs, comboboxes, and carousels
WCAG 2.1 Quick Reference (w3.org/WAI/WCAG21/quickref) — filterable view of all WCAG criteria with sufficient techniques and common failures; use the filters to show only Level AA
EN 301 549 — the actual European standard document; available free from ETSI; useful when clients need the formal regulatory reference rather than WCAG terminology
EU Web Accessibility Directive — while separate from the EAA (it covers public sector), the monitoring methodology and accessibility statement template from the Directive provides a useful template for EAA statements

The Opportunity Inside the Obligation

It would be easy to read this post as a list of burdens. It isn't. The June 28 deadline is a forcing function — and forcing functions, used correctly, create better products.

Consider the numbers. Approximately 1 in 4 adults in the EU has a disability. Across 450 million people, that represents a significant addressable population that is currently, in many cases, excluded from products that weren't designed with them in mind. Reaching those users is not just compliance — it is market expansion.

Beyond permanent disabilities, there is the concept of situational disabilities: a parent holding a child with one arm, a person navigating a website in direct sunlight with screen glare, a commuter listening to a podcast who can't also consume your video content. Accessible design consistently improves experience for all of these users. Captions benefit people in noisy environments as much as Deaf users. Keyboard navigation benefits power users as much as people with motor impairments. Clear form error messages benefit everyone who has ever mistyped their postcode.

There is also a structural SEO correlation that designers and product teams often overlook. Accessible HTML — proper heading hierarchy, descriptive link text, alt attributes, semantic landmarks — is exactly what search crawlers use to understand and index page content. A well-structured accessible page is also a well-structured page for Googlebot. The 2025 design landscape covered in the complete guide to UI/UX design trends 2025 treats these concerns as increasingly intertwined, and rightly so.

The practical path forward is straightforward: start with the checklist in this post. Run an automated audit with axe or Lighthouse this week — it takes 20 minutes and will surface the highest-severity issues. Conduct a keyboard walkthrough with a designer or developer pair. Prioritize by impact. Document your findings in an accessibility statement even if it currently reads "partially compliant" — because partial compliance, documented and with a remediation plan, is a demonstrably better legal and ethical position than no statement at all.

The EAA isn't the end of this story. WCAG 2.2 adds additional criteria around focus appearance and target size. WCAG 3.0 is in development with a fundamentally revised conformance model. Accessibility standards will continue to evolve. The teams that build accessible-by-default workflows and design systems now will adapt to those changes with far less friction than teams that continue treating accessibility as an afterthought.

Start now. June 28 is close — but accessible design is a long game, and the sooner you build it into your process, the better your products will be for every user you're trying to reach.