How to Test Accessibility Regressions for the European Accessibility Act

To test accessibility regressions for the European Accessibility Act (EAA), first establish whether the product or service is in scope, then map applicable requirements to representative user journeys. Run repeatable automated checks on each release, manually evaluate interaction and understanding, include assistive technology and disabled-user evaluation where appropriate, and record findings and retests. Automated checks can catch regressions, but they do not establish EAA conformity by themselves.

The EAA applies to specified products and consumer services, not every website or business. This guide describes a practical testing program; it is not a legal determination or a universal statutory test script. Confirm your service category, Member State implementation, applicable exceptions, and requirements before treating a workflow as EAA compliance testing.

1. Confirm scope and the applicable requirements

Directive (EU) 2019/882 applies from 28 June 2025 to listed products placed on the market and listed consumer services. Covered service areas include e-commerce, consumer banking, e-books, electronic communications, audiovisual media access, and specified passenger transport functions. Exceptions and transitional provisions apply, so do not assume that a site is covered merely because it is public-facing.

For covered services, Annex I requires websites, related online applications, and mobile-device services to be accessible in a consistent and adequate way by making them perceivable, operable, understandable, and robust. Sector-specific requirements also matter. For example, e-commerce requirements include accessible identification, security, and payment functionality where these are part of the service. Read the directive and applicable national rules rather than relying on a generic website checklist.

Identify the product or service, who provides it, the intended users, and the Member State or States involved.
Determine whether a listed category, exception, or transitional provision applies. Record the basis for your scope decision and have it reviewed by an appropriate legal or accessibility specialist when needed.
Map relevant Annex I obligations and the applicable clauses of EN 301 549 to product surfaces and user journeys. Mark requirements as applicable, not applicable with a reason, or awaiting assessment.
Record the standard version and clause set used for each test. Do not use “WCAG compliant” as shorthand for full EAA conformity.

Directive (EU) 2019/882 is the primary source for scope, requirements, exceptions, and transitional provisions.

2. Check the current standard status before setting your baseline

Standards status is time-sensitive. As of 3 October 2026, AccessibleEU reported that EN 301 549 v4.1.1 was published in September 2026 and adopted WCAG 2.2 as the benchmark for websites, software, and digital documents. AccessibleEU also reported that v4.1.1 had not yet been cited in the Official Journal as the legal EAA reference. Its update identified EN 301 549 v3.2.1 (2021), based on WCAG 2.1 Level AA, as the current reference pending that citation.

Recheck the Official Journal and the relevant national guidance close to publication or assessment. Do not describe WCAG 2.2 as the legal EAA baseline unless the formal reference has changed and you have verified it. The Commission explains that EN 301 549 includes requirements and evaluation methodology beyond WCAG; its standards guidance concerns the Web Accessibility Directive, so use it to understand the broader structure of the standard, not as an EAA legal determination.

Sources: AccessibleEU’s 7 September 2026 update on EN 301 549; European Commission guidance on standards and harmonisation.

3. Build a representative regression suite

There is no universal EAA-prescribed list of regression journeys or cadence. Choose journeys based on the service you provide, the requirements that apply, and the consequences of a barrier. Keep the suite small enough to run regularly and broad enough to cover meaningful tasks and states.

Journey or state	Examples to consider where relevant	Accessibility questions
Access and identity	Sign-in, account creation, identity verification, password reset	Can users operate controls by keyboard? Are labels, instructions, errors, and focus states understandable?
Find and consume	Search, browse, open a document, play or select content	Are structure and names available to assistive technology? Can users find controls and understand status changes?
Forms and recovery	Application forms, booking details, delivery information, invalid input	Are required fields and formats clear? Can users identify and correct errors without losing entered data?
Transactions	Cart, checkout, payment, confirmation, cancellation	Can the whole flow be completed accessibly, including security steps and confirmation?
Help and support	Contact form, help content, service status, support request	Can users locate support and submit or understand a request?
Responsive and alternate states	Mobile layout, zoom, dialogs, loading, empty, error, and success states	Does content remain usable when the layout or state changes? Is focus managed and status communicated?

