EAA compliance for Drupal: WCAG 2.1 AA checklist & fixes

What the EAA actually requires from a Drupal site

Drupal core passes WCAG 2.1 AA out of the box and its default Olivero theme was built to a high accessibility bar, so under the EAA the obligation sits almost entirely in the contributed-module ecosystem. EN 301 549 conformance forces you to audit Webform-rendered fields with implicit labels, Layout Builder regions that lack landmark roles unless you add them, and inline JS components from contrib modules (Slick Carousel and similar) with a long history of keyboard failures. The requirement is that your assembled site with its specific module and Layout Builder configuration stays AA, since core rarely is the problem.

Drupal is heavily used by EU public sector, higher education, and large institutions, so most in-scope Drupal sites are subject to both the EAA and the Web Accessibility Directive plus EN 301 549 procurement obligations. For these bodies the pressure is often statutory compliance reporting and audit findings rather than a commercial penalty, though large institutional operators still carry meaningful fine exposure. The typical Drupal user's risk profile is therefore procurement-driven and reputational, with formal accessibility statements required rather than merely advisable.

Remediation is done by a Drupal development team in theme layer YAML, Twig templates, and contrib-module configuration: add landmark role attributes to Layout Builder regions, update or patch older Webform and carousel modules, and use author-facing tools like Editoria11y and Sa11y to catch content issues. Scan both as an anonymous visitor and as a logged-in editor because Layout Builder UIs differ, and lean on Drupal core's own accessibility report under /admin/reports. This is structured, ticketed engineering work typical of institutional Drupal shops.

Top WCAG failures we see on Drupal sites

Across hundreds of Drupal scans, the same handful of issues show up over and over. None of them require ripping the theme apart — most are fixable in a few hours by someone comfortable in the platform's editor or template files.

• Webform-rendered fields with implicit labels in older modules

  Older Webform releases sometimes wrap inputs in <label> without the for attribute, which fails for screen readers using forms mode.

  1.3.1, 3.3.2 — Level A

• Layout Builder regions without landmarks

  Custom block regions lack <main>, <nav>, or <aside> unless you add the role explicitly.

  1.3.1, 2.4.1 — Level A

• Inline JS components from contributed modules ignoring keyboard

  Slick Carousel and similar contrib modules have a long history of failing 2.1.1.

  2.1.1 — Level A

Concrete code fixes for Drupal

Below are copy-paste fixes for the most common Drupal issues. They assume you have access to your theme code or the platform's custom-code injection panel. If you cannot edit code directly, share these snippets with whoever maintains the site — every one of them is a ten-minute change.

# In your theme's layouts/*.layouts.yml
my_layout:
  regions:
    main:
      label: 'Main content'
      attributes:
        role: 'main'
    sidebar:
      label: 'Sidebar'
      attributes:
        role: 'complementary'

Tools and plugins worth installing first

• Editoria11y — flags content-author accessibility issues inline

• Sa11y — manual content checker

• Drupal core "Accessibility" report under /admin/reports

How to scan a Drupal site without missing anything

Automated scanners catch about 30–40% of WCAG issues; the rest need manual review. The good news is that the 30–40% includes the most expensive issues to remediate after the fact, so an automated scan is the cheapest way to get unstuck. Run one before you change a line of theme code.

• Run scans both as anonymous and as a logged-in editor — Layout Builder UIs differ.