Accessibility

Drupal is an inclusive open-source community. Accessibility is an integral part of how Drupal is built. 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 enables more people to participate and makes digital experiences more inclusive. 

People with disabilities contribute to Drupal, just like everyone else. With more participation from people with different disabilities, access needs will improve.

While Drupal core provides strong 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.

Accessibility Standards

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.

In 2022, Drupal took the Global Accessibility Awareness Day (GAAD) Pledge to formalize accessibility as a core value of its framework. As part of this commitment, Accessibility Coding Standards were established for Drupal core and contributed projects.

These standards guide development and review. They do not mean that every Drupal interface, contributed project, or Drupal site conforms to every requirement.

Accessibility in Drupal’s Development Process

Drupal treats accessibility barriers as bugs. Contributors should 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’s primary purpose is to block updates to the code if they contain serious accessibility concerns. Passing the gate is an important safeguard, but it is not a complete conformance assessment.

Contributors must also 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.

Testing

Automated tests can help contributors identify common accessibility problems more quickly and easily. Contributors can use tools such as WAVE, axe DevTools, and Accessibility Insights to assist their review. Automated tests should examine the rendered page, including relevant components and interaction states.

Automated test results are evidence, not proof of WCAG conformance. Tools can identify only a subset of accessibility barriers. Reviews should also include manual 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 by people who have lived experience with disabilities helps to identify barriers that tools and reviewers may miss.

Conformance Reports

Drupal’s public issue queues provide a record of 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.
 

Assistive Technology

Drupal encourages semantic HTML that works across browsers and assistive technologies.
Assistive technology includes:

• Screen readers and other text-to-speech tools
• Speech recognition and other speech-to-text tools
• Keyboards, switch devices, and alternative input hardware
• Screen magnification and display customization tools
• Browser and operating-system accessibility features

Drupal accessibility reviews commonly include NVDA and VoiceOver because they are widely available and familiar to many contributors. Coverage of assistive technology varies by issue and contributor. No single browser and assistive-technology combination represents every user.

HTML and ARIA

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.

Modules

Core Modules 

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.

• The Inline Form Errors module is included in Drupal core but is not enabled by default. Enable it to provide error messages next to relevant form fields.
• Configure CKEditor when authors need to identify changes in the language of content.
• Review content formats, editor controls, media, forms, and other site-specific features as part of accessibility testing.

Defaults and available features can change between Drupal releases. Test the Drupal version and configuration that the site actually uses.

Contributed Modules

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.

Themes

Core Themes

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.

Contributed Themes

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 Community Sites

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.

Get Involved

Accessibility Team

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.

Other Ways to Contribute

Accessibility is a shared responsibility. There are many ways to help:

• Report accessibility barriers and explain who they affect.
• Test changes with keyboards, assistive technologies, and accessibility tools.
• Review patches and reproduce reported problems.
• Summarize long issue discussions.
• Write and update documentation.
• Answer questions and welcome new contributors.

Start with the accessibility contribution guide or ask in the #accessibility Slack channel. Constructive feedback helps Drupal remove barriers and include more people.