A website accessibility audit is a planned assessment of whether people with different needs can understand the content, navigate the interface and complete important tasks such as registration, purchasing, booking, signing in or submitting a form.
A reliable audit does not stop at an automated tool result. It combines code checks with manual evaluation of the interface, content, keyboard operation and selected assistive technology scenarios.
How is an audit different from an automated scan?
An automated scan can quickly identify some technical failures, including low contrast, a missing form label, an empty link or invalid ARIA. This is a useful starting point, but not the complete assessment.
A tool cannot reliably decide whether a menu operates logically, whether focus returns correctly after closing a dialog, whether an error message explains how to recover, or whether checkout can be completed without a mouse. Manual testing checks both individual elements and their behaviour across the full journey.
How is the audit scope selected?
It is usually more useful to select a representative sample of important templates, shared components and business-critical journeys than to test every similar page.
- Which tasks must users be able to complete?
- Which pages use different templates or components?
- Are login, payment, booking or other private areas involved?
- Which browsers, responsive states and assistive technologies are in scope?
- Will the team need a report only or implementation support as well?
For an online store, a useful scope normally includes search, filtering, product options, basket, checkout and error states, not only the home and product pages.
What is normally tested?
Page structure and content
Heading order, language, landmarks, link purpose, image alternatives, lists, tables and reading order.
Keyboard and focus
Whether every interactive element is reachable, focus is visible, no traps exist and the sequence follows the task.
Forms and errors
Labels, instructions, validation, understandable error messages and recovery after unsuccessful submission.
Responsive presentation
Text resizing, 200–400% zoom, reflow, mobile states and touch target size.
Selected screen reader scenarios
Accessible names, roles, states, form instructions, live messages and critical journeys within the agreed scope.
What should a useful audit report contain?
A product owner should see risk and priority, while a developer should see the location, reproduction steps and likely remediation direction.
- Page, component and state where the issue occurs.
- Exact reproduction steps.
- Actual and expected behaviour.
- User impact and severity.
- Related WCAG criterion.
- Practical remediation direction and screenshots where useful.
What happens after the audit?
Issues are grouped by impact, recurrence and remediation effort. Shared menu, modal or form problems are normally addressed before isolated page-level symptoms. After implementation, the original finding and the complete affected journey should be retested.
When is an audit worth commissioning?
- When the current accessibility condition is unknown.
- Before a significant redesign or platform migration.
- When a customer, procurement team or authority requests evidence.
- After receiving an accessibility complaint.
- When building an e-commerce, booking, banking or other important digital service.
Trusted sources
Need your website assessed?
Send the website URL and the most important user journey. Webmedic will propose a specific audit scope.