Blog
A head start, not a guarantee.
Drupal core targets WCAG AA, yet nearly every audit still finds issues. What Drupal does and doesn't solve for you.
Drupal gives you a head start on accessibility, not a guarantee.
Core targets level AA, the default themes are built on that, and every change to core has to pass a mandatory accessibility gate.
Yet almost every audit turns up the same outcome: the problems are almost never in core, but in the custom theme and in a handful of contributed modules.
What Drupal actually handles: a gate that blocks code
Accessibility in Drupal core is a requirement in the development process, not a line on a roadmap.
Every change has to pass six quality gates: accessibility, documentation, frontend, performance, testing and usability.
That gate is meant to ensure changes to core meet accessibility standards before they land.
It's concrete too.
A change comes with a fixed set of requirements: conformance with WCAG 2.1 and ATAG 2.0, an HTML structure that meets WCAG 2.1, sufficient contrast, a linked label on every form field and JavaScript that works with the keyboard.
New patterns get tagged needs accessibility review.
The goal drupal.org sets is WCAG level AA plus ATAG 2.0, with the caveat they add themselves: passing the gate is protection, not full compliance.
Semantics and ARIA live in core, not in a module
For the basics, you don't need an accessibility module in Drupal.
Core ships forms with linked labels and fieldsets, skip links to the main content and an aria-live mechanism that passes status messages to screen readers.
Alt text is required by default on an image field, so an editor has to actively fill it in.
Core uses ARIA where semantic HTML falls short, not as decoration on top.
An element that acts as a button is a button, not a div with a role bolted on.
In custom code I regularly see that order reversed, and then ARIA becomes an extra layer of bugs.
Olivero and Claro: the default themes play along
Since Drupal 9.4, Olivero has been the default frontend theme and Claro the default admin theme, and that's stayed the same in Drupal 10 and 11.
Both are still updated through core's issue queue.
Olivero is named after Rachel Olivero, a blind accessibility expert who led IT at the National Federation of the Blind and was active in the Drupal community.
Claro is the most underrated of the two.
ATAG 2.0 isn't about the site your visitors see, it's about the environment you create content in, so it's about whether an editor using a screen reader can publish on your site.
| What core handles for you | What your project has to handle itself |
|---|---|
| Semantic markup and labels in forms | The markup in your own Twig templates and components |
| Contrast within Olivero and Claro | Contrast of your brand colours and hover states |
| A gate on every change to core | Review of every module you add |
Where it still goes wrong: the custom theme
Most of the issues I find sit in the theme built after installation.
Core delivers correct HTML, the layer on top of it decides what the visitor gets.
- Focus made invisible: the focus ring stripped out because it didn't fit the design, with no alternative.
- Buttons that aren't buttons: menus, tabs and modals built as a div with a click handler, so unreachable with the keyboard.
- Contrast just too low: brand colours at 4.2:1 where 4.5:1 is needed, usually in secondary text.
- Heading structure broken: every component brings its own h2, so the page loses any hierarchy.
With Layout Builder and flexible paragraphs, the reading order in the DOM also stops matching the visual order once editors control the layout.
Not a bug, but a consequence of the freedom you hand over.
And with contributed modules: no gate, no promise
The accessibility gate doesn't apply to contributed modules.
Nothing obliges a maintainer to test keyboard operation, and that produces familiar problems: a carousel with no pause button, a datepicker that only works with a mouse, a cookie banner that doesn't trap focus.
You assess this per module and by hand, because there's no certification mark you can filter on.
I look at the latest release, activity in the issue queue and whether it can be fixed with a template override.
What this means for the EAA and WCAG 2.2 AA
Conformance is measured on your pages, not on your CMS.
The European Accessibility Act, directive 2019/882, has applied since 28 June 2025 and the standards are WCAG 2.2 level AA and EN 301 549.
Core itself targets level AA plus ATAG 2.0, but that goal always trails a little behind the latest WCAG version, and your site is assessed against the legal standard, not core's goal.
Whether the law applies to you depends on what you offer, so have that checked legally.
I handle the technical part and this article explains the law.
Staying on an old version costs you accessibility too
Improvements to Olivero, Claro and the core components ship in new releases, so an old version is an accessibility problem too.
Drupal 11 is the current stable version, in the 11.4 series.
Drupal 10 reaches end of life on 9 December 2026 with 10.6.0 as its last minor, and Drupal 12 is released in the week of 7 December 2026, the same week.
Drupal 7 has been out of support since 5 January 2025, Drupal 9 since November 2023.
There, it's a migration question first.
When the CMS isn't your problem
If the problems sit in the content, switching CMS changes nothing.
Inaccessible PDFs, video without subtitles and alt text that says "image1.jpg" get fixed by no platform at all.
A well-built project in a different system reaches WCAG 2.2 level AA just as well, so don't base a platform choice on this point alone.
What else weighs in alongside accessibility when drafting a brief is covered in my article on choosing a CMS for government and education.
My approach
I start with what you already have, not a platform debate: keyboard, screen reader, contrast, heading structure, ranked by impact per WCAG success criterion.
If you want to run that check yourself first, my guide on testing your website for accessibility walks through the same steps.
Fixing it happens in the theme and the components.
That's digital accessibility as code work, and on a new build I factor it in from the architecture onward.
Describe your situation via the contact form, I'll give you an honest picture within 24 hours.
Frequently asked questions
Do I need an accessibility module in Drupal?
Not for the basics.
Core delivers forms with linked labels and fieldsets, skip links to the main content, and an aria-live mechanism that passes status messages to screen readers, and alt text on an image field is mandatory by default.
An extra module adds little to that, since the issues I find in audits sit in the custom theme and in contributed modules, not in what core provides.
What is the accessibility gate in Drupal core?
A condition in the development process: every change to core has to pass six quality gates, including accessibility, and must meet the accessibility standards before it goes in.
Concretely, that comes with a fixed set of requirements: conformance with WCAG 2.1 and ATAG 2.0, an HTML structure that meets WCAG 2.1, sufficient contrast, a linked label on every form field, and JavaScript that's usable with the keyboard.
New patterns get the tag needs accessibility review.
Drupal.org itself adds the nuance: passing the gate is protection, not a full audit.
Are Olivero and Claro built accessibly?
They are built with that in mind.
Since Drupal 9.4, Olivero has been the default frontend theme and Claro the default admin theme, that's stayed the case in Drupal 10 and 11, and both are still being updated through core's issue queue.
Olivero is named after Rachel Olivero, a blind accessibility expert who was active in the Drupal community.
Claro is the most underrated of the two here: ATAG 2.0 is about the environment in which you create content, so about whether an editor using a screen reader can publish on your site.
Do those accessibility requirements also apply to contributed modules?
No, the accessibility gate only applies to core.
Nothing requires a contributed module's maintainer to test for keyboard operation, and that produces recognisable issues: a carousel without a pause button, a datepicker that only works with the mouse, a cookie banner that doesn't hold focus.
There's no certification you can filter on, so you assess it per module and by hand.
I look at the latest release, the activity in the issue queue, and whether it can be fixed with a template override.
Is my site automatically accessible because I use Drupal?
No.
Conformance is measured on your pages, not on your CMS.
Core gives you a correct foundation, the layer on top determines what the visitor gets, and that's where most of the errors sit: a removed focus ring, menus and modals built as a div with a click handler, contrast that comes in just under 4.5:1, and a heading structure without hierarchy.
Inaccessible PDFs and video without subtitles, incidentally, aren't fixed by any platform.
Does it matter for accessibility whether you are on Drupal 10 or Drupal 11?
Yes, but less than your custom theme matters.
Improvements to Olivero, Claro and the core components come in new releases, so on a version without support you no longer get those.
Drupal 10 reaches end of life on 9 December 2026, with 10.6.0 as the last minor.
An upgrade doesn't fix your issues, but it does take the brake off.
A question about this topic?
Briefly describe your situation, and I'll let you know what's going on and what it would cost. No sales pitch.
