Ch. 22 · Software Testing

Accessibility Tests Beyond Automated Scans

Accessibility Tests Beyond Automated Scans. Learn the reasoning, a practical example, common mistakes and an interview exercise.

~2 min readintermediateupdated Oct 3, 2026

Automated checks detect some accessibility defects, while interaction and assistive-technology testing reveal others. Focus, names and navigation need behavioral verification.

Before you start

You should understand inputs, expected outputs and the boundaries of the component under test. State the risk a test should detect before choosing a tool or mock. Distinguish controlled dependencies from real integrations so the result does not imply more coverage than the test actually provides.

The practical goal is to reason through this situation: Test a dialog’s keyboard focus and return focus after closing. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.

Step-by-step walkthrough

Step 1: Check semantic structure

Names, labels and descriptions must express the interaction.

Step 2: Exercise keyboard behavior

Focus entry, movement and restoration need actual interaction checks.

Step 3: Use automated scans as one signal

Passing them does not establish complete accessibility.

Worked scenario

Test a dialog’s keyboard focus and return focus after closing.

A dialog has valid labels and produces no automated violation, but closing it leaves focus on a removed node. Keyboard interaction exposes that recovery defect. A form error similarly needs understandable placement and appropriate announcement, not merely red styling that appears correct in a screenshot.

Common mistake

A zero-violation scan does not prove the interface is fully accessible.

Verify the behavior

Test keyboard-only completion, screen-reader context and error recovery on the real interface.

Interview exercise

Verify a form error.

Answer and reasoning

Check label and description relationships, keyboard operation and whether the error is understandable and announced appropriately.

Continue learning

Compare the scenario with the Software Testing interview questions and test your understanding with the Software Testing MCQs. For terminology and implementation details, consult the reference material.

More in Software Testing

read ✓Software Testing · hard

Testing Time with an Injected Clock

Inject a clock instead of calling the system time, freeze it in tests, and remove the sleeps that make tests flaky.

~2 min readread →
read ✓Software Testing · mid

Code Coverage and Its Limits

Read line and branch coverage as a signal, not a goal, and avoid the tests that chase the number without checking behavior.

~2 min readread →
read ✓Software Testing · hard

Scoping End-to-End Tests

Reserve end-to-end tests for critical user journeys, use stable selectors, and avoid duplicating coverage the lower tests already have.

~2 min readread →
esc