Weekly screen reader tests

A screen reader test is a short, repeated session: twenty minutes a week on three flows, with one reader and one browser fixed. It exists because automated tools read the DOM, not the announcement: criterion 4.1.2 Name, Role, Value, level A, is checked by listening to the name, role and state of every control.

The routine

• Landmarks and headings: open the landmark list, then the heading list. Every page needs a main and a hierarchy with no gaps.
• Tab and focus: walk the page with Tab and listen to the name of every control; focus must stay visible.
• A form error: submit an empty form, listen to the message and return to the field with Shift+Tab.
• A dynamic update: run a search and check that the result is announced without moving focus.

Which pair to choose

One pair, always the same, because a weekly comparison only means something if the tool does not change. On Windows: NVDA, GPL-2.0 licence, with Firefox or Chrome. On macOS and iOS: VoiceOver, included with the system. On Linux: Orca, LGPL-2.1 licence. Criterion 1.3.1 Info and Relationships, level A, shows up best in the heading list: if the visual hierarchy does not match the markup, the list gives it away.

What to write in the report

Three lines per problem: what you heard, what you expected, which criterion is involved. “The button says only Search, not which section it searches” is an accessible name defect and belongs to 4.1.2. “After submitting I hear nothing” belongs to 3.3.1 Error Identification, level A. The date and the reader version make the report reproducible.

The automated check before it

Before the session, run the static check on the main routes. It takes a minute and frees the twenty for what no tool hears.

for u in / /pricing /blog; do
  npx --yes pa11y "https://example.com$u" --standard WCAG2AA
done

Pa11y is open source under the LGPL-3.0 licence. It reports a selector and a criterion for each violation, and it keeps the listening session away from an unlabelled field you could have found automatically.

The EneUI catalogue

EneUI indexes the accessibility category, the status components and the shadcn sonner record, MIT licence from the shadcn/ui project: it is the case where a toast announcement depends on the live region, so it must be heard and not only seen. Checked on 1 November 2026 against 111,985 components.

The limitation

One person with a screen reader does not represent every disability, and one browser-reader pair does not cover the others. The weekly test is a filter, not a certificate: it replaces neither a full WCAG audit nor testing with disabled users.

Where to continue

The full method is in how to run an accessibility audit; the checklist is in accessible React components. The comparison of headless primitives is in Radix, Base UI and React Aria.