What EAA and WCAG 2.1 mean for WordPress sites
Since June 28, 2025, the European Accessibility Act (EAA, Directive 2019/882) has applied to products and services newly placed on the EU market. For a website or web application, that means meeting WCAG 2.1 AA, a W3C standard that defines how digital content should be made perceivable, operable, understandable, and robust. The EAA does not spell out WCAG success criteria itself; it references the European harmonised standard EN 301 549, which currently incorporates WCAG 2.1 Level AA. WCAG 2.2 is now the current W3C recommendation, but the legal floor most WordPress sites are held to today is still 2.1 AA, which is exactly why it is worth understanding on its own terms before moving deeper.
This article is the entry point. It covers who is actually in scope, which exemptions hold up and which do not, what WCAG 2.1 AA looks like on a real WordPress build, and where to go next. Learn more about WordPress development services at WPPoland if you need a team that ships accessible builds, not just audits them.
Two numbers explain why this is not a niche concern. Around 15% of the EU population lives with some form of disability, and a much larger share benefits situationally: older users, people with a temporary injury, anyone on a small screen in bright light. Accessibility work also overlaps heavily with SEO fundamentals - semantic structure, descriptive alt text, and clean markup help search engines and AI answer engines just as much as they help assistive technology. Both threads run through the rest of this guide.
Key dates and who is in scope
The EAA’s effective date is fixed, but “in scope” is not a single yes/no answer - it depends on the product or service category, the contract date, and the type of customer being served. The table below is the practical summary; legal nuance for edge cases belongs with counsel, not a blog post.
| Deadline | What it covers | B2C vs B2B nuance |
|---|---|---|
| 2025-06-28 | EAA accessibility requirements apply to products and services newly placed on the EU market: e-commerce, consumer banking, e-books, electronic communications, audiovisual media access services, and passenger transport interfaces (Annex I) | The e-commerce category is defined around a consumer contract (Article 3(30)); other categories such as banking and electronic communications do not carry that same consumer-only limitation |
| 2025-06-28 to 2030-06-28 | Transitional window: service contracts concluded before 2025-06-28 may continue on their original terms until this date at the latest | Applies regardless of customer type - the trigger is the contract date, not whether the buyer is a consumer or a business |
| Deployment date + up to 20 years | Self-service terminals (ATMs, ticket machines, check-in kiosks) already installed before the deadline can stay in service until end of useful life, capped at 20 years | Mostly a hardware point for physical terminals; rarely relevant to a pure WordPress build unless it drives an in-store kiosk |
| Ongoing, per financial year | Microenterprise reassessment: if a service provider’s headcount or turnover crosses the Article 4(5) threshold, the exemption stops applying from that financial year | Applies to service providers only - product-side obligations were never covered by this exemption, at any size |
| National transposition dates | Most member states transposed on or around the EU date - Germany’s BFSG entered into force the same day, 2025-06-28 - but local enforcement bodies, fine structures, and accessibility-statement rules vary by country | Applies to whichever market the product or service is placed into, not the operator’s country of incorporation |
The practical read: if a WordPress site sells to EU consumers, runs a WooCommerce checkout, or offers a service in one of the Annex I categories, the deadline has already passed and the obligation is live now, not something to plan for “eventually.”
Exemptions and micro-enterprise scoping
This is the section that gets misread most often. “We’re small, so we’re exempt” is a common assumption, and it is wrong more often than it is right. Directive 2019/882 defines several narrow carve-outs, not a general small-business pass.
| Exemption | Who can claim it | Conditions | What it does NOT cover |
|---|---|---|---|
| Microenterprise exemption (Article 4(5)) | Enterprises with fewer than 10 employees AND annual turnover or balance-sheet total under EUR 2 million | Both conditions must be met at the same time; the exemption is lost from the financial year either threshold is crossed | Only exempts services. Product manufacturing, importing, or distributing obligations apply regardless of enterprise size |
| Disproportionate burden (Article 14, Annex VI) | Any economic operator, any size | Requires a documented assessment against the criteria in Annex VI, weighing cost against benefit to users; must be renewed at least every five years and produced to authorities on request | Not a blanket opt-out - the operator still has to apply every requirement that is not shown to be disproportionate |
| Fundamental alteration (Article 14) | Any economic operator, any size | Applies only where meeting a requirement would fundamentally change the nature of the product or service | Rarely applicable to typical WordPress features (navigation, forms, content); more relevant to specialised hardware or bespoke software |
| Pre-existing service contracts (Article 32) | Any size | Service contracts concluded before 2025-06-28 can run on original terms until 2030-06-28 at the latest | Does not extend to new contracts signed after the deadline, even with an existing client |
| Self-service terminals in use (Article 32) | Any size, typically hardware operators | Terminals already deployed before the deadline can continue until end of useful life, capped at 20 years | Does not apply to new terminals purchased or deployed after the deadline |
| Pre-recorded media published before 28 June 2025 (Article 2(4)) | Any size | Time-based media (audio/video) published before the deadline is out of scope retroactively | New pre-recorded media published after the deadline must meet the requirements from day one |
A real scoping call, worked through. Take a WooCommerce shop with four employees and turnover well under EUR 2 million, selling directly to consumers. Under Article 4(5) it is a service microenterprise, so the accessibility obligations for the shopping and checkout service itself do not apply to it. That exemption stops the moment the shop hires a fifth-through-tenth employee and crosses ten, or turnover passes EUR 2 million - there is no grace period written into the directive itself, so the safer planning assumption is to lose the exemption from the financial year the threshold is crossed, not from some later renewal date.
Now change one fact: the same four-person shop, but it operates as a wholesale supplier under a negotiated contract to a larger company, with no direct consumer checkout at all. Two separate things happen here, not one. First, the e-commerce category in the EAA is defined around concluding a consumer contract (Article 3(30), recital 42) - a purely B2B sales channel can sit outside that category on its own terms, independent of the microenterprise exemption. Second, and this is the part that trips people up: being outside the EAA’s own e-commerce obligation does not mean the shop is free of accessibility requirements in that relationship. If the larger buyer is itself subject to EAA, NIS2, or public-procurement accessibility clauses, its own compliance programme can require WCAG-conformant supplier tooling by contract, regardless of whether the supplier is a microenterprise or outside the e-commerce category under EU law. The EAA exemption protects against the EAA’s own enforcement; it does nothing to a customer’s contractual accessibility clause.
This is a factual framing, not legal advice - if a specific classification is disputed or the revenue math is close to the threshold, confirm it with counsel before relying on an exemption in a public statement or a procurement answer.
WCAG 2.1 AA in practice on WordPress
WCAG 2.1 AA is not a checklist you tick once; it is a set of testable success criteria that either pass or fail on a given page, form, or component. Four areas account for most of the real-world work on a WordPress site.
Keyboard operability. Every interactive element - menu, dropdown, modal, carousel control, add-to-cart button - has to be reachable and operable using only Tab, Shift+Tab, Enter, and arrow keys, with a visible focus indicator at every step. This is where page builders and slider plugins fail most often: a slideshow that only advances on mouse hover, or a mega-menu that opens on hover but never on focus, silently locks out anyone who cannot use a mouse. The fix is rarely a rewrite; it is usually adding the missing keyboard event handlers and a visible :focus style with sufficient contrast.
Color contrast. WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text against its background. Brand palettes built for a logo, not for body copy, are the most common failure: a light grey on white that looks elegant in a mockup but fails the ratio for anyone with low vision. Contrast failures are cheap to fix once flagged and expensive to leave unfixed, because they affect every page that inherits the theme’s typography settings.
Forms. Every input needs a programmatically associated label (<label for="id">, not just placeholder text that disappears on focus), every required field needs to announce that it is required, and every validation error needs to be described in text near the field, not conveyed only through a red border. Checkout forms and contact forms are the highest-stakes surfaces here, because a form a screen-reader user cannot complete is a transaction lost, not just a compliance gap.
Media. Video needs captions, audio needs a transcript, and every meaningful image needs alt text that describes its function or content rather than repeating the filename. Decorative images (background textures, spacers) should carry an empty alt="" so assistive technology skips over them instead of announcing noise. This is one of the areas where editorial discipline matters as much as code: a developer can build an accessible image component, but only a trained content editor keeps every new upload compliant.
Common WordPress failure patterns we see in audits
A few patterns recur across nearly every WordPress audit we run, independent of theme or niche. Heading hierarchy breaks first: page builders frequently emit an <h1> or <h2> for every section’s hero text regardless of its actual place in the document outline, so a page can carry five h1 tags and no logical h2/h3 nesting underneath. Screen-reader users navigate by heading structure; a broken outline makes the page far harder to scan than sighted users would ever notice.
Icon-only controls come next - an add-to-cart or search button rendered as a bare icon with no visible text and, often, no aria-label either, leaves assistive technology with nothing to announce. Auto-rotating carousels are a close third: no pause control, no keyboard navigation, and content that changes every four seconds regardless of whether the reader has finished reading the current slide.
The fourth pattern is quieter but just as consequential: cookie-consent banners and newsletter modals that trap keyboard focus. A user tabs into the modal and can never tab back out to the page content, because the developer never wired a focus trap that releases on Escape or on a close action. It is invisible in a mouse-driven QA pass and immediately obvious the first time someone tests with a keyboard only.
None of these are exotic bugs. They are the direct, repeatable output of popular plugins and themes used the way most sites use them, which is exactly why an audit finds the same handful of patterns across unrelated projects. The 2026 compliance stack article walks through the plugin-by-plugin failure list - page builders, WooCommerce templates, slider plugins, form plugins - with the specific WCAG success criteria each one breaks and the concrete fix for each.
Implementation path: audit, remediate, statement, monitor
Turning “we need to comply” into a shipped, defensible result follows the same four-stage path on every project we run.
Audit. Start with a scoped WCAG 2.1 AA review against the site’s actual customer journeys - homepage, navigation, search, forms, and every revenue-critical checkout step - not just an automated scanner run against the homepage. Automated tools (axe-core, Lighthouse, WAVE) catch roughly half of real issues; the rest need a human tester with a keyboard and a screen reader.
Remediate. Fix in the order that protects the highest-value journeys first: keyboard traps and unlabelled checkout controls before cosmetic contrast tweaks on a footer link. One shared-component fix - the theme’s focus style, the form plugin’s label markup - often clears dozens of repeated findings at once, which is why remediation should target shared templates before individual pages.
Publish an accessibility statement. A statement declaring the conformance level, any known limitations, and a working contact channel for accessibility complaints is mandatory under several national transposition laws (Germany’s BFSG among them) and is good practice everywhere else. It also gives procurement teams something concrete to file.
Monitor. Accessibility drifts the moment a new plugin update, a new page-builder template, or a new content editor joins without training. An automated check in CI catches regressions on every deploy; an annual manual re-test catches what automation cannot see.
For the full legal stack - WCAG 2.2’s nine new success criteria, the EAA-BFSG relationship, and the plugin-level remediation detail - read the 2026 compliance stack for WordPress. If you want a scoped, written audit rather than a self-serve checklist, the EU compliance audit for WordPress covers accessibility alongside NIS2/DORA and AI Act exposure in one engagement, with an individual quote based on your site’s actual scope.
Why accessibility overlaps with SEO and AI readability
Most of the technical work behind WCAG 2.1 AA is also, separately, good SEO and good AI-answer-engine hygiene, which is why accessibility budgets are easier to justify than they first appear. A clean, sequential heading hierarchy is exactly what search-engine crawlers and large-language-model summarisers use to understand what a page is actually about; the same fix that helps a screen-reader user navigate a page also helps an AI system extract the right section when answering a query about it. Descriptive alt text does double duty as image-search signal and as a fallback description any AI system reading the page’s markup can use when the image itself is not processed.
Semantic HTML - real <button> and <nav> elements instead of styled <div> soup, proper <label> associations on forms - produces markup that is both accessible and easier for automated systems to parse reliably, whether that system is a screen reader, a search crawler, or a retrieval pipeline behind an AI assistant. None of this is a coincidence: both accessibility and machine-readability standards converge on the same underlying requirement, which is content that carries its own structure and meaning in the markup rather than relying entirely on visual styling. Treating a WCAG remediation project purely as a legal cost misses that a large share of the work pays for itself in organic visibility.
Where to go next
Ready to move past assessment and into action? Contact us to scope an accessibility review for your WordPress site, or start with whichever resource matches where you are:
- Need the deeper legal and technical map, including WCAG 2.2 and the BFSG? Read the 2026 compliance stack article.
- Need a scoped, written audit with a remediation backlog you can hand to a developer? See the EU compliance audit for WordPress.
- Need a team to build the fix, not just diagnose it? Explore our WordPress development services.
