Back to reviews and guides

Designing for EAA Compliance: European Accessibility Act Web Design Best Practices

This article explains how the European Accessibility Act affects web design and maps to standards such as EN 301 549 and WCAG. It gives a practical audit-and-fix checklist, a decision framework for retrofit versus rebuild, testing advice, and common implementation mistakes.

European Accessibility Act Web Design: what this means for teams

The phrase European Accessibility Act Web Design refers to designing websites and web apps so they meet the accessibility obligations the Act sets for products and services sold or supplied in the EU. The Act requires organisations to follow recognised technical standards. That usually means mapping to European harmonised standards and to web accessibility guidance such as WCAG at an appropriate level.

Scope and obligations — which sites and services are affected

The Act covers specific goods and services rather than every single website. Commonly affected services include e-commerce, online banking, ticketing, transport, telecoms services and public-facing digital services offered across EU markets. National laws implemented from the Act set the exact obligations and enforcement mechanisms in each Member State.

How the Act maps to WCAG and technical standards

The European Accessibility Act expects compliance with recognised technical standards. Member States and market practice often use the harmonised European standard EN 301 549 when assessing ICT accessibility. EN 301 549 commonly references Web Content Accessibility Guidelines, which are used to determine success criteria and test methods. For web content, teams typically aim to meet the level that national guidance or procurement requires; many programmes use WCAG level AA as the baseline.

Step-by-step EAA web design checklist

Use this practical roadmap for building or fixing a site so it aligns with EAA expectations. Treat it as a minimum working list you validate against your national rules and a technical standard chosen for conformity.

1. Audit and discovery

  • Run an automated scan to find obvious errors. Use several tools to reduce blind spots.
  • Conduct a manual test for keyboard access, focus order and screen reader reading order.
  • Inventory all document types and media (PDFs, videos, third-party widgets).
  • Gather analytics to find high-traffic pages and high-risk user flows to prioritise.

2. Prioritise fixes with a simple scoring method

Score issues on impact and effort. Use a 1–5 scale for both. Multiply the two scores. Fix items with the highest product first. Focus on tasks that block core tasks such as signing in, buying or booking.

3. Core coding and design changes

  • Use correct semantic HTML elements for headings, lists and tables.
  • Ensure all interactive controls are keyboard reachable and operable.
  • Implement visible focus styles that meet contrast needs.
  • Provide clear, descriptive alt text for images and empty alt for decorative images.
  • Label every form control and associate labels with inputs using label and for or wrapping.
  • Do not use colour as the sole means of conveying information.
  • Ensure colour contrast meets accepted thresholds used by your standard.
  • Use WAI-ARIA only to enhance semantics not to replace native elements.

4. Media, documents and dynamic content

  • Provide captions and transcripts for pre-recorded audio and video.
  • Offer accessible alternatives for PDFs and office documents or publish HTML versions.
  • Ensure dynamic updates announce themselves using live regions or other assistive strategies.
  • Test video players for keyboard control and screen reader access.

5. Forms, errors and transactional flows

  • Give clear error messages and describe how to fix the error.
  • Preserve user input after validation failures.
  • Provide autocomplete where appropriate, and avoid placing essential fields off-screen for assistive tech.

6. Accessibility statement and contact

  • Publish an accessibility statement that lists the standard you used for assessment, known accessibility limitations and a contact method for reporting problems.
  • Include a remediation timeline or note how reports will be handled.

Decision framework: retrofit versus rebuild

Decide by assessing three factors: the site risk, technical debt and business priority. High-risk public services and commerce flows deserve fast remediation. Low-traffic marketing pages may be scheduled into regular releases. Use this quick rule:

  • High risk and high technical debt: plan a rebuild or major refactor.
  • High risk and low technical debt: target urgent fixes and deliver in sprints.
  • Low risk and low technical debt: include fixes in regular backlog grooming.

Common mistakes to avoid

  • Relying only on automated tools. They miss context, focus and complex semantics.
  • Hiding skip links visually so keyboard users cannot use them.
  • Overusing ARIA to patch structural problems instead of fixing underlying HTML.
  • Publishing inaccessible attachments without an HTML alternative.
  • Ignoring mobile and zoom states. Test at 200% text size and on small screens.

Real-world scenario: e-commerce product page checklist

  • Product image alt text describes the product role not only colour: “Black wool coat, knee length, model wearing size M”.
  • Keyboard focus reaches thumbnail carousel, selects image and opens the gallery.
  • Price and availability are in semantic HTML and announced by screen readers.
  • Add-to-cart and quantity controls have accessible names and states.
  • Variant pickers have labels and use aria-checked or native radio inputs.
  • Error messages for required options sit next to the control and reference the input programmatically.

Testing strategy and evidence for conformity

Combine automated tools, manual expert review and user testing with people who have disabilities. Create test cases mapped to the standard you use. Produce an audit report that includes:

  • Scope and sampling method.
  • Pass, fail and partial results mapped to specific success criteria.
  • Remediation recommendations and responsible teams.

Keep evidence for changes and retests. An accessibility statement should link to the audit summary and provide a contact for issues.

Procurement, governance and long-term maintenance

Embed accessibility into procurement documents, acceptance tests and SLAs. Require accessibility training for product teams and QA. Track accessibility debt like any other technical debt and review it in sprint planning.

Bring in legal counsel when contract terms, cross-border sales or public procurement rules create uncertainty. Hire an accessibility specialist for complex widgets, interactive maps, or bespoke design systems. Use external audits as evidence if you expect formal compliance checks by a regulator.

Quick operational checklist you can use today

  1. Run an automated scan on the top 20 pages by traffic.
  2. Manually test keyboard and screen reader on two core user journeys.
  3. Publish or update an accessibility statement with contact details.
  4. Prioritise fixes that block transactions or account access.
  5. Schedule regular audits and at least one round of user testing each year.

Following these steps will align your web design work with the expectations set by the European Accessibility Act and by the technical standards commonly used to demonstrate conformity. For legal certainty, confirm the exact national requirements that apply to your organisation.