Accessibility tools for Developers & QAs

There are plenty of Accessibility tools that can help us improve our web sites/apps for more people. Choose your flavor and begin testing.

Martín Collazo
UX Collective

--

Illustration of a group of people with different dissabilities smiling.
Vector of Various people by pch.vector from Freepik.

FFor a long time accessibility has been an afterthought in the development process of sites, apps, and whatever thing you wanted to run on the web. Accessibility, A11y for short, has been around almost since the web began, but for various reasons it’s been neglected from the development process. I tend to believe that this has to do with a particular vision that, because of dedicating time to search for accessibility problems, run tests, etc; projects are going to be delayed or have additional extra costs to it, making it a hard sell for clients.

In recent years, there has been a shift in the industry towards inclusion, better user experiences, and making the web a more emphatic place. This has had positive consequences, like more people understanding its relevance and paying more attention to the subject (including myself 🙋‍♂️) thus resulting in more resources available, more conferences, and more tools were developed aimed at Designers, Coders, QAs, etc; and so on.

Automated tools for an Accessibility Review

The Web Content Accessibility Guidelines are a set of rules and recommendations developed in cooperation with individuals and organizations around the world.

Its goal is to provide “a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally”.

To perform an Accessibility Audit/Review following the WCAG guidelines over a website/web app, there are a series of steps that need to be done:

  1. Use automated tools to analyze it.
  2. Navigate the site with a keyboard only.
  3. Navigate the site with a Screen Reader.

In this article I will focus on the first step: use automated tools to easily find accessibility errors. Even if you don’t plan on making a full audit, doing this step will allow you to make quick fixes and improve the experience for everyone.

I suggest that you choose (at least) any 2 of the tools listed here to run tests. This is because they may have differences in the way they scan and analyze sites/apps. When you are running tests, the more feedback you can get, the better. But also be aware that automated tools aren’t perfect, especially those that scan code, and while they can detect common problems such as missing or invalid properties, sometimes they lack the context to properly identify something as an issue.

TIP: perform these tests while browsing on Incognito/Privacy mode to avoid extensions or other settings from interfering with the scan and thus the results.

Favlets

The first group of tools is Favlets. These are a type of bookmarks that when clicked on a specific page, execute JS code that checks the HTML document’s source code and detects violations of a defined presentation or accessibility standards. The following list features various tools that analyze the code against the WCAG or the Section 508 requirements.

CodeSniffer

HTML_CodeSniffer is one of my preferred tools because of how easy to use it is. CodeSniffer also gives you a way to write your standards, which can be useful in situations where you wish to enforce consistency across a web site. And offers other alternatives to use it: by calling it directly in JS source, run on the command line with the assistance of a headless browser app, or using it as a Node.js module. I prefer it’s bookmarklet interface, but feel free to give a try to the other options too.

Screenshot of CodeSniffer in action on google.com
CodeSniffer in action, even Google has room for improvements.

Examinator

I want to highlight this tool made by Carlos Benavidez, a Developer from Argentina as myself. Examinator can work either as a bookmarklet or by entering a URL in its website. Although it hasn’t been updated lately due to the Developer sadly passing away, it still works well and I like it because of the feedback it gives. Examinator tells you which guidelines are related to each item and this comes handy when writing an Accessibility audit/assessment.

Screenshot of Examinator’s homepage.

Naked Styles

What this does is simple, it removes all the CSS on a page. Why would you do that? Well, by striping the CSS you can see all tags with the browser’s default styles and may help you realize you didn’t use the best HTML tag in a particular scenario.
I don’t recall from where I got this bookmarklet, so no credits. Sorry about that 🙏.

tota11y

It’s a really neat tool by Khan Academy that once you run it stays on the bottom-left corner of the web page and has several checks you can make. It highlights the goods and the bads that it finds inside the document and explains why is that. I like the “Screen Reader Wand” functionality because you can quickly fix some S-R issues before doing Screen Readers tests.

Screenshot of “totally” working on the digital newspaper infobae.com
Images are missing alt text.

Various JavaScript Bookmarklets

These bookmarklets use JavaScript to highlight roles, states, and properties of accessibility elements on the page. These are mostly an alternative to the previous tools mentioned, so feel free to try them all and pick the one it works for you.

Browser Extensions / Features

The following tools have at least a version that runs as browser’s extensions or plugins. I have included some features that are useful too.

Accessibility Insights

This tool made by Microsoft, is really interesting because it can not only be used to tests webpages/apps but also Android and Windows native apps. I tried the Web version that offers 2 testing modes: Fastpass and Assessment. Fastpass can be used to catch the most common accessibility issues very quickly. It’s a good approach when you just want or need to run a quick test.
Assessment, on the other hand, is a manual experience in which you navigate through a set of tests that cover all WCAG 2.1 AA success criteria. Each test has one or more requirements that can be: Automated, Assisted, or Manual. Overall is a very complete tool worth giving a try, the only feature I think is missing is a Firefox extension.

