Learn how to test a website for accessibility with a repeatable workflow that combines automated scanners, keyboard checks, color-contrast review, structural inspection, and focused screen-reader testing.
Overview
A useful accessibility audit is not a single scan or a pass/fail badge. It is a comparison of evidence from several testing methods, each designed to reveal a different class of problem. Automated accessibility testing tools can identify many detectable issues in HTML, CSS, and common interface patterns, but they cannot reliably judge whether content is understandable, whether focus moves logically, or whether a custom control makes sense to a person using assistive technology.
The most dependable workflow starts with an automated scan, continues with manual checks, and ends with documented remediation and regression testing. Use the same representative pages each time: a home page, a content page, a search or listing page, a form, an account or checkout flow, and any page containing custom interactive components. Testing a narrow but representative page set is more useful than scanning many nearly identical URLs without reviewing the results.
WCAG is a useful reference framework, but an audit should also consider the site's actual users, content, navigation model, and technology stack. Treat results as findings to investigate rather than as an automatic legal or compliance conclusion.
What to track
Compare the main testing options
| Testing option | Best use | What it can reveal | Important limitation |
|---|---|---|---|
| Browser extension | Fast page-level checks during development or review | Missing labels, detectable contrast issues, heading problems, landmark concerns, and other rule-based findings | Usually tests one loaded page and cannot judge user experience or every state of a component |
| Hosted scanner | Recurring monitoring across a defined page set | Repeated rule-based issues, trends, and changes between scans | Crawl settings, authentication, templates, and dynamic content can affect coverage |
| Command-line or CI scanner | Regression checks during development and deployment | New automated findings introduced by code changes | Requires stable test pages and careful handling of false positives and incomplete states |
| Browser developer tools | Inspecting structure, focus, computed styles, and interaction states | DOM order, accessible names, focus visibility, contrast inputs, and layout behavior | Requires interpretation and does not replace testing with assistive technology |
| Manual keyboard test | Checking operability without a mouse | Keyboard traps, missing focus indicators, illogical tab order, and inaccessible menus or dialogs | Does not represent every input method or screen-reader experience |
| Screen reader spot check | Validating how key journeys are announced | Heading navigation, labels, landmark structure, status messages, and custom control announcements | Results can vary by browser, operating system, screen reader, and user settings |
Use an automated scanner first, but do not stop there
A browser-based WCAG checker is a practical first pass. Run it on the page after it has fully loaded, then repeat the scan for important states such as an open menu, expanded accordion, validation error, modal dialog, and successful form submission. Record the affected URL, selector or component, rule description, and a screenshot or reproduction step. A scan result without location and context is difficult for a developer to fix.
Command-line tools and CI checks are useful alternatives when the same application is tested repeatedly. They can help detect regressions before release, while a hosted scanner is better suited to scheduled coverage across a larger site. Choose based on the workflow rather than assuming that one tool is universally best.
Complete the manual checklist
- Keyboard: Move through the page with Tab, Shift+Tab, arrow keys, Enter, and Escape where appropriate. Confirm that every interactive control is reachable, usable, and visibly focused.
- Focus order: Check that the sequence follows the visual and task order. A visually attractive layout can still create a confusing DOM sequence.
- Color and contrast: Use a color contrast checker for body text, large text, controls, borders that communicate meaning, and focus indicators. Also verify that color is not the only way to convey an error or status.
- Headings and landmarks: Inspect the heading hierarchy and confirm that navigation, main content, complementary content, and footer regions are identified consistently.
- Forms: Check explicit labels, instructions, required-field cues, error messages, autocomplete behavior, and whether errors are announced or easy to locate.
- Images and media: Review alternative text, decorative-image handling, captions, transcripts, and controls for audio or video.
- Responsive behavior: Test zoom, narrow viewports, orientation changes, and increased text spacing where relevant. Look for clipped content, overlapping controls, and lost focus.
- Screen reader flow: Spot-check the primary journey rather than trying to test every page. Listen for meaningful names, useful headings, sensible landmarks, and status updates after actions.
For CSS-related failures, inspect the cascade and state styles rather than changing colors or outlines blindly. The CSS specificity debugging workflow can help when focus styles, contrast fixes, or responsive rules are being overridden.
Cadence and checkpoints
Run a baseline audit before a redesign or major template change. During development, scan changed components and test their keyboard behavior as soon as interaction is added. Before release, repeat the representative-page audit and complete the primary user journeys from a clean session.
For an established site, a monthly or quarterly review is a reasonable starting cadence, adjusted for publishing volume and release frequency. A scheduled scan can identify recurring automated issues, while a deeper manual review should rotate through templates and high-value journeys. Record the browser, viewport, assistive technology, page state, and tool version or configuration used for important findings so future comparisons remain meaningful.
Use a simple issue log with these fields:
- Issue ID and date found
- URL, template, component, and reproducible state
- User impact and affected interaction
- Observed behavior and expected behavior
- Relevant WCAG criterion or internal standard, if known
- Evidence, including steps, screenshot, or scan output
- Owner, priority, target release, and status
- Verification result after the fix
How to interpret changes
A higher issue count does not always mean the site became less accessible. A new scanner, broader crawl, newly exposed component state, or improved detection rule can increase findings without a corresponding regression. Compare like with like whenever possible: the same URLs, states, tools, settings, and browser conditions.
Prioritize issues by user impact and reach. A keyboard trap in a primary form deserves immediate attention even if it appears on one page. A repeated missing label across a shared component may affect many pages and should be fixed at the source. Cosmetic or low-impact findings should not displace barriers that prevent users from completing essential tasks.
Separate confirmed failures from items requiring review. Automated tools can flag a possible issue that depends on context, while manual testing can reveal a problem that no scanner detects. Do not mark an issue resolved merely because a scan is clean: retest the original journey and confirm that the fix did not remove focus visibility, alter reading order, or create a new problem at another viewport.
Accessibility results can be tracked alongside other web development metrics, but avoid reducing quality to a single score. A short list of verified, high-impact fixes is more actionable than an impressive dashboard with unclear coverage.
When to revisit
Revisit this workflow after a major browser, framework, design-system, or accessibility-tool update, and whenever WCAG guidance or your internal requirements change. Repeat testing after navigation redesigns, new form flows, authentication changes, third-party embeds, component-library updates, and substantial content migrations. Dynamic sites should also retest when client-side rendering or error handling changes.
At each monthly or quarterly checkpoint, review unresolved issues, compare recurring findings, sample pages that were not recently tested, and confirm that completed fixes still work in the current release. Before starting, refresh the page inventory and identify new templates or interaction states. After finishing, archive the evidence and schedule the next review.
For a practical next step, select six representative pages, run one automated accessibility scanner, and create an issue log. Then test the same pages with only a keyboard, use a color contrast checker for key text and controls, inspect headings and landmarks, and screen-reader-test one primary journey. This combination gives you a defensible baseline and a repeatable way to compare accessibility improvements over time. Related workflows for broader developer-tool selection are available in the developer tool comparison guide and the website search accessibility checklist.
