By platform · Drupal
Drupal Has a Strong Core, and the Rest Is on You
Drupal core targets WCAG 2.2 at Level AA and says so in public. It also says, in as many words, that a finished Drupal site is not automatically accessible. Both halves are worth taking seriously.
Last reviewed August 30, 2026
For the team running a Drupal site, often in government, education, or a large organization with a compliance obligation and a date attached.
Drupal is the only platform here whose own project publishes the argument this page would otherwise have to make for it. Core targets WCAG 2.2 at Level AA for the public site and the admin interface both, there is an active accessibility team, and core changes pass through a formal accessibility gate before they land.
Then Drupal says the other half out loud. A finished Drupal site is not automatically accessible, because accessibility also depends on configuration, content, contributed modules and themes, custom code and ongoing testing. Contributed modules do not go through that core gate. Drupal.org does not certify contributed themes at all. Your site is core plus every one of those things, and that is the part an audit finds.
What breaks on Drupal
The failures we find most often on this platform, and the rule each one breaks.
Custom theme markup
Twig templates written without accessibility in mind produce divs where landmarks belong and headings picked for their size. Since nobody reviews contributed or custom themes for this, a theme built four years ago by an agency that is since moved on is the likeliest source of what an audit reports.
1.3.1 Info and Relationships
Contributed module output
Module quality varies enormously, which is Drupal's own position stated more precisely than ours. Slideshows, accordions and modal modules are the categories we find problems in most often.
4.1.2 Name, Role, Value
Views with unlabeled exposed filters
Exposed filters render as ordinary form elements, and a custom theme that restyles them tends to lose the connection between the label and the field it belongs to.
3.3.2 Labels or Instructions
Media library alt text
Drupal can require alt text on media entities, which is more than most platforms offer. The setting is frequently switched off during a migration to get the content in, and switched back on by nobody.
1.1.1 Non-text Content
Layout Builder output
Flexible layouts let an editor arrange blocks into a visual order that does not match the source order a screen reader follows, and neither the editor nor the page gives any sign that the two have drifted apart.
1.3.2 Meaningful Sequence
Multi-step webforms
Progress indicators, conditional fields and validation messages in Webform each need explicit configuration before they announce anything, and the default is silence rather than a warning.
3.3.1 Error Identification
The plugin question, answered
Drupal calls them modules and there are genuinely useful ones. The split is the same as everywhere else, between modules that test and modules that claim to fix.
One thing is different here. Drupal's audience skews public sector, where the obligation is usually real and usually dated. In the United States, state and local government web content has to meet WCAG 2.1 Level AA by April 26, 2027 for entities with a Census population of 50,000 or more, and by April 26, 2028 for smaller entities and special districts. Procurement teams working to a date like that already know what an overlay is. Skip that aisle.
Editoria11y
An open source accessibility checker that runs for content editors inside the live site, flagging problems on the page as they browse it, with site-wide reporting and dismissals.
- What it does
- It runs more than 50 content tests and puts each one in front of the person who created the problem, which is where a large editorial team makes most of theirs. The site-wide queue is what turns per-page checks into something a distributed team can work through. It is on nearly 23,000 sites and covered by Drupal's security advisory policy.
- What it cannot
- It checks content, not the markup your theme generates underneath it.
The Automatic Alternative Text module
A module that generates suggested alt text for images at upload, using a third-party vision service.
- What it does
- It gives you a starting point for a large media library with nothing in it, which beats an afternoon of blank fields and a hundred guesses.
- What it cannot
- It needs an API key for a paid third-party service, so it does nothing at all until somebody configures one, and most descriptions of it leave that out. Generated descriptions also say what is in the picture rather than what the picture is doing on the page. Treat every one as a draft somebody still has to edit.
Editor-level checkers, and what happened to them
A CKEditor accessibility checker module that flags problems as content is written.
- What it does
- Catching a misused heading or a missing alt attribute inside the editor is the right moment for both.
- What it cannot
- Check the maintenance status before you install it. It is published as minimally maintained, it is on fewer than 500 sites against Editoria11y's 23,000, and its own project page says it will not be needed once the plugin reaches Drupal core. CKEditor 5 ships no checker of its own. If you want one tool for this job today, it is Editoria11y.
Overlay widgets (accessiBe, UserWay, AudioEye and the rest)
A script you paste into your template that draws a toolbar for visitors and claims to repair your pages automatically as they load.
- What it does
- The toolbar half is real. Bigger text, higher contrast, adjusted spacing and a reading guide are preferences some visitors use, and the field's own reference document on overlays says a non-trivial array of accessibility problems can genuinely be repaired this way.
- What it cannot
- It does not change the markup your server sends, and the categories it handles worst are the ones that decide whether a site works at all. Text alternatives, form labels and error handling, and keyboard access. More than 5,000 US digital accessibility lawsuits were filed in 2025, and the firm that compiles that dataset reads the filings the same way every year, which is that widgets do not materially reduce legal risk. Our overlays page has the documented record.
What to actually do
- Confirm alt text is required on your media entity fields. It is a configuration setting, it is frequently off, and turning it on stops the problem growing tonight.
- Audit your custom theme's Twig templates for real landmarks. Header, nav, main and footer, in that order of usefulness.
- Test every contributed module that renders something interactive, by keyboard, on a real page rather than in the module's demo.
- Check that exposed filters in your Views still have visible labels connected to their fields after your theme has restyled them.
- Test your webforms end to end with a screen reader, including a failed submission and a conditional field appearing.
- Run the free 10-page scan across one page of each main content type, since every template fails in its own way.
On themes and templates
Olivero, the default front-end theme, and Claro, the default admin theme, were both built with accessibility as a requirement, and starting from one of them is a real advantage. Claro's documentation is worth stealing from whatever you build. A 16 pixel base font size, form controls big enough to hit on a touch screen, and links underlined by default on light and dark backgrounds both. If your site runs a custom theme built years ago, that theme is the most likely source of whatever an audit finds, and drupal.org certifies nothing about contributed themes either way, which it states rather than leaves you to discover.
One honest limit
Drupal sites are usually large, with many content types and many templates, so a ten-page scan tells you about ten pages and nothing else. Auditing one properly means testing each distinct template rather than sampling URLs, which is how we scope this work. It is worth knowing what a regulator finds doing this at scale. The UK government monitored 1,203 public sector websites, and the commonest problems were insufficient color contrast, no visible focus indicator, keyboard operation failures, and content that does not reflow. Three of those four are not things a scanner settles on its own.
Keep reading
Other platforms
Drupal
We test all 55 WCAG 2.2 A and AA rules on your Drupal site, with an expert review and a real blind screen-reader user on your key journeys. Every finding screenshotted and mapped to its fix. $499, report in 5 business days.