Manual Accessibility Audits

Automated testing checks structure: roles, names, attributes, text contrast. Most of what makes a data interface usable or unusable for disabled people is behaviour and presentation that no rule engine can judge: whether focus goes somewhere sensible after deleting a row, whether a 400%-zoomed page scrolls sideways, whether selection survives Windows High Contrast, whether a sort announcement is heard at all. Those need a person, a keyboard, a zoom setting, a contrast theme and a screen reader — and a procedure, so the results are repeatable.

This topic provides that procedure for data interfaces: a keyboard-only script for grids, a zoom and reflow audit, a forced-colours audit, and a report format that turns findings into fixes. It is written for accessibility specialists running audits and for engineers and QA staff who want to check their own work before an audit finds it.

It belongs to testing & auditing accessible data interfaces, alongside the automated accessibility testing recipes.

WCAG criteria in scope

Manual audits are where most criteria are actually verified. The ones that matter most for data UIs, and the audit that checks each:

Criterion	Level	Audit
2.1.1 Keyboard / 2.1.2 No Keyboard Trap	A	Keyboard-only script
2.4.3 Focus Order	A	Keyboard-only script
2.4.7 Focus Visible / 2.4.11 Focus Not Obscured	AA	Keyboard script at 100% and 400%
1.4.10 Reflow	AA	Zoom audit at 400%
1.4.4 Resize Text / 1.4.12 Text Spacing	AA	Zoom audit at 200% and spacing overrides
1.4.1 Use of Color / 1.4.11 Non-text Contrast	A / AA	Forced-colours audit, greyscale checks
4.1.3 Status Messages	AA	Screen reader pass
1.3.1 Info and Relationships	A	Screen reader pass (headers, groups)

Prerequisites

The components’ intended behaviour, documented: keyboard contracts, announcement strings, states — for example entering and exiting cell edit mode and announcement queues for competing messages.
A test environment with seeded data, including edge cases (long names, empty states, errors).
Screen readers installed and configured with default settings: NVDA and Narrator on Windows, VoiceOver on macOS and iOS, TalkBack on Android.
Speech capture set up: capturing NVDA speech logs for manual testing.

Each pass uses one condition at a time, so a failure can be traced to its cause.

ARIA & HTML spec reference

Manual audits verify behaviour rather than markup, but auditors should inspect the accessibility tree whenever a behaviour fails, to find the cause:

Tool	What it shows	Used when
DevTools Accessibility pane	Computed role, name, description, states	A control is announced wrongly
Full-page accessibility tree view	Structure as AT sees it	Reading order or grouping is wrong
`document.activeElement` in the console	Where focus actually is	Focus seems lost
Rendering panel: forced colours, vision deficiencies	Emulated display conditions	Contrast and colour checks
NVDA Speech Viewer / VoiceOver caption panel	Exact speech	Any screen reader finding

Step-by-step implementation

Step 1 — Keyboard-only pass (SC 2.1.1, 2.1.2, 2.4.3, 2.4.7)

Mouse disconnected · no screen reader · run the 8-stage grid script · count journey keypresses

Step 2 — Zoom pass (SC 1.4.10, 1.4.4, 1.4.12, 2.4.11)

1280 px window at 400% · then 200% · then text-spacing stylesheet · Tab through key controls

Step 3 — Forced colours pass (SC 1.4.1, 1.4.11, 2.4.7)

DevTools emulation on every page type · Edge on Windows: one dark and one light contrast theme

NVDA + Chrome and VoiceOver + Safari minimum · critical journeys · Speech Viewer / captions on

Step 5 — Report and convert to tests

One ticket per finding · steps, quotes, criterion, impact, fix · regression test for components

A finding is only closed when a test would catch it next time.

Keyboard interaction contract

The keyboard pass verifies each component’s documented contract. The keys auditors should expect to work in data UIs:

