How to Prepare Your Website for the European Accessibility Act

The European Accessibility Act (EAA) is Directive (EU) 2019/882. It covers specified products and services, including e-commerce; it does not automatically impose the same obligations on every website. Start by identifying the service your site provides and the countries where you offer it. Then assess the complete customer journey against the applicable national law and technical requirements, fix barriers in the site itself, and keep records of your work. The general application date was 28 June 2025, but national implementation and transition provisions affect how the rules apply. Read the directive on EUR-Lex and the European Commission’s EAA overview.

1. Check whether the EAA applies to your website

Ask what service customers use the site to access, rather than treating the website itself as the test. E-commerce is expressly covered; examples include online shops and ticketing platforms. A general informational website is not automatically shown to be a covered EAA service by the sources cited here. If your service operates across borders, check the law transposed in each country where it is offered.

List the products or services people can access or buy through the site.
Determine whether each service falls within an EAA category, such as e-commerce.
List the countries where you offer the service and identify the relevant national transposition.
Record the reasoning, applicable dates, and any transition provisions that may apply.
Get legal advice on uncertain scope questions before relying on an interpretation or exception.

The EAA’s general application date is 28 June 2025. The directive also contains transition provisions, so do not assume every existing service has identical treatment from that date. Check the operative national law for your situation. Directive (EU) 2019/882 and the Commission overview describe the framework.

2. Map the entire customer journey

Accessibility can break at any step, including third-party interfaces. Map the tasks customers need to complete, then include every screen, component, and supporting service involved.

Discover the service: landing pages, menus, search, filters, and category pages.
Understand the offer: product or service details, prices, terms, images, and media.
Start and complete a task: registration or guest checkout, forms, consent choices, delivery options, and payment.
Recover from a problem: validation messages, correction paths, expired sessions, and payment errors.
Finish and get help: confirmation, account management, receipts, and customer support.

For each task, note who owns the step, which reusable components it uses, and what happens when a user makes an error or needs more time. Include third-party checkout, consent, chat, and payment components in the assessment. This journey map is an implementation aid; it does not replace checking the detailed requirements in applicable law and standards.

3. Use the EU technical reference carefully

The European Commission identifies EN 301 549 v3.2.1 as the harmonised standard underpinning EU web accessibility requirements. It draws heavily from WCAG 2.1. A WCAG 2.1 Level AA assessment is a useful technical starting point for web content, but saying a site “passes WCAG” does not establish that every EAA duty is met. The EAA also concerns service information and support, and EN 301 549 includes requirements beyond web content. Check the Commission’s current standards guidance before setting your target version, because harmonised references can change.

In practical terms, accessibility includes compatibility with assistive technology such as screen readers and voice control, multiple ways to operate and receive information, logical navigation, enough time to complete tasks, and avoiding flashing content that may trigger seizures. These principles should shape real tasks: find an item, understand its terms, enter details, correct an error, pay, and get help. See the Commission’s accessibility standards guidance and Your Europe’s requirements for services and products.

4. Audit the site and identify barriers

Review both shared templates and task-specific content. A defect in a design-system button may affect every step; a barrier in payment may block the whole purchase. Capture the page, browser and assistive-technology context, the user task affected, and a repeatable way to reproduce each finding.

Review the interfaces people use

Structure and navigation: meaningful headings, landmarks, page titles, link names, and a consistent, logical route through the service.
Keyboard and input: operate the full journey without a pointer; check visible focus, logical focus order, and controls that work with keyboard and voice input.
Forms and errors: programmatically associated labels, clear instructions, understandable validation messages, and a way to find and correct errors.
Perception and resizing: adequate text contrast, content that remains usable when text is enlarged, and information that does not depend on color alone.
Images and media: useful text alternatives for informative images and accessible alternatives for relevant audio or video content.
Timing and motion: enough time to finish tasks, a recovery path when a session expires, and no content that risks triggering seizures.
Documents and support: documents and customer-support routes needed to understand or complete the service.

This is a practical audit list based on the accessibility principles in EU guidance; it is not a substitute for checking each applicable criterion in EN 301 549 and national law.

Use screenshots to document visual context

Screenshots can help teams record a visual barrier, compare a page before and after a fix, or document a component state. They cannot prove keyboard access, screen-reader behavior, correct semantics, or compliance. Store the page URL, date, viewport, and task with each capture so reviewers can interpret it. Use an authorized environment and avoid capturing real customer data or credentials.

5. Test with automation, manual checks, and users

Automated checks can repeatedly find some machine-detectable issues. They do not exercise every customer task or determine whether content and interactions make sense to people with disabilities. Combine automated scans with manual review and representative user testing. The Commission recommends involving people with disabilities; an official Commission portal describes representative-sample review using both manual and automated testing. See the Commission’s web accessibility policy and its portal accessibility statement.

Automated checks: run them against representative templates and critical journey pages, and triage findings rather than treating a score as a verdict.
Keyboard review: complete important tasks without a mouse and check focus visibility and order.
Assistive-technology review: test relevant screen-reader and voice interactions in the browsers and environments your customers use.
Task-based user testing: invite people with disabilities to attempt realistic tasks, including recovery from errors and getting support.
Regression checks: repeat the same tests after changes to shared components, checkout, consent, or other critical flows.

