How to Test a Website for Accessibility: Methods, Tools and Best Practices

How to Test a Website for Accessibility is a practical set of checks you can run now. This guide shows methods, tools and best practices so teams find real problems and fix them quickly.

What accessibility testing covers and why it matters

Accessibility testing checks whether people with visual, hearing, motor or cognitive disabilities can use your site. Tests map to the Web Content Accessibility Guidelines, known as WCAG, and to any legal rules that apply. In the UK those rules commonly include the Equality Act 2010 and the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018.

Plan your test

Good testing starts with scope. Define the pages, user journeys and breakpoints you will test. Include login flows, forms, media players and any third-party widgets.

• Pick representative pages: homepage, product page, main form, account area.
• Decide standards to target: WCAG 2.1 AA or WCAG 2.2 AA for new work.
• Set acceptance criteria: which WCAG success criteria must pass and what counts as a failed issue.

Start with automated scans (fast, but incomplete)

Automated tools find obvious issues quickly. They are efficient for regression testing and CI checks. Expect 20 to 50 percent coverage depending on the site and the tool.

Common automated tools

• axe (browser extension or CLI)
• Lighthouse (Chrome)
• WAVE (browser extension)
• Accessibility Insights (Windows and browser)
• Colour Contrast Analyser

What automated checks catch: missing alt attributes, colour contrast failures, missing form labels, duplicate IDs, ARIA misuse in simple cases. They miss context, meaning and keyboard or screen reader behaviour. Treat automated output as a prioritized list of likely issues, not as proof of accessibility.

Manual testing: core checks you must run

Manual tests reveal real-world barriers. Run these on desktop and mobile using real browsers.

Keyboard-only navigation

• Tab through the page until you can reach every interactive element.
• Focus order must be logical and match visual layout.
• Visible focus indicator must be present and clearly visible against background.
• All actions must work with Enter or Space where appropriate.

Screen reader testing

• Test with at least one screen reader: NVDA on Windows or VoiceOver on macOS/iOS.
• Listen for correct reading order, meaningful link text, and useful alt text on images.
• Check ARIA roles and labels are accurate and not redundant.

Visual checks

• Check colour contrast with a tool and by eye. Ensure text remains readable at 200% zoom.
• Confirm headings form a logical outline using H1 to H6 in correct sequence.
• Ensure focusable elements are large enough and spaced for motor needs.

Forms and controls

• Every input must have a visible label or associated aria-label.
• Error messages must be programmatically associated and explain how to fix input.
• Check dynamic validation works with keyboard and assistive tech.

Testing specific content types

Images and icons

• Decorative images should have empty alt attributes.
• Informative images need descriptive alt text that matches the context.

Media

• Provide captions for prerecorded video and transcripts for audio.
• Offer controls that are keyboard accessible and labelled.

Tables and data

• Use table headers and scope attributes for data tables.
• Avoid layout tables for non-tabular content.

Navigation and focus management

• Provide a skip link to main content for keyboard users.
• Manage focus after dynamic updates and route changes in single-page apps.

Mobile and responsive checks

Touch targets must be large enough. Test with screen readers on iOS and Android. Ensure orientation changes and zooming do not break layout or functionality.

User testing with people who have disabilities

Automated and manual checks are not a substitute for real users. Recruit participants with vision, hearing, motor and cognitive disabilities. Observe specific tasks like completing a purchase or submitting a form.

Keep tests short and task-based. Offer payment and adjust the session to participant needs.

Prioritise findings and write actionable reports

Map each issue to a WCAG success criterion and assign severity: critical, major, minor. Include:

• Steps to reproduce
• Where it occurs (URL, component)
• Expected and actual behaviour
• Screenshots, HTML snippets and suggested fixes

Give quick wins first. Fixes that unblock keyboard access, form errors and missing alt text usually have high impact for low effort.

Integrate accessibility into development

Add automated checks to CI and run a full manual test for each major release. Use pull request gates for critical accessibility rules so issues are flagged early.

Maintain an accessibility backlog and track regressions with your issue tracker. Train designers and developers on semantic HTML and ARIA best practices.

Common developer mistakes and how to fix them

This section covers errors that often survive automated scans.

Poorly labelled controls

Problem: custom controls use divs and spans without role or keyboard handling. Fix: use native controls when possible. Add role, tabindex and keyboard handlers when a custom element is required. Provide aria-label or aria-labelledby when the visible label is not programmatically connected.

Incorrect ARIA usage

Problem: ARIA attributes contradict native semantics or are unnecessary. Fix: remove ARIA when native elements suffice. Follow the ARIA Authoring Practices to implement complex widgets.

Focus loss after actions

Problem: after an update the focus disappears or jumps to the end of the page. Fix: move focus to the updated region or the first new interactive element and announce changes with live regions when appropriate.

Practical step-by-step: test a complex form (example)

1. Open the form as a keyboard-only user. Tab through every control and ensure logical focus order.
2. Check that each input has a visible label or aria-label. Verify labels are associated using the for attribute.
3. Submit the form with invalid data. Confirm error message appears, is associated with the input, and focus moves to the first error.
4. Use a screen reader to navigate the form. Ensure field types, labels and error messages are read correctly.
5. Test with browser zoom at 200 percent and with default font size increased to 200%.
6. Run an automated scan to capture any missing attributes or contrast failures revealed by the form UI.

After testing: remediation and verification

Fix issues, then re-run the same manual tests and automated scans. Use regression tests in CI to prevent recurrence. For legal compliance or tender work, produce an accessibility statement showing the standard targeted and known exceptions.

Tools checklist (quick reference)

• Automated: axe, Lighthouse, WAVE, Accessibility Insights
• Screen readers: NVDA, VoiceOver
• Contrast and colour: Colour Contrast Analyser, browser devtools
• Developer aids: browser accessibility tree, ARIA Authoring Practices

Final notes

Testing a website for accessibility means combining automated scans, focused manual checks and real user testing. Aim for continuous testing, clear reporting and quick fixes that improve access for most users. Use WCAG success criteria as your objective measure and update test cases as your product changes.