These are practical examples, not a legal checklist. Select the actual journeys and states your service offers. Include recently changed areas, shared components, and adjacent flows that may be affected by a change.

4. Automate checks that can be repeated

The European Commission recommends testing early and regularly and lists basic checks, automated checks, comprehensive audits, and reporting among its approaches. Put automated checks in the development and release workflow so a change can be compared with an established baseline.

Choose representative pages or application screens and stable test data. Avoid making a single landing page stand in for a multi-step service.
Run automated accessibility checks during development and again against release candidates. Use the same configuration where possible so changes in results are interpretable.
Save findings in a durable format with page or component, rule or requirement mapping, severity, and a link to the relevant code or issue.
Compare results with the baseline. Triage new findings, confirm whether they are real barriers, and avoid treating a tool score as a pass/fail verdict for the whole service.
Keep a manual test layer for requirements and behavior that automation cannot reliably judge in context.

For screenshot evidence of visual states, capture consistent states and viewport sizes, and label each capture with the build, environment, journey, and state. A screenshot can help reviewers compare layouts and visible focus, but it cannot show keyboard order, screen-reader output, accessible names, or whether an interaction is operable. Do not use image comparisons alone as accessibility tests.

5. Evaluate behavior manually and with assistive technology

Manual evaluation should follow the applicable requirements and the task a user needs to complete. At minimum, consider these test dimensions where relevant:

Keyboard: complete the journey without a pointer; check that controls can be reached and activated, focus order makes sense, and focus remains visible.
Labels and instructions: verify that fields and controls have meaningful names, instructions are available when needed, and required formats are clear.
Errors and recovery: submit invalid or incomplete data, identify how errors are announced and associated with fields, and confirm users can correct them without avoidable loss.
Zoom and reflow: inspect content at increased zoom and narrow viewports, including dialogs and transaction steps. Check for clipped content or tasks that require unavailable two-dimensional scrolling.
Contrast and visual meaning: check text, controls, focus indicators, and information conveyed by color against the applicable clauses.
Content and status: check that instructions, headings, feedback, dynamic updates, and completion states are understandable and available to users who do not perceive the visual change.
Assistive technology: test representative journeys with relevant screen readers and other technologies used by your audience. Choose and document a matrix suited to your platforms; the reviewed sources do not prescribe one universal matrix.

Include disabled users or specialist evaluators where possible, especially for high-impact journeys or difficult-to-assess barriers. These checks complement automated tools; they do not replace mapping tests to the current EN 301 549 clauses and applicable Annex I requirements.

6. Make every run traceable

For each test case, retain enough information for another person to reproduce the result and understand its limits. A useful record includes:

Product or service, journey, requirement mapping, and applicability rationale.
Build or release identifier, date, environment, browser or device, viewport, and relevant assistive technology.
Setup and test data, steps, expected behavior, actual behavior, and pass/fail or not-tested status.
Evidence appropriate to the finding, such as a screenshot, recording, accessibility tree detail, console or tool output, and a concise description.
Finding severity and impact, owner, issue reference, remediation, and retest result.
Coverage limits, known barriers, accepted risks, and unresolved questions.

Annex V requires service providers to include information about the service, how it operates, how relevant Annex I requirements are met, and evidence that service delivery and monitoring ensure compliance. Regression records can support this evidence, but the directive does not prescribe a particular checklist or say that test records alone are sufficient. Align the test evidence with the service information and monitoring process.

Source: Directive (EU) 2019/882, Annex V.

7. Run the suite as part of change and release management

A practical cadence follows the risk and pace of change; the reviewed sources establish no universal mandatory interval. Run targeted checks when a shared component or relevant journey changes, and run the representative suite at release boundaries. Schedule broader evaluation when major flows, platforms, or requirements change, and retain a route for reporting barriers found between planned runs.

Before merge: run automated checks and the focused manual checks for the changed component or journey.
On a release candidate: run the representative journey suite, including key error and responsive states.
After remediation: retest the specific issue and rerun adjacent journeys that share the changed code.
At planned review points: revisit scope, standard references, test coverage, assistive-technology choices, and unresolved barriers.

