Test My Website Accessibility: A 15-Minute Scan Session You Can Run Right Now

Last updated: September 27, 2026

An accessibility scan of your website takes about five minutes; the two checks no scanner can run take another ten. That is the whole session below — automated scan, keyboard and zoom pass, then a triage read of what you found, ranked by legal risk. No budget, no developer, no signup. Set a 15-minute timer and work through it on the site you actually run.

Key numbers: 95.9% of the top one million home pages had detectable WCAG 2 failures in 2026, averaging 56 errors per page (WebAIM Million 2026). Automated tools detect roughly 60–70% of WCAG issues; the remaining 30% requires human testing (TestParty remediation data). Plaintiffs filed 3,117 federal website accessibility lawsuits in 2025, up 27% from 2024, and ecommerce is named in 69–77% of digital accessibility suits (Seyfarth Shaw).

Step 1 (minutes 0–5): Run the automated scan

Go to wave.webaim.org, paste your home page URL, and press Enter. WAVE is free, needs no account, and layers findings as icons directly over the elements that failed.

Scan two pages, not one: your home page and one page from your highest-traffic template. The home page tells you about a page; a template page tells you about a pattern, because a finding there repeats on every page built from it.

1. Scan the home page. Write down the first three numbers in the summary panel: errors, contrast errors, alerts.
2. Open the Details tab. Click any count to jump to the flagged element on the page.
3. Repeat on your template page. Same URL bar, same three numbers.
4. Screenshot both summary panels. Dated evidence costs two keystrokes now and cannot be reconstructed later.

What you should see: errors, not zero. The WebAIM Million found an average of 56 detectable errors per home page in 2026, and the density is a design problem rather than a scanner problem — one bad repeated component can generate 40 findings. A zero-error result is worth verifying, not celebrating: check that the page loaded fully and did not stop at a cookie gate.

What do the WAVE icons mean?

WAVE sorts findings into six categories, and only two are confirmed failures. Reading them correctly is the difference between a useful baseline and a panic.

The trap is alerts: a long alert count reads alarming and is often not actionable, while three errors on the checkout button is the finding that matters.

Step 2 (minutes 5–10): The two manual checks that matter most

Two checks catch a disproportionate share of what scanners miss: a full keyboard tab-through and a 200% zoom.

Check one — the tab-through (5 minutes). Put the mouse aside. Press Tab from the top of the home page until you have cycled through everything, then repeat on the template page. Failure looks like this:

• The focus outline disappears and you cannot tell where you are (WCAG 2.4.7).
• Focus jumps illogically — header straight to footer, skipping the nav (WCAG 2.4.3).
• A pop-up or drawer opens and Tab cycles inside it forever, with no Escape (WCAG 2.1.2, keyboard trap).
• A menu, slider, or carousel never receives focus at all (WCAG 2.1.1).
• A sticky header covers the element you just tabbed to (WCAG 2.4.11, new in 2.2).

Check two — 200% zoom (2 minutes). Press Ctrl/Cmd and + until the browser reads 200%. Text must stay readable with nothing cut off or overlapping, and no horizontal scrolling to read a line (WCAG 1.4.4). Push to 400% if you have a spare minute; that is where reflow failures surface (WCAG 1.4.10).

When our team runs this pass during onboarding, the scan is rarely the interesting part — the keyboard walk is. Across TestParty's work with 100+ brands, the recurring failure is not original theme code but third-party additions: a review widget, a subscription selector, an email modal that takes focus and never returns it.

Step 3 (minutes 10–15): Read your results by risk

Findings do not carry equal legal weight. Sort yours into three tiers: keyboard and screen reader blockers first, forms and alt text second, cosmetic issues last.

The pattern in demand letters is consistent — claims allege that someone using a keyboard or screen reader could not complete a task, and ecommerce absorbs 69–77% of digital accessibility suits (Seyfarth Shaw) because those tasks are transactions. Low contrast in a footer is a real WCAG failure, but it is not what gets pleaded.

