A Keyboard-Only Audit Script for Data Grids

A keyboard-only audit is the single most productive manual accessibility check for data interfaces. It needs no assistive technology, no special tools and no expertise beyond knowing the standard keys, and it finds the failures that automated scans structurally cannot: focus that vanishes after a delete, a filter popover you cannot leave, a sort button that only responds to clicks, a grid that takes forty Tab presses to cross, a focus ring that disappears on the selected row.

This page is a script — a fixed sequence of tasks with what to observe at each — so audits are repeatable and comparable between releases and auditors. It belongs to manual accessibility audits.

Spec reference

The script exercises these criteria:

  • SC 2.1.1 Keyboard (A) — every function is operable by keyboard.
  • SC 2.1.2 No Keyboard Trap (A) — focus can always leave a component.
  • SC 2.4.3 Focus Order (A) — focus moves in a meaningful order, including after actions.
  • SC 2.4.7 Focus Visible (AA) — focus is always visible.
  • SC 2.4.11 Focus Not Obscured (Minimum) (AA) — focus is not hidden by sticky content.
  • SC 2.1.4 Character Key Shortcuts (A) — single-key shortcuts can be turned off or are scoped.
  • SC 3.2.1 On Focus / 3.2.2 On Input (A) — focus and input do not trigger unexpected changes of context.

Standard keys to use: Tab/Shift+Tab, arrows, Home/End, Page Up/Page Down, Enter, Space, Escape, F2, Shift+F10, and any product-documented shortcuts.

The audit sequence The eight stages of the keyboard-only grid audit in order: reach, navigate, sort, filter, select, edit, row actions, exit. The audit sequenceReachTab from the top of the page to the gridcount presses; skip links?Navigatearrows, Home, End, Page keys, Ctrl+Homefocus visible and unobscured?Sort and filteractivate headers; type a filter; clear itfocus stays? result visible?SelectSpace on rows; Shift+Arrow ranges; select allstate visible without colour?EditEnter or F2, type, Enter; again with Escapevalue committed or restored?Row actions and exitmenu, delete, dialog; then Tab outfocus lands deliberately?
Always in this order — each stage starts from where the previous one left focus.

When to run it — and how often

Run it on every new grid or significant grid change before release, and as part of any periodic audit. A full pass on one grid takes 15–30 minutes. For small changes, run only the stages the change touches.

It complements, and partly seeds, automated keyboard tests: every failure found here should become a row in the component’s keyboard contract test, as in testing grid keyboard navigation with Playwright.

The misapplication to name is running the script with a screen reader on and calling it a keyboard audit. Screen readers change key handling (browse mode consumes arrows and letters); the keyboard-only audit must be done without one, and the screen reader pass done separately.

Annotated code example

KEYBOARD-ONLY GRID AUDIT — Invoices grid — build 2026.09.18 — Chrome 128 / Windows 11
Tester: ____   Mouse: disconnected   Zoom: 100%

1 REACH
  1.1 From address bar, Tab until focus reaches the grid.       Presses: __  (target ≤ 10)
  1.2 Is there a skip link to the main content? Does it work?   PASS / FAIL
  1.3 Is focus visible on every stop on the way?                PASS / FAIL  (note any invisible stop)

2 NAVIGATE (inside the grid)
  2.1 Right/Left/Up/Down move one cell; focus ring fully visible.   PASS / FAIL
  2.2 Home/End go to row start/end; Ctrl+Home/Ctrl+End to corners.  PASS / FAIL
  2.3 Page Down moves by a visible page; rows under sticky header?  PASS / FAIL (2.4.11)
  2.4 Tab leaves the grid in one press (single tab stop).           PASS / FAIL

3 SORT AND FILTER
  3.1 Tab to a sortable header; Enter sorts; focus stays on header.  PASS / FAIL
  3.2 Filter field: type a query; results update; focus stays in field.  PASS / FAIL
  3.3 Filter popover (if any): opens with Enter; Escape closes; focus returns.  PASS / FAIL

4 SELECT
  4.1 Space toggles a row; Shift+Arrow extends; Ctrl+A selects all.  PASS / FAIL
  4.2 Selected state visible without relying on colour.              PASS / FAIL

