Design Design Design! → Part 94: My Cheat Sheet — European Accessibility Act (EAA)

13 min readMar 24, 2025

The European Accessibility Act (EAA) is a game-changer for accessibility in digital and physical products across the EU. It harmonizes requirements across member states, tears down market barriers, and ensures better access for all — especially for people with disabilities and the elderly.

💡 Why it matters: Better accessibility = better design, broader reach, and more inclusive products.

What You’ll Learn in This Post

What the European Accessibility Act (EAA) is and who it applies to
How WCAG 2.1 Level AA fits into the picture
What a VPAT is and why it’s essential
Key design and development responsibilities for accessibility
The difference between EAA and ADA
Tools and standards like EN 301 549, ARIA, and more

1. What Is the European Accessibility Act (EAA)?

Goal: Ensure digital products and services are accessible across the EU.
Adopted: 2019
Transposition Deadline: June 28, 2022
Compliance Deadline for Businesses: June 28, 2025

Applies to:

Websites & Mobile Apps
Banking & E-Commerce
Transport Services & Ticketing
ATMs & Self-service Kiosks
E-books, Telephony, and more

👉 It’s not just for public services — the EAA targets private sector digital products too.

2. WCAG: The Foundation of Digital Accessibility

Web Content Accessibility Guidelines (WCAG) define how to make web content accessible for all users, especially those with disabilities.

WCAG Versions

1.0 (1999) → Obsolete
2.0 (2008)
2.1 (2018) → Referenced by the EAA
2.2 (2023) → Adds support for cognitive & mobile accessibility

WCAG Levels of Conformance

Level A: Basic accessibility
Level AA: Most common (and EAA-required)
Level AAA: High-end, rarely enforced

The EAA mandates WCAG 2.1 Level AA compliance.

3. What Are VPATs?

VPAT = Voluntary Product Accessibility Template
Creates an Accessibility Conformance Report (ACR).

Used for evaluating digital product accessibility
Based on WCAG + EN 301 549 + sometimes Section 508 (US)
Required when selling tech to public sectors in the US & EU

For EAA compliance, VPATs based on EN 301 549 are key.

4. 🇺🇸 ADA vs. 🇪🇺 EAA: Similar Goals, Different Paths

ADA = U.S. law (Title III covers business websites)
No explicit WCAG requirement, but WCAG 2.1 Level AA is used in court
EAA = EU directive backed by formal standards like EN 301 549

⚠️ EAA ≠ ADA — but both push for more accessible experiences.

5. Team Roles in Accessibility (Under EAA)

Accessibility isn’t just a dev checklist — it’s a cross-functional effort.

5.1 Designers: Design for Inclusion

5.1.1🎨 Perception & Visual Design (Perceivable)

5.1.1.1 Use adequate color contrast (4.5:1 for normal text)

To Keep Color Contrast Accessible by Following WCAG minimum contrast ratios means to use: 4.5:1 for normal text and 3:1 for large text (18px or 14px bold). Avoid using color alone to convey meaning (e.g., red for errors — use icons or text too). Test in both light and dark modes if your site supports them

Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;[Source]
Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.[Source]
Logotypes: Text that is part of a logo or brand name has no contrast requirement. [Source]

5.1.1.2 Avoid using color alone for meaning

This EAA (European Accessibility Act) criterion means that color should not be the only visual indicator to convey important information, status, or actions.

❌ Bad (Color alone is used): “Fields marked in red are required.”
Here, users who can’t see red won’t know what’s required.
✅ Good (Color + other cues): “Fields marked in red and with an asterisk (*) are required.”
Or use icons: <span style=”color: red;”>⚠️</span>

5.1.1.3 Ensure readable fonts and clear heading structures:

Making font sizes accessible is not just about making your font larger. While keeping your fonts between 12 to 14 px can help make your page easier to read, standard accessibility guidelines suggest using relative font sizes (relative units like rem, em, or % for font sizes). Accessibility in font size means more users can access your site, keeping you both within legal guidelines and helping improve equality across the internet. Keep base font size around 1rem (16px) and Avoid using fixed px sizes below 14px

📏 Absolute vs. Relative Font Size — Scales with user settings?
px Absolute font-size: 14px ❌ No
em Relative to parent font-size: 1.2em ✅ Yes
rem Relative to root (html) font-size: 1rem ✅ Yes
% Relative font-size: 100% ✅ Yes

