WCAG & Accessibility·4 min read

How to Run a WCAG Audit Across Your Whole Site

One URL in, a scored report out, roughly four minutes in between. If you're working out how to run a wcag audit across an entire site rather than a single page, the free WCAG Accessibility Scanner handles the heavy part: it seeds pages from your sitemap, crawls up to 30 of them, runs 70 automated WCAG 2.1 checks on every element it finds, and writes corrected code for each failure. This guide covers the run itself, then the part most people skip: reading the report and turning it into a realistic fix plan.

Open the tool All insights

What a WCAG 2.1 site audit covers and when you need one

The scenario first.

A city web manager gets an email from legal about the DOJ rule. An agency inherits a client site with no accessibility history. A store owner receives a demand letter citing missing alt text. All three need the same thing: a defensible picture of where every page stands against WCAG 2.1, not a guess based on the homepage.

That's what running a wcag 2.1 audit online gets you. Unlike a browser extension that inspects the tab you're looking at, a website accessibility audit tool that crawls will surface the forgotten pages: old landing pages, the events archive, the contact form nobody has touched since 2023. Those forgotten pages are usually where the worst failures live.

How to run a WCAG audit from a single URL

Paste, scan, wait about four minutes.

Enter any URL, example.com or a deeper path both work, and the engine takes over. It reads /sitemap.xml first, follows one level of sitemap index files, then merges those URLs with a breadth-first crawl of internal links, capped at 30 pages per run and 100 at the hard limit. Four parallel fetches keep it polite to shared hosting, and a fixed time budget of around four minutes means a run always finishes.

Every page then goes through 70 checks spanning images, links, forms, headings, landmarks, tables, ARIA, and language. Contrast isn't estimated: the engine fetches your stylesheets and computes the true ratio of text against its background, testing each pair against the AA threshold of 4.5:1 and the AAA threshold of 7:1. A full site accessibility checker that skips real CSS math will miss most contrast failures, so this detail matters more than it sounds.

A worked WCAG example: from flagged HTML to fix code

Two real failures, two ready fixes.

Say the crawl hits a staff page containing this: Input: <img src="team-photo.jpg">. The report flags it under criterion 1.1.1 Non-text Content, Level A, severity serious, and generates a fix from your own markup. Output: <img src="team-photo.jpg" alt="Support team at the annual meetup">. You review the suggested alt text, adjust the wording, and paste it back.

Contrast works the same way with numbers instead of attributes. Body text set to #777777 on a white background measures 4.48:1, which fails AA's 4.5:1 requirement by a hair. The report shows the measured ratio and a passing alternative: #767676 lands at 4.54:1 with no visible design change. Tiny edit, one criterion cleared across every page using that style.

Reading an accessibility report without drowning

Score, areas, then severities.

The report opens on an overall compliance score with a verdict, then breaks into per-area scores across 12 report areas, from graphics and forms to landmarks and ARIA. Reading an accessibility report gets manageable once you treat those area scores as your map: a 40 in contrast and a 95 in tables tells you exactly where the week's effort should go.

Below the scores, every check appears as fail, pass, or neutral, and each failure carries its WCAG success criterion, its level, a severity rating, and example occurrences with the pages they came from. Neutral simply means the site had nothing for that check to inspect.

Prioritizing accessibility fixes: three rules that hold up

Order beats effort.

People searching for an ada compliance scanner usually want a ranked to-do list, and that's the right instinct. No scanner makes you compliant, but a sensible fix order gets you close faster. Three rules cover most situations.

Fix by template, not by page. One unlabeled search field in the header is one code change, even if the report counts it 30 times.
Clear critical and serious severities before touching moderate ones; they block users outright rather than inconveniencing them.
Re-scan after each batch of fixes and keep the dated PDF export. A trail of improving scores is evidence a single report never provides.

Mistakes that skew a whole-site WCAG scan

The scanner is deterministic; the humans around it are where audits go wrong. These are the patterns worth avoiding.

Scanning only the marketing homepage. Seed the run from a deeper URL, like /services/, to audit the section your users actually depend on.
Treating a clean automated report as full conformance. Keyboard flow, focus order, and alt-text quality still need a human pass.
Ignoring the XLSX export. The multi-sheet file holds every recorded occurrence, which is what your developers need for ticketing.
Running one scan and never returning. New content regresses accessibility constantly; quarterly runs catch it while it's cheap to fix.

Scanner, checker, or checklist: choosing among the WCAG tools

Same engine, different jobs.

Use the WCAG Accessibility Scanner when the question is about a whole site: audits, deadlines, baselines, exports for stakeholders. When you're iterating on one template or a pasted fragment, the Instant Accessibility Checker runs the identical 70 checks in seconds without a crawl. For a single color pair, the Color Contrast Checker answers faster still, and the WCAG Compliance Checklist tracks the human-verified criteria no machine can test. Government teams working against the DOJ rule should start from the ADA Title II Checker, which wraps this scanner in a deadline-aware readiness process.

Try it now

Open WCAG Accessibility Scanner

The tool is one click away. No sign up, no upload, no payment.

Open WCAG Accessibility Scanner

Write a review