5 Accessibility Testing Tools and How to Use Them

Accessibility testing tools help you find barriers that are easy to overlook during a visual review. They are most useful when they support a clear task: identifying a problem, understanding its cause and checking that a fix works. No single score can describe every visitor’s experience.

This guide covers five useful tools and a way to combine them for a UK business website. Use them on representative pages and important journeys, including error states. A clean homepage scan does not tell you whether somebody can complete an enquiry or purchase.

Choose a useful test sample first

List the different kinds of page and interaction on your website. Include an article, a service or product page, forms, navigation, dialogs and any transactional steps that matter. Add pages containing tables, media or downloadable documents if they are important to your users.

Test more than the default state. Open a menu, trigger a validation error, change a filter and move through a dialog. Some issues exist only after interaction. Record the browser, device, URL and state so another person can reproduce the result.

1. WAVE: inspect issues in page context

WAVE, from WebAIM, presents accessibility information alongside the rendered page. Its visual annotations can help you connect a reported issue to a particular heading, image, form control or piece of content. This is useful when explaining a finding to an editor or designer.

1. Open the public page using WAVE’s supported evaluation route or browser tool.
2. Review the summary, then inspect individual annotations in context.
3. Read the explanation and examine the underlying element.
4. Check whether the issue is a genuine failure, a warning requiring judgement or an expected feature.
5. Retest after the relevant content or template is corrected.

Do not treat every visual marker as the same severity. A tool can locate a missing alternative, but a human still needs to decide what the image means and whether the proposed text is appropriate. Keep private or sensitive page content within an approved testing environment.

2. Lighthouse: a repeatable browser audit

Lighthouse is a developer-oriented auditing tool available through Chrome’s tooling and other supported workflows. Its accessibility audits can identify some programmatically detectable issues and provide links to further explanations.

Run it against a page in a known state, review the individual checks and save the relevant findings. Use it after a template change or as part of a repeatable release check. A change in the score can prompt investigation, but the underlying issues are more actionable than the number alone.

Automated coverage is limited. A page may receive a strong score while having confusing link text, an awkward reading order or a keyboard interaction that does not work as expected. Combine the audit with manual checks rather than using its score as a legal or usability certificate.

3. axe: investigate and integrate checks

Deque’s axe tools help developers identify accessibility issues and inspect affected elements. Depending on the product and integration used, they can support interactive checks and automated testing in a development workflow.

Start with the browser tool’s documented scan process. Group findings by the shared component that causes them, rather than treating every affected page as a separate engineering task. A correction to a reusable form control may resolve the same issue across many journeys.

For a development team, selected automated checks can be added to release tests. Keep the scope realistic and investigate failures. A test that is routinely ignored offers little protection. Make manual review part of changes to custom menus, tabs, dialogs and complex forms.

4. Accessibility Insights: follow a guided assessment

Microsoft’s Accessibility Insights for Web provides tools that combine automated checks with guidance for manual assessment. This can help teams that need a structured process rather than an isolated scan result.

Use the current tool documentation to choose the appropriate assessment, then work through the instructions on a representative part of the site. Record evidence for manual decisions, especially when a result depends on whether the content or interaction makes sense.

A guided workflow is useful for consistency, but it still needs a person who understands the service being tested. A correct technical pattern may be applied to an unclear task. Include the context of the journey in your report so the team can judge its effect on users.

5. NVDA: experience the information exposed to a screen reader

NVDA is a screen reader for Windows from NV Access. It lets testers examine how page structure, names and states are presented through speech or other supported output. This is a different kind of assessment from running an automated rules engine.

Learn the basic reading and navigation commands before drawing conclusions. Try moving by headings, listing links, entering a form and understanding an error. Ask whether the spoken information is sufficient to complete the task, not just whether something was announced.

NVDA testing is valuable, but it does not represent every browser, device or assistive-technology combination. Include other relevant combinations in your plan and, where possible, involve people who use assistive technology in everyday life.

Always include a keyboard pass

Put the mouse aside and move through the task using the keyboard. Check that focus is visible, follows a logical order and does not become trapped. Open and close navigation, use tabs or disclosures, complete forms and recover from errors.

Pay particular attention to third-party widgets and controls that appear only on hover. A sticky element should not cover the focused control. If a dialog closes, focus should return to a sensible location. Document the exact key sequence where behaviour fails.

Turn findings into a useful work list

Prioritise problems that prevent someone from reaching information or completing a task. Fix the common components that produce repeated failures. Then work through content quality and less severe friction. Avoid closing an issue simply because its warning disappeared from one tool; repeat the relevant manual task too.

Keep testing part of publishing

Choose a small set of checks that editors can perform for each article: headings, link text, image alternatives and the clarity of tables. Developers can maintain checks for shared navigation and interactive components. A fuller assessment is useful after a redesign or major integration.

The strongest process combines tools, informed manual review and feedback from users. Each provides evidence the others can miss. Used that way, accessibility testing becomes a practical way to improve the website rather than a one-off attempt to obtain a favourable score.