Pre-launch testing catches accessibility defects while changes are still easier to make. It should include prototypes, components and final implementation.
What the work is trying to prove
Good accessibility work starts with a testable question. Can a person complete the task without a mouse? Is the control name exposed in a way that matches the visible label? Does an error message identify the problem and help the user recover? Does focus move to the place a user would expect after a dialog opens, a route changes or a form submission fails?
Those questions are more useful than a generic score because they connect the standard to a real interface. WCAG success criteria describe outcomes. The audit translates those outcomes into evidence from pages, components, states and workflows.
What to include in scope
The sample should include distinct templates, shared components, content patterns and critical journeys. A small marketing site might need a home page, service page, article page, contact form and navigation states. A web application usually needs authenticated flows, dashboards, data tables, filters, dialogs, notifications and error recovery. A WordPress site needs theme templates, blocks, plugin output and representative authored content.
Scope also includes environments. Browser, assistive technology, viewport width, zoom level and device assumptions should be documented. Without that context, the same finding may be hard to reproduce later.
Automated testing has a place
Automated tools are valuable because they are consistent and quick. They can catch missing labels, invalid ARIA, empty buttons, some contrast failures, duplicate IDs and other rule-based issues. They are also useful in regression testing because the same rules can run repeatedly.
The limitation is that automated tools cannot reliably judge meaning or workflow quality. A page can have no automated violations and still be unusable by keyboard. A button can have an accessible name that is technically present but not useful. A modal can look correct while focus escapes into the background.
Manual testing fills the behavioral gaps
Manual testing checks operation. The tester uses the interface by keyboard, checks focus order, inspects names and roles, changes zoom and text spacing, submits forms with errors and follows real workflows. Screen reader testing adds another layer: what is announced, whether the structure is navigable, whether dynamic updates are perceivable and whether users can recover from mistakes.
This is why a finding needs more than a criterion number. A good finding explains evidence, impact, fix and verification. It should be possible for an engineer to reproduce the issue, understand why it matters and know what condition must be true before the issue can be closed.
How to document findings
Each finding should include a stable ID, affected component, user impact, environment, reproduction steps, expected behavior, actual behavior, recommended fix and verification instructions. WCAG mapping should be accurate and conservative. If the mapping is uncertain, the report should say so instead of forcing a criterion for appearances.
The best findings are not written to embarrass a team. They are written so a team can make a correct change. That means separating symptoms from root causes. A missing label on five instances of the same custom select may be one component defect, not five unrelated content issues.
Practical quality checks
Before publishing or shipping, check keyboard access, focus visibility, heading order, landmark structure, form labels, error summaries, dynamic status messages, reflow at narrow widths, text spacing, target size and reduced motion behavior. For auditing work, record what was tested and what was not tested.
Automated testing should run again after fixes, but passing automated checks is not the same as accessibility conformance. Retesting should revisit the original evidence and confirm that the user-facing barrier is resolved.
Need help evaluating a website or web application?
Request an Accessibility Review when you need technical findings your team can reproduce, fix and verify.