5 EDIT
  5.1 Enter/F2 opens editor with value selected; Enter commits.      PASS / FAIL
  5.2 Escape cancels and restores; focus returns to the cell.        PASS / FAIL
  5.3 Invalid value keeps editor open with a visible error.          PASS / FAIL

6 ROW ACTIONS AND EXIT
  6.1 Row menu opens with Enter or Down Arrow; arrows move; Escape returns.  PASS / FAIL
  6.2 Delete a middle row: focus lands on the next row.              PASS / FAIL
  6.3 Shift+F10 on a cell opens the context menu (if any).           PASS / FAIL
  6.4 Tab from the grid reaches pagination; nothing is trapped.       PASS / FAIL

Journey count: sort by Amount then open INV-1042 edit dialog = __ keypresses

The journey count at the end is not a WCAG measure, but it is the number product teams respond to. “Editing an invoice takes 43 keypresses” motivates the single-tab-stop and toolbar patterns more effectively than a criterion number.

Keyboard & AT behaviour

Stage Typical failure Criterion
Reach 30+ Tab stops before the grid; no skip link 2.4.1
Navigate Focus ring clipped by neighbouring cells 2.4.7
Navigate Rows scroll under the sticky header 2.4.11
Sort Header only sortable by click 2.1.1
Filter Popover cannot be closed without a mouse 2.1.2
Edit Escape commits instead of cancelling 3.3.4 (data)
Row actions Focus to body after delete 2.4.3
Exit Tab cycles inside the grid forever 2.1.2
A completed audit summary Mock results table from a keyboard-only audit showing each stage, its result, and the first failing step with its criterion. A completed audit summaryStageResultFirst failureReachPass—NavigateFail2.3 row hidden under header1Sort and filterPass—SelectFail4.2 selection by colour onlyEditPass—Row actionsFail6.2 focus lost on delete21SC 2.4.11 — add scroll padding for thesticky header2SC 2.4.3 — move focus to the next rowafter deletion
A one-screen summary for the report; details and key sequences live in the individual findings.

Integration context

Findings are filed using the structure in writing actionable accessibility bug reports: key sequence, expected, actual, criterion. The rules behind each stage are covered across the site — focus after changes in focus management in single-page apps, focus ring design in designing focus indicators for dense data grids.

After the keyboard pass, repeat key stages at 400% zoom — zoom and reflow testing at 400 percent — where focus obscuring and horizontal scrolling problems appear.

Exploratory keyboard poking versus a scripted audit Comparison of informal keyboard testing against running a fixed keyboard-only audit script. Exploratory keyboard poking versus a scripted audit✗ Exploratory pokingDifferent paths each timeMisses stages nobody thought to tryFindings hard to reproduceNo baseline to compare against✓ Scripted auditSame stages, same order, every releaseEvery stage coveredKey sequences recorded for each findingPass/fail and keypress counts over time
A script makes audits comparable across releases and testers — and makes nothing depend on who happened to test.

Gotchas

Mouse habits. Testers instinctively click to recover from a stuck state. Disconnect the mouse, or note every time you reached for it — each is a finding.

Browser and OS keys. On macOS, enable “Keyboard navigation” (System Settings) or Safari’s “Press Tab to highlight each item”, or Tab skips links and buttons.

Zoom and density. Run at 100% first, then repeat navigate and edit stages at 200% where focus rings are most often clipped.

Design system notes

Publish the audit script for each data component with its expected results, so product teams can run it against compositions and see immediately which failures come from the component and which from the product.

Testing checklist

FAQ

What is a keyboard-only accessibility audit?

A manual check where you use a page with only the keyboard — no mouse and no screen reader — to confirm that every function works, focus is always visible and in a sensible place, and nothing traps you.

How long does a keyboard audit of a data grid take?

Typically 15 to 30 minutes for a full pass over one grid using a script, less if you only re-test the stages a change affects.

Should I run a screen reader during a keyboard audit?

No. Screen readers change how keys behave. Do the keyboard-only pass first, then a separate screen reader pass.

Why count keypresses?

It turns efficiency into a number teams can act on. A journey that takes forty keypresses reveals missing single-tab-stop patterns, skip links or shortcuts even when every criterion technically passes.

← Back to Manual Accessibility Audits