Accessibility Insights for Web: a browser extension that audits accessibility in the page

The problem: accessibility findings that arrive after the code is written

Accessibility problems are cheap to fix when a developer sees them while building a component and expensive to fix once a page is shipped. Most tooling that reports accessibility issues waits for that later moment. Accessibility Insights for Web is a browser extension for Google Chrome and Microsoft Edge, and its stated purpose is assessing the accessibility of web sites and web applications, which means the assessment happens in the page you are already working in rather than in a separate scanning service pointed at a URL. The intended users are frontend engineers, QA engineers, and accessibility specialists working on real products. The extension is Microsoft maintained, MIT licensed, and its main branch had a push on 2026-10-19, so it is currently being worked on. The scope is deliberately the browser: this is a tool for inspecting a page you can open, not a service for auditing a site you cannot reach.

Three distribution channels that decide which build you get

How the extension reaches you changes what you are testing, and the README is unusually clear about it. There are three channels. Canary is released continuously. Insider is released on feature completion. Production is released after validation in Insider. That sequence is the key operational detail for an engineering team deciding what to install. A Canary build is the fastest way to see new work, and it is also the build most likely to change under you between two runs of the same check. Insider is the middle ground, where a feature has landed but has not yet been through validation. Production is the conservative choice and the one that matches what most users of the Chrome Web Store actually have. The Chrome Web Store listing linked from the README carries the users and stars badges and the version badge, so the current published version can be read from there. Choosing a channel is the first configuration decision, and choosing the wrong one leads to two engineers reporting different results for the same page.

A fastpass, a validator, and a report as separate packages

The repository layout shows how the tool is divided. The packages directory contains axe-config, report, report-e2e-tests, ui, and validator, and the root package.json wires them together as a yarn workspace. The axe-config package exists so the rules configuration the extension evaluates against can be generated and versioned, and the build script for it is separate from the rest of the build. The validator package is the deeper assessment engine, and the report package produces the shareable output that the report-e2e-tests package then exercises. The separation is the interesting part architecturally: a fast check, a deeper check, and a written artifact are different concerns with different lifecycles, and splitting them into packages lets the report be built and tested independently of the extension UI. The build script for the report package is a distinct command from the extension build, which is how you would produce a report artifact in a pipeline rather than by hand in a browser.

Building the extension from source with yarn and grunt

The repository pins the toolchain in the root package.json. The package manager is declared as yarn 3.5.0, and the node engine requirement is stated as a version range:

"packageManager": "[email protected]",

"node": ">=20.17.0"

Yarn 3 is the Berry generation, and the repository carries a .yarn directory and a .yarnrc.yml, with a yarn.lock at the root, which is the setup for a checked-in Yarn release rather than a globally installed one. The build itself is driven by grunt, with several targets defined in the root scripts:

"build": "grunt",
"build:all": "grunt build-all",
"build:prod": "grunt build-prod",

So a local build runs yarn build for the default grunt target, while build:all and build:prod are the wider and production variants. There is also a full assessment script that chains the checks in order, cleaning stylesheets, running the fastpass, building everything, and then running the unit and end to end tests:

"assessment": "npm-run-all --serial scss:clean fastpass build:all test test:e2e",

The fastpass script is the pre-merge gate. It runs the style build, then in parallel the type check, the copyright check, the lint checks for TypeScript and styles, the format check, and a null check, before invoking the ada-cat step:

"fastpass": "npm-run-all --print-label scss:build --parallel type:check copyright:check lint:check lint:scss format:check null:check && grunt ada-cat",

For a contributor, the path in the README is to read the CONTRIBUTING guidelines, then the git branch setup document, then the building document under docs. The presence of a strict format check, a copyright header check driven by copyright-header.config.json, and a separate null check tells you the project treats consistency as part of the build rather than as a suggestion.

Running the end to end tests inside a Playwright container

The repository includes a Dockerfile built on the Playwright image, which is how the browser driven tests run in a consistent environment. The base image is pinned:

FROM mcr.microsoft.com/playwright:v1.48.2-focal AS setup

The image installs Node 20 explicitly rather than accepting the Playwright default, and the Dockerfile says why in a comment, namely for consistency with the other build environments. The application code lands in a work directory and the yarn metadata is copied in before the rest of the source:

WORKDIR /app

COPY yarn.lock .yarnrc.yml package.json /app/

Only the manifests of the individual packages are copied at that stage, which keeps the layer cache useful while the packages themselves are still separate directories. The credential handling in the image is worth noting for anyone adapting it. The yarn configuration is mounted as a secret rather than baked into a layer, with the Dockerfile explaining that both mounts are optional so each caller provides whichever it has, the pipeline mounts a minted token and local builds mount the developer's own home yarnrc.yml, and the mount keeps the credential out of the image layers. There is also a .dockerignore at the root and an e2e-docker-build.js entry point, so the container path is a supported workflow rather than an undocumented one.

What the extension cannot tell you

Even a good accessibility tool has boundaries, and here they are structural rather than accidental. Accessibility Insights for Web evaluates a page in a browser session, so anything that only appears after a specific interaction, on a specific viewport, or behind a particular authentication state has to be reached before the assessment means anything. It does not evaluate your server rendered markup that never reaches a client browser. It also does not judge whether a page is legally compliant, because that is a question about your obligations and your jurisdiction rather than about a set of rules. Screen reader testing is a separate discipline that no automated tool replaces, and the README does not claim otherwise. The telemetry section is also worth reading carefully before you install it in a corporate environment: usage data is collected and sent to Microsoft when you opt in, along with anonymized data on the top accessibility issues found by users, which the project says helps focus the tools and standards community.

Release history, licence, and what an upgrade costs you

The tagged releases show a project that ships in batches rather than continuously. Accessibility Insights for Web v2.49.0 was released on 2026-09-08, v2.47.0 on 2026-06-11, and v2.46.0 on 2025-02-12. Those gaps are the practical cost of the three channel model, since a channel that only moves on validation can sit still for months. For a team, that is usually a feature: an assessment recorded last quarter can be compared with one recorded today without the tool itself shifting underneath you. The licence is MIT, and the repository root carries the LICENSE file along with a copyright header file and a copyright header configuration that the copyright check enforces on every source file. For anyone shipping the extension inside a proprietary product, the MIT terms mean you can use the code without a copyleft obligation, provided the notices stay in place. The trademark notice is separate from the licence and matters if you fork and rename the product, since use of Microsoft trademarks or logos in modified versions must not imply Microsoft sponsorship.

Editorial conclusion

Accessibility Insights for Web suits frontend teams and QA engineers who need an accessibility verdict on a live page during development, and it suits accessibility specialists who want a report artifact rather than a console warning. It does not suit server rendered applications you cannot reach in a browser session, and it will not tell you whether your application is legally compliant. Before adopting it, decide between the Canary, Insider, and Production channels deliberately, since Canary is released continuously while Production only ships after validation in Insider, and check whether the pages under test need authentication before you schedule a recurring audit.

Frequently asked questions

Official sources

1. License: MIT
2. microsoft/accessibility-insights-web on GitHub
3. Project website
4. README
5. Releases