Neither a scanner result nor a single user session guarantees that the service is accessible. Use findings from each method to find and fix root causes.

6. Prioritize fixes and build them into delivery

Fix barriers according to the user task they block. A problem that prevents someone from selecting, understanding, or paying for a service usually deserves attention before a cosmetic issue that does not prevent task completion. This is practical prioritization advice, not a statutory ordering.

Assign each issue an owner, impact, affected journey step, and due date.
Fix shared components at their source so that templates inherit the improvement.
Add accessibility requirements and acceptance criteria to design-system components and release reviews.
Re-test the task that exposed the problem, then check other flows that use the same component.
Track unresolved barriers and decisions so they are visible to product, engineering, content, and support teams.

Do not treat an overlay as a substitute for remediation. The European Commission advises fixing accessibility issues at their source; overlays that do not ensure the underlying site meets detailed criteria are not an appropriate solution. Commission web accessibility policy.

7. Document and maintain your work

Keep an accessible record of your scope assessment, the countries and laws considered, the standard and version used, test sample and methods, findings, fixes, unresolved barriers, owners, and review dates. EU business guidance says service providers should describe how a service meets accessibility requirements and the technical and design procedures used. Also provide a usable way for customers to report barriers, route those reports to someone who can act, and re-test when important flows change. Check the national rules to determine the specific documentation and reporting duties that apply.

Do not assume a public-sector accessibility-statement format automatically defines the exact deliverable for every private EAA service. The Web Accessibility Directive concerns websites and mobile apps of public-sector bodies; the EAA covers specified products and services, including private-sector e-commerce. Check the EAA text and the national transposition for your service. Web Accessibility Directive · European Accessibility Act.

8. Check exceptions before relying on them

Your Europe describes a service-based microenterprise exemption for businesses with fewer than 10 employees and annual turnover under €2 million. It also describes a disproportionate-burden claim that must be supported by evidence and reviewed every five years. These are distinct provisions, not general shortcuts: confirm the exact conditions and process under the national law before relying on either one. Transition provisions may also affect particular services. See Your Europe’s accessibility requirements guidance and the transposed law for each relevant country.

9. Troubleshoot common assessment problems

Problem	Likely cause	What to do
“We have a website, so the EAA definitely applies.”	Scope was inferred from the presence of a website rather than the service offered.	Classify the service and markets, check covered categories and national transposition, and record the reasoning.
“We are informational, so we are definitely exempt.”	An assumption was made without examining the service or national law.	Check whether the site provides a covered service and get advice on uncertain cases.
“The scanner passed, so we are compliant.”	Automated checks were treated as complete coverage.	Add manual keyboard and assistive-technology checks, task-based testing with people with disabilities, and review of service information and support.
“WCAG 2.1 AA is the whole EAA.”	A useful technical starting point was confused with all legal and service obligations.	Check EN 301 549 and the current harmonised reference, plus applicable national requirements and service duties.
“A widget fixed the accessibility issue.”	An overlay was used instead of repairing the underlying markup, content, or flow.	Identify the root cause and fix it in the site or component; verify the task with manual and user testing.
“Our checkout is accessible because the main site is.”	Third-party checkout, consent, payment, or support was left out of the journey.	Test the full journey, including embedded and third-party steps, and coordinate fixes with the component provider.
“We are under the employee threshold, so no review is needed.”	The microenterprise criteria or service-based scope were assumed to apply without checking national law.	Verify employee and turnover criteria, service scope, and the operative local provision before relying on the exemption.

10. Or skip the browser setup

If you need screenshots to document a page or visual change, ScreenshotNeo is a website screenshot API and MCP server for developers. A single GET request returns a screenshot or PDF, and its capture flow can accept cookie and consent banners and remove more than 60 known consent platforms, newsletter popups, and chat widgets. These steps can each be turned off. Screenshots of visual states are supporting evidence; they do not replace accessibility testing.

ScreenshotNeo API documentation

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed; response headers say whether a page was billed and its verdict. The MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Learn about ScreenshotNeo or sign up for 1,000 free screenshots a month, with no card.

FAQ

Does the European Accessibility Act apply to my website?

It depends on the service. E-commerce is expressly covered; a website’s existence alone does not establish that it provides a covered service. Check the relevant national law for each market.

Is WCAG 2.1 AA enough for the EAA?

It is a useful starting point for web content because EN 301 549 v3.2.1 draws heavily from WCAG 2.1. It does not by itself establish that all EAA requirements for the service, information, and support are met.

Do I need an accessibility statement?

Check the EAA provisions and national transposition that apply to your service. Do not assume the public-sector accessibility-statement format automatically applies to every private business.

Are small businesses exempt?

Your Europe describes an exemption for service-providing microenterprises with fewer than 10 employees and turnover below €2 million. Verify that your business, service, and circumstances meet the local legal conditions before relying on it.