Accessibility Compliance Strategy: WCAG, the EAA, and the ADA in Practice

Which standard is the baseline?

Laws rarely write their own technical requirements. They point to a standard. For the web, that standard is WCAG, and the latest version is WCAG 2.2, published as a W3C Recommendation on 5 October 2023; the current version of the Recommendation is dated 12 December 2024 (W3C: WCAG 2.2). Compared with WCAG 2.1, it adds nine success criteria, including criteria on focus not obscured, target size, and accessible authentication, and it removes criterion 4.1.1 Parsing. To review the criteria, see WCAG explained.

For a strategy, that means choosing a target level (in practice, AA) and documenting which version you use. If your client or your law asks for WCAG 2.1 AA, you do not have to move to 2.2 to comply, but your QA team should know the nine new criteria exist and review them.

Which laws look at a product?

It depends on the market. Two cases come up often in a strategy:

EAA. Directive (EU) 2019/882 has applied since 28 June 2025. It covers manufacturers, service providers, importers and distributors that offer certain digital products and services on the EU market, wherever they are based; among them, e-commerce, consumer banking and electronic communications. Microenterprises (fewer than 10 people and turnover up to 2 million euros) get exemptions or limitations, and each Member State enforces the law with its own procedures and penalties (DWT: European Accessibility Act).

The reference technical standard is EN 301 549. Its version 3.2.1 ties compliance to WCAG 2.1 Levels A and AA. On 2 September 2026, version 4.1.1 was published, aligned with WCAG 2.2 Levels A and AA (DWT: EAA ICT standards update). Its main legal effect arrives once it is cited in the Official Journal of the EU, because then it gives a presumption of conformity with the EAA. According to Deque, that citation was expected around 30 November 2026 (Deque: EN 301 549 v4.1.1). Check whether it has happened before you fix your target; at a minimum aim for WCAG 2.1 AA, ideally 2.2 AA.

ADA, Title II. The 2024 DOJ rule sets WCAG 2.1 Level AA as the technical standard for the web content and mobile apps of state and local governments (ADA.gov: Title II web rule). On 20 April 2026 the Federal Register published an interim final rule that moved the dates: 26 April 2027 for entities with 50,000 people or more, and 26 April 2028 for smaller entities and special districts. The calendar changed, not the standard.

This guide does not cover Title III of the ADA, which applies to private businesses and is mostly argued in courts. Do not treat this as legal advice: if your product sells in the US, talk to a lawyer.

How do you organize the strategy?

A useful strategy answers four questions:

1. Which product and which markets? A product that sells in one country has a different list of laws than a global one.
2. Which level and which version? For example, WCAG 2.2 AA as the documented internal target.
3. Who is responsible? Design defines patterns and contrast; development implements semantics and focus; content reviews alt text and messages.
4. How is it verified? Automated checks for what can be measured, manual tests with keyboard and screen readers, and people with disabilities taking part in testing.

Screen reader testing is a part many teams leave for the end. To start, see screen reader testing.

What changes for a designer?

A lot of compliance is decided in design. Color contrast, click target size, focus order, and error messages are visual and content decisions before they are code. A contrast error in one component repeats on every screen where that component appears, so fix it in the design system rather than screen by screen.

It is not all technical either. WCAG criteria on errors, instructions, and help depend on the words. Review how you write an error message and how you describe empty states.

When is a big strategy the wrong choice?

• If your product is a personal site with five pages, an annual audit and a contrast check at each publication are enough. You do not need a committee.
• If you do not know which markets you serve, do not invent a compliance level. Define the legal scope first with someone who knows the law.
• If your team has no workflow for fixing accessibility bugs, a twenty-page strategy stays on paper. Start with a simple process that people actually follow.

Illustrative example

Illustrative example: a software company sells to customers in Spain and the US. Its strategy sets WCAG 2.2 AA as the internal target, notes that the European side falls under the EAA, and records that the US side does not fall under Title II because the company is not a public entity. Design keeps a list of components with verified contrast, development runs a focus review on every pull request, and each quarter the team runs a screen reader test with two users who have visual impairments. When a new rule appears, the document names who reviews it and by when.

Common mistakes

• Treating accessibility as a one-time checklist, with no owner and no review.
• Citing a law from memory without checking the date or the official text.
• Confusing WCAG (a technical standard) with a law (something that is enforced).
• Assuming an automated scanner covers every criterion.
• Leaving components unreviewed, so the same error appears on every screen.

What you can do tomorrow

1. Write down on one page which markets your product serves and which standard you use as the target.
2. Check the contrast and focus states of your three most-used components.
3. Ask your product team for a date for the first screen reader test.

Sources

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI: What’s new in WCAG 2.2
• ADA.gov: Title II web rule (fact sheet)
• Davis Wright Tremaine: European Accessibility Act (digital products)
• Davis Wright Tremaine: European Accessibility Act ICT standards update (September 2026)
• Deque: EN 301 549 v4.1.1 is final