Using Browser DevTools for Accessibility

1. Why browser DevTools are the fastest path to accessible interfaces

Browser DevTools are mostly used for layout debugging and network analysis, but Chrome and Firefox have shipped a full Accessibility panel for years that exposes exactly the accessibility tree that screen readers such as NVDA, JAWS or VoiceOver use for announcements. Developers building accessible interfaces therefore need no additional software: the role, name and state of every element can be checked in the very same tool already used to debug markup and styles. That lowers the barrier to entry considerably, because no context switch to an external testing setup is required.

The real value lies in the short feedback loop: a markup change can be verified against the Accessibility panel immediately, without a deployment or a screen reader setup. Especially in Hyva themes, where many states are driven by Alpine.js, the panel shows live how aria-expanded, aria-hidden or role actually change when a dropdown opens. This article shows how to use the Accessibility panel in Chrome and the Accessibility Inspector in Firefox, how to reliably inspect computed name and role, how to simulate color vision deficiencies right in the browser, and where the Lighthouse Accessibility Audit reaches its limits.

2. The Accessibility panel in Chrome DevTools at a glance

In Chrome, the Accessibility panel opens under "Elements" in the right hand "Accessibility" tab, or as a standalone panel from the three dot overflow menu. For whichever DOM element is selected in the Elements panel, it shows three central pieces of information: the computed role, the computed name, and the position within the accessibility tree relative to parent and sibling nodes. The "ARIA Attributes" section additionally lists every ARIA attribute currently set along with its live value, which is especially useful for attributes such as aria-expanded that Alpine.js toggles dynamically.

The standalone "Full-page accessibility tree" (enabled through the DevTools overflow menu) renders the complete tree of a page as a navigable structure, independent of whichever node is currently selected in the Elements panel. That is particularly valuable for checking whether decorative elements were correctly removed from the tree with aria-hidden="true", or whether an entire navigation region is accidentally missing because a wrapping element has display: none or visibility: hidden set.

3. Inspecting computed name and role: understanding the accessibility tree

The computed name is the text a screen reader actually reads out for an element, and it is derived through a fixed algorithm, the Accessible Name and Description Computation: aria-labelledby takes precedence over aria-label, which in turn takes precedence over visible text content, and only after that do fallbacks such as the title attribute kick in. Developers frequently assume that an icon with a descriptive CSS class name like icon-trash is automatically understandable, but the accessibility tree only cares about what the algorithm actually computes, not the intent behind the code.

The computed role determines which interaction model a screen reader offers: a <div> with an onclick handler but no role="button" has the role generic and is not announced as interactive, even if it looks like a button visually. The Accessibility panel immediately shows when role and actual behavior diverge. The example below shows how the computed name changes depending on the ARIA pattern used, and how the result can be traced in the panel.

<!-- Bad: icon button with no accessible name at all -->
<button class="icon-btn">
  <svg aria-hidden="true" focusable="false"><use href="#icon-trash"></use></svg>
</button>
<!-- DevTools Accessibility panel shows: Name "" (empty), Role: button -->

<!-- Good: explicit aria-label sets the computed accessible name -->
<button class="icon-btn" aria-label="Delete product">
  <svg aria-hidden="true" focusable="false"><use href="#icon-trash"></use></svg>
</button>
<!-- DevTools Accessibility panel shows: Name: "Delete product", Role: button -->

<!-- Alternative: aria-labelledby references visible text nodes -->
<p id="cart-heading" class="cart-heading">Shopping cart</p>
<button aria-labelledby="cart-heading cart-count" class="cart-btn">
  <span id="cart-count">3 items</span>
</button>
<!-- Computed Name concatenates the referenced nodes: "Shopping cart 3 items" -->

4. Firefox Accessibility Inspector: differences and strengths

Firefox offers the Accessibility Inspector (enabled in the DevTools settings under "Enable default tools"), a functionally similar but independently implemented view of the accessibility tree. One advantage over Chrome is the built in "Check for issues" filter, which automatically flags contrast problems, missing text alternatives, keyboard issues and ARIA errors and highlights the affected nodes directly in the tree, without a separate Lighthouse run.