👉 Using relative units ensures accessibility because the browser can adjust the size based on user preferences.

✅ WCAG Recommendation (Source)

Minimum recommended font size:
Use at least 16px (or 1rem) for body text to support readability.
📖 Reference: While WCAG doesn’t specify exact font sizes, this is a common best practice supported by accessibility experts such as W3C WAI Tutorials and MDN Web Docs.
Allow zooming and resizing:
Ensure content is usable at 200% zoom without loss of functionality or content.
📖 Reference: WCAG 2.2 — Success Criterion 1.4.4: Resize Text
Avoid fixed font sizes:
Avoid locking in small font sizes like 12px or 14px, as they can be unreadable on high-DPI or small screens. Use relative units (like em, rem, or %) to allow better scalability.
📖 Reference: WCAG 2.2 – Understanding Use of Relative Units

💡 Code Example: Accessible Font Sizes

CSS Example:

/* Set base font size in root (HTML) */
html {
  font-size: 100%; /* Usually 16px by default */
}

/* Use rem or em instead of px */
body {
  font-size: 1rem; /* 16px */
  line-height: 1.5; /* Improve readability */
}h1 {
  font-size: 2rem; /* 32px */
}p {
  font-size: 1rem; /* 16px */
}.small-text {
  font-size: 0.875rem; /* 14px */
}

Tailwind CSS Example:

<p class="text-base">This is base (16px) text</p>
<p class="text-sm">This is small (14px) text</p>
<p class="text-lg">This is large (18px) text</p>

🔁 Bonus Tip: Respecting User Preferences

You can go a step further and adjust font sizes responsively using media queries:

@media (min-width: 768px) {
  body {
    font-size: 1.125rem; /* 18px on larger screens */
  }
}

5.1.1.4 Add alt text for images and video, avoid autoplay media

Images and videos must be accessible to all users — including those with visual or hearing impairments. This means:

✅ Provide alternatives like:

alt text for images
captions, transcripts, or audio descriptions for videos

❌ Avoid autoplaying videos with sound
✅ Always give users control to play, pause, or mute media

Example 1: Accessible Image with Alt Text

<img src="product.jpg" alt="A red cotton t-shirt on a wooden hanger">

alt describes the image for screen readers and users who can’t view it.
Avoid using empty or vague descriptions like "image" or "photo".

Example 2: Video with Captions

<video controls>
  <source src="video.mp4" type="video/mp4">
  <track src="captions.vtt" kind="subtitles" srclang="en" label="English">
  Your browser does not support the video tag.
</video>

<track> adds subtitles or captions
controls enables play/pause/volume functions

Example 3: Linked Transcript for Video

<video controls>
  <source src="interview.mp4" type="video/mp4">
</video>

<p><a href="interview-transcript.html">Read the full transcript</a></p>

This ensures people with hearing impairments can access the dialogue and important sounds in your video.

❌ Avoid This: Autoplay with Sound

<!-- Not accessible -->
<video autoplay>
  <source src="promo.mp4" type="video/mp4">
</video>

Autoplaying with sound can be disruptive and inaccessible.
If using autoplay, make sure the video is muted and not essential content.

5.1.2 🧭 Navigation & Interaction (Operable)

5.1.2.1 Ensure keyboard navigability

Under the EAA, all interactive elements on a website or app must be fully usable without a mouse — meaning users can navigate and operate the interface using only a keyboard.

This is essential for people who: Use screen readers, Have mobility impairments, Rely on assistive technologies.

What Should Be Keyboard Accessible?

Navigation menus
Buttons and links
Form fields (inputs, checkboxes, radio buttons)
Modals, sliders, drop-down, tabs
Video/audio controls
Custom components (e.g. carousels, popovers)

Every interactive element must:

Be reachable via Tab
Be operable via Enter or Space
Have a visible focus indicator (like an outline or border)

Manual Testing (Basic but effective):

Open your website in a browser.
Press the Tab key repeatedly.

Can you reach all important elements?
Do you see a clear focus style (outline)?

Use Enter or Space to activate buttons/links.
Try pressing Shift + Tab to go backwards.

Code Example: Focusable and Accessible Button

<button>Submit</button>

Avoid using non-semantic elements like <div> or <span> for buttons unless you add proper roles and tabindex:

