DEV Community

Cover image for Accessibility Testing with Chrome DevTools
Josefine Schfr
Josefine Schfr

Posted on • Updated on

Accessibility Testing with Chrome DevTools

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)

Accessibility Testing with Chrome DevTools

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.

Automated Testing, aka Lighthouse Accessibility Audit

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:

  1. After opening up your DevTools
  2. You might have to expand using the arrows >> for further options
  3. Select Lighthouse test
  4. Next, select the tests you would like to run, you can also only opt for Accessibility Audit.

Chrome DevTools with the drop-down to open lighthouse
Opening up Lighthouse in the Chrome DevTools

Overview of Lighthouse report, only checkbox for Accessibility test is checked
Running an Accessibility Audit with Chrome DevTools

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.

Lighthouse score of 78 in the Accessibility Report
Lighthouse will return the score and a list of accessibility issues and how to fix them

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.

Manual Testing with Chrome DevTools

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.

Accessing the Accessibility Pane in Chrome DevTools

In the Elements tab, at the bottom, there is a whole Accessibility Tab. To get there,

  1. Select an element you would like to inspect.
  2. Open the Elements Tab
  3. At the bottom right, there is the Accessibility Pane. (Again, it might be hidden behind the >> arrows)
  4. Open it up.

Here, you will find additional information about the ARIA labels, name, role, and computed properties.

Part of the Accessibility pane showing now aria labels added for the selected element, the buttons content is "Try for Free"

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.

DevTools elements tab open showing some code as well as the Accessibility Pane

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?

Accessibility Context when inspecting Elements

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.

Inspection tool tip on button

Checking Color Contrast in Chrome DevTools

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).

Color Inspector in Chrome DevTools showing a contrast ratio of 15.31 for the selected color (white)

Emulate Vision Deficiencies

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 Cmd + Shift + P in the console ( or Ctrl + Shift + 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.

Google DevTools drop down showing different options of emulating vision deficiencies including no emulation, blurred vision, reduced contrast, protanopia, deuteranopia, tritanopia and achromatopsia

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?

Top comments (1)

kolja profile image

Off topic, but:
Why are screenreader (or any a11y browsing tool) based on sourcecode and not based on the rendered output of a browser?