Home Resources Accessibility Guide

The EAA has applied since 28 June 2025

Website Accessibility Guide 2026

This guide covers conformity with the European Accessibility Act and WCAG. You get 84 checkpoints based on WCAG 2.1 and 2.2, the legal requirements and practical implementation tips. Updated 12 October 2026.

1.3 billion

People with significant disability worldwide (WHO)

28 June 2025

The EAA has applied since this date

Accessibility checkpoints

0 of 84 items checked

What is the European Accessibility Act (EAA) and why does it matter?

The European Accessibility Act (EAA) is EU Directive 2019/882 and has applied since 28 June 2025. It requires businesses in all EU member states to make certain products and services for consumers accessible to people with disabilities, online shops included. Microenterprises that provide services are exempt (§ 3 para. 3 BFSG). In Germany the MLBF market surveillance authority in Magdeburg oversees services.

Who is affected?

- E-commerce websites (B2C)
- Online banking & financial services
- Telecommunications services
- E-book platforms & readers
- Transport & ticketing services

Consequences of non-compliance

- Fines set by each member state (Germany: up to EUR 100,000 for offering inaccessible services, § 37 para. 2 BFSG)
- Fines of up to EUR 10,000 for other breaches, such as missing information
- Duty to provide information to the market surveillance authority (§ 14 para. 5 BFSG)
- Reputational damage

1.1 Text Alternatives

All images have descriptive alt text

Screen readers read this text aloud, so describe what the image shows and what it does

Decorative images have empty alt attributes (alt="")

Screen readers should skip images that are only decorative

Complex images have long descriptions

Charts, graphs, and infographics need detailed text descriptions

Icon buttons have accessible names

Use aria-label or visually hidden text for icon-only buttons

CAPTCHAs have accessible alternatives

Provide audio CAPTCHA or other accessible verification methods

1.2 Time-based Media

Videos have synchronized captions

Essential for deaf users and helpful for non-native speakers

Audio content has transcripts

Provide a written version of all spoken content

Videos have audio descriptions

Narration of visual content for blind users (Level AA)

Live video has captions

Real-time captioning for live broadcasts and streams

Sign language interpretation available

For pre-recorded content where applicable (Level AAA)

1.3 Adaptable

Content structure conveyed through proper markup

Use semantic HTML elements (headings, lists, tables) correctly

Reading sequence is meaningful when linearized

DOM order should match visual order for screen readers

Instructions don't rely solely on sensory characteristics

Avoid "click the red button" or "see the graph on the right"

Content works in both portrait and landscape orientations

Don't restrict display orientation unless essential (WCAG 2.1)

Input purpose can be programmatically determined

Use autocomplete attributes for personal data fields (WCAG 2.1)

1.4 Distinguishable

Color contrast at least 4.5:1 for normal text

WCAG AA standard. Check it with the WebAIM Contrast Checker

Color contrast at least 3:1 for large text (18pt+)

Large text can be readable with lower contrast

Non-text contrast at least 3:1

UI components and graphical objects must have sufficient contrast (WCAG 2.1)

Color is not the only means of conveying information

Links should have underlines, errors should have icons + text

Text can be resized up to 200% without loss of content

Users with low vision need to zoom, so use relative units

Content reflows at 320px width without horizontal scrolling

WCAG 2.1 Reflow criterion (1.4.10) for responsive design

Text spacing can be adjusted without breaking layout

Line height 1.5x, paragraph spacing 2x, letter spacing 0.12em (WCAG 2.1)

No content flashes more than 3 times per second

Flashing can trigger seizures in photosensitive users, so treat this one as critical

Audio doesn't auto-play for more than 3 seconds

Otherwise provide a way to pause, stop or mute it

Hover/focus content is dismissible, hoverable, and persistent

Tooltips and popovers must meet WCAG 2.1 criteria (1.4.13)

2.1 Keyboard Accessible

All functionality accessible via keyboard (Tab, Enter, Space)

Users without a mouse must be able to operate everything

No keyboard traps: users can always move focus away

Check modals, dropdown menus and widgets in particular

Keyboard shortcuts don't conflict with assistive technology

