Getting a website audit-ready under the European Accessibility Act is a six-step process: confirm scope, audit against the standard, fix in priority order, publish an accessibility statement, document everything, and keep monitoring. None of the steps requires heroics. And none of them can be replaced by a one-line JavaScript widget.

"Audit-ready" is the right target, and it is worth being precise about what it means: if a market surveillance authority (the public office that checks companies against this law), a customer, or a court asks where you stand, you can answer with evidence. A documented assessment, a prioritized fix record, a published statement. That is a different goal than claiming a perfect site, which essentially no real site is. It is also a more defensible one.

Step 1: Establish scope and obligation

Confirm whether you are in scope at all (our scope guide covers this in detail): can consumers complete a purchase on your site, and are you above the micro-service line (10+ staff or over €2M turnover)? The output of this step is one written sentence: *"We are in scope as an e-commerce service provider; no exemption applies."* That sentence anchors everything downstream, including the accessibility statement.

Step 2: Audit against EN 301 549 / WCAG 2.1 AA

The technical yardstick is EN 301 549, the EU standard for accessible technology, which for web content incorporates WCAG 2.1 Level AA (the widely used checklist of web accessibility rules). Two layers of testing exist, and being clear about the split matters:

  • Automated scanning catches roughly 30–40% of WCAG criteria (source: Deque Systems' Automated Accessibility Coverage Report): contrast, missing alt text, unlabeled controls, structure, page language. These also happen to be the most common failures on real sites, so the automated layer finds a large share of your actual exposure fast.
  • Manual and assistive-technology testing is needed for the rest: focus order, meaningful sequence, complex widgets, how the site actually behaves in a screen reader (the software blind users rely on to read pages aloud).

Start automated (minutes, and it defines the work list), then bring in manual testing for full coverage. Anyone selling an "automated audit = complete conformity assessment" is overselling.

You can run the automated layer right now. Our free website accessibility checker tests one page against WCAG 2.1 AA and shows the score plus the most serious finding with its legal reference.

Step 3: Fix in priority order

Not all findings are equal. The order that reduces real-world exposure fastest:

  1. Anything that blocks a purchase. A checkout you cannot operate by keyboard, unlabeled form fields. These are the failures that most directly harm users and most commonly appear in complaints.
  2. High-frequency easy wins. Contrast, alt text, page language, button names: high-volume issues that are often theme-level fixes scaling across the whole shop.
  3. Structure and navigation. Headings, landmarks, focus indicators.
  4. Edge-case widgets. Carousels, custom date pickers, complex filters.

Step 4: Publish the accessibility statement

In-scope service providers must publish an accessibility statement, in Germany the Barrierefreiheitserklärung. It is a public page that describes how the service meets the requirements, names known limitations, states the legal basis, and (critically) provides a feedback mechanism so users can report barriers. It lives publicly on the site, typically footer-linked next to the Impressum and privacy policy.

For the private sector there is generally no central registry to file it with. You publish it on the service, keep it in your documentation, and the surveillance authority can request it. A missing or boilerplate statement is one of the most commonly cited defects precisely because it is visible in ten seconds of checking. It is also one of the cheapest gaps to close.

If you are writing the statement for the first time, start from the structure. Our accessibility statement generator drafts one from your own details, with every required part including the feedback mechanism, which you then adjust and publish.

Step 5: Document everything

This step is the difference between "we did work" and "we can prove we did work." Keep, in one place:

  • the scope determination (step 1),
  • the audit results, automated and manual, with dates,
  • the remediation log: what was fixed, when, and what is scheduled,
  • any disproportionate-burden assessment, if you invoke that defense,
  • the published statement and its revision history.

Here is why this matters in practice: enforcement in every relevant market runs a graduated procedure, meaning it escalates in stages. Investigation, then a formal request to fix the problems by a deadline, and only then fines. If that letter arrives, a documented audit trail and an in-progress fix plan is good-faith evidence that you are already doing what the letter asks. That is not protection from fines (no documentation is), but it changes the conversation from "violator ignoring the law" to "provider mid-remediation with evidence." Regulators grade those situations differently, and the French Carrefour ruling (Tribunal judiciaire de Caen, 4 June 2026), which gave the company six months under a daily penalty, shows courts also think in fix-by-this-date windows.

Step 6: Monitor continuously

Two things move under your feet: your site (every release, theme update, and new product page can quietly break things again) and the standard (EN 301 549 is evolving toward newer versions incorporating WCAG 2.2). A one-off audit is a snapshot that starts aging the day it is done. Re-scan after fixes to verify them, then keep scanning on a schedule. That recurring evidence trail is itself part of the documentation from step 5.

Why overlays are not a shortcut

You will encounter vendors offering an accessibility "overlay": one line of JavaScript that claims to fix your site automatically. The evidence says otherwise:

  • Overlays do not fix the underlying code, so most WCAG failures remain present for the users and the auditors who look beneath the widget.
  • In 2025, the US FTC took action against accessiBe, the best-known overlay vendor, ordering a $1 million payment over misleading claims that its automated product could make any website compliant with the standard (FTC press release).
  • Accessibility advocates and testing organisations have documented for years that overlays can interfere with the assistive technology real users already run.

The pattern to internalize: if the fix could be a one-liner, the standard would say so. Real fixes happen in your code, CMS, and theme, which is also where they are cheapest at scale, since most shops fail on a handful of repeated, template-level issues.

FAQ

Q: How long does it take to become audit-ready? A: Steps 1, 2 (automated), and 4 fit in the first week. The remediation timeline depends on findings, but because the most common failures are template-level (contrast, alt text, labels), many shops clear the bulk of their exposure within one or two development sprints.

Q: Do we need an external auditor? A: Not legally, for the private-sector self-assessment path. You need a documented assessment against EN 301 549 / WCAG 2.1 AA. Automated tooling plus internal or contracted manual testing is a legitimate way to produce it. What matters is that the evidence exists and holds up.

Q: What goes in the accessibility statement if the site still has known issues? A: Exactly that. Known limitations are a designed-in part of the statement. A statement that names its open issues and remediation plans is more credible (and more useful in a remediation window) than one claiming perfection.

Q: We installed an overlay last year. Are we covered? A: Run an independent scan and see what remains beneath it, typically most of the underlying findings. Treat the overlay as neither fix nor evidence, and budget for actual remediation.

Sources

See where your site stands

A free scan checks your site against WCAG 2.1 AA and shows the first findings in minutes.

Scan your site free Download a sample report

This article is informational and does not constitute legal advice.