Two rules for reading it. Location beats severity: a medium finding on a template repeats on every page built from it, outweighing a critical finding on one orphan page. And ownership matters as much as priority — alt text is a content workflow problem, not a sprint item.

If you sell online, test checkout first

Checkout is the highest-stakes flow on a commercial site and the one scanners reach least often, because it sits behind a cart state. Spend three extra minutes: add an item to the cart, then reach the payment step using only the keyboard. Watch for a quantity stepper you cannot operate, an unlabeled discount field, a shipping option group arrow keys will not move through, and an error that appears visually but is never announced.

What a 15-minute test can and can't tell you

This session gives you a defensible baseline, not coverage. Three limits are worth being precise about.

First, the ceiling: automated tools detect roughly 60–70% of WCAG issues, and the remaining 30% — meaningful alt text, focus order, whether a status message is announced — needs human testing (TestParty remediation data). Second, scope: you tested two pages against WCAG 2.2 Level AA, which sets 86 success criteria across a whole site. Third, time: a scan is a snapshot, and themes, apps, and content change daily.

What it does tell you is real: whether a keyboard user can move through your site, and which findings a plaintiff's firm would lead with. W3C's Easy Checks adds more quick tests in the same spirit; for a version needing no tools at all, use the eight-question self-check you can score in five minutes.

Where your results put you, and what to do next

Read your error count against the population, then escalate one rung at a time.

Rung 1 — scan every template. Two pages is a sample. Our roundup of nine free accessibility checkers ranked by accuracy covers which tools handle multi-page runs; the week-long DIY audit extends this session to full coverage.

Rung 2 — professional audit. Bring in expert manual testing when a demand letter arrives, when you sell into the EU, or when checks failed and you cannot diagnose why: what a professional audit involves.

Rung 3 — remediation. Findings are not fixes; compliance comes from changing source code, the subject of this walkthrough of turning scan results into remediated code. As of August 2026, TestParty has remediated 35 million+ accessibility issues across customer stores.

Rung 4 — monitoring. Re-run these 15 minutes after every theme update, app install, or redesign. TestParty's post-remediation targets are Lighthouse 90+, WAVE errors at 5 or fewer, and axe errors at 3 or fewer, held with daily scans plus monthly expert audits — because one scan describes a day, not a site.

Frequently Asked Questions

I searched "test my website accessibility" and got a dozen tools. Which should I use? For a first session, WAVE — free, browser-based, and it shows findings in place on the page rather than as an abstract list. Every reputable automated tool hits the same 60–70% ceiling, so tool choice matters far less than whether you also run the manual checks.

How many errors is a normal accessibility scan result? The 2026 WebAIM Million found an average of 56 detectable errors per home page, with 95.9% of pages failing something. A two-digit count is statistically ordinary — reassurance about your peers, not a legal defense. What separates sites is whether those errors sit on the navigation and purchase path.

Does a clean automated scan mean my website is accessible? No. A zero-error scan means the machine-detectable 60–70% is clean and says nothing about the other 30%: focus order, whether alt text describes the actual image, whether dynamic updates are announced. Complaints originate in that gap — which is why Step 2 is not optional.

Can I scan a page that requires login, or a checkout flow? Not with a URL-based scanner, which only sees public pages. Use a browser-extension checker while logged in, or test those flows manually with the keyboard. On most commercial sites, logged-in and checkout paths carry the highest risk and the least automated coverage at once.

How often should I re-run this test? After every substantive change — platform or theme update, new app, redesign, major content push — and monthly at minimum. Accessibility drifts silently: a plugin update can reintroduce a keyboard trap you fixed six months ago, and nothing will tell you.

Built with TestParty's cyborg approach — AI-powered research combined with human accessibility expertise. This article contains TestParty's editorial analysis based on publicly available information. We're an accessibility vendor with opinions informed by working with 100+ brands, and we encourage readers to do their own due diligence when evaluating any solution.