Drupal Accessibility & ADA Compliance

Drupal Accessibility

Real, hand-built accessibility remediation that makes your site WCAG 2.1 AA compliant — and keeps the lawyers away. No overlays, no shortcuts.

WCAG 2.1 AA & Section 508

Theme & contrib code fixed by hand

Anti-overlay, no widgets

Built for gov, higher-ed & SMB sites

Drupal accessibility: a strong core, a fragile surface

Drupal accessibility is unusual among content management systems: the platform’s core is genuinely built for it. The Drupal project commits to WCAG 2.2 AA and ATAG 2.0 conformance, runs a dedicated accessibility team, and enforces an accessibility core gate — major releases have been delayed because identified barriers weren’t fixed. That heritage is why Drupal powers so many federal, state, and university sites where Section 508 conformance is mandatory.

But a strong core does not make a live site compliant. Your Drupal site’s accessibility lives in the custom theme, the contributed modules, and the content editors produce — and that’s where conformance breaks. Curbcut remediates all three by hand, the way the Department of Justice expects under ADA Title III and Section 508 expects for public-sector procurement. Drupal hands you better tools than almost any CMS, but tools aren’t conformance.

What Drupal core actually gives you

Drupal’s reputation cuts both ways — people assume core handles everything, or that nothing is done. The documented core features include real accessibility infrastructure:

Alt text required by default on image fields and in CKEditor, so editors can’t ship an undescribed image without overriding the setting.
Drupal.announce() — a built-in aria-live mechanism for announcing dynamic changes to screen readers, with polite/assertive priorities.
Drupal.tabbingManager — a JavaScript API for constraining and ordering keyboard focus in complex UIs like modals.
Form API fieldsets and legends for radio and checkbox groups, plus an optional Inline Form Errors module.
Accessible default themes — Olivero (front end) and Claro (admin) were built with focus states and forced-colors support as first-class concerns.

The catch: these only help if your developers use them. Drupal.announce() does nothing if your custom AJAX view never calls it, and the fieldset behavior applies only to Form API elements — not hand-coded HTML in a Twig template.

Where Drupal sites actually fail WCAG

Real-world Drupal failures cluster in the customization layer, not core. These are the issues Curbcut finds again and again:

Layer	Typical Drupal-specific problem	WCAG 2.1 AA principle
Custom Twig theme	Missing ARIA landmarks, weak focus styles, brand colors below contrast minimums	Perceivable / Operable
Views (AJAX)	Exposed filters and pagers that update results without calling `Drupal.announce()` — silent to screen readers	Operable / Robust
Paragraphs	Nested layout components rendering generic `<div>` soup with no headings or roles	Perceivable
Webform	Complex multi-step forms where labels, `fieldset`/`legend`, and error association get lost in configuration	Understandable
Menus	Superfish/responsive menus and hamburger toggles missing `aria-expanded` and focus management	Operable
CKEditor 5 content	Editors skipping heading levels; H1 is reserved for the theme but H2–H6 order still breaks	Perceivable
Admin Toolbar	Hover-only drop-downs that work with a mouse but not a keyboard	Operable

The pattern is consistent: a feature core got right gets undone the moment it’s themed, configured, or extended. CKEditor 5 became the default editor in Drupal 9.5 and 10 and correctly reserves H1 for the page title — but it can’t stop an editor jumping H2 straight to H4. Views is one of the most-used modules in the ecosystem, yet its AJAX behavior doesn’t announce result changes unless a developer wires it up.

Why contrib modules undo core’s good work

Drupal core is held to an accessibility gate. Contributed modules are not. The contrib ecosystem is maintained by thousands of independent developers, so a module that’s wildly popular for its functionality can still inject inaccessible markup — and module updates can reintroduce barriers you previously fixed. The Drupal-specific lesson: you can’t audit “Drupal,” you have to audit your Drupal — your exact theme, your exact module list, your editors’ habits.

Why overlays and checker modules aren’t compliance

There’s a contrib module or third-party widget for almost everything in Drupal, and accessibility is no exception. Two categories get confused with compliance, and neither is:

Accessibility-checker modules (such as Editoria11y for CKEditor 5) are genuinely useful — they help editors catch issues like missing alt text or bad heading order at authoring time. But they only flag problems; they don’t fix your theme code, and they don’t touch what’s already published.
Overlay widgets that load a JavaScript layer over your site are actively counterproductive. They never change the underlying Twig markup a screen reader reads, and the legal record is unkind: in 2024, more than 1,000 businesses running accessibility widgets were sued anyway, accounting for over a quarter of all digital accessibility cases that year. Many screen-reader users disable overlays on sight.

