Testing for Web Accessibility is important, as it removes barriers and makes our virtual world more inclusive. And it's part of our responsibility as developers, designers, and content creators. (If you are curious to dive deeper into why we should be testing for Accessibility, I am working on another article on that topic)
There are many different ways to test for Web Accessibility, and one very effective one is by using Chrome DevTools. Let's dive right in.
A good first place to start your Accessibility testing journey is automated testing. Accessibility tests are build into Lighthouse, so at the same time you are running your performance tests, you can check Web Accessibility.
Be ware that automated tests don't necessarily catch all the bugs and a perfect score doesn't equal a perfect website, but it's a great first start and catches a lot of issues already.
So let's have a look at the Lighthouse test first. To get start the test:
- After opening up your DevTools
- You might have to expand using the arrows >> for further options
- Select Lighthouse test
- Next, select the tests you would like to run, you can also only opt for Accessibility Audit.
The audit will return a score out of 100 and include a list of all the accessibility issues that need to be fixed. For each issue, you will find additional information and further resources to find out more.
Among the most common issues are missing alternative text, empty links, or insufficient color contrast.
Clicking on the examples will take you back to the elements in the source code so you can inspect them.
Please bear in mind that automated tests like this can find a lot of issues and be very helpful. But even a 'perfect' score does not necessarily mean your website is fully accessible. Always include manual testing in addition to automated tests.
Once we are done with our Lighthouse test, we can have a look at our page by testing manually. There are many ways to do so, tools and extensions - and one of the ways is directly in the Chrome DevTools.
In the Elements tab, at the bottom, there is a whole Accessibility Tab. To get there,
- Select an element you would like to inspect.
- Open the Elements Tab
- At the bottom right, there is the Accessibility Pane. (Again, it might be hidden behind the >> arrows)
- Open it up.
Here, you will find additional information about the ARIA labels, name, role, and computed properties.
We can even enable a full-page accessibility tree for our elements. By checking the corresponding box in the accessibility pane, a new icon with a figure will appear in your elements tab at the top right corner. You can toggle it to turn the accessibility tree view on and off. You might have to reload the DevTools to enable it.
With this view, you will get an overview of what a screen reader or assistive tech will work with: the accessibility tree. This enables you to investigate accessibility issues at the sources: Why is no label announced with a screen reader? How did the tab order get messed up?
You can even see a lot of this information when inspecting elements by hovering over them. The tool tip will give information on color contrast, keyboard accessibility, name, and role at a glimpse.
You can inspect the color contrast of a text element against the background within the DevTools. When you select the element and click the color code or example square in the Styles tab, a color picker opens up, letting you experiment with the color selection. It also provides a contrast ratio and a symbol to indicate whether your contrast ratio is sufficient (higher than 4.5:1 in compliance with WCAG AA standard).
DevTools has a feature to emulate vision deficiencies such as blurred vision, reduced contrast, or red-green color blindness to the page you are currently visiting. To enable this, in your DevTools, press
P in the console ( or
P on Windows) to open up the Command Menu. Select or type 'Show Rendering'. All the way at the bottom, you will find the option to emulate vision deficiencies.
Of course, this isn't a 100% accurate representation of what a website might look like for different kinds of users - but it is a really good start to simulate different kinds of experiences.
Chrome DevTools offers a great way to test for Web Accessibility directly in the browser - without the need to use additional tools or install extensions. Is it the only way to test for accessibility? Absolutely not. But it's a solid place to start. It offers both automated tests and options for manual testing, and you can get a lot of info about accessibility on the fly via the tooltip when inspecting an element.
Do you use Chrome DevTools for Accessibility Testing? What are your favorite tools?