Another difference is the "Simulate" menu, which, alongside color vision deficiencies, also previews how a page looks with reduced contrast, reduced transparency or disabled animations, directly tying into the prefers-reduced-motion and prefers-contrast media queries. Because Chrome and Firefox compute the accessibility tree with slightly different internal rules, based on different implementations of the operating system's accessibility API, it is worth checking critical components in both browsers rather than relying on a single tool.

5. Checking contrast and simulating color vision deficiencies right in DevTools

In the Chrome Elements panel, clicking a color value of a CSS property opens the color picker, which shows the contrast ratio against the background right below the color selector, including a visual slider that suggests the nearest WCAG compliant shade for AA (4.5:1) and AAA (7:1). That saves manually looking up an external contrast calculator, and it works directly against the actually rendered element, including all inherited background colors and transparency.

Through the Rendering panel (three dot menu -> "More tools" -> "Rendering"), "Emulate vision deficiencies" can also be enabled, with simulations for protanopia, deuteranopia, tritanopia as well as reduced contrast and blurred vision. That immediately shows whether a status color such as red for errors and green for success stays distinguishable without an accompanying icon or text. Firefox offers the same feature in the Accessibility Inspector under "Simulate". Important: these simulations are approximations and do not replace testing with real users who have visual impairments, but they are a fast first filter right inside the development workflow.

/* Ensure the focus indicator survives forced-colors and contrast simulation */
.btn-primary:focus-visible {
  outline: 3px solid Highlight;
  outline-offset: 2px;
}

/* Never rely on color alone to convey a state */
.form-field.is-invalid {
  border: 2px solid #b91c1c;
}
.form-field.is-invalid::after {
  content: "Error: required field";
  display: block;
  font-size: 0.75rem;
  color: #b91c1c;
}

/* Respect prefers-contrast for users who opt into higher contrast */
@media (prefers-contrast: more) {
  body {
    --text-color: #000000;
    --bg-color: #ffffff;
  }
}

6. Debugging focus order and keyboard navigation in DevTools

A correct visual focus order that matches the DOM order is a prerequisite for keyboard users to be able to traverse a page in a predictable direction. In Chrome, the "Show tab order" setting in the Rendering panel overlays colored numbers on top of every focusable element in the order the Tab key reaches them, directly on the rendered page. If this order deviates from the visual layout, for example because CSS Grid or Flexbox reordered elements with order, it becomes immediately visible without manually pressing Tab dozens of times.

For more complex checks, the order can also be read out through the DevTools JavaScript console. A short script lists every focusable element in its actual tab order and logs the currently active element on every focus change, which is particularly helpful with Alpine.js components that show and hide regions dynamically, for finding orphaned focus targets that still exist in the DOM but are no longer visible.

// Paste into the DevTools console to log the actual tab order of a page
const focusable = document.querySelectorAll(
  'a[href], button:not([disabled]), input:not([disabled]), select:not([disabled]), textarea:not([disabled]), [tabindex]:not([tabindex="-1"])'
);

[...focusable]
  .sort((a, b) => (a.tabIndex || 0) - (b.tabIndex || 0))
  .forEach((el, i) => {
    console.log(i, el.tagName, el.getAttribute('aria-label') || el.textContent.trim().slice(0, 40));
  });

// Log every focus change to spot orphaned or hidden focus targets
document.addEventListener('focusin', (e) => {
  console.log('Focused:', e.target, 'visible:', e.target.offsetParent !== null);
});

7. The Lighthouse Accessibility Audit: what it checks and what it does not

The Lighthouse Accessibility Audit built into Chrome DevTools is based on axe-core and checks purely automatable criteria: missing alt attributes, insufficient color contrast on static text, duplicate IDs, missing form labels and structural ARIA errors such as invalid role attribute combinations. The resulting score between 0 and 100 tempts teams to misread it as a complete accessibility certificate, yet according to the axe-core maintainers themselves it covers only around 30 to 40 percent of WCAG success criteria, because many criteria require human judgment.

