Let’s not send developers to the accessibility tree tool

Testing for accessibility is an incredibly important part of your development process. Products that don’t block out users because of easy to avoid issues have more success. And the longer you wait with fixing accessibility problems, the harder it gets. That’s why it is annoying when it is hard to find out about accessibility problems.

Tooling in the accessibility space has gone leaps and bounds in the last years. Screenreaders, high contrast modes and other assistive tools are part of the operating systems. Most even come with in-built tutorials to get you started.

In the browser tooling space a lot of tutorials on accessibility testing send you to an “Accessibility tab”. This is a display of the Accessibility tree and unless you are already in the know, feels rudimentary and daunting. For people who know what to look for, it is exactly what they need, but it feels like a wasted opportunity to get people into accessibility testing.

I don’t think accessibility tooling should be exclusive to accessibility experts. Accessibility is an integral part of any product. That’s why accessibility problem reporting should happen where people develop products.

And it already does. I wrote about this in detail back in January, and I even have a Skillshare course explaining this , but here is a quick refresher:

Accessibility information in the Inspector overlay

The Inspector tool allows you to move your mouse around the document and find out a lot about each element. The on-screen overlay shows you:

• How the element is positioned (flexbox or grid showing as an appropriate icon)
• The name of the element, such as a, h1, or div.
• The dimensions of the element, in pixels.
• The colour, as a colour swatch and a formatted value.
• Font information (size and font families).
• Margin and padding, in pixels.
• The contrast of the element and if it is enough (checkbox) or an accessibility problem (exclamation mark)
• The name and the role of the element in the accessibility tree
• If the element is keyboard focusable (checkbox) or not (circle with line through it)

That’s a lot more actionable information than the Accessibility tool gives you and you can immediately act on it inside the Elements tool. A button that isn’t keyboard accessible is broken, and you find it out by inspecting it. A DIV disguised as a button without keyboard functionality won’t even show up in the accessibility tree, which also means that it is broken, but you wouldn’t know about it.

Issue reporting in the Elements tool source code

The Elements tool highlights HTML elements with issues (accessibility or browser compatibility) by showing a wavy underline.

When you shift-click these, you get to the Issues tool that describes the problem and explains how to fix it with “Further reading” links, although the issue report should be self-explanatory.

You can also always go to the Issues tool directly clicking the issues counter in DevTools.

Live issue reporting in Visual Studio Code

These are all reporting tools that kick in after you deployed your product. If you use the Edge Tools for Visual Studio Code extension, you get the reporting as you write your code. If you – for example – add an image without an alternative text alt attribute, Visual Studio code rightfully adds a wavy underline and explains to you that you should add one.

You can see this feature in the following video on YouTube:

Let’s meet developers where they are and show them what needs fixing

Developers are busy people and we hope that by bringing accessibility information right to the tools they already use we get people to embrace the issue more.

You can read more in the overview of accessibility testing in DevTools article and we also provide a list of accessibility issues and which tool to use to test for these.

Do you think anything is missing? How can we be even better in doing that?