Testing accessibility of Drupal 8

The limit of bad usability is the lack of accessibility

– Sergio Lujan Mora

Accessibility refers to the design of products, devices, services, or environments for people with disabilities (How great wikipedia!)

Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Web accessibility also benefits others, including older people with changing abilities due to aging.

In this post I going to show some test that I have done in Drupal 8 about accessibility from 508 compliance until using a screen reader as ChromeVox.


The World Wide Web Consortium (W3C) in its Web Content Accessibility Guidelines (WCAG) 2.0 covers a wide range of recommendations for making Web content more accessible. Following those guidelines will make content accessible to a wider range of people with disabilities. See this for more details about these guidelines.

As I mentioned before I tested Drupal 8 in issues about accessibility, so let’s start

The first challenge: 508 compliance

In a nutshell, 508 compliance means that all users, regardless of disability status, can access technology. It’s a way to break down barriers and provide new opportunities for all Internet users. For this part of the test I used AChecker to evaluate HTML content for accessibility problems by entering 3 pages of proof from Drupal (home, configuration and registration pages). Here the results are.

Drupal Home



Configuration Page


It seems that everything is okay until this part, but let’s see this


Registration Page


AChecker noticed there’s an id that is not unique and it’s not following HTML standard about identifiers.

Here is the line and the id duplicated in the registration page:

By the way, I also reported that bug in Drupal.org

At this part, I didn’t find (actually AChecker) big problems about accessibility, so I decided to go beyond.

Second challenge: A depth audit

In this part of the testing I use AccessLint to check HTML markup and Accessible Rich Internet Applications (ARIA). I also used the same pages as before

ARIA defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. For a better formation, I recommend to read the documentation done by Mozilla Community.

Here are the results:

Configuration Page



The W3C describes this criterion intent as “The intent of this Success Criterion is to help users find content and orient themselves within it by ensuring that each Web page has a descriptive title. Titles identify the current location without requiring users to read or interpret page content. When titles appear in site maps or lists of search results, users can more quickly identify the content they need. User agents make the title of the page easily available to the user for identifying the page. For instance, a user agent may display the page title in the window title bar or as the name of the tab containing the page.”.

It also describes some examples of success as “The descriptive title of an HTML Web page is marked up with the element so that it will be displayed in the title bar of the user agent.”, and actually as you can see, the page has one, so I can not conclude what it wanted to say with that error 😛


Registration Page



In this test, I had the same issue as before and another one. That is because aria-expanded just accepts three right values true, false and undefined.




Here we have two well-known problems, but our interesting is the ARIA warnings that are so long and therefore I leave my test link here to be reviewed. However the markup showed doesn’t contain any ARIAstate or property, so I’m not sure what it detected :).

Ok, until here everything seems working fine according to our automated testing but “automated accessibility checkers can only identify a limited number of barriers in Web content with certainty. A human must interact with an accessibility review to make decisions on potential problems automated tools can not identify. For example, any check that requires the evaluation of meaning, such as whether link text accurately describes the purpose of a link, or whether Alt text sufficiently describes the meaning contained in an image, a human must make a decision.”

Making the test more human-dependent

At this point I decided to test the contrast of Drupal 8 using the most important part of a site, the home page where content are showed and the content itself. Let’s see how it was.

The Web Content Accessibility Guidelines define some recommendations in order to get a good contrast in our sites. To test this I used Color Contrast Analyzer, which is an extension for Google Chrome that allows us to analyze text color contrast problems on a webpage according to the WCAG 2 text color contrast requirements. So, at first I tested a W3C guideline to demonstrate how a good contrasted page will look before the extension makes its work.


Here are some interesting css properties to have in mind and make that the page has that contrast



The most important properties to get this are the background color, the font color, size and family. The recommendation about fonts is that they should have at least 1em(16px or 100%) of size, but in fact some fonts are bigger than others. For example Arial is bigger than Georgia (which is the font that Drupal seven theme uses).

So, this was the result for Drupal 8:

Testing an article


This improved when I change the color #3b3b3b by #111

And it was pretty good when I also increased the size of the font or changed it by Arial

My test changes just improve the main content, notice that the links doesn’t have almost contrast, without saying that in the home page, the font for the summarize of the article is smaller.

I also made a random test for the login block and the menu navigation


Making it human-tested: Screen Readers

In this part of the article I would like to show you my conclusions about the use of Screen Readers for Drupal 8, the screen reader used for this occasion was Chrome Vox

The first good impression

Using a screen reader activates the skip navigation link of Drupal that is useful when keyboard-only users interact with our site, they use the tab key to jump from link to link. If we have a lot of links at the first of our page in our header or in a menu, they must tab through those every time they come to a new page just to get to the main content. Providing a skip to main content link allows them to easily bypass this and therefore it’s considered as a good accessibility practice.


Testing the reading
Drupal 8 has good text containers that allowed me to navigate from the site using the mouse to mark easily the sections that ChromeVox should read and all reading was good to me (Note: I don’t have to much experience using this kind of tools because I don’t need it).

Minor issues

However, I found two issues during this. One of them is that when It had to read the publishing information it found an abbreviation of the day (in this case Mon of Monday), which is not a good practice.


And the other one was when it had to read the Feed RSS icon. ChromeVox said “Subscribe to…” and that is because the alt attribute is not well defined.


A really big issue

A site implements a skip navigation link because we want that the user use the keyboard to navigate through our site (using keys as tab). Well, to me the most important contents in a Drupal site are the nodes and this is what happened when we press Enter in the skip navigation link


It redirects us to a container without test when to me it should read the first article published title. But this doesn’t finish here, if you navigate more using tab you’ll notice that the publishing info is not taken entire (just the user who publised it) and the article itself is NOT read!




Web accessibility is a difficult concept to understand and is often misunderstood. Actually, it is difficult to implement fully for every kind of disabilities or difficulties that could prevent one user to access the content of a website. Indeed, the different natures of all these difficulties and the specific needs they imply are too vast to be answered all; the idea of answering them all would be a utopia: because it is impossible to list each and every difficulties encountered; because it is impossible to understand each and every disability when not being affected by them; and because, sometimes, a solution answering a particular problem may be a problem for someone else.

However, in this post I showed you some elemental requirements for an accessibility using Drupal and we noticed that a one important and not too difficult issue to resolve is the hierarchy of font size in its core themes that seems don’t have enough contrast and actually is has caused a some discussions about this topic in Drupal.org (see this, this and this) and I think is because there are no effective statements in Drupal design standards about accessibility.

There’s another important issue that is about the behaviors of Screen Readers and being honest I the intention of this article is get that you join to the initiative in order to create a Drupal more accessible. If you’re a person interested in accessibility issues why don’t you join to the accessibility group and start helping to fix some?



Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s