Back to reviews and guides

How to Audit Your Website for European Accessibility Act Compliance

This article gives a practical, step-by-step audit process to check your website for likely European Accessibility Act obligations. It covers scoping, standards to use, automated and manual tests, evidence to collect, prioritisation, common mistakes and reporting templates.

How to Audit Your Website for European Accessibility Act Compliance is a practical checklist for teams that must make digital services accessible under the European Accessibility Act. Read this if you need to decide scope, run tests, and produce an audit report your legal or procurement team can use.

Does the European Accessibility Act apply to your website?

First, decide whether the EAA likely covers the site. The Act targets specified products and services placed on the EU market. Ask simple questions.

  • Do you sell goods or services covered by the EAA, such as e-commerce, banking, transport booking, or digital content?
  • Is your organisation providing those services to customers in an EU country?
  • Is the site public-facing for sales, account management, ticketing, or customer information?

If the answer is yes to one or more, plan a compliance audit. If unsure, document your risk assessment and consult legal counsel. This article focuses on audit steps and evidence you will need.

Which standards and rules to reference

Use recognised technical standards as the audit baseline. Common references are the Web Content Accessibility Guidelines (WCAG) and the European standard EN 301 549. Use WAI-ARIA where interactive widgets require semantics for assistive technology.

  • WCAG 2.1 and WCAG 2.2 are widely used as technical success criteria.
  • EN 301 549 is a European standard that maps to WCAG criteria and is commonly cited in procurement and accessibility requirements.
  • Record which versions you used and why. That matters for evidence and future audits.

Step-by-step audit process

Follow a repeatable sequence. Each step produces evidence you keep in the audit record.

1. Scoping

  • List all domains, subdomains and hosted services used for the customer journey.
  • Identify pages and features in scope. Example: checkout, account pages, help centre, PDFs and downloadable files.
  • Note any third-party components you cannot change, for example a payment widget or embedded app.

2. Create acceptance criteria

Define which WCAG level or EN 301 549 clauses you will test against. Be specific. For each page type list the key success criteria.

3. Automated scanning

Run automated tools to find obvious failures. Automated checks cover roughly 20 to 40 percent of WCAG checks, but they are useful to find systemic issues fast.

  • Scan each URL set defined in scope.
  • Export results and group by issue type and frequency.

4. Manual testing

Manual checks are essential. Automated tools miss context, navigation structure and dynamic content problems.

  • Keyboard-only navigation. Test full user journeys without a mouse.
  • Screen reader testing. Use at least one native screen reader and one browser-based screen reader.
  • Colour contrast and text sizing. Verify with tools and by inspection.
  • Form labels, error identification and instructions.
  • PDF and downloadable document accessibility.

5. Assistive-technology verification

Test real assistive technologies. At minimum include a screen reader and keyboard-only navigation. If the site is heavily interactive, add a screen magnifier and voice-control test.

6. Mobile testing

Test the mobile site and mobile web apps. Check touch target sizes, viewport scaling, and on-screen form controls.

7. Compile findings and evidence

For each finding record the URL, a short description, the failing success criterion, screenshots, screen reader audio or transcripts, and steps to reproduce.

Test cases mapped to common WCAG checks

Use this short table when you write the audit checklist to ensure coverage of core requirements.

Test area Example checks Common WCAG references
Non-text content All images have meaningful alt text; decorative images marked empty 1.1.1
Keyboard access All interactive elements reachable and actionable by keyboard 2.1.1
Focus visibility Focus indicator is visible when tabbing through controls 2.4.7
Colour contrast Text contrast meets AA thresholds against background 1.4.3
Structure & semantics Headings used for document structure; ARIA only where needed 1.3.1; WAI-ARIA

Practical tools: automated, manual and assistive tech

  • Use at least one automated scanner for bulk checks and a developer extension for page-level review.
  • Use a screen reader such as NVDA or VoiceOver. Test with keyboard only.
  • Use a contrast analyser and mobile device emulation for responsive checks.

Information gain: how to decide which pages to test first

Start with pages that drive business outcomes. That reduces legal and commercial risk quickly.

  • High priority: checkout, login, account management, booking flows.
  • Medium priority: product pages, search, content that attracts high traffic.
  • Lower priority: marketing landing pages without critical actions.

This prioritisation helps you show rapid improvements where they matter most.

How to grade and prioritise audit findings

Use three simple labels so stakeholders can act fast.

  • High: prevents core task or exposes legal risk. Fix quickly.
  • Medium: degrades experience or blocks some assistive tech. Schedule in next sprint.
  • Low: cosmetic or rare edge cases. Track for backlog grooming.

Include a cost estimate and test steps for each item. That helps developers plan fixes without repeated questions.

Common mistakes teams make under the EAA

  • Testing only with automated tools and assuming the site is compliant.
  • Missing third-party components placed into scope without vendor guarantees.
  • Failing to version-control acceptance criteria so the audit becomes stale.
  • Delivering a list of issues without reproduction steps or proof of failure.

How to document compliance and keep evidence

Good evidence reduces dispute and speeds approval. Store evidence in a secure repository and link it from the final report.

  • For each issue include URL, date, browser, assistive tech used, screenshots and a short video or audio where relevant.
  • Note the exact success criterion that failed and reference the standard version used.
  • Keep change logs and regression test notes after fixes are deployed.

Consider external auditors when you need independent evidence for procurement, cross-border compliance, or litigation. Engage legal counsel if you face a formal complaint or need clarification on whether the EAA applies to a particular service.

Report template: what to include in the audit deliverable

  • Scope and definitions, including standards and versions used.
  • Methodology with tools and assistive tech listed.
  • Priority-ranked findings with evidence and remediation steps.
  • Acceptance criteria for each fix and plan for regression testing.
  • Executive summary that states residual risk and recommended next steps.

Next steps for teams after the audit

Schedule remediation sprints, confirm third-party fixes and set a date for a follow-up audit. Keep the audit record for procurement and compliance checks.

An audit is a process, not a one-off task. Use this checklist to make your evidence clear and your fixes effective. If you need a printable checklist or sample report sections, create one from the test cases and evidence fields above.