Browser devtools CSS accessibility testing starts where the rendered page meets the accessibility tree. The accessibility tree is not the DOM, and it is not a screenshot of the layout. It is the structure that assistive technology consumes, and CSS computes it from source order and the cascade. The trap is that a visually perfect page can fail the tree silently. A flexbox rule that reorders rows passes any visual review and then changes what a screen reader announces, because the accessibility tree respects the underlying DOM order unless CSS also changes the logical order. The second trap is colour ratios. The human eye cannot compute a WCAG 1.4.3 ratio, and a tool that reads the computed colour from the wrong colour space gives a false pass. These are not hypothetical failures; they are the daily output of CSS that never got inspected. You fix them the same way you fix a layout bug: open the browser’s developer tools, but open the accessibility panel, not the styles pane. Walk three runnable samples, each attached to a vendor’s documentation, and learn what each tool catches that the others miss.

Chrome DevTools Accessibility Panel: Finding the Flexbox Order Failure

Chrome DevTools ships an accessibility panel that exposes the accessibility tree for the inspected element. The panel does not invent the tree; it renders it from the compositor’s output. That is exactly why it catches a failure the styles pane cannot.

Why Visual Reorder Breaks The Tree

The sample below is a card with a title and a call-to-action button. Visually, the button should appear after the title. The CSS uses flexbox with the default order, then reorders the button to the bottom. The DOM order is button-first, title-second, and the visual order is title-first, button-second. The rule looks like it works.

Inspect the button in the accessibility tree. The button still comes first, because the flexbox reordering changes the visual order only. The WCAG criterion is 2.4.7, focus order, which requires a logical focus order. The failure is that a keyboard user tabs from the button to the title, which is backwards.

.card {
  display: flex;
  flex-direction: column;
}
.card .cta {
  order: 2; /* visual reorder only */
}

<div class="card">
  <button class="cta">Buy now</button>
  <h3>Title</h3>
</div>

Chrome’s documentation for the Accessibility panel tells you to inspect an element and read the “Accessibility” pane to see its position in the accessibility tree. That pane shows the reordered element still exposing its DOM position. The fix is not to remove the flexbox order but to change the DOM order and use margin or grid to place the button visually. The Chrome DevTools panel is the only one that shows this specific failure without a third-party audit, because it reads the live tree rather than a computed style snapshot.

Firefox Accessibility Inspector: Contrast Ratio and the Colour Space Trap

Firefox’s Accessibility Inspector is the tool for a ratio failure that a bad colour space hides. The CSS rule below uses a hex colour for the text and a light background. A visual review says it passes, but the inspector computes the ratio against the WCAG 1.4.3 threshold of 4.5:1 for normal text. Here is the trap: the rule sets the colour in sRGB, but the page uses a colour profile that the browser interprets differently. The computed value in the inspector is not what the author typed; it is the used value after colour management. Firefox’s Accessibility Inspector displays the ratio directly in the inspector’s computed panel, and it reads the actual rendered colour, not the authored value.

When A Profile Breaks The Pass

body {
  color: #767676;
  background: #ffffff;
}

The authored color against white computes to roughly 4.6:1 in sRGB, which passes. But if the page loads a colour profile that shifts the rendered white to a warm off-white, the inspector’s ratio drops below 4.5. Firefox’s documentation for the Accessibility Inspector notes that it reports the ratio as computed by the browser’s colour management, which includes the ICC profile applied to the page. That is the false pass: the authored rule passed a naive calculation, and the inspector exposes the real failure. The WCAG criterion is 1.4.3. The fallback is to use the inspector’s colour picker to re-check, or better, to set the background in the same colour space as the text. Firefox is the only major browser whose accessibility panel documents this colour-management caveat in its vendor notes, and the only one that warns a computed ratio depends on the profile.

Safari Web Inspector: Accessible Name Computed from CSS Content

