WCAG & Accessibility·4 min read

How to Check a Page for Accessibility, Instantly

Five minutes before a deploy is exactly when accessibility questions tend to surface: does this new landing page have labeled inputs, does the hero image carry alt text, did anyone set the page language? A single-page check turns that panic into a routine step. The WCAG Accessibility Checker takes a URL or raw pasted HTML, runs 70 automated WCAG 2.1 rules against that one document, and returns a scored breakdown with corrected code in a few seconds.

Open the free WCAG Accessibility Checker All insights

Quick WCAG checks before launch: why one page at a time

Small scope, fast feedback.

Whole-site crawls are for audits. Day-to-day work happens one page at a time: a pull request touching the signup form, a new campaign page from the design team, an HTML email that has to hold up in screen readers. A check that finishes before your coffee cools fits into that rhythm, so there's no excuse to skip it.

The single-document scope also changes what you can test. A crawler needs a deployed, reachable URL. A paste box accepts anything up to 2 MB: staging output, a local build, a fragment you're still arguing about in review.

How to check a page for accessibility in under a minute

Two modes, one button.

Pick your mode with the two buttons at the top. Check a URL fetches a live page; Paste HTML takes raw markup into the editor, which is the route for anything not yet public, including pages behind a login, since you can copy the source straight from your browser while signed in.

Press Check page, or Check HTML in paste mode, and the results arrive as a score out of 100 with counts of failed, passed, and not applicable checks, plus totals by severity: critical, serious, moderate, minor. Expand any failure to see the affected elements, each with its selector, the offending snippet, and a suggested corrected version tagged with the WCAG criterion and level. The first five occurrences show by default, and Show all recorded occurrences expands the rest. When the list is long, filter by level or severity, or group the failures by WCAG criterion.

From unlabeled input to passing WCAG: a worked example

Placeholder is not a label.

Paste this fragment and run it: <input type="email" placeholder="Your email">. The checker fails it against criterion 3.3.2 Labels or Instructions, because a placeholder disappears the moment someone types and is not a reliable label. The fix pairs the field with a real label: <label for="email">Your email</label> <input id="email" type="email">.

Run the same test on a full document starting with <html> and no lang attribute, and criterion 3.1.1 Language of Page fails too. The fix is one attribute, <html lang="en">, and it changes how screen readers pronounce your content. Two-minute fixes like these are the bread and butter of single-page checking.

Automated vs manual accessibility testing on a single page

Know what the machine can't see.

The split is roughly this: machines verify facts about markup, humans verify experiences. The 70 rules reliably catch missing alt attributes, unlabeled fields, absent page titles, broken ARIA references, and contrast math. They cannot judge whether your alt text is accurate, whether focus lands somewhere sensible after a modal closes, or whether your error messages make sense read aloud.

The rules also map to WCAG 2.1, so the nine criteria added in WCAG 2.2, such as minimum target size, need manual testing, and the Needs manual review list under the results names each of them. Treat a high score as clearance to proceed to the human pass, not as a certificate. Even a perfect run ends with the tool reminding you that keyboard testing and alt-text review still stand between you and real WCAG conformance.

Mistakes that make a page accessibility check lie to you

The checker reports honestly on what you give it. Feed it the wrong thing and the honest report misleads.

Pasting a fragment when you meant to test a document. Without the surrounding html and head, structural checks like page title and language can't run meaningfully.
Testing the empty state only. Error messages, validation summaries, and success banners carry their own failures; paste the page in those states too.
Reading the score and skipping the not applicable list. A page with zero images can't fail image checks, which flatters the number.
Fixing the first five occurrences and stopping. The count chip tells you the real total. Expand the full list, or download the CSV, which holds every recorded occurrence.

Habits that make single-page checks stick

Three small habits.

A few workflow tweaks turn this from an occasional tool into a safety net. First, make it part of code review: paste the rendered output of any template change and attach the PDF report to the pull request. Second, after fixing a batch of issues, re-run immediately rather than assuming; fixes to one element sometimes reveal the next failure behind it. Third, when the same failure keeps returning across pages, stop patching pages and fix the shared component that generates it. The CSV download, one row per occurrence with selector, snippet, fix and criterion, drops straight into a ticket tracker, and Copy Markdown summary gives a ready-made ticket body.

When the WCAG Accessibility Checker is the wrong tool

Reach for a sibling instead.

Auditing more than a handful of pages calls for the Website Accessibility Scanner, which crawls up to 30 pages from a sitemap seed and exports PDF, XLSX, and CSV reports. Comparing two specific colors is quicker in the Color Contrast Checker, which also suggests compliant shades of your own brand color. And for the criteria no automation can verify, caption quality, focus order, reading level, the WCAG Compliance Checklist tracks your manual review with progress saved in the browser.

Try it now

Open WCAG Accessibility Checker

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

Open WCAG Accessibility Checker

Write a review