Testing and audits
A practical guide to finding accessibility barriers: what automated scans catch, what hands-on testing reveals, and how to turn audit findings into a clear repair plan.
No guides in this topic yet. Check back soon.
Start with a question, not a score
An accessibility test is useful when it answers a real question: Can someone complete the main task with a keyboard? Does a screen reader announce each control clearly? Can a visitor understand the page and recover from an error? A scan score can point you toward trouble, but it cannot answer all of those questions by itself.
Good testing combines repeatable automated checks with human review of meaning, interaction, and user journeys. The result should help your team decide what to fix first and how to confirm the fix worked.
What automated scans are good at
Automated tools can quickly inspect many pages for detectable patterns. Depending on the tool and page, they may flag missing accessible names, invalid or incomplete markup, some contrast problems, and other issues that deserve a closer look. Scans are especially useful for establishing a baseline and checking whether familiar problems return after code or content changes.
A flagged result is a lead to investigate, not always a confirmed failure. A clean result also does not mean a page is accessible: software cannot reliably judge every word, workflow, or interaction. Treat automated results as one input to testing.
What hands-on testing adds
Manual testing checks whether people can understand and operate the experience in context. A tester can follow important tasks, inspect how controls behave, and assess whether instructions, labels, and feedback make sense. Keyboard-only use and assistive technology checks can uncover barriers that a source-code scan will not settle.
For a scoped accessibility evaluation, the tester and organization should agree on the pages, templates, features, user journeys, standard, and conformance level to review. This makes the findings easier to interpret and makes clear what the evaluation did and did not cover.
A practical first-pass checklist
When reviewing a page or workflow, work through it as a person would use it:
- Navigate by keyboard: reach every link and control, follow a sensible focus order, and check that focus stays visible and does not get trapped.
- Check names and instructions: confirm form fields, buttons, and links have clear labels and that required formats or errors are explained.
- Review structure: scan headings in order and verify that page regions and content relationships are conveyed beyond visual styling.
- Inspect images and media: ask whether text alternatives communicate the purpose of meaningful images and whether media has the needed alternatives.
- Complete key tasks: submit a form, open a menu, or finish checkout and check that status changes and errors are announced and understandable.
- Run an automated scan: investigate the results, confirm which are actual barriers, and look for repeated patterns across similar pages.
This checklist is a starting point, not a complete WCAG conformance evaluation. The right test methods depend on the content, technology, and scope.
How to read an audit report
A useful report makes each finding actionable. Look for the affected page or component, the relevant accessibility requirement, what a person experiences, steps to reproduce the issue, and enough evidence for a developer or content editor to locate it. Clear recommendations should explain the intended outcome without prescribing a single implementation when several fixes are possible.
Also check the report’s scope and testing date. A report describes the pages and features evaluated at that time; it is not a permanent guarantee for content or functionality that changes later. After repairs, retest the affected experience and check related templates for the same underlying issue.
Choose the next step
- Compare a WCAG audit with an automated scan to understand what each method can tell you.
- See what a WCAG accessibility audit includes, from scope and testing through documented findings.
- Learn when to repeat an accessibility audit after redesigns, new features, or significant content changes.
For an evaluation with documented findings, visit our WCAG accessibility audit service. For ongoing visibility between evaluations, see website accessibility monitoring.
Discuss Your WCAG Accessibility Needs
Speak with a DHS Certified Trusted Tester about a WCAG accessibility audit, WEAR report, and POCC documentation. We can discuss evaluation scope, findings, and practical next steps for your organization.
MonkeyHub
- Aticles & News — Evolving insights on digital accessibility legislation, design practices, and corporate risk mitigation from beginner to enterprise scale. Articles & News
- Learning Center —
- MonkeySupport — Have an accessibility question? Submit a ticket and our team will see how we can help. Support Ticket


