Essential Drupal Accessibility Modules and Themes

Web accessibility, building digital experiences that people with disabilities can use, has moved from good practice to legal requirement. Since 2025, the European Accessibility Act and a US Department of Justice rule under the Americans with Disabilities Act have made WCAG conformance mandatory for many organizations, with real deadlines and litigation risk attached. For governments, universities, and nonprofits especially, an accessible website is now a compliance obligation as much as an inclusive one, and Drupal gives them a strong foundation to meet it.

What accessibility standards and laws apply to your website in 2026?

Two things now determine your obligations: the WCAG standard, which defines what an accessible site is, and the laws that make a version of it mandatory. The Web Content Accessibility Guidelines (WCAG) are produced by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative, and organized under four principles: perceivable, operable, understandable, and robust, at conformance levels A, AA, and AAA.

The current version is WCAG 2.2, published as a W3C Recommendation on 5 October 2023 and later adopted as an ISO standard. It added nine success criteria to WCAG 2.1, including visible focus appearance, alternatives to dragging movements, and a minimum 24 by 24 pixel target size, and it is backwards compatible, so meeting 2.2 also meets 2.1. WCAG 3.0 exists only as an early working draft and is years from being a requirement, so it should not drive decisions yet.

The laws that reference WCAG are what create deadlines:

• European Accessibility Act (EAA): enforceable across EU member states since 28 June 2025, requiring consumer-facing digital products and services to meet EN 301 549, which references WCAG 2.1 AA. It reaches non-EU organizations that serve EU users.
• ADA Title II (United States): the Department of Justice's 2024 rule adopted WCAG 2.1 AA for state and local governments, including public universities, school districts, and libraries. After a 2026 extension, entities serving 50,000 or more people must comply by 26 April 2027, and smaller entities and special districts by 26 April 2028.
• Section 508 (United States federal): requires WCAG 2.0 AA for federal agencies and the vendors that sell to them.

The practical takeaway is that WCAG 2.1 AA is the binding floor almost everywhere, and building to WCAG 2.2 AA is the safe forward step, since it satisfies 2.1 and future-proofs the work.

Why is accessibility now a compliance requirement, not just good practice?

Accessibility is now a compliance requirement because the laws above turned WCAG from a recommendation into an enforceable standard with penalties, deadlines, and procurement consequences. Organizations that fall short face litigation, regulatory action, and exclusion from government contracts, and public bodies now have fixed dates to meet. The older argument, that accessibility widens your audience and improves experience for everyone, is still true, but it is no longer the main reason leadership acts.

Two cautions matter here, because both are common and both fail. Accessibility overlay widgets, the plug-in toolbars that promise instant compliance, do not fix the underlying code, often fail to deliver real access, and provide no reliable legal protection. And automated scanning alone is not enough: automated tools catch only a minority of issues, so manual expert review and testing with real assistive technology remain necessary. Accessibility also depends heavily on content, since alt text and heading structure are created by editors, not by the platform, which is why it has to be managed continuously rather than fixed once.

Our view: accessibility is a governance problem, not a one-time audit

Our view: accessibility is a governance problem, not a checklist you complete once. The organizations that stay compliant are the ones where accessibility is built into the theme, the components, and the editorial workflow, so every new page inherits it, rather than being audited back into shape after each launch or redesign.

In Vardot's work building accessible platforms for public-sector, university, and nonprofit clients, a one-time remediation project almost always decays, because new content and new campaigns reintroduce the same issues within months. What holds is an accessible foundation plus in-workflow checking: an audited theme and component library so the markup starts correct, a checker that flags problems while authors write, and periodic audits as part of ongoing maintenance. Compliance becomes a property of how the site is run, not a sprint before a deadline.

How does Drupal support web accessibility?

Drupal supports web accessibility strongly at the platform level, which is why it is widely used for government, higher-education, and nonprofit sites that must meet WCAG. Accessibility is maintained by a dedicated Drupal Accessibility Team, and much of what used to require contributed modules is now handled in core.