That’s why Curbcut is anti-overlay. Compare the approaches in overlay vs manual remediation, or read why overlays don’t work.

How Curbcut remediates a Drupal site

We work inside your existing theme and module stack — no widget, no forced rebuild.

Audit. A combined automated and manual test against WCAG 2.1 AA across your real templates — node pages, Views listings, Webforms, Paragraphs layouts — with screen-reader and keyboard navigation passes.
Theme remediation. We fix the Twig templates, CSS, and theme libraries: ARIA landmarks, visible focus styles, accessible menus with proper aria-expanded state, and compliant color contrast.
Module review. We identify which contrib modules emit inaccessible markup, configure Webform and Views correctly, wire Drupal.announce() into AJAX behaviors, and recommend accessible alternatives where a module can’t be fixed.
Content & editor fixes. Heading order in CKEditor content, alt text, descriptive links, and editor guidance so new content stays compliant.
Documentation. A VPAT / Accessibility Conformance Report and accessibility statement — often required for government and higher-ed procurement.
Monitoring (optional). Module and core updates can regress accessibility; ongoing monitoring catches it early.

The result conforms to WCAG 2.1 AA — the same Level AA bar that Section 508 incorporated when its revised standards took effect in 2018.

Start with what you can see today

A few high-impact Drupal items you can sanity-check yourself:

Tab through a Views listing with an exposed AJAX filter — does the screen reader announce when results change, or go silent?
Open your main menu on mobile and try the hamburger toggle with the keyboard alone.
Check contrast on buttons and links your brand theme styled, and inspect a Paragraphs-built page for real headings and landmarks, not just nested <div>s.

For the full picture, run a free accessibility scan, then dig into heading structure and landmarks to interpret what you find. Want it handled end to end? See our accessibility remediation service, built for Drupal teams on government, higher-ed, and small-business budgets.

This page is general information, not legal advice. If you’ve received a demand letter or face a procurement deadline, consult a qualified attorney about your specific situation.

Frequently asked questions

Is Drupal accessible out of the box?

Drupal core is one of the most accessible CMS foundations available — it commits to WCAG 2.2 AA and ATAG 2.0, requires alt text by default, ships accessible form fieldsets, and gates releases on accessibility review. But a live Drupal site is only as accessible as its theme, contrib modules, and content. Custom Twig templates, Views, Paragraphs, and Webform configurations routinely reintroduce WCAG failures that core never had.

Does Drupal make my site Section 508 compliant automatically?

No. Drupal is a popular choice for federal, state, and university sites precisely because its core is built to support Section 508 and WCAG, but the platform can't guarantee conformance for the markup your theme and editors produce. Section 508's technical standard incorporates WCAG 2.0 Level AA, and you still have to verify the rendered pages — that's what an audit and VPAT are for.

What are the most common Drupal accessibility issues?

Inaccessible custom Twig themes (missing landmarks, poor focus styles), AJAX Views filters that don't announce updates to screen readers, Paragraphs and Webform widgets that drop labels, mega menus and hamburger toggles missing aria-expanded, low color contrast introduced by brand styling, and editor content with broken heading order. Core is strong; the customization layer is where things break.

Will a Drupal accessibility module or overlay make my site compliant?

No. Contrib accessibility-checker modules (like Editoria11y) are useful for catching issues, but they don't fix code. Overlay widgets that inject a script are worse — they don't change the underlying Twig and theme markup, and in 2024 over 1,000 businesses running such widgets were still sued. See why overlays don't ensure ADA compliance.

Can you fix accessibility without rebuilding our Drupal site?

Almost always, yes. Most Drupal accessibility problems live in the theme's Twig templates, CSS, library JavaScript, module configuration, and content — all of which we remediate in place. A full rebuild is rarely necessary; we work inside your existing theme and module stack.

Does Drupal core accessibility carry over to contrib modules?

Not reliably. Core has an accessibility maintainer team and a release-blocking accessibility gate, but contributed modules are maintained by thousands of independent developers and aren't held to the same bar. Popular modules can still ship inaccessible widgets, so each one on your site needs its own review.