Accessibility is fundamental to the mission and purpose of the web. However, it can be difficult to know if you are following good accessibility practices as a developer or if your site’s content is accessible. For Drupal users, I am excited to announce a remedy to both problems: the Holmes module, which provides easy accessibility debugging at the click of a button.
Introducing the Holmes module
The Holmes module is an adaptation of Holmes – The CSS Markup Detective , which describes itself as “a stand-alone diagnostic CSS stylesheet that can highlight potentially invalid, inaccessible or erroneous HTML(5) markup by adding one class.” In addition to highlighting markup issues, Holmes even makes clever use of CSS to display messages about the specific issues with the highlighted markup. You can find a full test suite of what Holmes can do here.
The Holmes module includes all the Holmes CSS and does all the work to integrate it seamlessly with Drupal, providing accessibility validation at the click of a button. The Holmes module includes the following features:
- Permission-based access to Holmes debugging
- A simple button to toggle Holmes debugging on any page
- Ability to display Holmes debugging information by default on any page using the query parameter holmes-debug=true
The fact that the original Holmes tool requires only CSS only made it very easy to integrate with Drupal, since the only dependency was the Holmes CSS file itself. The downside of this CSS only approach is that there are only a limited amount accessibility issues which can be revealed using CSS. However, some of the issues that can be targeted by CSS are by far the most common accessibility issues, especially missing alt tags on images for Drupal sites. So you can think of the Holmes module as your “first line of defense” for accessibility issues, which you can then supplement with more advanced tools like the WAVE tool mentioned below.
Why this matters
Fundamentally, accessibility is really just an extension of the core principle that the web should be available to everyone. When the web is inaccessible, people are excluded from information the rest of us can access and even the shared sense of digital community. And so it up to us as developers to ensure that we create experiences which are accessible by default.
From an organizational standpoint, when content and functionality isn’t available to a portion of the population, they cannot be a user of the service.
In the context of the web, “accessibility” has a very specific meaning. As defined by the W3C, web accessibility “means people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web.” The most common example people associate with web accessibility is blind users using screen readers to read web pages, but other examples include dyslexic users who may only be able to read certain typefaces and farsighted users that may need larger text to read.
One of the challenges is that not everyone knows what constitutes good accessibility. It can be intimidating to explore formalised accessibility standards like 508 compliance or WCAG, making it difficult to even begin adopting accessibility principles at all. The situation also gets more complex when developing on a CMS platform, where most content is user created and that content is not necessarily vetted for accessibility.
Other Tips for Better Accessibility
Thankfully, Drupal 8 has much better defaults with regards to basic accessibility issues, like requiring alt text when adding images so that there is accessible text for screen readers. At last year’s Drupalcon in New Orleans, my colleagues, Catharine McNally and David Spira, gave a session on accessibility, which covered the changes made in Drupal 8 to encourage better accessibility and tips for developers on how to develop with accessibility in mind. We’ve also shared steps to addressing accessibility in your digital platforms in our Accessibility Playbook which you can download and read more about here.
In addition to good development practices and habits, we also need good tools to validate our work for accessibility. Numerous such tools exist, perhaps the most powerful being the WAVE accessibility evaluation tool, which will inspect webpage markup and give a detailed report on accessibility issues. There are also numerous browser plugins targeting specific accessibility problems, such as this Firefox plugin which checks whether the color contrast of a webpage is sufficient to meet WCAG standards. Color contrast is especially important for colorblind users, who may have difficulty reading web content without sufficient contrast.
Standalone tools for accessibility validation are extremely important and powerful, but especially in the CMS context, we need a tool that lives inside the CMS – which is where Holmes comes in. There are some features that may be added to Holmes in the near future, such as checking for ARIA landmarks, but as always, the best feedback on improvements will come from the community.
So add Holmes to your projects, let me know what you think, and don’t be shy about contributing. Let’s make accessibility elementary on the web.
Sign up for the Phase2 newsletter for exclusive content and news.