Safari’s Web Inspector lacks a dedicated accessibility tree pane as of 2026, but it does expose the accessible name in the Node tab’s Accessibility section. This matters for a sample where the accessible name comes from CSS. The CSS content property can generate text, and for some elements that generated text becomes the accessible name. The rule below uses a pseudo-element to inject a label, but the generated content is empty because the CSS variable is not set. The accessible name is then empty, and a screen reader announces nothing, even though the visual label appears to be there.

Empty Content, Silent Button

.icon::before {
  content: var(--label, "");
  display: inline;
}

<button class="icon" aria-label="Not empty">Click</button>

The aria-label overrides the generated content, so that part passes. But if the button had no aria-label, the accessible name would be taken from the computed content, which is empty. Safari’s inspector shows the accessible name field, and it will be blank. The WCAG criterion is 4.1.2, name and role. The failure is that the name is present visually but absent from the tree. Safari’s Web Inspector documentation describes the Accessibility section as showing the computed accessible name, which is the only place this failure shows up without a screen reader. The fix is to avoid using CSS content for meaningful labels and put the text in the DOM, or to use an aria-label. Safari’s inspector is the only one that calls out this specific computed-name behaviour in its release notes, making it the right tool for this exact rule.

Chrome DevTools CSS Overview Panel: Contrast Reporting and Forced-Colours

Chrome’s CSS Overview panel added ratio reporting in Chrome 96. This panel is not an accessibility tree; it is a page-level audit that flags text whose computed ratio fails the WCAG thresholds, and it does so across all elements at once. The panel is useful for a forced-colors scenario.

System Colours Under Audit

The sample below uses a system colour keyword, ButtonFace, in a forced-colours context. The CSS Overview panel checks the ratio against the default threshold, and it will flag a rule that relies on a system colour misapplied.

@media (forced-colors: active) {
  .submit {
    background: ButtonFace;
    color: ButtonText;
  }
}

Chrome’s documentation for the CSS Overview panel explicitly says it reports ratio violations, and the panel computes these against the user’s OS settings. If the user is in forced-colors mode, the panel flags a rule that authored a low-ratio pair in the fallback, because the panel also inspects the non-forced state. The WCAG criterion is 1.4.3 again. The failure is that the author tested only the non-forced state. The Chrome panel is the only one that reports the ratio from the forced-colours perspective, because it runs the audit on the active CSS, not the base stylesheet. The fallback guard is to wrap the system colours in the forced-colors media query and ensure the base rule also passes. Run the CSS Overview panel before you manually keyboard-test. It finds every ratio in one pass.

Emulating Vision Deficiencies: Chrome DevTools and Firefox Inspector

The rendering tab in Chrome DevTools and the accessibility panel in Firefox both offer vision-deficiency emulation, but they are not interchangeable. Chrome’s emulation simulates blurred vision and several colour-vision deficiencies, including protanopia and deuteranopia. Firefox’s simulate vision deficiencies adds the same options in its accessibility panel. Neither tool is a substitute for ratio checking. They are for seeing the layout as a user with low vision would see it, which changes where a focus indicator lands or where a gradient loses readability.

Gradients The Colour Picker Misses

The common failure is that a developer checks the ratio on flat text but misses a gradient behind the text. The emulation shows the gradient washing out the text in a way the individual colour picker does not. The WCAG criterion is 1.4.3. The technique is to run the ratio report first, then the emulation, and then manually tab through the page. Safari has no such emulation in its Web Inspector, so a cross-browser test needs Chrome or Firefox for this step.

Source Order vs Visual Order: The Focus Order Debug

A page’s keyboard focus order follows the source order unless CSS changes it. The browser tools expose this mismatch in different ways. Chrome’s accessibility panel shows the accessibility tree, which follows DOM order, and the Firefox inspector does the same. Neither tool shows the visual tab order directly. You have to tab manually and watch the focus ring.

Tab And Compare

