As an inclusive community, we are committed to making sure that Drupal is accessible. Content creators and site builders of all abilities should be able to use this platform to reach their audience. Disabilities are an integral part of our human experience. People have permanent, temporary, and situational disabilities. Prioritizing accessibility within Drupal is critical to our values. Digital tools are so embedded with our lives that accessibility is even more critical.

Goals

We are a community that believes in open standards. We  have committed to ensuring that all features of Drupal core align with the guidelines from the World Wide Web Consortium (W3C)’s Web Accessibility Initiative (WAI).

This initiative started in 2009 with adding accessibility advancements for Drupal 7. It was here we first embraced Web Content Accessibility Guidelines (WCAG) 2.0 AA for both front-end and back-end. With Drupal 8, we added support for Authoring Tool Accessibility Guidelines (ATAG) 2.0 (Part A was already included in Drupal 7).

We began evaluating issues with WCAG 2.1 AA shortly after its release. Drupal is currently striving to attain WCAG 2.1 AA.

Our community process and project governance will continue to align with the latest recommended release of the WCAG guidelines.

Drupal was selected by the GAAD Foundation for the #GAADPledge in 2022. This further cemented our public commitment to accessibility. As part of our GAAD Pledge we have created our Accessibility Coding Standards to help guide best practices in our community. 

The Drupal Accessibility Team follows the latest W3C WCAG Recommendations.

Accessibility in Drupal’s Development Process

The Drupal community tries to fix accessibility issues in the development process.  Everything is documented in the issue queue, and tagged for accessibility.

Important issues can block a Drupal release if it fails the accessibility gate.  Our community has decided that accessibility is essential. Major releases have been delayed several times because identified barriers were not fixed.

The team actively works to avoid adding accessibility regressions. When updates and modifications introduce accessibility regressions, fixing them becomes a priority.

Occasionally barriers are discovered after release. If they are critical barriers, then the fixes may be part of an update to the latest stable release of Drupal. This is often avoided as changes to core code can have unintended consequences to live sites.

Some of Drupal’s Accessibility features are described in the handbook.

Automated Testing

We use automated testing extensively. Some of the tools we use include WebAIM’s WAVE, Deque’s Axe and Microsoft’s Accessibility Insights. There is also a list of recommended open source accessibility tools to check common accessibility issues.

We acknowledge that automated tools and checklists have limitations. Manual testing and input from users with lived experience is required to build an inclusive experience.

Assistive Technology 

Drupal encourages and supports the proper use of semantic markup. This is the best way to produce robust experiences that adapt to individual users’ assistive technologies (AT). Common examples of AT include:

  • text-to-speech (TTS) tools like screen readers,
  • speech-to-text (STT),
  • hardware inputs such as keyboards and switch devices, 
  • screen magnification tools,
  • many browser extensions.

As of the most recent update to this document, testing with assistive technologies is primarily done with NVDA and VoiceOver. This is because they are common freely available screen readers. It is also easier to find volunteers who have the most knowledge of these tools. We build on the contributions from both blind developers and other experienced screen reader users as much as we can.

We need more people with lived experience of disability to further improve Drupal's accessibility.

HTML & ARIA

Drupal semantics are defined with modern HTML5 and WAI Rich Internet Applications (WAI-ARIA or ARIA). We use ARIA landmarks to highlight the page regions. We try to limit the use of ARIA where possible. HTML generally provides more consistent support with assistive technologies. 

Core Module

In Drupal Core, we want to build a platform that is accessible by default. This means that features specifically designed to support accessibility are typically enabled.This is because we  assume that most people will want to reach the widest possible audience when building a website. There are some exceptions to this:

  • The Inline Form Error module is part of Core, but is not enabled by default. To have more accessible inline form errors, please consider enabling this module.  
  • You will need to enable internationalization support in CKEditor, if you want to be able to provide support for Language of Parts. 
  • Please suggest updates to this list. There may be other defaults that can be adjusted for specific accessibility goals.

Contributed Modules

Drupal Core usually has stricter criteria than the contributed modules and themes. It is worth noting that this isn’t always the case. We are happy to point to the Webform module as one which has gone above and beyond. Contributed modules may not always comply, but most developers follow community best practices. 

A list of contributed modules which may improve accessibility is available in the handbook. 

Core Themes

Drupal Core themes have been developed with accessibility in mind. Most recently Olivero and Claro have been added to Drupal 9.  Extra effort has gone into the accessibility of the new default theme, Olivero. Olivero is named in honor of community member Rachel Olivero who died  suddenly in 2019. She was a blind developer who was active in promoting inclusion in the Drupal community. 

Contributed Themes

Many of the accessibility challenges are implemented at the theme layers. It is generally an accessibility best practice in Drupal to start with an accessible base theme like Olivero and build out from there. There are non-Core themes constructed with accessibility in mind, but these are not organized.

The list of tools, techniques, & resources in the handbook has also been updated with information that may be helpful. Unfortunately, there isn’t an up-to-date guide for creating accessible Drupal themes. The legacy guide for Accessible Theming for Drupal 7 is still useful.  

Drupal Community Sites

The Drupal community is largely focused around three websites, Drupal.org, Drupal Groups and the API. These are managed by the Drupal Association. These sites are not always running the latest version of Drupal. Some accessibility issues in legacy code may not be prioritized if the barrier will be fixed with an upgrade. 

If you have issues that are stopping your participation, please contribute a bug to the issue queue for that project.

Accessibility Team

The accessibility team has worked to identify and resolve accessibility barriers with Drupal.  Any actively developed software will have some accessibility barriers. The challenge is to  proactively identify those issues and ensure that they are resolved quickly. We have an open issue queue and accessibility issues are tagged so that they are easy to find. This applies to both Drupal core and other projects on Drupal.org

Accessibility is a team effort, and although we have already done a lot, there is a lot more which we should be doing. In Drupal 7, the community decided to see accessibility barriers as bugs, rather than feature requests. This resulted in us raising awareness and changing the culture of the community. 

There are many ways to engage with our accessibility community. Most Drupal events include accessibility.  Drupal also uses Slack as a messaging platform. Please sign up and join the #accessibility channel. We are also hosting monthly A11y Office Hours to talk about accessibility issues in core. 

Please, consider joining #diversity-inclusion for a broader and  less technical discussion about inclusion in our community. 

More information is available about our accessibility community from our handbook

Our Community of Developers and Designers

We need your involvement to make Drupal even more accessible. Here are some common ways people are involved: 

  • reporting bugs
  • testing patches for bugs
  • summarizing long comments threads
  • adding or updating documentation 
  • answering questions on Slack

If you have general questions on how to do this, please post a question to Slack. 

There are lots of ways to become involved.  We strive to make the development and design environment accessible to people with disabilities. 

The Drupal community is generally quite responsive to constructive user feedback. Do let us know what we can do to ensure you are included.