Audit a website for accessibility by first defining scope and target level, then selecting a representative sample of pages, testing them with both automated tools and manual checks, and recording each pass or failure in a report that can be acted on. Automated tools find only some problems, so the manual part is not optional. The W3C’s evaluation method, WCAG-EM, gives a structure you can follow.
The five WCAG-EM steps
The W3C’s WCAG-EM overview lays out five steps.
- Scope. Set the boundaries of the evaluation, its goals, and the target WCAG conformance level (A, AA or AAA). Many organisations aim for AA, but confirm which level any contract, policy or legal advice requires of you.
- Explore. Map the site’s key views, core functionality, content and design types, and the technologies it relies on.
- Sample. When testing every page is impractical, choose a representative set of views using structured and random selection.
- Audit the sample. Determine which criteria pass or fail, consider accessibility support for specific features, and record the steps you took.
- Report. Combine findings, state conclusions about conformance and give an overall result.
WCAG-EM is a supporting resource that adds no new requirements. Its page also notes that involving users with disabilities is recommended, and that effective use requires knowledge of WCAG, accessible design and assistive technologies. At the time of writing (November 2026), the W3C page states that WCAG-EM 2 has been published to cover apps and other digital products, while version 1.0 remains available.
Step by step in practice
1. Start with Easy Checks
The W3C’s Easy Checks are a quick first pass, not a full evaluation. They cover:
- Page titles that describe the page and differ across the site.
- Alt text on informative images, and empty alt on decorative ones. See writing good alt text.
- Real headings in a sensible hierarchy.
- Colour contrast, with 4.5:1 as the minimum for normal-size text.
- Text that resizes without overlap, cut-off or horizontal scrolling.
- Full keyboard access, visible focus and no keyboard traps.
- Form labels, clear errors and required fields not marked by colour alone.
- Moving or flashing content that can be paused, and nothing flashing more than three times per second.
- Captions, transcripts, audio description and keyboard-operable media controls.
- Content that still makes sense with images and styles off.
The W3C warns that a page can pass these and still have significant barriers.
2. Choose the sample
Include the home page, key templates (article, product, contact), forms and checkout flows, pages with media, and any page with custom widgets such as menus, carousels or modals. Add a few random pages to catch surprises.
3. Run automated tests
Use a browser-based checker or accessibility linter on each sampled page. These detect things such as missing alt attributes and some contrast failures. The W3C notes that tools can detect some problems but judging whether alt text is appropriate requires a person to look at the image in context.
4. Test manually
- Keyboard only: tab through every control, open every menu, submit every form.
- Screen reader pass: test key journeys with a screen reader on at least one desktop setup.
- Zoom and reflow: zoom text and test small screens.
- Reduced visuals: check content order with styles off.
- Language and plain wording: check that error messages and instructions are understandable.
5. Record every finding
For each issue note the page, the criterion, what happened, severity and a fix suggestion. Screenshots help developers.
A report structure that works
| Section | Contents |
|---|---|
| Summary | Scope, target level, date, headline result |
| Method | Pages sampled, tools, assistive technologies, browsers |
| Findings | Table by issue: location, criterion, severity, fix |
| Priorities | What blocks tasks first, then what affects many pages |
| Next steps | Owner, timing and a retest plan |
Prioritise issues that stop someone completing a task, such as an inaccessible form or checkout, ahead of cosmetic ones, and fix template-level problems first because they repair many pages at once.
Limits and honest caveats
- A sample audit describes the sampled pages, not every page.
- Passing the Easy Checks or an automated scan is not conformance.
- Comprehensive assessment needs professional evaluation and testing with people who use assistive technology.
- Legal obligations vary and change. This is general information, not legal advice; seek professional advice for your situation.
- Accessibility is easier when it is built in from planning, as WCAG-EM itself stresses. Include it in any website redesign, and remember that accessible, clear sites also tend to support conversion, because clarity helps every visitor.
Where Radiance Impact fits
Radiance Impact’s Technology division designs, builds and maintains business websites and can fold accessibility checks into that work. To talk through an audit or rebuild, contact the team or see Digital Technology and AI Solutions.
Sources
- Website Accessibility Conformance Evaluation Methodology (WCAG-EM) Overview, W3C Web Accessibility Initiative
- Easy Checks: A First Review of Web Accessibility, W3C Web Accessibility Initiative
- Images Tutorial: Decision Tree, W3C Web Accessibility Initiative
