Accessibility in practice
Why a passing accessibility scan still needs manual review
Use a small dialog example to see what a DOM scan can tell you, what requires interaction, and how to turn both into a reproducible accessibility review.
By A11y Scan editorial team
Published
Updated
An automated accessibility scan is a useful starting point. It can flag certain missing accessible names, invalid relationships, and contrast problems. A result with no reported violations means that the configured checks found no violations in the content they evaluated. It does not establish that every task, page state, or WCAG requirement works for the people using the site.
A dialog that looks fine in the first scan
Imagine a checkout page with a native button labelled Review order. The button has a useful name, can receive keyboard focus, and opens an order-confirmation dialog. Before activation, a scanner can inspect the button and the surrounding page. It cannot review an unrendered dialog or discover every possible action that leads to it.
Now activate that button using only the keyboard. Suppose the dialog appears but focus stays on the checkout button behind it. Tab then reaches background links and the user cannot reach Confirm order. The initial page scan did not exercise this sequence. A fresh scan may expose some structural issues in the dialog, but deciding whether the whole task works requires interaction and judgment.
Capture the state that contains the problem
In A11y Scan, start a workflow session, give the initial state a meaningful name, and capture it. Open the dialog yourself, then capture a second named state. Each capture runs with the validated scan configuration and records the page URL, timestamp, viewport, and findings. This is a local review session, not a script that will automatically replay the interaction later.
A capture only describes the visible state at that moment. If an error message appears after submission or a menu appears on a different action, capture and review those states separately. Export the workflow report before closing the sidepanel if you need to retain it; active workflow captures are held in memory.
Test the interaction as well as the markup
Return to the initial state and repeat the task with the pointer set aside. Confirm that you can open the dialog, understand its name and purpose, reach its controls, activate the intended action, and dismiss it using the expected interaction. Check where focus moves afterward. Use the WAI-ARIA dialog pattern as implementation guidance, while evaluating the actual page against the applicable WCAG criteria.
Then try a real screen reader. A reading-order or browser-speech preview can help you inspect names and document order, but it does not reproduce every behavior of a screen reader and browser combination. Listen to the dialog's announcement and verify that the available actions make sense. Include magnification, zoom, contrast, and other checks relevant to the task.
Keep evidence separate from interpretation
An actionable report says which page and state were tested, how to reproduce the behavior, what actually happened, and what a user needs to accomplish. For example: on the confirmation dialog at a 1280 CSS-pixel viewport, pressing Tab from Review order moves to a background navigation link; the Confirm order button is not reached in the expected sequence. Include the scan profile and affected selector when available.
Record automated findings alongside that observation. Do not turn the absence of a finding into a passing manual verdict. If you ask AI Chat to explain a selected finding, follow its finding references back to the scanner's evidence. AI explanation is an aid to interpretation and does not add, remove, or certify findings.
Retest the same task after the fix
Repeat the same actions, configuration, and viewport after changing the dialog. Re-run the scan in each relevant state and redo the keyboard and screen-reader steps. Local run comparison can show changes in reported findings, while your interaction notes establish whether the task now works. Neither replaces the other.
Sources and further practice
W3C: Selecting Web Accessibility Evaluation Tools
WAI-ARIA Authoring Practices: Dialog (Modal) Pattern