The WCAG criterion is 2.4.7. The failure is that a flexbox reorder or a grid placement changes the visual tab order without changing the DOM. The fix is to use the keyboard to tab through the page after any layout change, and to use the accessibility tree to confirm the order. The browser tools do not auto-fix this; they show the tree, and the tree follows the DOM. The only way to catch a visual reorder is to tab and compare the focus ring position against the source order in the Elements panel.

Automated Audits and Their Limits: Lighthouse and axe-core

Lighthouse, built into Chrome DevTools since Chrome 60, and the axe-core engine behind the axe DevTools browser extension, are automated audit tools that catch a subset of accessibility issues. They are not a replacement for the browser panels. They operate on the computed styles and the accessibility tree, but they cannot see a flexbox order failure if the DOM order is also changed to match. The ratio check in Lighthouse uses the same colour-management caveat as the Firefox inspector, and it will flag the false pass sample above.

What Audits Cannot Test

The limit is that automated audits cannot test keyboard interaction. A rule that only fails on focus traversal passes. The WCAG criteria are 1.4.3 and 2.4.7. The technique is to run the audit, fix the flagged items, and then manually test the keyboard path. The tools are complementary: Chrome’s panel shows the live tree, Firefox’s inspector shows the computed ratio, and the audits give a page-level score.

The Costs and the Fallbacks: When the Normal Route Is Closed

The failure case is when the browser tools themselves give no colour reading, which happens on a canvas that animates or on a gradient. The CSS Overview panel and the Firefox inspector both compute a static ratio. Neither handles a colour that changes with an animation. The fallback is to pause the animation via the rendering tab’s “Emulate CSS media feature prefers-reduced-motion” option, then run the ratio check, and then re-enable the animation.

Empty Content And Missing Variables

For an accessible name that comes from CSS content, the fallback when the content is empty is to check the DOM, not the tree. The tree shows the empty name and the DOM shows the missing variable. The cost of relying on a single tool is that you miss the other failure classes. The practical path is to run the CSS Overview panel for a ratio sweep, tab through the page for focus order, and open the accessibility tree in either Chrome or Firefox to confirm the name and role. No single tool catches every CSS accessibility failure.

FAQ: Four Quick Answers

Which browser tool shows the accessibility tree? Chrome DevTools and the Firefox Accessibility Inspector both expose the tree. Right-click an element and choose Inspect, then find the Accessibility tab or pane. Safari’s Web Inspector has a limited version in the Node tab.

Does Chrome DevTools automatically flag a flexbox order failure? No. The accessibility panel shows the tree in DOM order, but you must compare it to the visual order yourself. No automated audit catches a reorder that keeps the DOM fixed.

Can I rely on the ratio in the computed styles pane? No. The computed styles pane shows the authored colour value, not the rendered value after colour management. Use the accessibility panel’s ratio readout, which reflects the actual pixel colour.

Is axe-core a replacement for the built-in panels? No. axe-core and Lighthouse catch a subset of issues, but they cannot test keyboard focus, and they miss a false pass from a colour profile shift. Use them as a first pass, then manually verify with the tree and tab key.

Who This Subject Suits and Who It Does Not

This subject suits the front-end developer who writes CSS daily and needs to know which tool ships where, what each catches, and what the fallback is when the normal route fails on an animated gradient or an empty CSS variable. It suits the performance-conscious developer who wants to understand what a declaration actually costs in the accessibility tree, not just what it looks like. It suits the technical writer who needs sourced statements about browser tooling without laundering guesses into facts.

Who Should Start Elsewhere

It does not suit someone learning CSS from zero. That reader should start at web.dev/learn/css or the MDN CSS first-steps guide and return here once the cascade is familiar. It does not suit someone debugging a React state bug or comparing CSS-in-JS libraries. That is a JavaScript tooling question, not a CSS accessibility one. It suits a developer who is already keyboard-tabbing and needs to know which panel to open first, and which tool to trust when the DOM and the rendered page disagree.

Testing CSS Accessibility Using Browser Developer Tools and the Accessibility Panel