Hidden Gem of Chromium Accessibility

Low-level accessibility tools

There’s a hidden gem in Chromium accessibility. It is the command line accessibility tools. Similar to accessibility inspection tools available on all popular platforms such as Windows or OSX, these tools are designed for the very same purpose: they provide a low level access to accessibility features of a web site. They also have a superpower though that makes them mighty and unique, but let’s talk about it later. Let’s do some backgrounds for the start.

An accessible website means that the assistive technologies like a screen reader can see, perceive and operate on the website. Not every website is accessible. If website content can’t be expressed in a way the assistive technologies understand, then the website is inaccessible. It’s like translating the website to the assistive technologies language: if it cannot be done, then you are out of luck.

Each platform has its own accessibility API, the assistive technologies rely on those to work with websites. In particular it means the website content should be designed in such a way that it can be mapped to those APIs. So if you have an accessibility issue on a website, then quite likely it indicates the content is not properly mapped to the accessibility APIs.

If a website has an accessibility bug, then it’s often a good idea to inspect how the website is mapped to the APIs. Each platform has its own set of accessibility tools: Linux has Accerciser, OSX has Accessibility Inspect, Windows has Inspect. Each browser is also packed by developer tools which incorporate functions for website accessibility inspection. They all are designed to help web authors to better understand how screen readers see a web site. They represent website content in a quite techy way in terms of APIs, objects and their properties, but it may give you a clue why accessibility doesn’t work as expected. It’s definitely worth a shot.

Let’s stop from burrowing further into tech details of how accessibility works. It should be good enough for the context to move back to the original topic. In case if you want to dive deeper, then you can check out this podcast where igalians discuss tech accessibility.

So what makes Chromium accessibility tools special?

The Chromium accessibility is packed by two tools:

Being able to inspect an accessible tree which shows a hierarchy of accessible elements and includes all accessibility properties like name, description is a quite handy feature when you dig into accessibility bugs.

Accessibility events logging can be also super helpful. It’s not something typically supported out of box by existing accessibility tools, but this is a super important bit of information. Indeed, events are the primary notification mechanism used by the assistive technologies to pick up changes from a website. If events are broken, then the assistive technologies get broken too. It makes the ax_dump_events tool special, and also makes another good reason why you’d want to try it next time :)

These tools support a bunch of pre-defined selectors to grab a tree or record events in browsers in no time. For example:

For example, you do:

ax_dump_tree — edge

to dump the accessible tree of Microsoft Edge browser on Windows.

Same with events. To start recording events for Safari browser you do:

ax_dump_events — safari

If you need to scope the tool to a web site (as opposed to the whole browser), then you have — active-tab selector to do so. In case of multiple windows of the same application, you can tune your search by — pattern option. For non browser applications you can specify process ID via — pid option. See docs for full documentation.

Let’s recapture some of the above. You’d want to use these tools when:

There is no official place for the tools yet. You can build those yourself from Chromium sources. I also prepared nightly builds and uploaded them at my google drive at your convenience.

The tools are awesome: fast, reliable and easy to use. They are perfect except … they have no GUI :) All console tools have such flaws, just by design. Indeed, CLI lacks certain useful options inherent to GUI tools, for example, click-to-inspect feature, which allows you to select a DOM element and inspect its accessible tree. This is very handy. You can find the feature literally in any accessibility tool, and not having it is a real bummer.

But no-GUI disadvantage can become a benefit: the tools can be easily incorporated into other accessibility tools as an accessibility inspect engine. You can create a cross platform GUI tool backed, for example, by Electron, and powered by Chromium’s ax_dump tools. Indeed, you don’t have to c++ or python into web applications accessibility, you can rely on ax_dump tools output instead. Chromium developer tools, which is not surprising, are based on these very same CLI tools.

And last but not least. It opens a new world for cross browser testing. Now you should be able to automate the platform accessibility mapping, for example, HTML-AAM, and it might be an easier solution than Accessible Testing Protocol. Needless to say Chromium already uses it in their automated test suite.

This is the beauty of the Unix word: you have a basic but powerful command line tool, which can serve as an engine to build anything you want upon it: GUI accessibility tools, automated testing, or you can use them as is because they are just cool.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alexander Surkov

Software engineer and author passionate about web, open source, accessibility and user-facing technologies.