Character key shortcuts can be turned off or remapped (WCAG 2.1)

Arrow key navigation for complex widgets

Menus, tabs, and listboxes should support arrow keys

2.2 Enough Time

Session timeouts provide warnings and extension options

Users need at least 20 seconds warning to extend time

Moving content can be paused, stopped, or hidden

Carousels, sliders, auto-play videos need pause controls

Users can control auto-updating content

Live feeds and tickers need a pause or stop control

No time limits or adjustable time limits for tasks

Unless essential for security or real-time events

2.3 Seizures and Physical Reactions

No content flashes more than 3 times per second

Red flashes in particular can cause photosensitive seizures

Animation from interactions can be disabled

Respect prefers-reduced-motion media query (WCAG 2.1)

2.4 Navigable

Skip links to bypass repetitive content

"Skip to main content" link at beginning of page

Descriptive page titles

Unique titles help with tab navigation and screen readers

Logical focus order matches visual layout

Tab order follows reading order: top to bottom, left to right

Link text is descriptive (not "click here")

Links must be understandable out of context

Multiple ways to find pages (search, sitemap, navigation)

At least two ways to locate content within the site

Headings and labels are descriptive

Users can understand structure from headings alone

Visible focus indicator on all interactive elements

Never use outline:none without a replacement. Focus must stay visible.

Focused elements are not hidden behind sticky bars

Sticky headers, cookie banners and chat widgets must not fully cover the focused element (WCAG 2.2, criterion 2.4.11, Level AA)

Section headings organize content

Proper heading hierarchy (H1-H6) without skipping levels

2.5 Input Modalities (WCAG 2.1)

Touch targets are at least 24x24 pixels, ideally 44x44

WCAG 2.2 criterion 2.5.8 (Level AA) asks for 24x24 CSS pixels; 2.5.5 asks for 44x44 at Level AAA. Larger targets help people with motor impairments.

Dragging has a single-pointer alternative

Drag-and-drop and sliders can also be operated with simple clicks or taps (WCAG 2.2, criterion 2.5.7, Level AA)

Pointer gestures have simple alternatives

Multi-point and path-based gestures have single-pointer alternatives

Actions can be cancelled or undone

Up-event for activation, abort mechanism available

Visible labels match accessible names

Text in labels is included in accessible name (Label in Name)

Motion actuation has alternatives

Shake-to-undo type features have button alternatives

3.1 Readable

Page language defined in HTML tag (lang="en")

Screen readers then use the correct pronunciation

Language changes in content marked (lang attribute)

Foreign words/phrases have appropriate lang attribute

Clear, simple language used

Explain technical terms, use short sentences, active voice

Abbreviations are expanded on first use

Or provide glossary/definition mechanism

Pronunciation provided for ambiguous words

Mainly for specialized terms and names

3.2 Predictable

No unexpected context changes on focus

Focusing an element shouldn't trigger navigation or popups

No unexpected context changes on input

No auto-submit on selection change, no pop-ups without user action

Consistent navigation across all pages

Menu structure stays the same, recurring elements in same position

Consistent naming for identical functions

Don't call it "Search" on one page and "Find" on another

Help and contact stay in the same place on every page

Repeated help links, contact details or chat appear in the same area of the page (WCAG 2.2, criterion 3.2.6, Level A)

Changes initiated only by user request

Or mechanism to turn off automatic changes

3.3 Input Assistance

Form labels correctly associated with fields

Use for attribute in label matching id in input

Input errors are clearly identified and described

Say "Email address is invalid" instead of only "Error"

Error messages appear near the relevant field

Place them at the affected field, not only at the top of the page

Error suggestions provided when known

Suggest correct format or valid options when possible

Required fields are clearly indicated

Use an asterisk, a text note and aria-required

Form instructions provided before the form

Explain format requirements before users reach the field

Error prevention for important submissions

Add a review step before users submit orders or legal agreements

Submissions are reversible or confirmable

Ability to undo or confirm before finalizing

Context-sensitive help available

Help text, tooltips, or links to help pages near complex inputs

Information already entered is not requested again

