ARIA DevTools: seeing your page the way a screen reader presents it

What the extension actually shows you

The premise is stated plainly in the README: creating accessible web applications is difficult, and it gets even harder if you do not understand how people with disabilities use computers.

With ARIA DevTools you see your website the way screen readers present it to blind users. All page elements are presented according to their explicit or implied ARIA roles, and the README calls out headings, images, tables and form items among the categories covered. The key word is implied. A button element with no explicit role still has a role that assistive technology infers from the element, and that inferred role is what the extension shows you.

The stated payoff is that it is now easy to spot missing ARIA labels, misused ARIA roles, and incomplete keyboard support, which the project says makes testing and development of accessible websites easier.

So the tool is a view onto the accessibility tree, computed live from the page you are looking at. That is the whole concept, and everything else follows from it. The primary language is TypeScript, the licence is MIT, and the extension is available for free on the Chrome Web Store and on Firefox Add-ons.

Roles versus labels versus keyboard support

The three problems the extension names are different in kind, and it is worth separating them because the tool helps with them to different degrees.

A missing ARIA label is a naming problem. A control with a visible text child may be named by its contents, and an icon-only control may not be named at all, in which case a screen reader announces something anonymous. The extension shows the effective name alongside the role, so a control that is announced as just button is visible as a problem without any special scanning.

A misused role is a semantics problem. Putting role=button on a div gives the div a role it was never designed to carry, and the browser then offers it to assistive technology as a button even though it has none of the keyboard behaviour a button has. Seeing the role the tree actually contains makes these mismatches obvious, because the role and the element type sit next to each other.

Incomplete keyboard support is a behaviour problem, and this is where the tool is weakest and most useful at the same time. The extension highlights which elements are focusable and which are reachable by keyboard, which turns a manual tab-through-the-page exercise into a visual audit. It does not run the interactions, so it tells you that a widget is not reachable, not that activating it does the wrong thing.

For a developer who writes markup, that is the most common source of accessibility defects and the one that is easiest to fix once it is visible.

The dependency list explains the implementation

The package.json is a good guide to how the extension is put together, and several entries are more revealing than they first look.

ally.js at 1.4.1 is the accessibility engine. It is the library that computes roles and names from the DOM, and putting it in the dependency list rather than reimplementing that logic is the single most sensible decision in the project, because accessible name computation is a specification with many edge cases and getting it subtly wrong produces a tool that lies.

React with mobx and mobx-react provide the UI, and styled-components handles the styling. popperjs is there for positioning the overlay onto the elements it inspects, and react-shadow is the isolation mechanism, rendering the tool's own UI into a shadow root so that the extension's styles do not leak into the page and the page's styles do not break the tool.

The build tooling is Parcel, and the package name in the manifest is a10y-view while the version is 1.4.2, which is a leftover from an earlier name for the project. The browserslist targets more than 0.2 percent, not dead and not op_mini all for production, and the last 1 chrome version, the last 1 firefox version and the last 1 safari version for development.

There is also a testing setup with mocha, chai, chai-wait-for and the parcel test runner, and bowser is a dependency, which is the browser detection library, used to present the extension differently per browser.

Running it from source, and the parcel scripts

Working with the repository is documented, and the prerequisites are NodeJS and YARN.

The development environment is three steps: run yarn to install, run yarn start, and then load the extension directory as an unpacked extension in the browser extensions page. The documentation notes that you need to enable Developer Mode in the Chrome extensions page to load unpacked extensions.

The development script is the interesting one, because the hot reload configuration is baked into it.

    "start": "parcel watch src/index.tsx --out-dir extension --out-file inject.js --hmr-hostname localhost --hmr-port 3005 --https",

The build output is written straight into the extension directory as a file named inject.js, and hot module replacement is served over https on port 3005 with the hostname localhost, which is what lets the extension reload its injected script as you edit the TypeScript.

The production build is the same thing without the watch and the hot reload flags.

    "build": "parcel build src/index.tsx --out-dir extension --out-file inject.js"

And the test script, named test, runs the parcel test runner against a test HTML page on port 3000.

The build result can be found in the extension directory, and the extension source is in src/ with a tsconfig.json and a types.d.ts at the root, alongside a .babelrc for the Babel presets.

The maintenance question a sponsorship note raises

There is a note at the top of the README that deserves to be read rather than skipped, because it describes the state of the project plainly.

The author says he recently dropped his full time job to pursue being an independent developer working on his own projects, and that to make it sustainable he has to be very careful about what he spends his time on. He would love to work further on ARIA DevTools if he finds a sponsor of the project, and states that he does not want to make the extension paid, with a contact address given for anyone interested.

The facts behind that note are in the metadata. The last push was on 2026-06-15, which is more than four months before the present date. The repository has no GitHub releases at all, so there is no tagged version history to track. The manifest still declares version 1.4.2, and the dependency versions are old, with mobx at 5.x, react-shadow at 17.6.0, typescript at 3.7.5 and parcel-bundler at 1.12.4.

None of that makes the extension bad or useless, and the Chrome and Firefox builds are what most people will install. But it does tell you what to expect: a small, free, actively solicited tool maintained by one person in between other work, where a change to the underlying browser APIs or the accessibility specification may wait. The fact that the author is asking for sponsorship rather than charging is a reasonable trade, and it also means there is no support contract behind it.

One detail worth knowing for anyone building on the source: the extension icon assets in the repository root, banner.xcf and logo.xcf, are GIMP files, so editing them needs GIMP.

How it differs from automated rule checkers and real screen readers

The realistic alternatives for finding accessibility problems fall into three categories, and this tool sits between the first two.

Automated rule checkers, such as the ones built into browser developer tools, run a fixed set of heuristics over the DOM: missing alt attributes, low contrast, missing form labels, duplicate ids. They are fast, they run in CI, and they catch the mechanical mistakes. What they cannot do is tell you that a role is wrong for the element, because deciding whether role=tab on that container is correct requires knowing what the widget is supposed to do.

Real screen readers, NVDA, JAWS, VoiceOver, are the ground truth, because they are what users actually run. Their limitation is that they are slow, they are hard to learn, and they give you an audio experience that is awkward to scan for structural problems. You cannot easily read a page structure out of speech.

ARIA DevTools is the middle. It is the accessibility tree rendered visually, which means the fast tool tells you what the role tree contains, and the visual format tells you what a screen reader would announce, without the audio. That is exactly the gap the author describes when he says the extension shows your website the way screen readers present it.

The real caution is about scope. This is a development and inspection aid, not a conformance test. An automated checker plus this extension plus a real screen reader plus keyboard testing are different instruments covering different failures, and a page that looks clean in the role tree can still be unusable.

Editorial conclusion

Adopt ARIA DevTools when you build or audit web interfaces and need to see the accessibility tree your own markup produces, since it catches role and label mistakes during development rather than in an audit. Do not adopt it as a substitute for testing with a real screen reader or for automated rules engines, because it shows you the role tree, not the experience. Before you rely on it, check the version of the extension you install, since the last push was on 2026-06-15 and the manifest still declares a 1.4.2 package version.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. ziolko/aria-devtools on GitHub