Accessibility Smoke Test Builder

Build a page-specific manual accessibility smoke test — what to check, how to test it, and what a bug looks like.

Runs 100% client-side
Copy outputCSV & Markdown export
On this page4 sections
Keyboard navigationHigh

All interactive controls are reachable and operable with the keyboard.

How: Put the mouse aside. Tab and Shift+Tab through the page; activate controls with Enter/Space.
Expected: Focus moves through every control in a logical order and nothing is keyboard-trapped.
Example bug: Focus jumps to the footer before the password field, or a custom dropdown can't be opened with the keyboard.
Focus visibilityMedium

Every focused control shows a visible focus indicator.

How: Tab through all controls and watch for the focus outline/ring.
Expected: A clear visible indicator appears on each focused element.
Example bug: The focus outline is removed (outline:none) on the primary button.
Form labelsHigh

Form fields have visible and programmatic labels.

How: Click each label and confirm it focuses the field; inspect for matching for/id or aria-label.
Expected: Each input has an associated label, not a placeholder standing in for one.
Example bug: The email field uses placeholder text only and has no <label>.
Error messagesHigh

Validation errors identify the field and are announced.

How: Submit the form empty and with invalid values.
Expected: Errors name the affected field and are associated with the input (aria-describedby / role=alert).
Example bug: A generic 'Something went wrong' appears with no field association.
Login page specificsMedium

Password show/hide toggle is accessible.

How: Tab to the show/hide control and toggle it with the keyboard.
Expected: The toggle is a real button with a name and announces its state.
Example bug: The eye icon is a div that can't be focused with the keyboard.

HOW TO USE

  1. 01Select the page type you are testing — login, checkout, modal, navigation, and more.
  2. 02Toggle the test areas to include (keyboard, focus, labels, errors, contrast, and others).
  3. 03Read the generated checklist — each item has what to test, how, the expected result, and an example bug.
  4. 04Copy as Markdown or export a TestRail-style CSV to drop the cases into your test management tool.

Try it

Page type = Modal / dialog → note the focus-trap and Esc-to-close checks added automatically.

WHEN TO USE

Use this when your team knows accessibility matters but isn't sure what to check manually before release. It produces a page-specific smoke test that any tester can run without being an accessibility specialist. This is a smoke test, not a full WCAG audit — and automated tools don't catch everything, so the manual keyboard and screen-reader checks here are deliberately included.

WHAT BUGS THIS FINDS

  • Keyboard and focus traps

    Checks that every control is reachable, operable, and visibly focused — catching the bugs automated scanners miss.

  • Unlabelled fields and controls

    Form-label and button-name checks find inputs and icon buttons a screen reader can't announce.

  • Silent state changes

    Screen-reader and live-region checks catch totals, errors, and toasts that update without being announced.

QA USE CASES

01

Pre-release a11y smoke pass

Generate a checklist for the page under test and run it before sign-off.

02

Standardise manual a11y testing

Give every tester the same page-specific checks so coverage is consistent.

03

Complement automated scans

Pair with the static Accessibility Checker to cover both heuristic and manual findings.