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 · 10:35am, January 29, 2026, Brussels, Belgium
20 minutes total. Set expectations: law moved, deadlines passed, now it is about operational maturity.
Purpose: Frame the talk as “what changes Monday morning,” not a legal lecture.
- June 28, 2025 is past. The risk now is false confidence and operational debt.
- Define scope: WAD (public sector), EAA (market-facing services), EN 301 549 (procurement standard that wraps
WCAG for ICT).
- Promise: practical actions for Drupal owners, procurement teams, and service managers.
Event: https://drupal4gov.eu/#agenda
Drupal event listing: https://www.drupal.org/community/events/drupal4goveu-2026-01-29
Slides: https://ox.ca/presentations/EAA-drupal4gov-eu26.html
Accessibility in the EU
- Governments led the way with the Web Accessibility Directive (WAD).
- This drove a procurement-ready standard: 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. EN 301 549 is how procurement makes WCAG enforceable across ICT, not just web
pages. WCAG 2.2 is already a W3C Recommendation.
Claims behind the bullets:
- WAD (Directive (EU) 2016/2102) established baseline requirements for public sector websites
& mobile apps and required an accessibility statement & feedback mechanism.
- EN 301 549 is the harmonized European accessibility standard used for ICT procurement,
mapping WCAG for web content and extending requirements to software, documents, support, and services.
- WCAG is the normative W3C standard for web accessibility; WCAG 2.2 is a W3C Recommendation
and is the practical direction of travel for web requirements.
- When you buy services, you must cover the whole service boundary: web, documents, apps, support, and
operational processes.
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 (AccessibleEU 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 started applying June 28, 2025; enforcement is national
- Penalties vary by member state; assume scrutiny & complaint-driven enforcement
- 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 applies from June 28, 2025. Enforcement is national, so risk varies by country. Emphasize service boundary:
web plus support channels, docs, and flows.
Claims behind the bullets:
- EAA (Directive (EU) 2019/882) applies to specified products & services and shifts
accessibility into a single-market obligation beyond government.
- Enforcement is implemented by member states, so authorities, processes, penalties, and complaint mechanisms
differ.
- Microenterprise exemptions exist in the directive, but they are not a free pass. Teams need legal review of
scope and national transposition rules.
- Exemptions are narrow and must be documented. Do not treat them as a strategy.
- Service accessibility means the complete user journey, including support and off-site steps. If support is
inaccessible, the service fails users.
References:
- EAA (EUR-Lex): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32019L0882
- AccessibleEU hub: https://accessible-eu-centre.ec.europa.eu
- EN 301 549 (AccessibleEU library entry):
https://accessible-eu-centre.ec.europa.eu/content-corner/digital-library/en-3015492021-accessibility-requirements-ict-products-and-services_en
- Readable explainer with references: https://tetralogical.com/blog/2025/03/19/understanding-the-eaa/
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
- Compliance remains low, especially across critical user journeys
Use Almanac to puncture “we got a score” thinking. Automation improves; real accessibility is still low. Mention
that automated testing covers a minority of issues.
Claims behind the bullets:
- Lighthouse and similar tools are improving and easier to run at scale, which drives score improvements.
- Automated checks identify patterns, but they cannot validate task completion, comprehension, or user journey
friction.
- The Lighthouse color-contrast audit pass rate has been historically low at internet scale; use it as an
example of persistent baseline failures.
- If you only test pages, you miss services: login, payments, identity, support, and documents.
References:
- Web Almanac 2024 Accessibility chapter: https://almanac.httparchive.org/en/2024/accessibility
- Lighthouse overview (what it is, what it measures): 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 it concrete: WCAG 2.2 targets real pain points (auth, predictable help, touch targets, focus visibility). Tie
each bullet to an everyday failure people complain about.
Claims behind the bullets: WCAG 2.2 AA adds or strengthens success criteria that address
frequent, practical usability failures.
- Accessible Authentication (3.3.8) reduces “memory tests” and fragile login flows that
create barriers for cognitive disabilities and many everyday users.
- Consistent Help (3.2.6) prevents support options from moving unpredictably across pages and
steps.
- Target Size (2.5.8) reduces touch errors for mobility limitations and situational use.
- Focus Not Obscured (2.4.11) targets sticky UI, overlays, and widgets that hide keyboard
focus and break navigation.
References (W3C):
- 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) is public, accessible & maintained
- Compliance needs to be updated 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)
Key message: publishing accessibility info is not optional paperwork. It is required, must be maintained, and you
must be able to produce evidence on request. “Issue queue” is the living log.
Claims behind the bullets:
- EAA obligations include public accessibility information for services and maintaining that information over
time (see Article 13 & Annex V).
- Compliance is ongoing. Releases, content changes, integrations, and support changes can introduce new
barriers.
- Authorities may request evidence. Teams should be ready with test results, known issues, remediation
actions, and timelines.
- A practical operational approach is: (1) an “Annex V” information page (public-facing) and (2) a defect
& remediation log (internal, but auditable).
References:
- EAA (Article 13 + Annex V): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32019L0882
- WAD (accessibility statement requirement): https://eur-lex.europa.eu/eli/dir/2016/2102/oj/eng
- WAD model statement (Implementing Decision (EU) 2018/1523):
https://eur-lex.europa.eu/eli/dec_impl/2018/1523/oj/eng
- Readable explainer with references: 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
“Drupal helps but does not guarantee compliance.” Emphasize culture: treat a11y as defects. Then warn: themes,
content, and third-party widgets can break everything.
Claims behind the bullets:
- Drupal has an established accessibility practice and community norms that treat accessibility as a quality
requirement.
- Core supports semantic HTML and accessible patterns, but implementers can break them through custom themes
and components.
- Real compliance is end-to-end: content authoring, editorial workflow, templates, and integrations.
- Position Drupal as a risk reducer and a better default starting point, not a compliance certificate.
References:
- Drupal accessibility feature page: https://www.drupal.org/about/features/accessibility
LocalGov Drupal
Collective implementation reduces risk.
- LGD targets WCAG 2.2 AA out of the box; shared patterns reduce risk
- Southwark PDF Importer turns inaccessible PDFs into better HTML
- Community contributes a11y fixes upstream to Core & contrib modules
- Shared governance = faster remediation aligned with evolving standards
- This is what procurement should buy: shared patterns & upstream fixes
LGD is the “compliance at scale” story: shared patterns, shared governance, upstream fixes. Use Southwark PDF
Importer as a concrete example of moving from PDFs to HTML.
Claims behind the bullets:
- LocalGov Drupal (LGD) aims for WCAG 2.2 AA as a shared target, reducing duplication and lowering regression
risk.
- Shared pattern libraries and governance reduce “every council re-invents the same mistakes.”
- Upstream contributions spread fixes across the ecosystem instead of trapping them in one deployment.
- The Southwark PDF Importer is an example of shifting toward more accessible, maintainable publishing by
producing better HTML from PDFs.
References:
- LGD accessibility targets: 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
- LocalGov Drupal: https://localgovdrupal.org
EN 301 549 — The European Wrapper
- Legal benchmark for WAD & beyond; reused as WCAG+ for procurement
- Today aligns to WCAG 2.1 AA; next revision is expected to reference WCAG 2.2 — Start migrating now!
- Clause 11.7 may require respecting user preferences
- Do not override platform settings (theme, contrast, reduced motion & text size)
EN 301 549 is the procurement standard. It is broader than WCAG. Clause 11.7: user preferences must be respected.
Make it an acceptance test: prove you do not block platform settings.
Claims behind the bullets:
- EN 301 549 is used as the procurement and conformance reference for ICT accessibility and
includes WCAG mapping for web content plus additional requirements.
- Even if your current baseline is WCAG 2.1 AA, planning for WCAG 2.2 reduces future remediation debt as EN
301 549 revisions evolve.
- Clause 11.7 addresses user preferences. In practice, implementations should not block
relevant operating system or browser accessibility settings.
- This is enforceable through procurement: specify supported preferences and test them during acceptance, not
after launch.
References:
- EN 301 549 (AccessibleEU 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 (Design for All process standard):
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
- ETSI revision context:
https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility
AI & Accessibility — Accelerator or Liability?
- 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
AI is useful for drafts and triage, not compliance. Make the risk explicit: hallucinations and lack of lived
experience. Keep data local when required. Always include user testing.
Claims behind the bullets:
- AI can accelerate competent teams by generating drafts (alt text, summaries, structural checks) and helping
triage defects.
- AI cannot substitute for human judgment or user testing because it does not experience friction or
disability-related barriers.
- Data handling matters: privacy, procurement constraints, and security requirements can prohibit sending
content to external tools.
- Maintain manual testing and include users with disabilities to validate real tasks and journeys.
References:
- Web Almanac 2024 Accessibility (automation limits, overlays context):
https://almanac.httparchive.org/en/2024/accessibility
- EU-facing critique of overlays (example source):
https://www.fondazionelia.org/en/research-and-development/accessibility-overlays-are-not-the-solution-says-the-european-commission/
Procurement can force collective behaviour
- Require Annex V service accessibility information is published & look for WAD-style accessibility
statements
- Stop buying debt: require an Accessibility Conformance Report mapped to EN 301 549 before award (OpenACR)
- Require open deliverables and upstream-first fixes; don’t fund one-off bespoke patches that never land
upstream
- Ask for vendor credentials and history, don't accept claims to "know accessibility"
Procurement is leverage. Require published accessibility info plus structured evidence (ACR). Require open
deliverables and upstream-first fixes. Reject “trust us” claims.
Claims behind the bullets:
- Require a public-facing accessibility information deliverable aligned with EAA Annex V, and use WAD-style
statements as a familiar format where applicable.
- Require structured supplier disclosure before award: an Accessibility Conformance Report (ACR) mapped to EN
301 549 (OpenACR is a practical toolchain).
- Public money should produce reusable public value: open issue queues, upstream-first fixes, and avoidance of
one-off patches that never land upstream.
- Evaluate suppliers based on evidence: past work, contributions, maintenance history, and demonstrated
testing methods.
References:
- EAA (EUR-Lex): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32019L0882
- Annex VI criteria (UK mirror of EU text): https://www.legislation.gov.uk/eudr/2019/882/annex/VI
- VPAT/ACR overview (ITI): https://www.itic.org/policy/accessibility/vpat
- LocalGov Drupal patterns: https://patterns.localgovdrupal.org
- Readable EAA guide: 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 (include an Accessibility Statement
where helpful)
- Update procurement: require EN 301 549 evidence, don't accept unsubstantiated claims
- Check national enforcement; do not assume uniformity in application
- Book Announcement: Digital Accessibility Ethics — Disability Inclusion in All
Things Tech
Keep it actionable: audit, publish, maintain, procure evidence, and check country enforcement. Output is
documentation plus a plan, not just findings.
Claims behind the bullets:
- Audit against WCAG 2.2 AA and document known issues and remediation plan (not just a score).
- Publish & maintain service accessibility information (Annex V expectations) and keep it current as the
service changes.
- An accessibility statement can still be useful operationally even when not strictly required for a given
service context.
- Procurement should require EN 301 549 evidence early: structured disclosures plus test artifacts.
- Enforcement varies by member state, so teams must validate local complaint routes and regulator
expectations.
References:
- Digital
Accessibility Ethics — Disability Inclusion in All Things Tech
- WCAG 2.2: https://www.w3.org/TR/WCAG22/
- EAA (EUR-Lex): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32019L0882
- WAD model statement: https://eur-lex.europa.eu/eli/dec_impl/2018/1523/oj/eng
- AccessibleEU hub: https://accessible-eu-centre.ec.europa.eu
- Readable EAA guide: https://tetralogical.com/blog/2025/03/19/understanding-the-eaa/
Resources
Tell them what to read: legal authority (EUR-Lex), procurement standards (AccessibleEU entries), and practical
implementation sources (Almanac, LGD, Drupal).
How to use these resources:
- TetraLogical is a readable bridge to the directive text, useful for non-lawyers.
- Drupal Association frames Drupal implications for teams making platform decisions.
- AccessibleEU library entries are good citation targets for EN 301 549 and EN 17161 in
procurement contexts.
- Web Almanac is evidence against “automation equals compliance.”
- LGD & Drupal links are implementation pathways and governance examples.
Links on-slide are the canonical references.
Questions
Close hard: standards are moving, enforcement is real, and Drupal plus good procurement can reduce risk. Invite
specific questions (procurement, statements, testing, WCAG 2.2 migration).
Prompt for Q&A: Ask what role they are in (policy, procurement, product, engineering,
content) and answer from that lens.
- Procurement: ACR evidence, acceptance tests, open deliverables.
- Delivery: audits, remediation logs, maintaining accessibility info.
- Drupal: what helps out of the box vs what breaks quickly.
