Skip to main content
Hero Background Image

Exploring Drupal’s Built-in Accessibility Tools

April 15, 2019

Planning early and often for web accessibility creates a better experience for site visitors who have disabilities, as well as those who live in an area with connectivity issues, or those without access to the most up to date technology. Because of this, we want to go out of our way to do as much as we can to ensure that every experience is accounted for when we begin to plan, design, and develop a new website build. The best way to go about doing this is to start with an accessible CMS (content management system) right at the start, which is why we lean on Drupal. Drupal has a dedicated accessibility team continuously working to create a strongly accessible system from the very moment of the site install. 

Accessibility Out-of-the-box

What does it mean for Drupal to be accessible out of the box? We tend to think of this in the basic terms of what is needed to meet  WCAG 2.1 guidelines: the alt text on images is required (this is true for Drupal 8), forms have labels by default, the base admin theme is easily keyboard navigable, etc. Beyond accessibility, the Drupal community takes an even broader view, showing a big interest in constantly trying to upgrade the platform to allow access to all people with visual, physical, verbal, cognitive, and other disabilities. 

Choosing Drupal means you are creating a website that has a strong focus on these issues both in the current build and any future upgrades as the project continues to grow. 

Exploring Drupal’s Accessibility Features 

Even with all that we know already in there, digging deeper we found there was more to Drupal’s accessibility features than even we were aware of. Heading to the list of Drupal accessibility features or Drupal 8 specific features you can find a plethora of items that are being added under the hood. These include a more accessible search engine form and presentation, drag and drop functionality, and other interesting things such as a JavaScript library that works specifically with screen readers and controlled tabbing order. 

Things to be Aware of with Drupal

With all that Drupal is providing to meet expected accessibility for websites, there are still little “gotchas” that you should be aware of when building a new site. Like any CMS, it’s best to have some accessibility checkers (both manual testing and automated tools) in your back pocket.  


Drupal has created great starting themes that come with strong color contrasts to allow for the visually impaired to see different elements on a website easier. This doesn’t just affect those with low vision but also those with color blindness. For example, the header for this has really poor contrast:

poor color contrast

For somebody with red/green colorblindness it looks more like this:

poor color contrast in a green header

For those with colorblindness, the Drupal default theme looks like this:

color contrast in Drupal default admin theme

With such a high contrast the site’s information is still accessible to those with this specific visual impairment. To test the colors on your website, WebAIM has a handy tool just for that.

Themes May Vary 

Not every theme comes with the same accessibility features. Be aware when you are choosing a parent theme to work from exactly what it offers. On top of that, frontend developers who are using the base themes as a starting point to create their own child theme need to be aware of what is available, so they know what they have to work with when creating their own child theme. Some accessibility items are being rendered in the parent theme using different variables in the templates. It’s important to be aware of what these are so that they aren’t overwritten and the built in accessibility features get stripped away.

Modules May Vary

The same goes with modules. When plugging in a module to cover a specific bit of functionality for your website, check to see if the module has the D7AX or D8AX tag attributed to it. The Token module has it in their pledge about maintaining an accessible project. You can see it here: 

module accessibility statement

This tag communicates to the user that the selected module was crafted with accessibility in mind. Those that don’t have the tags may not have the needed accessibility. You may not be able to find a module every time that you need that also has the tag of accessibility approval so when you find one that you need to use that doesn’t have it, be aware that it means you’ll have to make up for the accessible shortcomings of what you are using.

Test it!

Another accessibility issue to be aware of when theming is to test any third-party JavaScript library that you enable. Some can break accessibility feature of a website when added to a theme. Much like modules, when researching a JS library check to see if accessibility is mentioned. Also, be aware that certain CSS styles can adversely affect built in functionality as well, such as setting a tabindex to -1 will cause it to become the first tabbed item on the page instead of the “skip to main content” link. Proper testing can help to catch any of these potential issues, so be certain to take a bit of time for QA. 


We already know that accessibility is important. Without it, the online world would effectively cut off many people from accessing resources and information. Making certain that your site addresses these issues often times starts at the very beginning by choosing an accessible platform to start from. As one of these platforms, Drupal makes a point to be as accessible as it can out of the box but be sure you take a moment to become aware of just how much it offers from base install to parent theme, modules, and third party resources. And just as important, once you know what you’re working with, be certain you don’t accidentally remove any of it when creating or working on a child theme.