Drupal is an inclusive open source community. Accessibility is part of how Drupal is designed, built, reviewed, and improved. Content creators, site builders, administrators, and visitors with disabilities should be able to use Drupal.
Disability is part of the human experience. It may be permanent, temporary, or situational. Accessible design helps more people participate and makes digital experiences more resilient.
Drupal core provides accessible foundations and defaults. A finished Drupal site is not automatically accessible. Accessibility also depends on configuration, content, contributed modules and themes, custom code, and ongoing testing.
Drupal supports open standards. Drupal core targets the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA for both public-facing and administrative interfaces. The community also uses the Authoring Tool Accessibility Guidelines (ATAG) 2.0 to guide the authoring experience.
Drupal began a formal accessibility initiative in 2009 during the development of Drupal 7. The community adopted WCAG 2.0 AA as a target for the front end and administration interface. Drupal 8 expanded this work by incorporating ATAG requirements.
These standards guide development and review. They do not mean that every Drupal interface, contributed project, or Drupal site conforms to every requirement.
In 2022, the GAAD Foundation selected Drupal for the GAAD Pledge. Work associated with that pledge included publishing Accessibility Coding Standards for Drupal core and contributed projects.
Drupal treats accessibility barriers as bugs. Contributors document them in public issue queues and use the Accessibility issue tag to make them easier to find.
Significant changes to Drupal core must pass the accessibility quality gate. The gate can block a change until accessibility concerns are reviewed and addressed. Passing the gate is an important safeguard, but it is not a complete conformance assessment.
Contributors work to prevent accessibility regressions. When a change introduces a barrier, resolving the regression becomes a priority. Critical barriers discovered after a release may be fixed in a stable release when the change can be made safely. Maintainers must also consider backward compatibility and the risk to existing sites.
The accessibility guide documents Drupal features, coding standards, review methods, and ways to contribute.
Automated tests help contributors identify common accessibility problems. Contributors use tools such as WAVE, axe DevTools, and Accessibility Insights. Automated tests should examine the rendered page, including relevant components and interaction states.
Automated results are evidence, not proof of WCAG conformance. Tools can identify only a subset of accessibility barriers. Reviews also need keyboard testing, zoom and reflow testing, inspection of names and semantics, and testing with assistive technologies.
Checklists and technical tests cannot replace feedback from people with disabilities. Testing with people who have lived experience helps identify barriers that tools and reviewers may miss.
Drupal’s public issue queues record known accessibility barriers, but they are not a complete assessment or an Accessibility Conformance Report (ACR). Organizations that need formal documentation can follow Drupal’s ACR process.
An assessment should identify the Drupal version, interfaces, tasks, configuration, test methods, and environments included in its scope. It should also document known limitations. An assessment of Drupal core cannot establish conformance for a finished site that includes contributed projects, custom code, and content.
Drupal encourages semantic HTML that works across browsers and assistive technologies. Assistive technology includes:
Drupal accessibility reviews commonly include NVDA and VoiceOver because they are widely available and familiar to many contributors. Coverage varies by issue and contributor. No single browser and assistive-technology combination represents every user.
People with disabilities contribute to Drupal as developers, designers, testers, content creators, and site builders. More participation from people with different disabilities and access needs will improve Drupal.
Drupal uses modern HTML to communicate structure, relationships, and controls. Native HTML elements are preferred when they provide the required semantics and behavior.
Accessible Rich Internet Applications (WAI-ARIA) can provide information that HTML cannot express. Drupal uses ARIA where it is necessary, including names, states, properties, and landmarks. ARIA does not add keyboard behavior or repair incorrect HTML, so implementations still require testing.
Drupal core aims to provide accessible defaults. Features designed specifically to support accessibility are generally available without additional contributed code. Configuration can still affect the resulting experience.
Defaults and available features can change between Drupal releases. Test the Drupal version and configuration that the site actually uses.
Contributed modules are maintained independently and do not pass through the Drupal core accessibility gate. Their accessibility varies by project, version, configuration, and use.
Review a module’s interface, issue queue, release history, and test coverage before relying on it. The Webform module is one example of a contributed project that has invested extensively in accessibility. The accessibility guide also lists contributed modules that may support accessibility. Inclusion in that list is not a certification.
Drupal core themes are developed with accessibility as a priority. Olivero is the default theme for public-facing pages. Claro provides the default administration experience. Both continue to be reviewed and improved through the Drupal core issue queue.
Olivero is named in honor of community member Rachel Olivero. She was a blind developer and an advocate for accessibility and inclusion in the Drupal community.
The theme layer can introduce or remove accessibility barriers. Starting with an accessible core theme and reusing tested Drupal patterns can reduce risk. Custom styles, templates, components, and JavaScript can still change the result.
Drupal.org does not currently certify contributed themes for accessibility. Evaluate each theme in the context of the site, its content, and its enabled modules. Use the Accessibility Coding Standards and the guide to performing an accessibility review.
Drupal.org, API.Drupal.org, and related community properties are services managed by the Drupal Association. Their accessibility is separate from the accessibility of Drupal core. These sites include different applications, integrations, and legacy code.
If a barrier prevents or limits participation, report it in the Drupal.org issue queue. Include the affected page, the task you were trying to complete, what happened, what you expected, and steps to reproduce the problem. When relevant, include the browser and assistive technology used.
Drupal’s accessibility contributors identify barriers, review changes, improve documentation, and help maintain accessibility standards. Accessibility issues remain visible in the public issue queues for Drupal core and contributed projects.
The community needs developers, designers, writers, testers, and people with lived experience of disability. Prior accessibility expertise is helpful but is not required for every contribution.
Join the Drupal Slack workspace and use the #accessibility channel for technical questions and coordination. The Accessibility Topic Maintainers also host monthly accessibility office hours. The #diversity-inclusion channel supports broader discussions about inclusion in the community.
Accessibility is a shared responsibility. There are many ways to help:
Start with the accessibility contribution guide or ask in the #accessibility Slack channel. Constructive feedback helps Drupal remove barriers and include more people.