Drupal has one of the strongest accessibility records of any open-source CMS, and it still does not make your site accessible. Drupal.org says so itself: a finished Drupal site depends on its configuration, content, contributed modules, themes and custom code [3]. This page separates what core gives you from what stays your job, on a public-sector site or a Drupal Commerce shop.
Does the BFSG apply to your Drupal site?
It depends on what the site does. The BFSG covers listed services to consumers: e-commerce, banking, telecoms, e-books and passenger transport. If you sell to consumers through Drupal Commerce, you provide an e-commerce service – a "Dienstleistung im elektronischen Geschäftsverkehr" (§ 1(3) no. 5 BFSG) – and the law has applied to it since 28 June 2025. It transposes the European Accessibility Act, so selling into other EU countries brings equivalent national laws there [1][2].
Micro-enterprises that provide services are exempt: fewer than 10 employees and an annual turnover or balance sheet total of no more than €2 million (§ 2 no. 17, § 3(3) BFSG) [1]. Both conditions must be met; details are on our page on the micro-enterprise exemption. A purely B2B shop is not a service to consumers.
A company's information site with no consumer transactions is generally not itself one of the listed services – but a booking or order function on it can be. Universities, ministries and municipalities – many of them on Drupal – fall under BITV 2.0 instead. For the full scope, see the BFSG and the European Accessibility Act; for shops, BFSG for online shops.
What the platform gives you, and what it does not
You get:
- A core held to WCAG 2.2 AA, with a gate. Core targets WCAG 2.2 AA for the public site and the administration interface and treats barriers as bugs: an accessibility gate is meant to block core changes with serious accessibility problems [3]. Author-facing interfaces are held to ATAG 2.0 as well [5].
- Olivero and Claro. The default themes – Olivero for visitors, Claro for administration – were developed with accessibility as a priority [3][4].
- APIs for dynamic pages.
Drupal.announce()feeds an ARIA live region and the TabbingManager contains keyboard focus [4] – where a module or theme actually calls them. - CKEditor 5 with alt-text controls. Image fields and CKEditor 5 have alt-text controls; the standard Article configuration requires alt text. The Basic HTML text format offers headings from H2 to H6 [4].
- Inline Form Errors in core. This core module puts error messages next to their fields, and Drupal's documentation says sites that must meet WCAG should use it [7].
You do not get:
- Your theme. Very few production sites run Olivero unchanged. Themes are Twig templates, and every template can be overridden [8] – including the ones that render labels, landmarks and skip links. The core gate does not reach your theme.
- Accessible contributed modules. The coding standards bind core; contributed modules are asked to aim for the same [5]. Drupal.org says plainly that installing a module does not make a site conform [6].
- Editor discipline. A text format that allows full HTML lets editors paste anything, and nothing stops a heading being chosen for its size.
- An accessible shop by default. Drupal Commerce is a contributed project with its own checkout flows and a payment API that connects to over 100 gateways through further modules [9]. Its project page makes no accessibility commitment.
What we find on Drupal sites
Custom themes that undo Olivero
The common pattern: an agency theme with focus outlines removed, a skip link dropped from html.html.twig, and a palette that fails contrast on buttons and links. Twig overrides of form templates sometimes drop the <label>, <fieldset> or <legend> the Form API generates. One template renders on many pages, so one defect becomes hundreds of findings.
Menus and components from contributed modules
Mega menus, accordions, tabs and sliders usually come from contributed modules or layout-builder components. Submenus open on hover only, toggles are links without aria-expanded, and accordion panels are divs that cannot take focus. Each module brings its own markup, so two accordions on one site can fail in different ways.
Editor content in CKEditor 5
On content-heavy sites – universities, authorities, associations – editors are the largest source of findings. Headings are picked for size, so a page jumps from h2 to h5. Tables pasted from Word lack header cells; links read "more". Where images are reused, an alt text written for one context appears in another where it no longer fits.
Views listings, filters and pagers
Listings are built with Views, part of core, which can expose filters to visitors [10]. When filters or pagers reload results via AJAX, the result count is often not announced and focus jumps to the top. Teaser lists repeat "Read more" links that say nothing out of context.
Forms without inline errors
Contact, application and form-builder forms frequently show errors only at the top of the page. Browser validation and Drupal's own validation can report different things, and Drupal's documentation notes that screen readers may then read unhelpful messages [7]. Required fields marked only with a red asterisk and mouse-only date pickers are common.
Drupal Commerce checkout and payment
Address forms need autocomplete values, the cart updates silently, and card fields or express buttons from the payment provider arrive in iframes that need a title and a sane focus order on the way out. Consent banners, usually a contributed module or an external script, sit in front of all of it.
Where to look first
| Criterion | Why on Drupal | Automation |
|---|---|---|
| 1.3.1 Info and Relationships (A) | Pasted tables, overridden form templates | Partly automated |
| 2.4.6 Headings and Labels (AA) | Headings chosen for size in CKEditor 5 | Manual only |
| 1.1.1 Non-text Content (A) | Reused media, optional alt fields | Partly automated |
| 2.4.4 Link Purpose (In Context) (A) | "Read more" in Views teaser lists | Partly automated |
| 2.1.1 Keyboard (A) | Contributed menus, accordions, date pickers | Partly automated |
| 2.4.7 Focus Visible (AA) | Custom themes that remove outlines | Partly automated |
| 4.1.2 Name, Role, Value (A) | Menu toggles, accordion panels | Partly automated |
| 4.1.3 Status Messages (AA) | AJAX filters, Commerce cart updates | Manual only |
| 3.3.1 Error Identification (A) | Forms without Inline Form Errors | Manual only |
| 1.4.3 Contrast (Minimum) (AA) | Theme palettes, buttons, links | Automated |
"Automated" means a rule can decide the criterion on its own; "partly automated" means a rule finds some failures and a person has to judge the rest. The full list is in WCAG 2.2 AA, criterion by criterion.
A sensible order of work
- Measure your theme against Olivero. Scan a staging copy once with Olivero. Whatever disappears came from your theme and its Twig overrides – fix those first; each fix reaches every page.
- Tighten the text formats. Give editors Basic HTML with a CKEditor 5 toolbar that offers only what they need, keep Full HTML for the few who must have it, and make alt text required on image fields and media types.
- Switch on Inline Form Errors and walk every form. Contact, application and Commerce checkout forms, with a keyboard, including the error states.
- Inventory contributed modules. For every module that renders on the public site, check its issue queue for accessibility bugs and decide: patch, replace or document.
- Walk the key journeys. On a shop: category → filter → product → cart → checkout → payment in test mode. On a public site: search, a form and a download.
- Re-test after updates. Core minor releases, contributed module updates and a new editor on the team all change what the site renders. A scheduled crawl catches regressions early.
What Reviseberg checks on Drupal – and what you still test yourself
Reviseberg crawls your site, including listings and detail pages, and runs every axe-core rule on every page at a desktop width of 1280 pixels, then repeats the rules that change with the layout – contrast and target size among them – at 360 pixels. Results are mapped to WCAG 2.2 A/AA and EN 301 549. Findings are grouped into issues by rule and ranked by the points you gain by fixing them, so a defect in one Twig template shows up as one issue on 400 pages rather than 400 separate entries.
The keyboard agent opens the pages of a journey you name – a listing, a detail page, a form, the cart – and presses Tab, Shift+Tab and Escape through each, recording every step. It reports unreachable elements, lost or invisible focus, missing skip links and keyboard traps. It does not fill in forms or place an order, so error states, the checkout behind a full basket and the payment iframe are yours to walk by hand. The free report covers up to 100 pages and runs the keyboard agent on one page you choose.
You still test some things yourself: whether alt text describes the image, whether headings and error messages make sense, and how the site behaves with a screen reader and zoom. Screen-reader, zoom and voice-control agents are not built yet; for those criteria the platform gives you guided manual tests, and a criterion nobody has tested is reported as untested, never as passed. PDF documents are not checked – on a public-sector site, count them separately. There is no Drupal module from us, nothing is applied to your site automatically, and we never inject an overlay script.
Written to be useful, not as legal advice. As of 27 September 2026.