WCAG 2.2 and the European Accessibility Act: What Agency Builds Now Need

A client forwards an email from their legal team asking whether the site you built last year meets the European Accessibility Act. You have a contrast checker bookmarked and a vague memory of alt text standards. That is not an answer, and in some markets it is now a commercial risk rather than a best-practice discussion.

The EAA’s obligations applied from 28 June 2025, and the technical standard behind them points at WCAG. This post explains what changed, what WordPress accessibility compliance means in practice for an agency build, which WCAG 2.2 criteria bite hardest on typical client sites, and how to fold the work into your build process without doubling your quotes.

What actually changed

Three separate things landed close together and are frequently confused.

• WCAG 2.2 became a W3C Recommendation in October 2023. It is backwards compatible with 2.1 and adds nine success criteria, mostly around focus visibility, dragging alternatives, target size and reducing cognitive load in authentication and forms.
• The European Accessibility Act (Directive (EU) 2019/882) extends accessibility obligations from the public sector into a defined set of private-sector products and services, with obligations applying from 28 June 2025. It is implemented through each member state’s national law, so the enforcement detail varies by country.
• EN 301 549 is the harmonised European standard that expresses the technical requirements, and it aligns with WCAG Level AA. In practice, building to WCAG 2.2 AA is the route to conformance.

Two clarifications that save a lot of client confusion. First, the EAA covers specific service categories — e-commerce, banking, transport, e-books, telecoms and similar — not literally every website. Second, several national implementations exempt microenterprises providing services, so a ten-person consultancy’s brochure site is in a different position from a retailer’s checkout. Your client’s own counsel decides whether they are in scope. Your job is to be able to say what the site does and does not meet, with evidence.

Note also that the UK is outside the EAA, but the Equality Act 2010 and long-standing public sector regulations already create obligations there, and the US has its own ADA-driven litigation environment. Building to WCAG 2.2 AA satisfies the practical requirement in all three markets.

The WCAG 2.2 criteria that actually affect agency builds

Most of 2.2 is straightforward if you already build to 2.1 AA. These are the ones that most often fail on a real WordPress site.

Criterion	Level	What breaks on typical builds
2.4.11 Focus Not Obscured	AA	Sticky headers and cookie bars covering the focused element
2.5.7 Dragging Movements	AA	Sliders, before/after image widgets, drag-to-reorder UI with no click alternative
2.5.8 Target Size (Minimum)	AA	24x24px minimum — small social icons, pagination, close buttons
3.2.6 Consistent Help	A	Contact or chat entry point appearing in different places across templates
3.3.7 Redundant Entry	A	Multi-step checkout and booking forms re-asking for the same data
3.3.8 Accessible Authentication	AA	Login flows blocking password managers or requiring a cognitive puzzle

Alongside these, the older failures still dominate audits: insufficient colour contrast, images without meaningful alternative text, form inputs without programmatic labels, headings used for size rather than structure, keyboard traps in modals, and carousels that cannot be paused. None of these are hard. They are just invisible to a sighted developer using a mouse.

Where WordPress sites fail most often

• Page builder output. Generic <div> soup with click handlers instead of real buttons and links. Keyboard users cannot reach them and screen readers do not announce them.
• Third-party embeds. Booking widgets, chat bubbles, review sliders and cookie consent banners are frequently the least accessible part of an otherwise clean site — and often the hardest to fix.
• Theme design decisions. Light grey body text on white, a 2px focus outline removed “for aesthetics”, and a mobile menu that traps focus.
• Client-authored content. Decorative images given long descriptions, real content images given none, PDFs uploaded as scanned pictures, and link text that says “read more” fourteen times.
• WooCommerce checkout. Error messages announced only visually, required-field indicators that rely on colour alone, and variation selectors that cannot be operated with a keyboard.

The pattern is clear: accessibility fails at the seams — between your theme, the builder, the plugins and the client’s own editing. Which is why the fix belongs in the build standard rather than in a post-launch audit.

Building it in: a practical process