Within one process, pre-fill previously entered data or offer it for selection (WCAG 2.2, criterion 3.3.7, Level A)

Password managers and pasting from the clipboard work; image recognition or retyping characters is not the only hurdle (WCAG 2.2, criterion 3.3.8, Level AA)

4.1 Compatible

Valid HTML without parsing errors

Check with the W3C Validator: correct nesting, closed tags. WCAG 2.2 dropped criterion 4.1.1 (Parsing); EN 301 549 V3.2.1 still includes it

ARIA attributes used correctly

aria-label, aria-labelledby, aria-describedby where needed

Semantic HTML elements used

nav, header, main, footer, article, section instead of just div

ARIA roles only when necessary (prefer native HTML)

Use button instead of div role="button". Native HTML is more robust.

Status changes announced (aria-live regions)

Dynamic content updates announced to screen readers

Name, Role, Value for all interactive elements

Buttons, links, form elements must be programmatically determinable

Tested with current screen reader (NVDA, VoiceOver)

NVDA is free. Test complete user flows with it.

Custom components follow ARIA Authoring Practices

Tabs, accordions, modals implemented per WAI-ARIA patterns

No duplicate IDs in the document

Each ID must be unique for proper ARIA relationships

Form elements have accessible names

Every input, select, textarea has an associated label

Modal dialogs trap focus appropriately

Focus stays within modal, returns to trigger on close

Status messages can be programmatically determined

Success/error messages use role="status" or role="alert" (WCAG 2.1)

Recommended testing tools

Automated testing

WAVE browser extension (wave.webaim.org)
axe DevTools browser extension by Deque
Lighthouse, built into Chrome DevTools
Pa11y, a CLI tool for CI/CD integration
Accessibility Insights by Microsoft (Windows)

Manual testing

NVDA, a free screen reader for Windows
VoiceOver, built into macOS and iOS
JAWS, a commercial screen reader for Windows
Keyboard navigation: tab through the entire site
Contrast Checker from WebAIM

Testing tip

Automated tools catch only some accessibility issues. To find the rest, test manually with the keyboard and a screen reader. Always test the critical user journeys, such as checkout, forms and navigation.

Frequently asked questions

What is the European Accessibility Act (EAA)?

The European Accessibility Act (EAA) is EU Directive 2019/882 and has applied since 28 June 2025. It requires businesses to make certain products and services for consumers accessible to people with disabilities. It affects e-commerce websites, banking services and electronic communications in particular.

What WCAG level must I comply with?

The EAA works through the harmonised standard EN 301 549. The legally referenced version is currently EN 301 549 V3.2.1, which builds on WCAG 2.1 Level AA. Version V4.1.1, based on WCAG 2.2, has been published but is not yet cited in the EU Official Journal. Level AAA is not required.

Who is affected by the European Accessibility Act?

The EAA affects B2C companies with e-commerce websites, financial service providers, telecommunications providers, and providers of audiovisual media services. Microenterprises that provide services are exempt under § 3 para. 3 BFSG: fewer than 10 employees and an annual turnover or balance sheet total of no more than EUR 2 million.

What are the four WCAG principles?

WCAG has four principles, known as POUR. 1) Perceivable: information must be presentable in ways users can perceive. 2) Operable: all users must be able to operate the interface components. 3) Understandable: information and operation must be understandable. 4) Robust: content must be robust enough to work with various assistive technologies.

What are the penalties for non-compliance with EAA?

Each EU member state sets its own penalties. In Germany, § 37 BFSG allows fines of up to EUR 100,000 for offering products or services that are not accessible, and up to EUR 10,000 for other breaches such as missing information. The MLBF market surveillance authority in Magdeburg oversees services.

How do I get started with accessibility?

Start with an accessibility audit in an automated tool such as WAVE or axe DevTools. Then test manually with the keyboard and a screen reader. Fix the critical issues first (navigation, forms, images), and use this checklist to track your progress.

Is your website accessible?

We check your website against WCAG 2.2 AA and implement the changes it needs. The initial consultation is free, and afterwards you receive an individual fixed-price quote.

Free Initial Consultation

More Resources

Your browser saves your progress