<!-- NOT accessible -->
<div onclick="submitForm()">Submit</div>

<!-- Accessible version -->
<div role="button" tabindex="0" onclick="submitForm()" onkeypress="if(event.key === 'Enter'){ submitForm(); }">
  Submit
</div>

But really: prefer semantic elements like <button> whenever possible.

5.1.2.2 Keep consistent layouts

Consistency directly supports usability and accessibility, especially for people with cognitive, visual, and motor disabilities. When layouts stay consistent, people are less likely to make mistakes, especially in forms, shopping carts, or any complex flow like signing up or checking out.

Predictability for Cognitive Accessibility:

People with cognitive disabilities (like ADHD, autism, or dyslexia) rely on predictable layouts to understand and navigate content more easily.
Inconsistent layouts can cause confusion, increase cognitive load, and lead to errors.

Screen Reader & Keyboard Navigation

Users who rely on screen readers or keyboard-only navigation expect interface elements (like navigation, search, or buttons) to appear in the same place on every page.
Inconsistent placement disrupts the user’s mental model and makes it harder to move efficiently.

Motor Disability Support

People with motor impairments (e.g., using switches or eye-tracking) benefit from fewer layout changes, as they reduce the need to relearn or adjust movements for every page.

Note: On a futher note a layout should still work at 200% zoom.

5.1.2.3 Make click/tap targets large enough (44x44px)

Making click/tap targets at between 24x24 (lvl AA) and 44x44 pixels (lvl AAA) is directly aligned with accessibility best practices. While not yet strictly enforced under Level AA, it reflects best practices that help meet the intent of the law — especially for touchscreen usability and inclusive design.

Where does the 44×44px target size come from? It comes from WCAG 2.5.5: Target Size (Level AAA): “The size of the target for pointer inputs is at least 44 by 44 CSS pixels.” Even though this is Level AAA in WCAG 2.1, many designers and developers treat it as a best practice — especially for mobile and touch interfaces. The European Accessibility Act references EN 301 549, which in turn references WCAG 2.1 Level AA, but…

So is it required under EAA?

Strictly speaking: The 44×44px minimum is not mandatory under WCAG 2.1 Level AA — but the EAA requires that interactive elements be accessible on touch screens, which implies:
Targets must be easy to hit
Users should not accidentally activate nearby elements
Some EU countries may interpret or enforce this based on real-world usability — so adopting 44×44px is the safest and most inclusive move.

WCAG 2.2 makes it even more real

In WCAG 2.2, which the EU is moving toward, Target Size becomes Level AA with a minimum of 24x24 CSS pixels, unless certain exceptions apply.
Still, 44×44 is the gold standard recommended by Apple, Google Material Design, and inclusive UX guidelines.

5.1.2.4 Avoid motion triggers for sensitive users

This refers to the requirement to protect users who are sensitive to motion-based interactions or animations. It involves respecting physical and neurological conditions and is a key part of creating inclusive digital experiences under the EAA. Examples include:

Parallax scrolling
Auto-playing animations or videos
Gestures like shaking or tilting to trigger actions
Transitions or effects that mimic motion, zoom, or spinning

These can cause dizziness, nausea, disorientation, or even seizures in users with:

Vestibular disorders (inner ear balance issues)
Photosensitive epilepsy
Motion sensitivity, migraines, or other cognitive conditions

What does this mean practically? Under the EAA (via WCAG 2.1/2.2 and EN 301 549), products must:

Provide a way to disable motion-based triggers

WCAG 2.5.4 — Motion Actuation (Level A) requires:

“Functionality that is operated by device motion or user motion can also be operated by user interface components, and motion can be disabled to prevent accidental activation.”

Example:

If you can shake your phone to undo something, you must also provide an on-screen “Undo” button.
You must allow users to turn off the shake gesture in settings.

Reduce unexpected motion

WCAG 2.3.3 — Animation from Interactions (Level AAA) (and included in many best practices):

Avoid triggering non-essential animations (e.g., parallax, zoom effects) based on user interaction, unless the animation is essential or the user has opted in.

Modern browsers support the prefers-reduced-motion CSS media query, so developers can check if a user has requested minimal motion in their OS.

@media (prefers-reduced-motion: reduce) {
  * {
    animation: none !important;
    transition: none !important;
  }
}

