DevTools for accessibility

Accessibility tooling has a quiet pattern: extensions rebuilding what the browser already ships. This sheet is the built-in inventory — the panels and toggles that cover most of an audit's tooling needs before you install anything — and the short list of add-ons that genuinely add something. Everything here can be tried on this very page.

Already in the browser

Paths are Chrome and Edge unless named otherwise; Firefox gets its own row where it shines. None of this needs an account, a license, or an update cycle — it ships with the engine you're debugging.

The accessibility paneElements → Accessibility: Role, name, and the full computed-name chain for the selected element — which source won and which were skipped. A checkbox switches the whole panel to the page-wide tree, and the source-order viewer overlays reading order on the page.
Contrast in the color pickerStyles → any color swatch: Click a text color and the picker shows its contrast ratio with AA and AAA lines drawn on the spectrum — pick a passing shade without leaving the panel.
The inspect tooltipthe element picker, before you click: Hovering with the picker already answers the audit basics: accessible name, role, contrast, keyboard-focusable — for every element you sweep across.
Rendering emulationsMore tools → Rendering: Emulate prefers-color-scheme, reduced motion, forced colors, prefers-contrast, and six vision deficiencies — several extensions replaced by one panel, no device settings touched.
Emulate a focused pageMore tools → Rendering: Keeps focus-dependent UI — dropdowns, comboboxes, tooltips that close on blur — open while your cursor is in DevTools. The single most "how did I not know this" checkbox in the panel.
Live expressionsConsole → the eye icon: Pin document.activeElement and Tab through the page: you watch focus move in real time without pausing. The keyboard test, with a dashboard.
Lighthouseits own panel: No install needed — and its accessibility audit is axe-core, the same engine this site's test suite runs. Anything below 100 lists the machine-checkable failures with the failing nodes.
Firefox's accessibility inspectorFirefox → Accessibility tab: Its own full tree, a "check for issues" sweep (contrast, keyboard, text labels), and a tabbing-order overlay drawn directly on the page. Worth keeping Firefox around for on its own.

The first row is the pane the proof chapter walks through — the four examples there make a good first target for it. And the Rendering emulations are this site's own test rig: flip forced colorsForced colorsAn OS accessibility mode (like Windows High Contrast) that replaces site colors with the user’s own palette. CSS meets it through the forced-colors media query; component boundaries must survive it. or reduced motion right here and watch the page hold.

Add-ons that earn their place

The test for this list: an add-on must do something the panels above can't. Three pass it.

axe DevToolsDeque: The same engine as Lighthouse's audit, but scoped: scan one component instead of the page, and get each failing node pinpointed with its rule documentation. The extension form of the suite this site runs in CI.
Accessibility Insights for WebMicrosoft: FastPass draws tab stops on the page as numbered lines while you Tab — the visualization DevTools doesn't have — and the guided assessment walks a full manual WCAG review, question by question.
WAVEWebAIM: Renders findings as icons on the page itself: headings, landmarks, labels, and errors all visible at once. The didactic one — made for showing a page's structure to someone who doesn't live in DevTools.

What none of them change

Tooling — built-in or installed — sees the machine-checkable slice, and the layered model says what that slice is worth: necessary, never sufficient. The rest is still you, a keyboard, and a screen reader's first fifteen minutes.