Drupal & ADA Compliance
What is ADA?
The Americans with Disabilities Act, and subsequent amendments, is designed “to provide a clear and comprehensive national mandate for the elimination of discrimination against individuals with disabilities”. For websites, this is known as “Website Accessibility”. Read our Website Accessibility post for more info...
Can my Drupal 8 website be ADA compliant?
Yes. And it's pretty close to compliant out of the box with the standard installation profile, at least it is intended to be. But the standard installation isn’t what most people end up with. They start there and add onto it. They can add content, modules, and maybe a custom view or two. And if they are feeling really spicy, maybe they even roll their own theme. Of course, as soon as content starts getting added, an effort must be made to ensure the content itself is compliant. Do all of your images have accessible alternative text? If you are using modules that generate markup for a section of the site, is its markup compliant? What if you’re rolling your own theme? Are your twig files generating compliant markup? Are your colors contrasting properly to maintain readability? There are a lot of things that can affect your accessibility. Being aware of the issues is the first step.
Does my Drupal 8 website need to be ADA compliant?
Short answer: Yes. Long answer: If it isn’t already, you should probably start working on it today! We listed a couple of reasons in our Website Accessibility post, but it isn’t all about the ADA. A lot of the WCAG guidelines are best practices for reasons beyond just visitor accessibility. SEO can be improved if semantic markup is used. Proper markup and page structure can allow search engines to extract meaning and intent from your content. If mobile-friendly was the worst kept secret in SEO for the last decade, accessibility and semantic web is likely to be the SEO winner for the next decade.
How can I ensure my Drupal 8 website will be ADA compliant?
There are a number of methods to ensure compliance with the WCAG guidelines. Most likely you will want to use some or all of the below options as part of your toolkit as they all compliment each other.
Manual Inspection
The most basic option is to manually inspect your site and make changes according to the WCAG/ADA guidelines. This would involve reading through the guidelines yourself and then checking the markup and styling directly on your site to see if it meets the criteria. WCAG AA is the minimum that most legislation is requiring, but AAA is highly desired whenever possible. While this isn’t the easiest method, it is probably the most thorough. Even if you use the other tools and get an audit you’ll probably need to manually inspect and confirm compliance with a few sections of the WCAG guidelines. The most common areas that require manual inspection are going to be labeling. Just because an image HAS alt text, doesn’t mean it describes the image well or is useful. The same goes for section labels, navigation labels, and other parts of a site that describe the functionality and intent behind a piece of content or markup.
Using tools
W3C Validator: While this one isn’t specifically for accessibility, it can show you parts of a page that don’t match the HTML specification. Since failing to meet that specification is an A level accessibility failure, this tool can be used to quickly find validation errors.
Check it out here https://validator.w3.org/
Chrome Dev Tools Accessibility: Chrome browser offers an accessibility audit feature. For an in-depth guide on how to do an accessibility check using Chrome, see https://developers.google.com/web/tools/chrome-devtools/accessibility/reference
Other tools: Many other tools exist. A quick Google search for accessibility checks, validators, or audits will return hundreds of results. Any of them can help you check the accessibility of your site. Recently I came across this nice list of tools you might consider https://dynomapper.com/blog/27-accessibility-testing/246-top-25-awesome-accessibility-testing-tools-for-websites
Get an Audit
Lots of companies offer audits regarding ADA compliance. Some are free and others are quite pricey depending on the level of service you require. Contract one to help you out. While they won’t always fix the issues for you, they are wonderful at pointing out where you are still missing critical components.
Here are some good resources:
Bureau of Internet Accessibility A11y Tool: The Bureau of Internet Accessibility offers a free accessibility audit checking A/AA compliance. They offer more services than just a free audit tool. They are a great resource for any website with accessibility-related questions. The free audit is located at https://www.boia.org/products/free-wcag-2-0-aa-report/
Site Improve: Site Improve is an entire suite of audit tools that show you issues with performance, SEO, Content Quality, Accessibility, and more. Find out more at https://siteimprove.com
Audioeye: “Our suite of products and services are designed to enable equal access, enhance the user experience for all, and provide sustainable, results-driven accessibility solutions for any enterprise with an online presence.” Learn more about Audioeye here https://www.audioeye.com
Use a script to help visitors
This one is more of a quick fix than a proper solution, although it still has a place on otherwise compliant sites. Essentially, the script will load tools that allow the visitor to make the site more accessible for themselves. These tools can range from making all text larger, to increasing contrast between colors. There are many other adjustments these can make to improve a user’s experience. Some even include a text-to-speech component that will read aloud the text from your site.
Here are some we recommend:
Audioeye Ally Toolbar: If you visit the Audioeye site, you’ll see the little Accessibility icon at the bottom right of the screen. This activates the toolbar and lets you adjust major aspects of the site to help with accessibility. Any changes you make are only on your end so you can customize it to what works best for you. This tool can be used on your own site to provide the same level of customization.
Our Solution: A fully automated script that covers about 90% of accessibility issues. It allows site visitors to adjust contrast, font sizing, and more. When a user activates the script it automatically goes through and adds aria attributes where it can to help assistive technology understand the site. There are a number of other handy features to help visitors such as a keyboard accessible menu complete with search and a table of contents style overview of the current page. If you want to try it out, click the little blue accessible icon at the bottom left of our website.
While most visitors that require assistive technology will already have a tool or device that handles this for them, scripts can be an easy way to help visitors that might not require full accessibility. Scripts can also automate a large portion of the work required for accessibility. Because they depend on javascript, they won’t provide any assistance to users with devices that don’t support javascript. Since they are automated, you should still consider manually reviewing your site or getting an audit to ensure full compliance. The one thing scripts won’t help you with? SEO.
Examples of Website Accessibility Issues
Color Contrast Accessibility Issues:
WCAG states that 4.5:1 contrast or more is the minimum for text or images of text. There is an exception for large text (18pt or greater) which allows down to 3:1 contrast.
In this example, the first image shows a contrast that is far too low to meet the minimum. The second image has improved the color contrast to over 5 which meets the minimum specified for AA but doesn’t meet the AAA guideline of 7:1. To fix this, the font size was increased to 18pt font to meet the 4.5:1 contrast requirement for a large font.
For an in-depth post on WCAG for color contrast, the folks over at WebAIM (https://webaim.org/) have put together a comprehensive guide. Read it over if you want further clarification. [https://webaim.org/articles/contrast/]
A tool we’ve used before to find nice colors that meet the requirements is http://colorsafe.co/. It lets you start with a font size and background color, choose your target compliance level, and then get a variety of suggested colors that meet that requirement.
If you just want to check the contrast of your existing colors, a quick tool is https://contrastchecker.com/. It’s very simple to use and it shows you what WCAG guidelines your colors meet or don’t meet.
Navigation Accessibility Issues:
While many web visitors are going to be navigating with keyboard and mouse, others will be using a touchscreen, keyboard-only navigation, voice, or any number of other input devices. To ensure that all visitors are able to properly navigate your site, navigation elements should be readily available. Now, that doesn’t mean you just put menus everywhere. A logical site structure is probably the most helpful in achieving usability for all users. For example, all menus should be in a ‘nav’ element. In fact, any section that just lists collections of links, should be in a nav with a proper unique label. One other important part of navigation assistance is header tags. These are the h1, h2, and other h tags. They should form a hierarchical “Table of Contents” for the page. That means top level is marked with h1, sub items with h2, the children of those sub-items with h3, and so on and so forth. This provides a logical structure to the page that assists with navigating throughout the page. Another important element, specifically for non-pointer navigation, is the focus highlight. This is achieved by using the css outline property on :focus. Most browsers define an accessible `focus { outline: ...; }` by default but a lot of designers don’t like how they look and remove them. To ensure your site is accessible, make sure you: 1. don’t remove the focus and 2. style it so it contrasts with the rest of your site in an accessible manner. If the focus style matches the background color of an element it is highlighting, users won’t be able to use the focus which defeats the purpose of having it in the first place.
Label Accessibility Issues:
Sections of your site need to be labeled in some meaningful way. All input elements need a proper label. And no, the placeholder attribute does not constitute a proper label. Navigation elements need meaningful labels so they can be differentiated between each other. For input elements, you should be using the “label” element with a “for” attribute. For navigation elements and sections, use either `aria-labeledby` set to the ID of the label (usually an h2 or something that labels the section) or if there is no obvious label for a section, you can use `aria-label` to set the label directly. Another form of labeling is alt text on images. It should be descriptive of the PURPOSE for the image. If the image contains important text, the alt text should have this text. Any image that is purely decorative and not used for any useful purpose should have the alt text set to the empty string “” as well as set the role attribute to ‘presentation’.
Ok, I did all that. Am I compliant?
No. Probably not. Maybe? Requirements and regulations change constantly and are always being improved to match the latest technology. Basically, you have taken the first major step toward compliance. “Wait!” you might say, “None of that was specifically about Drupal though?” Correct. Drupal is a content management system, not a quick fix. It is designed to be compliant out of the box, but any modifications that you do from then on need to be compliant as well. While the Drupal community does its best to ensure that the Drupal ecosystem remains accessible, the responsibility for your own site still rests with you. Take ownership and make your site the best it can be.
