Accessibility Insights FastPass on Data Pages

Accessibility Insights for Web, a free browser extension from Microsoft, combines axe-core automated checks with guided manual tests. Its FastPass — automated checks plus a Tab stops visualisation — takes about five minutes and finds a large share of the most common issues. On data pages, the Tab stops part is particularly revealing: it draws the keyboard path as numbered circles, which makes grids with hundreds of tab stops, toolbars in the wrong order or focus that escapes dialogs instantly visible.

This guide belongs to accessibility tree & API inspection.

Spec reference

  • Automated checks — axe-core rules mapped to WCAG success criteria (names, roles, contrast, ARIA validity, table structure).
  • Tab stops — supports SC 2.1.1 Keyboard (A), SC 2.1.2 No Keyboard Trap (A) and SC 2.4.3 Focus Order (A); you record the path by pressing Tab and the tool visualises it.
  • Assessment — a guided manual test of all WCAG 2.x AA criteria, with instructions per criterion.
A FastPass run on a grid page Chain: load the page in a stable state; run automated checks; triage failures; record tab stops through toolbar, grid and pagination; repeat for key states. A FastPass run on a grid pageStable statedata loaded, noloading spinnersAutomated checksaxe rules mapped toWCAGFix or filegroup by componentTab stopstoolbar, grid,paginationruntriagerecordOther statesfiltered, editing,dialog open
Five minutes per state finds most common problems.

When to use — and when not to

Run FastPass during development on every page with a data grid, and as a gate before merging significant UI changes. Use it on each important state, because data pages change drastically when filtered, edited or showing dialogs.

Do not treat FastPass as a complete audit; it does not test screen reader output, live region timing, or most of the interaction patterns covered on this site. The misapplication: running FastPass once on the empty state of a grid, before data loads.

One run on the empty state versus runs per state Comparison: a single run on the loading or empty state misses most issues; runs on loaded, filtered, editing and dialog states find issues where they live. One run on the empty state versus runs per state✗ One run, empty stateGrid not rendered yetNo dialogs openToolbar disabledFew tab stops to recordPasses with false confidence✓ Runs per stateGrid with real rowsFilter and edit dialogs openToolbar active with selectionFull keyboard path recordedFindings in every state

Annotated code example

FastPass is interactive, but the same automated checks can run in CI. A Playwright test that mirrors FastPass for each state:

import AxeBuilder from '@axe-core/playwright';

const states = {
  loaded: async (page) => page.goto('/invoices'),
  filtered: async (page) => { await page.goto('/invoices'); await page.getByLabel('Filter rows').fill('overdue'); },
  editing: async (page) => { await page.goto('/invoices'); await page.getByRole('gridcell', { name: '1,240.00' }).press('Enter'); },
  dialog: async (page) => { await page.goto('/invoices'); await page.getByRole('button', { name: 'Filter Amount' }).click(); },
};
for (const [name, go] of Object.entries(states)) {
  test(`fastpass-equivalent: ${name}`, async ({ page }) => {
    await go(page);
    const { violations } = await new AxeBuilder({ page }).withTags(['wcag2a', 'wcag2aa', 'wcag21aa', 'wcag22aa']).analyze();
    expect(violations.map(v => `${v.id}: ${v.nodes.length}`)).toEqual([]);
  });
}
// Tab stop count through the grid region — a regression guard for roving tabindex
const stops = await page.evaluate(() => [...document.querySelectorAll('[role="grid"] *')].filter(el => el.tabIndex === 0).length);
expect(stops).toBe(1);

Keyboard & AT behaviour

The Tab stops visualisation tells you about keyboard behaviour directly:

Visualisation shows Meaning Fix
A numbered circle on every cell No roving tabindex One tab stop with arrow navigation
Circles jumping across the page Focus order does not follow visual order Fix DOM order
Path leaving an open dialog No focus containment Modal dialog or inert background
Missing circle on a button Not focusable Use a real button
Path ending inside the grid Possible keyboard trap Ensure Tab leaves the grid
Tab stops recorded on one page before and after fixes Bar chart of recorded tab stops: before roving tabindex the grid alone had 480 stops; after, the whole page has 24. Tab stops recorded on one page before and after fixesBefore: grid cellsevery cell focusableBefore: rest of pagetoolbar, filters, paginationAfter: gridroving tabindexAfter: rest of pageunchanged plus a skip link
The Tab stops view makes this problem impossible to miss.

Integration context

The automated part overlaps with setting up axe-core in a GitHub Actions pipeline and axe scans of grid states with Playwright. The keyboard part complements keyboard-only audit script for data grids. Use inspectors for root causes, as in inspecting the accessibility tree in Chrome DevTools.

Gotchas

Iframes and shadow DOM. Results can be incomplete inside cross-origin iframes; scan embedded content separately.

“Needs review” items. Some checks return items needing human judgement (contrast on images, for example). Review them rather than ignoring them.

Virtualized grids. Only rendered rows are checked. Scroll to different positions and re-run if row templates vary.

Common mistakes

  • Running once, on the empty state.
  • Skipping Tab stops because “it is just keyboard”.
  • Treating FastPass as an audit.
  • Filing findings without grouping them by component.

Framework notes

FastPass works on any rendered page, including local development servers. For component libraries, run it on Storybook stories in their iframe view to isolate components. The CLI and CI equivalents (axe-core) use the same rule engine, so results match across development and pipelines.

Worked example

A product team ran FastPass on its reporting page for the first time. Automated checks found 11 issues (mostly unnamed icon buttons and a missing table caption). Tab stops showed 360 circles across the grid and a path that escaped the column filter popover. The team fixed the names in an afternoon, added roving tabindex and moved the popover to a proper dialog over the next sprint, and added the state-by-state Playwright test above to keep it fixed.

Triage tips

Group automated findings by component, not by page; the same unnamed icon button usually appears in every row and every grid. Fix the component once and re-run. For Tab stops, take a screenshot of the visualisation before and after fixes — it is the most persuasive artefact for explaining keyboard problems to people who do not use a keyboard. Record states you tested in the ticket so the next person knows what “passed FastPass” actually covered.

Testing checklist

Design system notes

Run FastPass on every component story as part of release QA, and publish a short “FastPass clean” badge in component docs. Teams adopting components then start from a known-good baseline.

FAQ

Is FastPass enough for WCAG conformance?

No. It catches common, detectable issues. Conformance needs manual testing, including screen readers.

How long does FastPass take?

About five minutes per page state once you are familiar with it.

What does Assessment add?

A guided, criterion-by-criterion manual review with instructions — useful before major releases or formal audits.

Can FastPass test keyboard traps?

The Tab stops recording reveals them when you try to Tab out and cannot.

Does it work in Firefox?

Accessibility Insights for Web is available for Chromium-based browsers. Use Firefox’s inspector separately.

Should developers or testers run it?

Both. Developers before opening a pull request; testers when verifying features.

What if FastPass and our CI axe results differ?

Check the axe-core versions and rule tags; differences usually come from versions or from scanning different states. Align them so developers and CI see the same results.

Should FastPass findings block merges?

Automated failures, yes, once your baseline is clean. Tab stop findings need a human decision, so treat them as review items.

← Back to Accessibility Tree & API Inspection