Drupal is widely used by governments, universities, and enterprises - organisations with legal accessibility obligations. Drupal core has a dedicated accessibility gate and follows WCAG standards as a project policy, making it arguably the most accessibility-conscious CMS available. But a Drupal site is more than core: contributed modules, custom themes, and content authoring practices all affect the rendered output. Under the EAA, any Drupal site providing services to EU consumers must meet EN 301 549.
Common Drupal accessibility issues
Contributed modules don't share core's accessibility standards
Drupal core has an accessibility gate - contributed modules do not. Modules for media, layout, forms, and interactive features frequently ship with missing ARIA attributes, keyboard traps, and inaccessible JavaScript behaviours.
Custom Twig templates break semantic structure
Drupal's Twig theming layer gives developers full control over HTML output. Custom templates frequently replace semantic elements with divs, remove landmark roles, or produce incorrect heading hierarchy - undermining core's accessible defaults.
Views output lacks context for screen readers
Drupal Views generates lists, tables, and grids of content. Without careful configuration, Views output can lack table captions, proper heading structure, and ARIA labels - producing long lists of visually distinct but programmatically identical items.
Layout Builder and Paragraphs accessibility gaps
Layout Builder and the Paragraphs module let content teams create complex page layouts. These tools can produce deeply nested markup with broken heading hierarchy and missing landmark structure, especially when content teams combine components in unexpected ways.
CKEditor content without enforced structure
Drupal's CKEditor integration lets content authors enter rich text, but it doesn't enforce accessibility practices. Authors can skip heading levels, insert images without alt text, create empty links, and produce tables without headers.
AJAX-driven content updates without announcements
Drupal's AJAX framework powers exposed filters, infinite scroll, and dynamic content loading. These updates frequently fail to announce changes via ARIA live regions, leaving screen reader users unaware that content has changed.
How Lumi works with Drupal
Lumi scans your Drupal site across all content types, Views pages, taxonomy pages, and custom layouts. Our five engines detect issues in Twig template output, contributed module markup, Layout Builder pages, and author-entered content. Set up monitoring to catch regressions from module updates, theme changes, and content publishing.
Drupal-specific WCAG gotchas
Core accessibility doesn't cascade to themes and modules
Drupal core's accessible markup is only as good as the theme that renders it. A custom theme can completely override core's semantic HTML with non-semantic markup, losing all of core's accessibility work.
Content authoring is the biggest variable
Even with a perfectly accessible theme, content authors can introduce failures through the CMS - missing alt text, broken heading hierarchy, low-contrast text in styled content, and link text like 'click here'.
Drupal major upgrades change rendered HTML
Upgrading between Drupal versions (e.g. Drupal 9 to 10) can change markup patterns, CSS class usage, and JavaScript behaviours. Accessibility must be re-validated after any major upgrade.
Scan your Drupal site for free
See how your site measures up against WCAG 2.2 and EN 301 549 - in 30 seconds, no signup required.
Frequently asked questions
Is Drupal the most accessible CMS?
Drupal core has the strongest accessibility commitment of any major CMS, with a formal accessibility gate that requires all core features to meet WCAG 2.0 AA. However, a Drupal site's actual accessibility depends on its theme, contributed modules, and content - not just core.
Does Drupal meet EN 301 549 requirements?
Drupal core aims for WCAG compliance, which covers many EN 301 549 requirements. But EN 301 549 includes requirements beyond WCAG (like authoring tool accessibility and documentation accessibility), and your specific Drupal site needs to be validated independently.
How do I maintain accessibility on a Drupal site with multiple content authors?
Use Drupal's content modelling to enforce structure: require alt text fields, limit heading level choices, and configure CKEditor to restrict formatting options. Pair this with continuous scanning to catch issues that slip through editorial processes.
Are Drupal accessibility overlays a good solution?
No. Accessibility overlays that promise one-line fixes are not effective on Drupal or any platform. Drupal's architecture actually makes proper accessibility easier to implement at the template and module level, which is far more effective than overlay scripts.
Related resources
Last reviewed: April 2026. Content is reviewed quarterly for accuracy.