YarifyStart a conversation

EAA compliance audits, aimed past where the law is today

The European Accessibility Act has been binding since June 2025. The EU's own presumption-of-conformity standard still runs on WCAG 2.1 — but its WCAG 2.2 revision is weeks from the Official Journal. Audit to 2.2 now and don't rebuild your remediation backlog twice.

Scope runs by named product and service category, not by industry

The EAA doesn't regulate "the web" in general — it lists specific product and service categories in its Annex I. If what you build or sell falls into one of these categories, the accessibility requirements apply regardless of whether you think of yourself as a "tech company."

Products

  • Consumer general-purpose computer hardware and operating systems
  • Self-service terminals — payment terminals, ATMs, ticketing and check-in machines
  • Consumer terminal equipment for electronic communications (smartphones)
  • Consumer terminal equipment for accessing audiovisual media (set-top boxes, smart TVs)
  • E-readers

Services

  • Electronic communications services (telephony)
  • Access to audiovisual media services
  • Air, bus, rail and waterborne passenger transport elements — websites, apps, e-tickets, real-time info
  • Consumer banking services
  • E-books and dedicated reading software
  • E-commerce services

E-commerce is explicitly listed

An online store selling to EU consumers is a named service category under Annex I — this isn't an inferred obligation. Directive (EU) 2019/882.

Legacy items get until 2030

Products and services already on the market before 28 June 2025 generally have until 28 June 2030 — but a substantial change resets that clock immediately.

Not every list is exhaustive here

Treat these as representative categories. Confirm your specific product or service against the full Annex I text rather than pattern-matching from a summary table.

The standard regulators check today is still WCAG 2.1

The EAA itself sets functional accessibility requirements, not a specific WCAG version. In practice, conformance is demonstrated through EN 301 549, the harmonized standard that gives "presumption of conformity." That standard hasn't caught up to WCAG 2.2 yet.

In force today

EN 301 549 V3.2.1 (March 2021) incorporates WCAG 2.1 AA by reference. This is what grants presumption of conformity right now. EN 301 549 V3.2.1.

Weeks away

Draft V4.1.0 moves the web, document and software clauses to WCAG 2.2 AA. It went to public comment in November 2025 and is expected in the Official Journal around October 2026. Draft EN 301 549 V4.1.0.

Why audit to 2.2 before it's mandatory

WCAG 2.2 adds success criteria that didn't exist under 2.1 — including target-size minimums, restrictions on dragging-only interactions, focus visibility, and limits on cognitive-function tests in authentication. These typically require actual interface changes, not configuration tweaks. Finding them during your EAA audit now is cheaper than a second remediation pass once V4 is referenced. Understanding WCAG 2.2.

Two different escape routes, easy to confuse

"We're exempt" means something different depending on which provision you're actually invoking. One is a blanket exemption; the other requires ongoing documentation you can produce on demand.

RouteWho can use itWhat it requires
Microenterprise exemptionService providers with fewer than 10 employees and annual turnover or balance sheet under €2 millionNo formal application — but it covers services only, never products the same business manufactures or distributes
Disproportionate burden / fundamental alterationAny business, of any size, for a specific requirementA documented, retained assessment of costs against benefit to people with disabilities — producible to authorities on request, and revisited on relevant change

A product manufacturer with six employees is not exempt just because it's small — the microenterprise carve-out doesn't extend to products, only to services provided by a microenterprise. European Commission — EAA overview.

An automated scan is a starting point, not an audit

Automated tools reliably catch a real slice of issues — missing alt text, insufficient contrast, unlabeled form fields. They cannot evaluate most of what actually blocks a disabled user from completing a task.

Automated scanning

Catches technical, pattern-matchable issues at scale — the fast, cheap first pass, not the whole audit.

Keyboard-only testing

Every interactive element — including custom widgets, modals and drag interactions — must be operable without a mouse.

Screen-reader testing

Real testing with NVDA, JAWS and VoiceOver, not just checking for the presence of ARIA attributes.

Cognitive and authentication review

Checks whether login and verification flows avoid pure memory or puzzle-solving tasks, per WCAG 2.2's new authentication criteria.