1. Set the standard in the proposal. Name it: “WCAG 2.2 Level AA, verified by automated and manual testing before handover.” Vague promises create disputes; a named standard creates a scope.
2. Check the design before development. Contrast ratios, focus state designs, target sizes and text-resize behaviour are cheap to fix in Figma and expensive to retrofit in CSS.
3. Use semantic components. Real buttons, real links, real landmarks, one <h1> per page, headings in order. This is theme-layer work and belongs in your WordPress theme development standard, not in a plugin.
4. Constrain the editor. Restrict the colour palette to compliant combinations and prevent heading levels being chosen for size. Building blocks the client cannot misuse — the approach in our post on reusable Gutenberg blocks clients cannot break — removes a whole class of accessibility regressions.
5. Automate the obvious checks. axe-core or Pa11y in CI catches roughly a third to a half of issues. Run it on every template, not just the homepage.
6. Test manually where it counts. Keyboard-only pass on every interactive component, then a screen reader pass on the primary conversion flow with NVDA or VoiceOver. Budget two to four hours for a typical marketing site.
7. Document what you delivered. A short conformance statement listing what was tested, what conforms, what does not, and why — third-party widgets usually live in that last column.

On lead-generation pages the stakes are higher because the form is the product. Accessible labels, error handling and focus management on those pages are part of how we approach landing page development, and the same discipline is covered from a conversion angle in our post on high-converting WordPress landing pages.

What to tell clients about overlays

Someone will suggest an accessibility overlay: one script, instant compliance, a few hundred dollars a year. Be straight with the client. Overlays can offer useful personalisation features, but they do not remediate underlying code, they are not accepted as evidence of conformance under EN 301 549, and they have been a factor in legal complaints rather than a defence against them. Automated tooling of any kind detects only part of the picture, and detection is not repair.

The honest position: use automated tools to find issues fast, fix them in the code, and keep a manual testing pass in scope. If the budget genuinely does not allow full remediation, prioritise the conversion path — navigation, forms, checkout — and document the rest as a roadmap.

Pricing accessibility work

Rough shape, based on how the work divides rather than any published rate card. On a new build, doing it properly from the design stage adds something in the order of 5–10% to the project — mostly design review and manual testing time. Retrofitting an existing site is a different job: an audit plus remediation of a mid-sized site is usually a discrete project, and page builder sites cost more because the fixes reach into generated markup.

Sell the audit as its own deliverable. It gives the client a defensible document, gives you a scoped remediation quote, and avoids the trap of promising conformance for a site you have not examined. Agencies without in-house expertise here often bring in white label capacity for the audit and remediation; the model is set out in our guide to white label WordPress development for agencies.

Frequently asked questions

Does the European Accessibility Act apply to every website?

No. It applies to defined product and service categories such as e-commerce, banking, transport and e-books, and national implementations include exemptions, notably for microenterprises providing services. Whether a specific client is in scope is a legal question for their advisers, not for their web agency.

Is WCAG 2.2 AA the right target for WordPress accessibility compliance?

For almost every commercial client, yes. EN 301 549 aligns with WCAG Level AA, UK and US expectations point to the same place, and 2.2 is backwards compatible with 2.1. Level AAA is rarely required in full and is impractical for most marketing sites.

Can a page builder site be made accessible?

Usually yes, with effort. Modern builders have improved, but generated markup, sliders and pop-ups are common failure points and some fixes require custom code on top of the builder. Expect a higher remediation cost than on a hand-built theme, and test the specific widgets in use rather than trusting the vendor’s claims.

How long does an accessibility audit take?

For a typical 15–25 page marketing site, plan on one to two days for automated scanning plus manual keyboard and screen reader testing of the key templates and flows, and a written report. Larger sites with e-commerce or booking flows take longer because each interactive component needs individual testing.

Who is liable if a client’s site is non-conformant?

The obligation sits with the service provider — your client — but your contract determines what you promised. Never state or imply full conformance for work you have not tested, name the standard you build to, and keep the test evidence. Ambiguity in the proposal is what turns a client’s problem into your problem.

Where to start

Take your two most valuable client sites, run an automated scan, then do a keyboard-only pass through the main conversion flow. You will have a credible picture of exposure within an afternoon, and a reason to talk to those clients before their legal teams do.

If you would like the audit and remediation handled under your brand, send us a site to look at and you will get a scope and timeline back the same business day, under NDA.

You can see how this is priced on the dedicated developer plans page — monthly hour blocks, NDA on every tier, month to month.