Firefox Accessibility Inspector for Data Grids

Firefox’s Accessibility Inspector is a strong complement to Chrome DevTools, and for data grids it is especially relevant: NVDA with Firefox is one of the most common screen reader combinations, and Firefox’s accessibility mapping occasionally differs from Chrome’s. The inspector shows the tree, each node’s states and relations, and runs built-in checks for missing labels, contrast and keyboard issues. It also overlays the tab order and simulates colour vision deficiencies — both directly useful for grids and charts.

This guide belongs to accessibility tree & API inspection.

Spec reference

IAccessible2 / ATK mappings — Firefox exposes the accessibility tree to NVDA and JAWS through IAccessible2 on Windows and to Orca through ATK on Linux; relations such as labelled by, described by and controller for appear in the inspector.
SC 1.3.1, 4.1.2 (A) — structure, names and states.
SC 2.1.1 (A) and SC 2.4.3 (A) — the tabbing order overlay shows the keyboard path.
SC 1.4.1, 1.4.3, 1.4.11 — the checks and simulators help with colour issues.

Relations and overlays are where it adds most beyond Chrome.

When to use — and when not to

Use the Firefox inspector when NVDA-with-Firefox behaviour differs from Chrome, when you need to see relations (which element labels which), and when auditing tab order across a grid and its toolbars. Use its simulation for charts, heatmaps and status badges.

Do not rely on its checks as a full audit; they are a subset of what axe-core covers. The misapplication: running only the “Check for issues” filter and declaring the grid accessible.

Annotated code example

Example: verifying that a grid’s column headers label its cells through table relations, and that a filter button controls its popover.

<button type="button" aria-controls="filter-amount" aria-expanded="false">Filter Amount</button>
<div id="filter-amount" role="dialog" aria-labelledby="fa-h" hidden><h3 id="fa-h">Filter Amount</h3>…</div>

In the inspector: select the button → Relations → “controller for: dialog ‘Filter Amount’”. Select a cell → its “labelled by” relations are not shown for table headers, but the column header node appears as a sibling in the row structure; NVDA uses table structure for headers.

// Quick check in the console: tab order of focusable elements inside the grid toolbar and grid
[...document.querySelectorAll('.grid-toolbar *, [role="grid"] *')]
  .filter(el => el.tabIndex >= 0 && !el.disabled && el.offsetParent)
  .map(el => el.getAttribute('aria-label') || el.textContent.trim().slice(0, 30));

Keyboard & AT behaviour

Inspector feature	What to verify in a grid	Common finding
Show tabbing order	One tab stop per grid; toolbar stops in order	Every cell focusable (tabindex=“0” everywhere)
Checks → Keyboard	Interactive elements are focusable	Click handlers on non-focusable divs
Checks → Text labels	Controls have names	Icon buttons without names
Checks → Contrast	Text meets thresholds	Muted text in dense grids
Simulate → Deuteranopia	Statuses and chart series distinguishable	Red and green statuses identical

Each check catches a distinct family of grid problems.

Integration context

Chrome’s view is covered in inspecting the accessibility tree in Chrome DevTools. Behaviour differences between readers and browsers are catalogued in assistive technology behaviour differences. Tab order problems usually come from missing roving tabindex.

Gotchas

Inspector must be enabled. The Accessibility panel enables accessibility services in Firefox; performance may change while it is on.

Relations for table headers. Header associations in tables are computed by the reader from table structure, not exposed as “labelled by” relations; absence of a relation is not a bug.

Simulation is approximate. Colour vision simulation is a strong signal but not a substitute for checking with colour-blind users.

Common mistakes

Treating “no issues found” as a full audit.
Ignoring the tabbing order overlay for grids with many cells.
Checking colour only in the default theme.
Not testing in Firefox at all because “Chrome is fine”.

Framework notes

Firefox’s inspector works on any framework’s output. When a component library behaves differently in Firefox with NVDA, inspect the library’s rendered roles; libraries occasionally add roles that Firefox maps differently (for example, role="row" on elements outside a grid). Report such differences with an inspector screenshot of the node’s properties — maintainers can act on that.

Worked example

NVDA users reported that a filter popover’s Apply button “did nothing” in Firefox but worked in Chrome. The Firefox inspector showed the popover’s dialog node as a child of the grid’s last row in the tree — because the library rendered it inside the grid and Firefox mapped it as part of the row. Moving the popover outside the grid DOM fixed the reading order and focus handling in Firefox, and the inspector’s relations view confirmed the filter button now controlled the dialog.

A ten-minute Firefox pass on a grid

Open the Accessibility panel and turn on “Show tabbing order”; Tab through the toolbar and into the grid and note every stop.
Select the grid node; confirm its name and that it is a grid (or table) as intended.
Select a header cell and a body cell; confirm roles, names and states such as selected or expanded.
Run “Check for issues” with all filters; note label, keyboard and contrast findings.
Switch on deuteranopia and protanopia simulation and look at status badges and any charts.
Open the filter popover and confirm its role, name and the button’s “controller for” relation.

Ten minutes per page is enough to catch the majority of Firefox-specific and structural issues.

Testing checklist

Grid nodes have expected roles, names and states in Firefox.
Tabbing order shows one stop per grid and a sensible toolbar order.
Built-in checks report no missing labels or keyboard issues.
Colour vision simulation keeps statuses and series distinguishable.
Differences from Chrome are investigated, not ignored.

Design system notes

Include Firefox in component QA explicitly, and add “inspected in Firefox Accessibility Inspector” to the review checklist for components with custom roles.

FAQ

Why test in Firefox if most users use Chrome?

NVDA with Firefox is a common screen reader combination, and mapping differences cause real bugs.

Does the inspector slow pages down?

It enables accessibility services, which can affect performance slightly while the panel is open.

Can it audit a whole site?

It audits the current page. For site-wide coverage, use automated tools; use the inspector for investigation.

Are colour simulations accurate?

Good enough to catch obvious problems like red-green status pairs.

How do I share findings?

Screenshot the node’s properties and relations panels; they show exactly what Firefox exposes.

Does the tabbing order overlay include shadow DOM?

Yes, focusable elements in open shadow roots are included.

Can I print or export the tree?

You can copy a node’s properties as JSON from the context menu, which is handy for attaching to bug reports.

Chrome DevTools accessibility tree — the other inspector
Accessibility Insights FastPass — guided checks
Assistive technology behaviour differences — when browsers disagree

← Back to Accessibility Tree & API Inspection