What Lighthouse cannot structurally check: whether an alt text is meaningful rather than merely present, whether the logical reading order makes sense for screen reader users, whether focus traps in modal dialogs actually work, or whether a state change announced through aria-live is actually communicated in an understandable way. These criteria require manual testing with a keyboard and a screen reader. The excerpt of a Lighthouse JSON report below shows how a passing audit can still miss a critical contrast problem when the color is only set later through a JavaScript interaction.

{
  "categories": {
    "accessibility": {
      "score": 0.86,
      "auditRefs": [
        { "id": "color-contrast", "weight": 7 },
        { "id": "image-alt", "weight": 10 },
        { "id": "aria-allowed-attr", "weight": 10 },
        { "id": "focus-traps", "weight": 0 }
      ]
    }
  },
  "audits": {
    "color-contrast": {
      "score": 0,
      "title": "Background and foreground colors do not have a sufficient contrast ratio",
      "details": {
        "items": [
          { "node": { "snippet": "<span class=\"badge-sale\">Sale</span>" } }
        ]
      }
    },
    "focus-traps": {
      "score": null,
      "scoreDisplayMode": "manual",
      "title": "Requires manual review: focus traps and keyboard-only interaction"
    }
  }
}

8. Integrating DevTools findings into the development workflow

Manual checking in the Accessibility panel is indispensable for detail work, but it does not scale across hundreds of product pages in a Magento store. The axe-core engine, which also powers the Lighthouse audit, can be run as a standalone CLI tool or as a Puppeteer script inside the CI pipeline, checking the same criteria automatically on every pull request before a regression even reaches the manual DevTools check.

A two tier strategy makes sense: automated axe-core and Lighthouse checks in the CI pipeline as a safety net against regressions, complemented by targeted manual review in the Accessibility panel for every new component, especially interactive Alpine.js widgets such as accordions, tabs or modal dialogs, whose states can only be evaluated automatically to a limited degree. A score threshold in CI prevents obvious regressions from silently reaching production.

# Run an automated accessibility scan against a local Hyva build
npx @axe-core/cli http://localhost:8080/sample-product.html \
  --exit \
  --tags wcag2a,wcag2aa

# Run Lighthouse in CI, accessibility category only
npx lighthouse http://localhost:8080/sample-product.html \
  --only-categories=accessibility \
  --output=json \
  --output-path=./lighthouse-a11y.json \
  --chrome-flags="--headless"

# Extract the numeric accessibility score and fail the CI job below a threshold
node -e "const r = require('./lighthouse-a11y.json'); \
  const score = r.categories.accessibility.score * 100; \
  console.log(score); \
  process.exit(score >= 90 ? 0 : 1);"

9. DevTools checks compared side by side

Not every testing method catches the same kinds of defects. The overview below shows where a purely automated Lighthouse check reaches its limits and which DevTools pattern reliably closes the gap.

In practice, both levels complement each other: Lighthouse delivers a fast, reproducible baseline for the CI pipeline, while the browser's Accessibility panel covers the cases that only become visible in the actually rendered, interactive state of a page. Combining both levels, instead of relying on the Lighthouse score alone, uncovers considerably more real barriers before users of assistive technology run into them.

10. Summary

Browser DevTools are the fastest entry point into accessible development, because they expose the accessibility tree directly inside the very tool already used for every frontend debugging task. The Accessibility panel in Chrome and the Accessibility Inspector in Firefox show computed name and computed role in real time, immediately surface discrepancies between visible text and the name actually announced, and, with color vision deficiency emulation and the contrast display in the color picker, provide two tools that make external add on software unnecessary. Focus order can be traced visually with "Show tab order", instead of manually pressing the keyboard dozens of times.

The Lighthouse Accessibility Audit is a good first filter for automatable criteria, but by the axe-core maintainers' own account it covers only part of the WCAG success criteria and structurally cannot evaluate focus traps, meaningful alt text or correct live region announcements. Combining manual DevTools review, automated axe-core checks in the CI pipeline and targeted screen reader testing, instead of relying on a single score, achieves considerably more reliable coverage of real barriers.

11. FAQ: Using Browser DevTools for Accessibility