Make release decisions from documented evidence and your organization’s applicable obligations and risk process. A clean automated scan is useful evidence about the checks it ran; it is not a complete conformance finding.

8. Troubleshooting common regression-test failures

Symptom	Likely cause	What to do
A scan passes, but a user cannot complete a task	The check covered detectable markup issues but not the interaction, content, or full journey.	Reproduce the journey manually, inspect focus and assistive-technology behavior, and map the barrier to applicable requirements.
Many new findings appear after a tool or rules update	The scanner, ruleset, or configuration changed, so results are not directly comparable.	Record the tool and ruleset versions; rerun the baseline with the updated setup if practical and triage findings before labeling them regressions.
Tests fail intermittently	Dynamic content, timing, unstable test data, third-party widgets, or inconsistent state may affect the run.	Stabilize fixtures and setup, wait for a meaningful state rather than an arbitrary delay, and preserve failed-run evidence for investigation.
A screenshot diff flags harmless changes or misses a barrier	Rendering varies by font, viewport, animation, or content; many barriers are not visual.	Normalize capture conditions, use visual diffs only as a review aid, and pair them with semantic, keyboard, and assistive-technology checks.
A fix passes on desktop but breaks mobile	The test matrix omitted a responsive layout or platform-specific state.	Add the affected viewport or device journey, then retest shared components at representative sizes.
Findings are closed without confidence in the fix	The issue lacks reproducible steps, expected behavior, or a recorded retest.	Document those details, assign an owner, and keep the finding open until the affected flow is retested.
The team cannot tell which standard a result refers to	Reports use “WCAG compliant” without version or clause mapping.	State the exact standard version, clauses, and applicable requirements used, and recheck the legal reference before publication or assessment.

9. Performance, reliability, and cost considerations

Keep routine automated checks focused on representative pages and changed areas so they can run frequently. Reserve broader manual and specialist evaluation for planned review points and high-impact changes. This is a workflow choice, not a statutory cadence.

Reliability: deterministic fixtures, stable test accounts, documented environment details, and captured failure evidence make results easier to reproduce. Track flaky tests separately from product findings.
Coverage: expand coverage based on risk, service journeys, platforms, and observed barriers. More pages do not automatically mean better coverage if important interactions are omitted.
Cost: include engineering time for triage and remediation, specialist evaluation, assistive-technology coverage, and maintaining test fixtures. An automated tool’s scan price alone does not represent the cost of a useful program.
Evidence quality: preserve test configuration and version information so teams can explain what was evaluated and what remains untested.

Or skip the browser setup

If you need consistent screenshots of pages or visual states for review evidence, ScreenshotNeo is a website screenshot API and MCP server. A screenshot supports visual review; it does not replace keyboard, screen-reader, or other accessibility evaluation. The API supports PNG, JPEG, WebP, and PDF captures, plus options such as full-page capture, CSS selector capture, device viewports, custom CSS, and JavaScript. See the ScreenshotNeo API documentation.

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

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

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

ScreenshotNeo accepts cookie and consent banners like a visitor, then removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots. Every feature is on every plan.

Frequently asked questions

Does a passing automated scan prove EAA conformity?

No. It reports on the checks the tool performed. Conformity assessment needs the applicable requirements and broader evaluation of the service, including relevant manual and service-delivery evidence.

Does the EAA apply to every website?

No. It covers specified products and consumer services and includes exceptions and transitional provisions. Establish scope for the particular service and jurisdiction.

Is WCAG 2.2 the current legal EAA baseline?

As of 3 October 2026, the cited AccessibleEU update said EN 301 549 v4.1.1 adopted WCAG 2.2 but had not yet been cited in the Official Journal for EAA conformity; it identified v3.2.1 (2021) as the current reference. Recheck the Official Journal because this status can change.

How often should a team run regression tests?

The reviewed sources do not set one universal cadence. Run repeatable checks around changes and releases, then set broader evaluation intervals according to service risk, change rate, and applicable obligations.

What evidence should a regression report preserve?

At minimum, preserve the build and environment, requirement mapping, reproducible steps, expected and actual behavior, evidence, owner, and retest status, alongside coverage limits and unresolved barriers.