Key	Context	Expected	Failure indicator
`Tab` / `Shift+Tab`	Page	Moves in reading order; one stop per composite widget	Dozens of stops inside a grid or chart
Arrows, `Home`, `End`	Grid, listbox, chart	Move within the widget	Page scrolls instead
`Enter` / `Space`	Buttons, headers, rows	Activate	Only click works
`Escape`	Menus, popovers, dialogs, editors	Close or cancel; focus returns	Nothing, or focus lost
`Shift+F10`	Grid cells with context menus	Open the menu at the cell	Browser menu opens
Documented shortcuts	As documented	Work only where scoped	Fire while typing in fields

A realistic manual matrix for data products — at least two readers on each release, all four for major releases:

Pass	NVDA + Chrome	VoiceOver + Safari	JAWS + Chrome	TalkBack / iOS VoiceOver
Every release	✓	✓	—	—
Major release	✓	✓	✓	✓ (mobile products)
New data component	✓	✓	✓	✓
Evidence	Speech Viewer log	Caption panel log	Speech history	Notes + screen recording

No single pass finds everything; the four together cover most of what automation misses.

Edge cases & failure modes

1. Auditing with non-default settings

Diagnosis: a tester’s customised screen reader verbosity hides or adds announcements. Fix: audit with default settings; note any deliberate change.

2. Findings that are reader behaviour

Diagnosis: a difference between NVDA and VoiceOver filed as a bug. Fix: check the accessibility tree; if the markup is correct and standard, document rather than hack — see assistive technology behaviour differences.

3. Only the happy path

Diagnosis: audits cover loaded tables but not empty, error or loading states. Fix: include state variants in every pass.

4. Audits that never become tests

Diagnosis: the same finding reappears two releases later. Fix: every component finding ships with a regression test.

5. One giant ticket

Diagnosis: “Fix accessibility on Invoices (37 items)”. Fix: one ticket per finding.

Keyboard-only audit script

A keyboard-only audit script for data grids walks through reach, navigate, sort and filter, select, edit, row actions and exit, with pass/fail per step and journey keypress counts.

2.3 Page Down moves by a visible page; rows under sticky header?   PASS / FAIL (2.4.11)

Behaviour note: disconnect the mouse — every reach for it is a finding.

Zoom and reflow testing

Zoom and reflow testing at 400 percent covers the 400% reflow pass, the 200% resize pass and text spacing, with a console snippet that finds overflowing elements outside exempt tables.

.filter((el) => el.getBoundingClientRect().right > window.innerWidth + 1)

Behaviour note: zoom a 1280 px window; do not resize to 320 px.

Windows high contrast audits

Windows high contrast audits for data UIs checks table boundaries, focus, selection, status and charts in forced colours, emulated and on real Windows.

[role="row"][aria-selected="true"] { outline: 1px solid SelectedItem; }

Behaviour note: the design is supposed to change; information must not disappear.

Actionable bug reports

Writing actionable accessibility bug reports gives the report structure — environment, key-sequence steps, quoted output, criterion, impact, fix and regression test — with a severity guide.

ACTUAL (NVDA Speech Viewer): "Amount  button  column header  not sorted"  [nothing further]

Behaviour note: quote what was heard, separately from what was inspected.

Planning estimates for an experienced tester on one page type with one main data component.

Cross-cutting concerns

Audit scope. Audit page types and components, not every URL. A product with forty list pages built from one table component needs the component audited thoroughly and a sample of pages checked for composition problems.

Who audits. Engineers can and should run the keyboard, zoom and forced-colours passes on their own work; they need no specialist tools. Screen reader passes benefit from experienced users — ideally including disabled testers who use assistive technology daily, whose findings often differ from those of sighted auditors.

Frequency. Run the fast passes on every significant change, the screen reader pass per release, and a full audit — all passes, all readers, all page types — at least annually or before major releases and procurement reviews.

Evidence. Keep audit artefacts — scripts with results, speech logs, screenshots — with the release. They show progress over time and are the evidence base for accessibility conformance reports.