• Olivero, the default theme: Olivero has been Drupal's default front-end theme since Drupal 10, developed with accessibility as a first-class requirement and tested by the National Federation of the Blind. It provides a WCAG 2.1 AA baseline: sufficient contrast, visible focus indicators, semantic landmark regions, keyboard-navigable menus, skip links, and support for multilingual and right-to-left languages such as Arabic.
• CKEditor 5 and core semantics: Drupal 10 and later ship CKEditor 5, a more accessible editor, along with semantic HTML5, WAI-ARIA landmarks and live regions, the Drupal.announce() API for screen-reader messages, and an accessible inline form errors module you can enable in core.
• Editoria11y for in-workflow checks: Editoria11y is a multilingual, real-time accessibility checker that gives authors live feedback as they write, flagging missing alt text, heading and link problems, and contrast issues, with site-wide reporting. It is included in the Drupal CMS accessibility tools recipe, and an AI Editoria11y add-on offers a "Fix with AI" suggestion inside CKEditor 5.
• AI-assisted alt text: AI modules can generate descriptive alt text using vision models, and Varbase AI auto-generates alt text as images are added, which closes the most common content-level gap before it reaches a page.

Keeping the platform current is itself part of compliance: Drupal 7 reached end of life in January 2025 and Drupal 9 in November 2023, so sites on those versions receive no further accessibility patches. Drupal 10 and 11 provide the strongest accessibility foundation, and Drupal 10 reaches end of life on 9 December 2026, which makes Drupal 11 the version to build on.

How do you keep a Drupal site accessible over time?

You keep a Drupal site accessible by making the compliant path the default and checking it continuously, rather than treating accessibility as a pre-launch task. The practices below are what turn conformance into something that lasts.

• Start on an accessible foundation: build on Olivero or an audited accessible theme, and a component library with accessibility built in, so markup starts correct.
• Check inside the editorial workflow: run Editoria11y so authors catch missing alt text, heading, and contrast issues as they write, since content is where most regressions occur.
• Test in layers: combine automated scans with manual expert review and testing on real assistive technology, because automated tools alone miss most issues.
• Avoid overlay widgets: they do not remediate the underlying code and offer no reliable legal protection.
• Govern and document it: publish an accessibility statement, require WCAG 2.1 or 2.2 AA in procurement through VPATs and conformance reports, and run periodic audits as part of ongoing support and maintenance.

How Vardot raised accessibility standards for the IASLC

Vardot has extensive experience building accessible open-source digital experiences that meet W3C standards, including the project for the International Association for the Study of Lung Cancer (IASLC). The IASLC had an outdated site that was hard to maintain, carried multiple SEO errors per page, made key content hard to find, and needed its accessibility improved.

Vardot mapped clear user journeys to inform the site structure, then rebuilt the site on Varbase, Vardot's Drupal distribution, as a mobile-first platform that met modern accessibility standards. The rebuild gave non-technical staff an editing experience they could manage, added multilingual support including right-to-left Arabic, and restructured content for findability and search. At the time, the work reduced SEO errors by 99% and raised the site's accessibility score to around 90% on Google and IBM tooling.

Getting your site to WCAG compliance

Accessibility is now both a legal obligation and a way to reach more of your audience, and for public-sector, higher-education, and nonprofit organizations the deadlines are already set. The most reliable path is an accessible platform paired with a partner who builds compliance in from the start and keeps it there through ongoing checks and audits, rather than a one-time remediation that decays. Whether you are upgrading an existing site or building a new one, Vardot builds and maintains accessible Drupal experiences designed to meet WCAG 2.1 and 2.2 AA and the laws that require them.

Accessibility deadlines are already on the calendar, and for governments, universities, and nonprofits the cost of missing them is measured in litigation risk and lost trust, not just remediation. Vardot builds and maintains accessible Drupal experiences designed to meet WCAG 2.1 and 2.2 AA and the laws that require them, from an audited foundation to in-workflow checks and ongoing audits.