Drupal accessibility: a strong core, a fragile surface
Drupal accessibility remediation is mostly theme-layer work, because Drupal core already satisfies most of WCAG at Level AA and the failures are reintroduced by custom Twig templates, contributed modules, and editor-entered content. That single sentence is the shape of almost every Drupal engagement, and it explains how a site built on the most accessibility-committed CMS in the field still fails an audit.
The commitment is real. The Drupal project follows WCAG 2.2 AA and ATAG 2.0, runs a dedicated accessibility team, and enforces an accessibility core gate on changes to the user interface — Drupal’s own documentation notes that “major releases have been delayed several times because identified barriers were not fixed.” That heritage is why Drupal powers so many federal, state, and university sites where Section 508 conformance is mandatory.
A strong core still does not make a live site conformant. Curbcut fixes the three layers core does not control — theme, contrib, content — by hand, the way ADA Title III and Section 508 expect.
What does Drupal accessibility remediation actually involve?
Drupal remediation concentrates in the theme layer because core’s gate only fires on core’s own user interface. Your theme, your modules, and your editors sit outside it. Three surfaces account for the overwhelming majority of any fix list.
Which Twig template changes fix the most WCAG failures?
Templates carry structure, so structural failures concentrate there. The recurring fixes are landmark regions a custom page.html.twig dropped, focus styles a designer removed, heading levels a node template hard-codes at the wrong depth, and menu templates that never expose aria-expanded on their toggles. These are edits to your own theme’s Twig, CSS, and library JavaScript — they change the markup a screen reader receives, and they survive every future core update because they live in your theme rather than in a patch.
Drupal’s own guidance points the same way: it recommends starting from an accessible base theme such as Olivero and building out, while acknowledging there is no up-to-date official guide for creating accessible Drupal themes. That documentation gap is exactly why heavily themed Drupal sites drift.
Which contrib modules most often undo core’s accessibility?
The useful answer is a category, not a blocklist. The modules that generate front-end markup are the ones that can undo core’s work: anything rendering interactive UI (AJAX-driven Views listings with exposed filters and pagers), anything nesting layout components (Paragraphs, which can produce deep generic <div> structures with no headings or roles), and anything building complex forms (Webform, whose configuration decides whether labels, fieldset/legend, and error association survive).
Drupal is candid about the tier difference: “Drupal Core usually has stricter criteria than the contributed modules and themes.” The same page names Webform as a module that “has gone above and beyond” — which is the nuance that matters. A well-built module can still be configured into an inaccessible form. What gets audited is your exact module list and your exact configuration, never the module’s reputation.
How do you fix editor-entered content without retraining every editor?
Change the defaults rather than the people. Drupal already helps here: alt text is required by default on image fields and in CKEditor, and the Basic HTML text format starts authors at H2 so the theme keeps its H1. An administrator can override both, so step one is confirming that nobody switched them off.
Two further accessibility features ship in core but stay off until someone enables them: the Inline Form Errors module (“you need to manually enable this module,” per Drupal’s documentation) and the CKEditor Language of Parts button, which “needs to be added to the WYSIWYG controls by an administrator.” Turning both on is a configuration change, not a training programme, and it removes two entire classes of future editor error.
Where Drupal sites actually fail WCAG
Real-world Drupal failures cluster in the customization layer, not core.
| 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 announcing the change — silent to screen readers | Operable / Robust |
| Paragraphs | Nested layout components rendering generic <div> structures with no headings or roles | Perceivable |
| Webform | Multi-step forms configured so labels, fieldset/legend, and error association get lost | Understandable |
| Menus | 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 |
| Media / file fields | Untagged PDFs attached to media entities and served byte-for-byte as uploaded | Perceivable / Robust |
That last row is the one teams are most often surprised by. Drupal does not remediate a document for you — a PDF on a media or file field is delivered exactly as it was uploaded, so tags, reading order, headings, and alt text have to be corrected in the source file before it goes back into the library. Accessible PDFs and remediation covers what that work involves and which parts of it a scanner will never see.
The pattern repeats: a feature core got right gets undone the moment it is themed, configured, or extended. Core ships a JavaScript mechanism for announcing dynamic changes to screen readers and a tabbing manager for constraining focus in complex interfaces — neither does anything unless your custom AJAX behaviour calls it.
Does Drupal core’s conformance commitment cover your site?
No — and the gap is specific enough to name, because procurement teams misread it constantly.
Drupal’s accessibility commitment is a commitment about Drupal core. The accessibility gate applies when core changes its UI. Your custom theme was never gated. Your contrib modules were never gated. Your editors’ content was never gated. A conformance claim about the CMS is not a conformance claim about the site, and a VPAT has to describe the rendered site a buyer will actually use.
Two more distinctions matter when someone asks “isn’t Drupal already accessible?”:
- Core’s target moves. The Drupal accessibility team follows the latest recommended WCAG release — currently WCAG 2.2 AA — while U.S. legal exposure is still measured against WCAG 2.1 AA. Those are compatible, not identical, and your conformance statement should name the version you actually tested.
- Accessible defaults can be switched off. Alt-text enforcement can be overridden in both CKEditor and image fields. Inline Form Errors is off unless enabled. An install that turned those off is less accessible than stock Drupal, and nothing in the platform warns you.
Olivero, Drupal’s newest default front-end theme, was built with focus states and forced-colors support as first-class concerns and has been tested with the National Federation of the Blind. A site that kept Olivero and changed little starts from a strong position. A site with a heavily customized subtheme starts from its developer’s decisions.
Which accessibility fixes survive the next module update?
Every buyer worries about this and almost nobody writes about it, so here is the honest answer: a fix survives an update when it lives in code you own.
| Where the fix lives | Survives a contrib update? | Survives a core update? |
|---|---|---|
| Your custom theme’s Twig, CSS, JS | Yes | Yes |
| Module configuration (Webform, Views, text formats) | Usually — but a new release can add options that default to inaccessible | Yes |
| A patch applied to a contrib module | No — reapplied by hand, or lost | n/a |
| A template override in your theme for a contrib module’s output | Yes, until that module renames its templates | Yes |
| An overlay widget | Irrelevant — it never changed the code | Irrelevant |
Two consequences follow. Remediation should push fixes into your theme wherever the same result is achievable there, because patched contrib is the layer that silently regresses. And the sites that stay conformant re-test after module updates rather than after complaints — which is the job accessibility monitoring exists to do.
What breaks when a Drupal 7 site moves to Drupal 10 or 11?
Migration-induced regression is a real, Drupal-specific event, and it catches teams who assumed their accessibility work would travel. Drupal 7 reached end of life on January 5, 2025, which makes this a live problem for a large population of government and education sites.
A migration does not carry accessibility fixes forward, for three structural reasons:
- The theme layer is replaced. Drupal 7’s themes and templating are gone; the site is re-themed, typically onto Olivero for the front end and Claro for the admin. Every landmark, focus style, and ARIA attribute a developer added to the old theme has to be re-created in the new one.
- The editor changes. Drupal 7 sites commonly ran CKEditor 4, which Drupal’s security team explicitly stopped covering — the Drupal 7 end-of-life notice states it “will not issue security advisories for any unsupported libraries that Drupal 7 contributed modules or themes rely on, such as CKEditor 4.” CKEditor 5 handles headings and alt text differently, and years of legacy body HTML arrives in it unchanged.
- Opt-in accessibility features do not migrate themselves. Inline Form Errors and the Language of Parts button are configuration, and configuration is rebuilt rather than copied.
The sequencing that follows is simple: migrate, then audit the migrated site, then remediate. Remediating a Drupal 7 theme weeks before it is discarded spends the budget twice.
How long does a Drupal accessibility remediation take?
Timeline is driven by the number of distinct templates, not the number of nodes, because a fix applied to one Twig template propagates to every node that renders through it. A 40,000-node site with twelve templates is a smaller job than a 300-node site with sixty.
How do you count distinct templates on a Drupal site?
Count rendering paths, not pages: each content type’s node template, each view mode (teaser, card, full), each Views display, each Paragraph type, each Webform, plus the site-level page, region, and menu templates. Enabling Twig debug output in a development environment prints the candidate template names into the HTML source of every page, which turns the count into a mechanical exercise instead of a guess. Then add the interactive components that are not templates at all — search autocomplete, exposed filters, modals, media embeds — because each needs its own keyboard and screen-reader pass.
What changes when the site is on Drupal 7 versus 10 or 11?
On Drupal 10 or 11 you are remediating a modern theme against a core that already handles the fundamentals, so the work concentrates in custom templates and module configuration. On Drupal 7 the platform is past end of life, and the right advice is usually to schedule remediation around the migration rather than fight the old theme. A Drupal 7 site that cannot migrate yet can still be remediated — but every fix has a known expiry date, and that belongs in the quote rather than in a footnote.
Why overlays and checker modules aren’t compliance
Two categories get confused with conformance, and neither qualifies:
- Accessibility-checker modules genuinely help editors catch issues such as missing alt text or broken heading order at authoring time. They flag problems; they do not change your theme code, and they do not touch what is already published. Drupal’s own gate documentation says as much: “automated checkers do not guarantee accessibility and do not check all WCAG 2.1 criteria. Some criteria require human review.”
- 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 — UsableNet’s 2024 report found that “in 2024, over 1,000 businesses were sued despite having accessibility widgets on their websites, accounting for more than 25% of cases”.
That is why Curbcut is anti-overlay. Compare the approaches in overlay vs manual remediation, or read whether accessibility overlays work at all.
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 passes. That is a website accessibility audit, scoped by template rather than by page count.
- Theme remediation. We fix the Twig templates, CSS, and theme libraries: ARIA landmarks, visible focus styles, accessible menus carrying proper
aria-expandedstate, and compliant color contrast. - Module review. We identify which contrib modules emit inaccessible markup, configure Webform and Views correctly, wire screen-reader announcements into AJAX behaviours, and recommend accessible alternatives where a module cannot be fixed.
- Content and editor defaults. Heading order in CKEditor content, alt text, descriptive links — plus switching on the accessibility features core ships disabled.
- Documentation. A VPAT / Accessibility Conformance Report and accessibility statement — routinely required in government and higher-education procurement.
- Monitoring. Module and core updates can regress accessibility; ongoing monitoring catches it before a user does.
The result conforms to WCAG 2.1 AA — the same Level AA bar Section 508 incorporated when its revised standards took effect.
Start with what you can see today
Three checks you can run on your own Drupal site this afternoon:
- Tab through a Views listing with an exposed AJAX filter — does the screen reader announce that results changed, or go silent?
- Open your main menu on mobile and operate the hamburger toggle with the keyboard alone.
- Inspect a Paragraphs-built page for real headings and landmarks rather than nested
<div>s, and check contrast on the buttons your brand theme styled.
For the full picture, run a free accessibility scan, then read 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.