Screenshot of the “Testing Tabs” functionality of Accessibility Insights on mercadolibre.com
Testing Tab stops on MercadoLibre.

Axe by Deque

Axe is an a11y testing toolkit that runs as a browser extension available for Firefox and Chrome or an Android App. The Web version sits within the Developer Tools and helps you identify and resolve common accessibility issues by giving you a description of the issue and guidance on how to solve it. It can be used to do single-page tests or test hundreds of pages while integrated into existing CI/CD processes. It’s fairly simple to use, and doesn’t require advanced accessibility knowledge to get started.

Screenshot of Axe’s homepage.
Axe’s homepage.

Funkify

This is an extension for Chrome that helps you experience the web and UIs through the eyes of users with different abilities and disabilities. You can simulate blurry vision, dyslexia, partial vision loss, trembling, and more issues that people could have while browsing your website. If you upgrade, there are more options to add to the list.

Screenshot of LenioLabs’ homepage altered by a Funkify’s preset in action.
LenioLabs’ homepage altered by a Funkify’s preset in action.

LightHouse

Lighthouse is an automated tool developed by Google that allows you to analyze web apps/pages, obtain metrics and insights that will help you improve its performance. You can also use it to analyze pages that require a password, which is handy a feature. Lighthouse can audit accessibility, performance, SEO, and more. You can use it in various ways: In Chrome DevTools, from the command line, as a Node module, and finally from a web UI. As you can see, Lighthouse is a very complete tool that can help you not only with a11y testing but with quality assurance too.

Screenshot of Ars Technica’s website with Lighthouse’s score on display.
Lighthouse just finished auditing Ars Technica’s website.

NoCoffee

NoCoffee is a Chrome extension similar to Funkify that can simulate vision problems like low acuity, low contrast sensitivity, colorblindness, and more. The difference between them is that NoCoffee has more granular controls for each setting and it’s completely free.

Screenshot of twitter.com with NoCoffee’s filter activated.
NoCoffee in action on Twitter’s home.

WAVE

WAVE is one of my favorite tools from the list, it was launched in 2001 by WebAIM as a free community service. Like other tools listed here, you can use it to identify accessibility and WCAG errors and also facilitate the human evaluation of web content. It can be used in many ways: by entering a web page address, by installing the WAVE Firefox and Chrome extensions (very useful for checking password-protected pages), a WAVE Runner service, an API, and a stand-alone version for collecting data on many pages. It’s been recently revamped and given a much-needed face-lift.

Screenshot of dribbble.com scanned with WAVE.
Dribbble scanned with WAVE.

• Built-in Features

Browsers have been recently adding more features in their Developer tools towards better Accessibility testing and it’s really good news. Here I present a very short list of related links about them.

Web Tools

The tools listed below require that you give them a URL to test, so they may not be suitable for instances where you need to test something that is behind a login form, etc. Anyways, they are pretty useful too so make sure you check them out.

AChecker

This is another tool that scrapes websites and detects potential a11y errors. It gives you feedback about what could be wrong with your markup and which WCAG success criteria refer to. You can either enter a URL, upload a file, or paste the code directly inside a text area. It lacks an update to version 2.1 of the WCAG rules, but it still can help you get started in the search for errors anyway.

Button Contrast Checker

This tool can test your buttons to check if they have enough contrast and are compliant with WCAG 2.1. Just enter a URL and it will test default, hover and focus states and compare the button’s background versus the adjacent background. It also offers guidelines on Color Contrast with examples that are very clear and useful.

Screenshot of the Results page of Button Contrast Checker.

🔎 On my Radar

The following list includes a variety of tools and services (Accessibility as a Service!) that I find pretty interesting, but haven’t given them a try yet. So if you already know or tried them, let me know your experience in the comments section.

Bonus track: Create and verify PDF accessibility (Acrobat Pro)

These are evaluation tools that will help you with automated tests. However, no tool alone can determine if a site meets accessibility standards. Human evaluation is required to determine if a site is accessible. Keep in mind that these tools by no means are going to reveal every a11y problem your project could potentially have. You can trick them into giving you a perfect score while having a total unusable site/app. The best way to evaluate web accessibility compliance is by making a complete assessment/audit.

I hope you find this article interesting. Let me know in the comments what you think, recommend tools, or whatever you want to say.

Let’s continue making the web a better place for everyone! 💪

Thanks to Sergio, Mariana, and Agustín Capeletto for reading and reviewing this article.

More info and Trivia

  • The reason why I sometimes referred to Accessibility as “a11y” in the article, is because there are 11 letters between the “a” and the “y,” so you can shorten it that way.
  • When tools check for color contrast, sometimes they can detect that there are issues with text color and the background image it has behind, even if you can see that the contrast is just fine. This is because the tools don’t check the image set as CSS’s background, but the background-color value. These are sort of false-positives, and the best way to fix them is by making sure you have set a background-color that will allow the user to read that text even if the image couldn’t be loaded.

--

--