Mobile app accessibility

Native iOS and Android accessibility APIs, not just a mobile browser view of the same site.

Document accessibility

PDFs, e-books and downloadable forms checked against PDF/UA and EN 301 549's document clauses, not just the web pages linking to them.

The statement has to map to requirements, not vibes

Article 13 and Annex V require service providers to publish a self-assessment — in general terms and conditions or an equivalent public document — that a regulator or a user could actually check against your interface.

Describe the service

State what the service is and how it works, in plain language a non-expert user can follow.

Requirement-by-requirement mapping

Set out how each applicable EAA accessibility requirement is met — not a single blanket claim of compliance.

Known limitations

Disclose known gaps honestly rather than implying full compliance where remediation is still in progress.

Contact and feedback path

Provide a route for users to report accessibility barriers, and keep it actually monitored.

Product manufacturers face a different mechanism — a formal EU Declaration of Conformity and CE marking under the directive's New Legislative Framework-style provisions — rather than the services-side statement described above. Directive (EU) 2019/882.

Prioritize remediation by what actually blocks a task

A findings list sorted by WCAG success-criterion number is easy to produce and useless to act on. Sort by what stops a real user from completing checkout, booking, or account access.

Blocking issues first

Keyboard traps, unlabeled required form fields, missing focus indicators on the checkout flow, and CAPTCHA or authentication steps with no accessible alternative — fix these before anything cosmetic.

Then structural gaps

Heading structure, landmark regions, reading order and consistent navigation — these compound across every page and are usually cheaper to fix once in a shared component than per page.

Fix components, not pages

Most accessibility debt lives in a small number of shared components — the design system's button, form field, modal and navigation patterns. Remediate the component library first and most page-level findings resolve automatically; remediating page by page just recreates the same bugs in the next new page.

Audit the critical path before the whole site

Prove the process — audit, prioritize, remediate, verify — on the flow that matters most (usually checkout or account access) before spending the same effort across every page on the site.

  1. Confirm scope and exemption status

    Determine which of your products or services fall under EAA Annex I, and whether any qualify for the microenterprise exemption or a documented disproportionate-burden case.

  2. Audit the critical user path

    Combine automated scanning with manual keyboard and screen-reader testing on your highest-value flow, mapped to WCAG 2.2 and EN 301 549.

  3. Prioritize by blocking severity

    Rank findings by whether they block task completion, not by success-criterion number.

  4. Remediate shared components first

    Fix the design-system level patterns that repeat across pages before chasing page-specific findings.

  5. Publish a requirement-mapped statement

    Draft an accessibility statement that maps each applicable requirement to how it's met, with known limitations disclosed.

  6. Re-audit and expand

    Verify the fixed flow, then extend the same process to the rest of the site or app ahead of the EN 301 549 V4 update.

Acceptance criteria for the audit

Manually verified

Every reported finding was confirmed with keyboard and/or screen-reader testing, not just an automated scan output.

Severity-ranked

Findings are prioritized by whether they block task completion, with a clear fix-first list.

Standard-mapped

Each finding references the relevant WCAG 2.2 success criterion and EN 301 549 clause, not a vague category.

Component-first

Remediation targets shared components before page-specific instances of the same bug.

Statement-ready

The audit output supports a requirement-mapped accessibility statement, not just a pass/fail score.

Forward-compatible

The audit checks against WCAG 2.2 now, ahead of EN 301 549 V4's expected adoption.

EAA & WCAG 2.2 FAQ

Is the European Accessibility Act actually mandatory now?

Yes. Directive (EU) 2019/882 has applied to new products and services placed on the market since 28 June 2025 — that date is in the past as of this page's 2 September 2026 review. Products and services already on the market before that date generally get until 28 June 2030 before they must comply, provided they don't undergo a substantial change in the meantime; a substantial change resets that clock.

Does the microenterprise exemption cover our website?

It depends on whether you're a service provider or a product manufacturer. The EAA's microenterprise exemption (fewer than 10 employees and annual turnover or balance sheet under €2 million) applies to service providers only. If your business manufactures or distributes a covered product — self-service terminals, consumer computer hardware, e-readers — the microenterprise exemption doesn't apply to that product line, regardless of your headcount.

