The WAD, the EAA & Drupal — Now What?
Beyond the June 2025 Deadline: From Mandates to Masterclasses
Mike Gifford
CivicActions · Drupal Core Accessibility Maintainer
Drupal4Gov EU · January 29, 2026 · 17:15–17:35 CET · Brussels, Belgium
20 minutes;
Welcome everyone. Thanks to Drupal4Gov EU for the opportunity to speak. My name is Mike Gifford; I am CivicActions’ Director of Accessibility & the Drupal Core Accessibility Maintainer. Today we will cover what the WAD & EAA mean in practice, how Drupal helps you meet those requirements, and what to do next to stay ahead of evolving standards.
Event: https://drupal4gov.eu/#agenda
Event listing: https://www.drupal.org/community/events/drupal4goveu-2026-01-29
Slides: https://ox.ca/presentations/EAA-drupal4gov-eu26.html
Hook: June 28, 2025 is in the rear-view mirror. If you shipped this morning without WCAG 2.2 checks & service-wide support coverage, you may already be out of step with where EN 301 549 is heading.
Accessibility in the EU
- Government lead the way with the Web Accessibility Directive (WAD).
- To do this a new EU standard needed was built, EN 301 549
- EN 301 549 is an evolving standard based on the W3C Web Content Accessibility Guidelines (WCAG)
- The next release is expected for early 2026 & on the web should mostly align with WCAG 2.2 AA
WAD set the public-sector floor (Directive (EU) 2016/2102). EN 301 549 is the procurement-ready wrapper that turns WCAG into an ICT-wide standard (web, apps, docs, software, support). WCAG remains the normative source for web requirements via EN 301 549’s web clauses (notably the WCAG-mapping section). WCAG 2.2 is already a W3C Recommendation; EN 301 549 revisions are expected to track it in the next cycle, so treat WCAG 2.2 as the direction of travel now, not a future surprise. Emphasize “service-wide compliance”: web + documents + mobile + support channels + procurement, not just homepage scores. References: WAD (EUR-Lex) https://eur-lex.europa.eu/eli/dir/2016/2102/oj/eng ; WCAG 2.2 https://www.w3.org/TR/WCAG22/ ; EN 301 549 library entry https://accessible-eu-centre.ec.europa.eu/content-corner/digital-library/en-3015492021-accessibility-requirements-ict-products-and-services_en
The European Accessibility Act (EAA) & All Things Digital
- The EAA became law in June 2025; 27 member states = 27 enforcement setups
- Fines can reach up to €1M; authorities may monitor compliance
- Microenterprises providing services may be exempt, but verify scope & specifics
- Exemptions are specific: old PDFs, third-party content, archived sites
- If your Drupal site sells a ticket but your help desk is inaccessible, you fail
EAA (Directive (EU) 2019/882) moves accessibility from “public sector obligation” to “single market requirement” for defined products & services (Annex I). The practical trap: teams focus on the website UI & ignore the service boundary. Under EN 301 549 logic, the user’s journey includes PDFs, email flows, identity & payments, call centers, chat, kiosks & support scripts. June 28, 2025 is the application date, but enforcement is national: different authorities, different complaint routes, different penalties, different priorities. Treat exemptions as narrow & documented, not hand-wavy. For the most human-readable overview, see TetraLogical’s explainer (with references back to the Directive): https://tetralogical.com/blog/2025/03/19/understanding-the-eaa/ . References: EAA (EUR-Lex) https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng ; AccessibleEU centre https://accessible-eu-centre.ec.europa.eu ; EN 301 549 entry https://accessible-eu-centre.ec.europa.eu/content-corner/digital-library/en-3015492021-accessibility-requirements-ict-products-and-services_en
Web Almanac 2025 — The Hard Truth
- Lighthouse scores trend up as automation gets easier
- Automated tests only cover a minority of accessibility issues
- Only ~29% of mobile sites pass the Lighthouse color-contrast audit
- The draft 2025 Almanac signals modest movement, not a step-change
- Very few websites in the EU are in compliance with the law
Use Web Almanac data to puncture false confidence. Automated scores improve year over year, but core usability failures remain routine. In the published 2024 Accessibility chapter, the Lighthouse “color-contrast” audit passes on 29% of mobile pages, up from 23% in 2022. That is progress, but it is still failure at internet scale. This is Goodhart’s Law in practice: teams optimize what tools measure. Automation finds patterns; it does not prove task success, comprehension, or low-friction journeys. Label 2025 as draft/preliminary & do not oversell small deltas. References: Web Almanac 2024 Accessibility https://almanac.httparchive.org/en/2024/accessibility ; Lighthouse overview https://developer.chrome.com/docs/lighthouse/overview/
WCAG 2.2 AA: The Practical Upgrade
Better accessibility by removing cognitive barriers to login, making help predictable, improving touch accuracy & ensuring keyboard focus not lost.
- Accessible authentication (3.3.8 AA)
- Consistent help (3.2.6 A)
- Target size minimum (2.5.8 AA)
- Focus not obscured (2.4.11 AA)
Keep this slide concrete: WCAG 2.2 is not abstract. It hits real pain points people complain about. 3.3.8 targets “memory tests” & fragile authentication flows; it matters for MFA, password managers & cognitive load. 3.2.6 stops “help whiplash” by making support predictable. 2.5.8 makes small touch targets less error-prone. 2.4.11 is a direct strike at sticky headers, cookie banners, chat widgets & modals that hide focus. References (exact SC text): 3.3.8 https://www.w3.org/TR/WCAG22/#accessible-authentication-minimum ; 3.2.6 https://www.w3.org/TR/WCAG22/#consistent-help ; 2.5.8 https://www.w3.org/TR/WCAG22/#target-size-minimum ; 2.4.11 https://www.w3.org/TR/WCAG22/#focus-not-obscured-minimum
EAA Reporting
Publish It, Maintain It, Produce It on Request.
- EAA mandates service accessibility information (Article 13 + Annex V): public, accessible, maintained
- Maintain compliance as services change, not just at launch
- Be ready to supply evidence to authorities on request (tests, defects, remediation actions)
- Practical output: a publishable “Annex V page” + a living defect & remediation log (issue queue)
Be precise about terminology. WAD (Directive (EU) 2016/2102) explicitly requires an accessibility statement & the Commission published a model statement (Implementing Decision (EU) 2018/1523). EAA does not reuse the phrase “accessibility statement”, but Article 13 requires service providers to comply with accessibility requirements, document & maintain compliance & provide information in line with Annex V (public, accessible & kept available/updated for as long as the service is offered). This is the part most teams miss. The compliance deliverable is not just “fix bugs”; it is “publish the accessibility information, keep it current & be ready to produce supporting evidence on request.” References: WAD https://eur-lex.europa.eu/eli/dir/2016/2102/oj/eng ; model statement decision https://eur-lex.europa.eu/eli/dec_impl/2018/1523/oj/eng ; EAA (see Article 13 + Annex V) https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng ; human-readable guide https://tetralogical.com/blog/2025/03/19/understanding-the-eaa/
Drupal Is Already a Strong Baseline
- Core culture: accessibility issues are treated as defects, not optional enhancements
- Modern Drupal is built for semantic HTML, keyboard access & accessible theming patterns
- Community commitment: strive to keep up with the latest WCAG (including WCAG 2.2 AA)
- Warning: you can easily break accessibility with themes, content & integrations
This is the “don’t panic” slide. After standards & reporting requirements, decision-makers need to hear: you are not starting from zero. Drupal has an active accessibility team & governance expectations that track the current WCAG Recommendation, including WCAG 2.2. The message is not “Drupal guarantees compliance.” The message is “Drupal reduces the baseline risk if you do not sabotage it with bad themes, inaccessible components, PDFs-as-a-strategy & third-party widgets.” Reference: Drupal accessibility feature page https://www.drupal.org/about/features/accessibility
LocalGov Drupal
Collective Action on Accessibility
- LGD targets WCAG 2.2 AA out of the box; shared patterns reduce risk
- Example: Southwark PDF Importer turns inaccessible PDFs into better HTML
- Drupal community: contribute a11y fixes upstream to Core & contrib modules
- Shared governance means faster remediation aligned with evolving standards
Position LGD as “how public sector executes compliance at scale.” Shared patterns & shared governance reduce duplication, reduce regressions & speed up remediation. The Southwark PDF Importer is the right kind of innovation: shifting from PDF-first publishing to HTML-first, which is usually more accessible & more maintainable. Tie it back to EN 301 549 service-wide thinking: content, templates, workflows & support all matter. References: LGD accessibility target conformance (WCAG 2.2 AA) https://docs.localgovdrupal.org/accessibility/ ; Southwark PDF Importer write-up https://www.drupal.org/about/starshot/initiatives/ai/blog/from-hours-to-minutes-building-an-ai-powered-pdf-importer-for-local-government-for-localgov-drupal ; LGD main site https://localgovdrupal.org
Position LGD as “how public sector executes compliance at scale.” Shared patterns & shared governance reduce duplication, reduce regressions & speed up remediation. The Southwark PDF Importer is the right kind of innovation: shifting from PDF-first publishing to HTML-first, which is usually more accessible & more maintainable. Tie it back to EN 301 549 service-wide thinking: content, templates, workflows & support all matter. References: LGD accessibility target conformance (WCAG 2.2 AA) https://docs.localgovdrupal.org/accessibility/ ; Southwark PDF Importer write-up https://www.drupal.org/about/starshot/initiatives/ai/blog/from-hours-to-minutes-building-an-ai-powered-pdf-importer-for-local-government-for-localgov-drupal ; LGD main site https://localgovdrupal.org
EN 301 549 — The European Wrapper
- Legal benchmark for WAD & beyond; increasingly reused as WCAG-plus for procurement
- Today aligns to WCAG 2.1 AA; next revision is expected to reference WCAG 2.2 — Start migrating now!
- User preferences (Clause 11.7) will likely require respect for personalization (light/dark, reduced motion)
Frame EN 301 549 as the procurement touchstone: it incorporates WCAG for web content & extends beyond it to software, documents, support & operational requirements. The reason to “start migrating now” is simple: if you hard-code WCAG 2.1 AA today, you are purchasing remediation debt the moment EN updates. Use clause-style thinking: user preferences (11.7) forces you to stop overriding OS/browser settings & to design for reduced motion & system color scheme preferences. To stay compliant over time, pair EN 301 549 (requirements) with EN 17161 (process & management approach for continuing conformance). References: EN 301 549 library entry https://accessible-eu-centre.ec.europa.eu/content-corner/digital-library/en-3015492021-accessibility-requirements-ict-products-and-services_en ; WCAG 2.2 https://www.w3.org/TR/WCAG22/ ; EN 17161 entry https://accessible-eu-centre.ec.europa.eu/content-corner/digital-library/en-171612019-design-all-accessibility-following-design-all-approach-products-goods-and-services_en
Frame EN 301 549 as the procurement touchstone: it incorporates WCAG for web content & extends beyond it to software, documents, support & operational requirements. The reason to “start migrating now” is simple: if you hard-code WCAG 2.1 AA today, you are purchasing remediation debt the moment EN updates. Use clause-style thinking: user preferences (11.7) forces you to stop overriding OS/browser settings & to design for reduced motion & system color scheme preferences. To stay compliant over time, pair EN 301 549 (requirements) with EN 17161 (process & management approach for continuing conformance). References: EN 301 549 library entry https://accessible-eu-centre.ec.europa.eu/content-corner/digital-library/en-3015492021-accessibility-requirements-ict-products-and-services_en ; WCAG 2.2 https://www.w3.org/TR/WCAG22/ ; EN 17161 entry https://accessible-eu-centre.ec.europa.eu/content-corner/digital-library/en-171612019-design-all-accessibility-following-design-all-approach-products-goods-and-services_en
AI & Accessibility — Friend or Foe?
- It's both!
- Be proactive and reiterate accessibility requirements in prompts
- Use AI for drafts: alt-text suggestions, structure checks
- Never outsource final judgment; humans feel friction, AI does not
- Keep data local; respect privacy & procurement constraints
- Do manual testing AND testing with users with disabilities
Frame AI as an accelerator for competent teams, not a compliance engine. Good uses: draft alt text (with human review), detect structural issues (headings/labels), assist with remediation triage. Bad uses: “AI will make it compliant.” AI does not experience confusion, vestibular issues, low vision, cognitive load, or the stress of a broken form. It will hallucinate plausible explanations & confident nonsense. Keep the governance message blunt: treat AI as a data handling & procurement decision. Prefer local or controlled deployments where possible; avoid leaking content, user data, or incident details. Caution hard on overlays & “automated remediation” products that promise compliance. References: Web Almanac overlay/automation limits https://almanac.httparchive.org/en/2024/accessibility ; EU-facing commentary example https://www.fondazionelia.org/en/research-and-development/accessibility-overlays-are-not-the-solution-says-the-european-commission/
Strategic Procurement (EN 301 549)
- Mandate Annex V service accessibility info (publishable) & look for WAD-style accessibility statements
- Stop buying debt: require an Accessibility Conformance Report mapped to EN 301 549 before award (OpenACR)
- Mandate the use of open source, with an open issue queue; no fixing bespoke bugs with public money
- Ask for vendor credentials and history, don't accept claims to "know accessibility"
Make procurement do the work. EN 301 549 only matters if you enforce it at contract award & acceptance, not after launch. Require two outputs: (1) a publishable accessibility information page aligned with EAA Annex V (services) & WAD statement requirements where relevant & (2) an evidence package procurement can evaluate (test reports, known issues, remediation plan). ACR/VPAT is a practical supplier reporting format because it has an EN 301 549 edition & forces structured disclosure. Mandate shared patterns (LGD Pattern Library) so councils do not pay repeatedly for the same errors. “Upstream history” means evidence of contributions & maintenance, not claims. If a supplier invokes “disproportionate burden” or “fundamental alteration”, treat it as a controlled process: assess using Annex VI criteria, document it, keep it for five years & repeat for services when altered or at least every five years. References: EAA https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng ; Annex VI (criteria) https://www.legislation.gov.uk/eudr/2019/882/annex/VI ; ITI VPAT/ACR overview https://www.itic.org/policy/accessibility/vpat ; LGD patterns https://patterns.localgovdrupal.org ; human-readable burden summary https://tetralogical.com/blog/2025/03/19/understanding-the-eaa/
What to Do Monday — For Businesses Serving Europeans
- Audit your services against WCAG 2.2 AA; document gaps & known issues
- Publish & maintain your EAA Annex V service accessibility information
- Add or update your Accessibility Statement (helpful, if not required)
- Update procurement: require EN 301 549 evidence, don't accept unsubstantiated claims
- Check national enforcement; do not assume uniformity in application
Make this actionable. Step 1 is an audit, but the output is documentation: known issues + remediation plan. Step 2 is publishing: Annex V service accessibility information must be public & accessible & kept current. Step 3 is WAD hygiene where applicable: accessibility statement + feedback mechanism + enforcement link. Step 4 is procurement alignment: make suppliers show EN 301 549 evidence early. Step 5 is jurisdiction reality: enforcement is national. References: WCAG 2.2 https://www.w3.org/TR/WCAG22/ ; EAA https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng ; WAD model statement decision https://eur-lex.europa.eu/eli/dec_impl/2018/1523/oj/eng ; AccessibleEU hub https://accessible-eu-centre.ec.europa.eu ; human-readable EAA guide https://tetralogical.com/blog/2025/03/19/understanding-the-eaa/
Resources
You can keep the legal links (EUR-Lex) for authority & TetraLogical for readability. Everything else is implementation support.
Handout later: add product-side “economic operator” duties (EAA Articles 7–12) with a checklist format.