Automation handoff. Every manual finding in a component is a candidate for an automated test. Over time, the manual audit should find fewer structural issues and spend more of its time on the judgements only people can make.

Planning an audit

A useful audit starts with scope and ends with a plan, not a list.

Choose page types and components. List the product’s page types (list, detail, dashboard, report, settings) and the data components each uses. Audit every component once in depth and every page type for composition problems.

Choose states. For each data component, include loaded, empty, loading, error and at least one interactive state (sorted, filtered, editing, selected, expanded). Most serious findings live in states other than “loaded”.

Choose the assistive technology matrix. NVDA with Chrome and VoiceOver with Safari at minimum; add JAWS for enterprise and government products, Narrator for managed Windows fleets, and TalkBack and iOS VoiceOver for anything used on mobile.

Prepare data. Seed realistic edge cases: long names that wrap, negative numbers, empty cells, hundreds of rows, a record with every optional field.

Agree the output. One ticket per finding in the product’s tracker, severity by user impact, and a short summary for stakeholders: what works, what blocks users, what is planned.

Schedule the re-test. Fixes are verified in a follow-up pass focused on the findings, and the next full audit is booked before this one ends.

Who audits should include

Audits by sighted specialists using assistive technology find most structural and behavioural failures. They miss some of what daily users of assistive technology notice immediately: announcements that are technically correct but too verbose to use at speed, workflows that are possible but exhausting, and patterns that work in isolation but conflict with how experienced users actually navigate. Where possible, include disabled testers who use screen readers, magnifiers, voice control or switch access every day, and pay them for their expertise. Their findings are often the most valuable in the audit.

Design system integration

Artefact	Owned by	Purpose
Per-component audit scripts with expected results	Design system	Consistent audits across products
Reference speech logs per component	Design system	Distinguish component from product regressions
Forced-colours and 400% screenshots per component	Design system	Visual baselines
Report template and severity guide	Accessibility team	Consistent, actionable findings
Audit schedule and scope per product	Product teams	Coverage of page types and states

Testing checklist

Per change

Keyboard-only script run on affected components.
400% zoom check on affected page types.
Forced-colours emulation check on affected states.

Per release

Screen reader pass on critical journeys with NVDA and VoiceOver.
Findings filed as individual, actionable tickets.
Component findings shipped with regression tests.

Periodic

Full audit across page types, states and all target readers.
Artefacts stored with the release.

FAQ

Why do data interfaces need manual accessibility audits if automated tests pass?

Automated tests check structure and attributes. Whether focus goes to the right place, whether pages work at 400 percent zoom, whether states survive high contrast mode and whether announcements are heard all need a person following a procedure.

What manual checks should be done first?

A keyboard-only pass without a mouse or screen reader. It needs no special tools, takes under half an hour per component and finds many of the most serious data UI failures.

Can engineers run manual accessibility audits themselves?

Yes, for the keyboard, zoom and forced-colours passes, which need no specialist tools. Screen reader passes benefit from experienced users, including disabled testers who use assistive technology daily.

Which screen readers should a manual audit include?

At minimum NVDA with Chrome and VoiceOver with Safari. Add JAWS for enterprise and government products, Narrator where users are on managed Windows devices, and TalkBack and iOS VoiceOver for mobile use.

What should an audit deliver?

One actionable ticket per finding with steps, evidence, criterion, impact and a suggested fix, a short summary for stakeholders, and a date for the re-test of fixed findings.

Do audit findings count as a conformance report?

Not on their own. Audit results are the evidence; a conformance report such as an ACR or VPAT summarises conformance per criterion across the product, based on that evidence.

How often should a full manual audit be done?

Fast passes on every significant change, a screen reader pass on each release, and a full audit across all page types and readers at least once a year or before major releases.

Testing recipes — the automated layer
Screen reader smoke testing — per-release speech checks
AT behaviour differences — interpreting reader results
Focus indicator contrast auditing — measuring focus visibility
Responsive data tables — what zoom audits check

← Back to Testing & Auditing Accessible Data Interfaces