WCAG 2.2, BFSG, and the EU Accessibility Act: the 2026 compliance stack for WordPress
Three documents define what a WordPress site has to do in 2026 to be legally accessible in the European Union: the W3C’s Web Content Accessibility Guidelines 2.2, the EU’s Accessibility Act (Directive 2019/882), and Germany’s Barrierefreiheitsstärkungsgesetz. They are not interchangeable; they stack. This article is the implementation map.
The piece pairs with the headless WordPress service pillar where the technical surface is described, and with the SEO patterns for headless WordPress checklist where a couple of accessibility patterns also touch SEO.
TL;DR
- WCAG 2.2 is the current W3C Recommendation, published on 2023-10-05.
- The EU Accessibility Act applies from 2025-06-28 in every member state.
- Germany’s BFSG implements the EAA into federal law on the same date.
- Microenterprise carve-outs exist but are narrower than people assume.
- Fines under BFSG paragraph 37 reach the upper five-figure euro range.
The three layers, in order
Three legal and technical layers stack to define the site’s obligation:
Layer one, WCAG 2.2 (technical). The set of measurable success criteria that define accessible web content. Authored by the W3C Web Accessibility Initiative. WCAG 2.2 was first published as a W3C Recommendation on 2023-10-05 (the current published version on www.w3.org/TR/WCAG22/ is dated 2024-12-12) and adds nine new success criteria over WCAG 2.1, including focus appearance, dragging movements, and consistent help.
Layer two, the European Accessibility Act (EU). Directive 2019/882, adopted in 2019, applying from 2025-06-28. It defines which products and services must be accessible and references the EN 301 549 European standard, which incorporates WCAG by reference. The EAA does not say “follow WCAG 2.2” word for word; it references the European harmonised standard, which currently incorporates WCAG 2.1 Level AA. National transpositions can require WCAG 2.2.
Layer three, national transposition (member state). Each member state passes its own law to transpose the EAA. Germany’s is the BFSG, in force on the same date as the EAA application date. Other member states transpose with similar names and similar (sometimes higher) requirements. The site has to comply with the transposition law in every market it sells into, not only the country of incorporation.
The order matters. WCAG is the technical bar. The EAA is the legal envelope at EU level. The national law is the local enforcement instrument. Audits go in this order: technical first, legal next, local last.
What WCAG 2.2 actually requires
WCAG 2.2 has 86 success criteria across 13 guidelines under 4 principles (Perceivable, Operable, Understandable, Robust). Three levels: A, AA, AAA. The legal and contractual default is AA. AAA is aspirational and not always practical for content-heavy sites.
The nine new criteria in WCAG 2.2 over WCAG 2.1:
- Focus Appearance (AA, Level AA in 2.2 only)
- Focus Not Obscured Minimum (AA)
- Focus Not Obscured Enhanced (AAA)
- Dragging Movements (AA)
- Target Size Minimum (AA, 24 by 24 CSS pixels)
- Consistent Help (A)
- Redundant Entry (A)
- Accessible Authentication Minimum (AA)
- Accessible Authentication Enhanced (AAA)
For a WordPress site that already aimed at WCAG 2.1 AA, the practical work in 2026 is verifying the nine new criteria, with target size and dragging movements being the most common gaps (small clickable icons, drag-only sliders).
EAA: scope, exemptions, deadlines
The EAA covers a defined list of products and services placed on the market from 2025-06-28. The list relevant to most WordPress operators:
- Consumer banking services.
- E-books and dedicated e-reading software.
- Electronic communications services.
- Audio-visual media access services.
- Passenger transport services (web and mobile interfaces).
- E-commerce services (the catch-all for most WooCommerce stores).
The directive defines microenterprise exemptions: fewer than 10 employees AND annual turnover or balance-sheet total under EUR 2 million. These exemptions apply to service providers; the threshold for product manufacturers is stricter. The common misreading is “small site, no rules”; the actual rule is “small operator, narrower obligation, narrower exemption.”
Transitional period: service contracts concluded before 2025-06-28 may continue under pre-EAA terms until 2030-06-28 at the latest. Self-service terminals already in use can continue until end of useful life, with a hard ceiling of 20 years.
BFSG: the German implementation
Germany passed the Barrierefreiheitsstärkungsgesetz (Accessibility Strengthening Act) to transpose the EAA. It came into force on 2025-06-28.
Three things the BFSG adds beyond the EAA baseline:
One, federal-level enforcement. The Bundesanstalt für Arbeitsschutz und Arbeitsmedizin and federal market surveillance authorities supervise compliance. Member-state structures vary; in Germany, federal supervision is the mechanism.
Two, fine structure (paragraph 37, BFSG). Penalties for non-compliance are defined in BFSG paragraph 37. Specific infraction types attract fines in the upper five-figure euro range per infraction. Repeated or systemic non-compliance compounds.
Three, accessibility statement requirement. The site must publish an accessibility statement linked from a discoverable place (footer is conventional). The statement declares the conformance level, the exceptions claimed, and a contact mechanism for accessibility complaints.
Operators that sell into Germany without German incorporation are still subject to the BFSG when their products or services are placed on the German market. The “I’m not a German company” defence does not exist.
What this means for a WordPress site
The implementation work breaks into four columns.
Theme and core. Pick a theme tagged accessibility-ready on WordPress.org and verify against WCAG 2.2 AA. Audit the WordPress admin, not just the front-end; the BFSG covers the user interface employees use too if they are subject to inclusive employment requirements. WordPress core is generally accessibility-aware (the Accessibility team is active) but plugins and custom code regularly break the bar.
Plugins. Audit every active plugin’s front-end output. Concrete failure patterns we have seen audit after audit:
- Page builders (Elementor, Divi, WPBakery): emit
<h1>for hero text on every section, breaking heading hierarchy. WCAG 2.4.6 (Headings and Labels) and 1.3.1 (Info and Relationships) both fail. Fix at theme template level by overriding heading levels, or move to block editor where heading levels are explicit per block. - WooCommerce default add-to-cart on archives: the icon-only add-to-cart has
aria-labelbut no visible text and the focus indicator from many themes is invisible. WCAG 2.4.7 (Focus Visible) and 2.5.8 (Target Size Minimum, 24 by 24 CSS pixels in WCAG 2.2) often fail together. Fix: increase the clickable region to 24×24 minimum, add a visible focus ring at 3:1 contrast, restore visible text on archives where possible. - Slideshow plugins (Slick, Owl Carousel, MetaSlider, Smart Slider): keyboard navigation broken (no arrow-key support), no pause control on auto-rotating slides. WCAG 2.2.2 (Pause, Stop, Hide) and 2.1.1 (Keyboard) fail. Fix: replace with a static image grid where possible; if slideshow is required, add visible pause and previous/next buttons with proper labels and keyboard handlers.
- Form plugins (Contact Form 7, Gravity Forms, Ninja Forms): skip
<label for>associations and use placeholder text as the only label. WCAG 1.3.1 and 3.3.2 (Labels or Instructions) fail. Fix: every input gets an explicit<label for="id">, error messages connect viaaria-describedby, required fields usearia-required="true".
Audit the admin too if non-developer staff use it.
Content and editorial discipline. WCAG enforcement at the editorial level requires standing rules: every image needs alt text, every link needs descriptive text (not “click here”), every heading hierarchy is sequential, every video has captions, every PDF embedded in a page is itself tested. The CMS makes the technical compliance possible; the editorial team makes it actually happen.
Accessibility statement and complaint mechanism. The statement is mandatory in Germany under the BFSG. The complaint mechanism (a contact email or form) must be functional, not vestigial. Complaints about accessibility have to be acknowledged and addressed within reasonable time.
Why headless WordPress is not automatically accessible
A headless WordPress build with an Astro or Next.js front does not inherit accessibility from the WordPress origin. The front-end framework is responsible for the rendered HTML, the keyboard interaction model, the focus management, and ARIA semantics. Picking the right framework helps (both Astro and Next.js have strong accessibility communities), but the work has to be done explicitly.
Per our current Tech Radar opinion, Astro 5+ and Next.js 15 are both in the Adopt ring. Neither is automatically WCAG 2.2 compliant. The accessibility audit is a separate work-stream from the framework selection.
The headless build does buy one thing: per-route control over the rendered HTML, which makes accessibility patches landable and predictable. A monolithic WordPress build mediated through a heavy page builder is harder to remediate when the builder is the source of inaccessible markup.
Audit cadence and tooling
Two audits, two cadences:
Automated, every CI run. axe-core or pa11y running against a representative sample of routes. Fails the build on any new violation. Catches roughly half of WCAG issues; misses the half that requires human judgement (alt-text quality, focus order intent, ARIA landmark intent).
Manual, annually plus on major change. Trained accessibility tester running a full WCAG 2.2 AA audit with assistive-tech testing (screen reader, voice control, keyboard-only). The output is a gap report keyed to specific success criteria.
A site that runs only the automated audit is not WCAG 2.2 AA conformant. A site that runs only the manual audit drifts between annual reviews. Both are necessary.
Where this fits
This pillar anchors to the headless WordPress service cluster as the compliance dimension. For framework selection see the Next.js vs Astro decision matrix. For SEO migration risks (some accessibility patterns also affect SEO, particularly heading hierarchy and link text) see the SEO patterns checklist. For NIS2 and DORA compliance which often appear in the same procurement scorecard, see the dedicated NIS2 and DORA on WordPress article.