Can a larger company just claim 'disproportionate burden' and skip compliance?

No — that's a documented, case-by-case assessment, not a blanket opt-out. A business claiming disproportionate burden or fundamental alteration has to actually perform and retain the assessment, covering costs and benefits relative to the estimated benefit for people with disabilities, and be ready to produce it to a competent national authority on request. It also isn't permanent — a reasonable reassessment cadence, or a trigger like a product/service redesign, is expected to prompt a fresh look.

Should we audit against WCAG 2.1 or WCAG 2.2?

The EU's current presumption-of-conformity route still runs through EN 301 549 V3.2.1, which incorporates WCAG 2.1 AA — that's the version a regulator will check first today. But a draft revision (V4.1.0) moving the standard's web, document and software clauses to WCAG 2.2 AA went to public comment in November 2025 and is expected to be referenced in the Official Journal around October 2026 — a matter of weeks from this page's review date. Auditing to 2.2 now means you're not rebuilding a remediation backlog the moment the standard catches up.

What does an EAA accessibility statement actually need to say?

For services, Article 13 and Annex V of the EAA require you to publish a self-assessment — typically in your general terms and conditions or an equivalent public document — that describes the service, explains how it works, and sets out how each applicable accessibility requirement is met. A vague 'we care about accessibility' paragraph doesn't satisfy this; it needs to map to the specific requirements your service is subject to.

Is an automated accessibility scanner enough to prove compliance?

No. Automated tools reliably catch a meaningful slice of technical issues — missing alt text, contrast ratios, missing form labels — but they cannot evaluate most WCAG success criteria that depend on context: whether reading order makes sense, whether a custom widget is actually operable by keyboard, whether error messages are genuinely understandable, or whether authentication doesn't rely on a cognitive test a screen-reader or low-vision user can't complete. A credible audit combines automated scanning with manual keyboard and screen-reader testing.

What happens to products or services already in the EU market before June 2025?

They get a transition period running to 28 June 2030, but that grace period is conditional, not automatic forever. Self-service terminals lawfully in use before the application date, and service contracts concluded before it, can generally continue under the older terms for a defined period, but a substantial change to the product or service — a redesign, a new major version — is generally treated as bringing it back into full scope immediately rather than at the 2030 deadline.

Primary sources and status

Reviewed 2 September 2026. The EAA (Directive (EU) 2019/882) has applied since 28 June 2025. EN 301 549 V3.2.1, based on WCAG 2.1 AA, was the in-force harmonized standard on the review date; draft V4.1.0, moving to WCAG 2.2 AA, had not yet been finalized or referenced in the Official Journal. WCAG 2.2 itself is a W3C Recommendation, not EU law. Yarify's audit methodology and delivery sequence are engineering recommendations, not legal advice — confirm exemption eligibility and conformity routes with qualified counsel for your specific situation.

  1. Directive (EU) 2019/882 — European Accessibility ActBinding EU directive setting accessibility requirements for the products and services listed in its Annex I, applicable since 28 June 2025
  2. European Commission — European Accessibility ActOfficial Commission policy page summarizing scope, obligations and the Union disability strategy context
  3. ETSI EN 301 549 V3.2.1 (2021-03) — current harmonized standardThe in-force EU harmonized accessibility standard, incorporating WCAG 2.1 by reference, that grants presumption of conformity
  4. Draft ETSI EN 301 549 V4.1.0 (2025-11) — WCAG 2.2 revisionDraft revision that would move the harmonized standard's web, document and software clauses to WCAG 2.2 AA once finalized
  5. W3C — Web Content Accessibility Guidelines (WCAG) 2.2The W3C Recommendation defining WCAG 2.2's success criteria, published 5 October 2023
  6. W3C WAI — Understanding WCAG 2.2W3C's own explanatory guidance for each WCAG 2.2 success criterion, including the criteria new in 2.2

Send us your site, app, or PDF library.

Tell us what you need audited — an e-commerce checkout, a mobile app, a document library — and which flows matter most to your users. We'll scope a manual-plus-automated WCAG 2.2 audit and a remediation plan you can actually work through.