WCAG 2.2, BFSG, and the EU Accessibility Act: the 2026 compliance stack for WordPress

#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:

1. Focus Appearance (AA, Level AA in 2.2 only)
2. Focus Not Obscured Minimum (AA)
3. Focus Not Obscured Enhanced (AAA)
4. Dragging Movements (AA)
5. Target Size Minimum (AA, 24 by 24 CSS pixels)
6. Consistent Help (A)
7. Redundant Entry (A)
8. Accessible Authentication Minimum (AA)
9. 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-label but 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 via aria-describedby, required fields use aria-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.

#Applicability triage before an audit begins

Do not begin with a scanner and assume that its result answers the legal question. Begin with a short applicability record owned by the organisation, with legal advice where the classification is uncertain. Record the operator, markets served, service offered, customer type, employee count, turnover or balance-sheet basis used for any microenterprise assessment, relevant contract dates, and every claimed exemption. Site traffic, the number of templates, and the fact that WordPress is used do not decide applicability.

Next, map the actual customer journey. For a WooCommerce business this normally includes search, product comparison, account creation, authentication, basket, checkout, payment hand-off, order confirmation, returns and customer support. Add third-party surfaces such as a payment iframe, booking engine, consent manager, embedded map or downloadable PDF. A homepage-only scan can be clean while a keyboard user remains unable to buy.

The triage should produce three things: a documented scope, a list of assumptions requiring legal confirmation, and a technical inventory for testing. It is not a declaration of compliance. It prevents developers from spending the budget on low-impact template defects while an essential transaction remains inaccessible.

#Build an evidence pack, not a dashboard screenshot

An audit becomes useful when another person can reproduce its findings. Keep an evidence pack under version control or in a controlled document store. For each tested release, it should contain:

• the production URL, build identifier, test date and responsible reviewer;
• the route and component sample, including states that require authentication or form input;
• browser, viewport, operating system and assistive technology combinations;
• automated tool versions and raw exports, rather than only an aggregate score;
• manual keyboard paths, screen-reader observations and zoom or reflow checks;
• each finding mapped to a WCAG success criterion, severity, owner and retest status;
• screenshots or short recordings where they clarify the failure, with personal data removed;
• accepted limitations, third-party dependencies and the decision behind any exception.

Lighthouse or axe percentages can support regression monitoring, but they are not conformance certificates. A useful record shows what was tested, what was not tested and why the reviewer reached the conclusion. That distinction matters during procurement, handover and later remediation.

#Testing and acceptance criteria for a WordPress release

Define acceptance before fixes enter development. Start with representative templates, then test complete tasks. Include the homepage, navigation, search, article, archive, contact form, error page and every revenue-critical WooCommerce step. Add one example of each Gutenberg block, custom component and plugin-controlled interaction that appears in production.

Automated checks should fail on newly introduced detectable violations, invalid landmark structures and regressions in labelled controls. Manual acceptance should verify logical focus order, visible focus, keyboard operation without traps, useful accessible names, error identification and recovery, content at 200 and 400 per cent zoom, reflow at narrow widths, and announcements after dynamic changes. Screen-reader testing should cover the combinations agreed for the audience rather than an arbitrary single device.

A finding is closed only when the fix is deployed to the tested environment, the original reproduction path passes, and a neighbouring path has not regressed. Record residual risk separately. Passing the agreed sample supports a release decision; it does not prove that every future page, upload or third-party update will remain conformant.

#Remediation sequence that protects the buying journey

Sequence work by user harm and dependency, not by the number of scanner alerts. First remove blockers: keyboard traps, inaccessible authentication, unlabelled checkout controls, missing error feedback, time limits without controls and content unavailable to assistive technology. Second, fix shared sources such as the theme header, design-system buttons, form renderer and WooCommerce templates. One component correction can remove hundreds of repeated failures.

Third, address content and document debt, including heading structure, link purpose, alternatives for meaningful images, captions and inaccessible PDFs. Fourth, refine lower-severity presentation issues and advisory improvements. Re-test after each component batch and before release. If a third-party plugin owns the defect, document whether it can be configured, patched, replaced or isolated; merely assigning the ticket to the vendor does not restore the user journey.

#Ongoing governance after remediation

Accessibility is a release discipline, not a one-time project. Give each shared component an owner and accessible acceptance criteria. Add automated checks to pull requests, maintain a small manual regression script for critical journeys, and re-run it when the theme, checkout, consent layer or major plugin changes. Content editors need practical rules for headings, links, images, tables, video and documents, plus a route for questions before publication.

Review the accessibility statement and feedback channel on a scheduled cadence. Log reports, acknowledgement, investigation, resolution and recurring causes without exposing personal data. Quarterly review should look for repeated component failures and supplier risk, while a broader independent review should follow major redesigns or material transaction changes. Governance cannot guarantee permanent compliance, but it makes drift visible and gives the organisation evidence of how issues are managed.

#Turn the findings into a written implementation brief

If you want WPPoland to assess the implementation rather than only explain the rules, use the WordPress accessibility audit service. Send a written brief with the production and staging URLs, target markets, essential customer journeys, WordPress theme and builder, active plugins that render customer-facing interfaces, authentication requirements, planned release date, and any previous report or complaint. Do not send credentials in the first message; identify the protected paths and we can agree a safe access method.

The useful first outcome is a scoped audit and prioritised remediation backlog with reproducible evidence and acceptance criteria. It is not a blanket legal guarantee. Where applicability or an exemption is disputed, keep legal interpretation with qualified counsel and use the technical audit to establish what the product actually does.

#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.

For the legal grounding behind the WCAG layer, EAA and WCAG 2.1, how to implement digital accessibility walks through the directive itself in more depth than the compressed summary above. Once the audit and remediation sequence in this article is underway, the mandatory publication step is the accessibility statement template with EN 301 549 mapping, which maps conformance claims directly to the harmonised standard referenced by the EAA. Operators who need accessibility assessed alongside NIS2/DORA and AI Act exposure in a single engagement should start from the EU compliance audit for WordPress pillar, which scopes all three regimes together.