By Drupal Association on

Posted on behalf of the Drupal accessibility maintainers and written by Mike Gifford.

Drupal is well known for its accessibility. While not perfect, Drupal made an early commitment to accessibility when Drupal 7 was released at the beginning of 2011. Its release was delayed several months because the core team was working to include accessibility releases for both front-facing and back-end user interfaces. This was a huge step for a general purpose content publishing tool like Drupal. Our community was one of the first to make accessibility accommodations for people with disabilities as not just users, but also as authors. 

At that time, Dries Buytaert, the founder of Drupal, announced that accessibility was going to be one of the core gates of accessibility. It is still rare to see a software project launch get delayed because of accessibility issues. In my experience, this demonstrates when a community really values accessibility.

So when Drupal was nominated for the 2022 GAAD Pledge (an initiative of the GAAD Foundation that works with one influential open source project annually), we knew we had already demonstrated commitment to this part of the pledge.

The GAAD Pledge committed projects to formally update their guidelines to WCAG 2.1. WCAG 2.0 is still the default for many organizations, and Drupal was no exception. WCAG 2.0 was released in 2008, 18 months after the first iPhones were available for sale. Members of the Drupal Accessibility Team started looking at how they would implement WCAG 2.1 AA before it was released. The Accessibility Team has embraced 2.1 informally for a long time. We could have left it there, but we knew WCAG 2.2 and WCAG 3.0 were being developed. As such we updated our commitment to follow the latest W3C WCAG Recommendation. 

We do not have a formal adoption of the Accessibility Coding Standards, but we are close. The Drupal Standards team may want a few additional changes, but we have documented many of the best practices that we have built into Drupal. We looked at other Accessibility Coding Standards, and felt we were able to create a project specific accessibility standard that was going to be helpful in educating people who are new to either Drupal or Accessibility.

This was tied to the important step of cleaning up our documentation. The instructions built into most open source projects are out of date, or incomplete, yet they are so important. This is especially true for accessibility. People new to accessibility, need an entry point that allows them to access the information that is relevant to the latest versions of the project. We’ve worked to improve this for Drupal. 

We have been tracking accessibility issues in Drupal Core and Contrib under the accessibility tag. This is already a long-standing practice, and we have a staggering 2817 open issues. 

How can we be a leader in accessibility, and have so many open issues? Ultimately, it is really a factor of how complex the user interface is, and how actively people are addressing issues. We have an active developer community with lots of modules and themes. 

We recently started tagging issues for WCAG Success Criteria. Going this extra distance helps aggregate issues. With Drupal Core we can better understand the impact of particular issues on populations we care about. It also helps us create an Accessibility Conformance Report (ACR). I’ve outlined the process that we put together for Drupal and ACRs. 

We are hoping to be able to provide a machine-readable ACR into every release of Drupal Core in the form of a simple OpenACR file. 

We’d love to have members of the Drupal community become involved in helping Drupal continue to lead on accessibility. Help us take the next steps to ensure that we are catching accessibility errors earlier. We also hope that everyone takes time to engage in Global Accessibility Awareness Day, where we can share best practices and learn from each other.