“Avoid motion triggers for sensitive users” means:

Don’t rely solely on motion gestures (e.g., tilt, shake).
Don’t surprise users with intense movement.
Always provide a static alternative or a way to turn motion off.

5.1.3 🧠 Content & Structure (Understandable)

5.1.3.1 Use plain language and proper form labeling

📄 What it means:
Make sure content is written in simple, understandable language, and that form fields have clear, descriptive labels.

Example:
Instead of saying “Authenticate your credentials”, say “Log in with your email and password.”
Label form fields like: Label: Email address instead of leaving it blank or using placeholder text only.

5.1.3.2 Add inline validation and helpful error messages

📄 What it means:
Provide immediate feedback next to the input field when there’s an error, and explain what went wrong in a friendly, specific way.

Example:
If a user enters an invalid email:
“Please enter a valid email address like name@example.com.”
Display this message right below or beside the input field — not only after submitting the form.

5.1.3.3 Manage focus between modals and overlays

📄 What it means:
When a modal or overlay opens, keyboard focus should move inside it. When it closes, focus should return to where it was before. This helps screen reader and keyboard users stay oriented.

Example:
When opening a “Settings” modal, the first input inside the modal is focused. When closing it, focus returns to the “Settings” button.

5.1.4 🧱 Semantics & ARIA (Robust)

Absolutely! Here’s a structured breakdown with explanations, examples, and useful tips for each point — including screen reader usage, when and how to use ARIA, and accessible HTML structure.

5.1.4.2 Only use ARIA when necessary — bad ARIA can break UX

What it means:

ARIA (Accessible Rich Internet Applications) is a powerful tool for improving accessibility, but only when native HTML can’t do the job. Misused ARIA can confuse screen readers, keyboard users, and create a worse experience than no ARIA at all.

When ARIA 🟢 is necessary:

You’re creating custom UI components (e.g., tabs, modals, sliders) not covered by native HTML.
You want to provide extra context (e.g., aria-live, aria-describedby).
You’re adding semantic roles that are missing (e.g., role="dialog" on a custom modal).

<div role="dialog" aria-labelledby="dialog-title" aria-describedby="dialog-desc">
  <h2 id="dialog-title">Delete item?</h2>
  <p id="dialog-desc">Are you sure you want to delete this?</p>
</div>

When 🔴 NOT to use ARIA:

Don’t replace native HTML elements (<button>, <nav>, <input>) with div + ARIA.
Don’t use ARIA roles that conflict with native semantics.
Avoid adding ARIA attributes just because it “seems more accessible.”

Better approach — use native HTML when possible:

<!-- GOOD: Native button -->
<button type="submit">Send</button>

<!-- BAD: Div pretending to be a button -->
<div role="button" tabindex="0" onclick="submitForm()">Send</div>

5.1.4.3 Structure your HTML to support screen readers

What it means:

Good semantic HTML is the foundation of accessibility. It ensures screen readers can interpret and announce content correctly without needing ARIA.

Use semantic HTML structure:

<header>
  <nav aria-label="Main navigation">
    <ul>
      <li><a href="#home">Home</a></li>
    </ul>
  </nav>
</header>

<main>
  <article>
    <h1>Welcome</h1>
    <p>This is the main content of the page.</p>
  </article>
</main><aside>
  <h2>Related articles</h2>
</aside><footer>
  <p>Contact us</p>
</footer>

Use heading levels logically:

<h1> for main page title
<h2> for sections
No skipping heading levels (e.g., avoid jumping from <h1> to <h4>)

When does the screen reader come in?

Screen readers read the structure, landmarks, and roles of HTML content aloud. That’s why good HTML structure is crucial.

How to activate a screen reader:

macOS (VoiceOver)

Press: Cmd + F5
Or go to: System Settings > Accessibility > VoiceOver

Windows (Narrator)

Press: Ctrl + Windows + Enter
Or go to: Settings > Accessibility > Narrator

5.1.5 🔧 Design Workflow Tips

[more infos coming soon …]

5.1.5.1 Start accessible — don’t retro-fit5.1.5.2 Test dark mode, zoom, screen readers, and motion[more infos coming soon …]
5.1.5.3 Include users with disabilities in personas[more infos coming soon …]

5.2 Developers: Implement the Standard