A scan is a useful start
Automated tools can identify some potential barriers, but they do not establish complete accessibility. W3C explains that some checks need human intervention and tools can produce inaccurate results. [E03] Label an Atlas accessibility dimension as automated checks of the tested sample, not a certification that every user can complete every task.
Inspect the task, not only isolated elements
A form may have labels and still be confusing when validation errors appear. Follow a complete task with a keyboard and inspect whether focus, error messages and confirmation make sense. Include dialogs and expanded menus in the review. A page that passes at first load can still fail when a user opens a control or returns after an error.
Explain the impact of each finding
A list of rule identifiers is difficult for a site owner to prioritize. Connect a finding to the affected element and the task it may interrupt. Offer a specific correction and preserve evidence for the original state. Avoid treating every warning as a confirmed barrier; some require examination of the content’s purpose and the surrounding interaction.
Recheck the behavior after correction
A changed label or color may resolve one check while a redesigned component introduces another issue. Repeat the affected automated checks and the relevant manual journey. Store the environment and release version so the result can be traced. Forge can turn a finding into a scoped task with explicit acceptance rather than asking an agent to “make accessibility perfect.”
A scanner can find issues; a journey reveals usability
An automated check can identify some missing labels, structural problems or contrast issues. It cannot establish that every user can complete the application’s important tasks. Review a real journey with keyboard navigation, visible focus, error recovery and a narrow viewport.
For a registration form, ask whether fields have meaningful labels, whether errors point to the right input and whether the user can correct a mistake without losing unrelated data. For a menu, test opening, closing, keyboard access and what happens when focus leaves it. Record these observations separately from automated results.
| Decision | Useful requirement | Evidence |
|---|---|---|
| Automated checks | Find reproducible machine-detectable issues. | Tool output and affected element. |
| Keyboard journey | Complete the important task without a pointer. | Focus order and successful interaction. |
| Human review | Inspect meaning and practical usability. | Observed limitations and follow-up work. |
Where this goes wrong
Zero detected violations is not a blanket accessibility certification. Avoid using an Atlas automated category as such a claim. A positive result should state the tested scope and leave manual review visible.
A higher automated score is useful only when the experience also improves.
Turn it into a working checklist
- Label the automated scope.
- Test meaningful keyboard journeys.
- Explain impact and uncertainty.
- Retest changed components.
A concrete next step
Build an accessibility checklist around critical journeys and keep evidence per release. Recheck interactions after layout changes; a purely cosmetic edit can still affect focus, labels or reading order.
Watch a related case
The video could not be loaded. Try again later.