Website Accessibility Audit: A 7-Day Step-by-Step Guide You Can Run Yourself

Last updated: September 16, 2026

You can run a credible website accessibility audit yourself in one working week, using free tools and roughly two to three hours a day. This guide is the walkthrough: what to do each day, which templates to test, what a failure actually looks and sounds like, how to write the findings up, and the honest line where a self-audit stops and a professional one has to start.

Key numbers: In February 2026, 95.9% of the top one million home pages had detected WCAG 2 failures, averaging 56.1 errors per page — worse than 2025 (WebAIM Million 2026). Six error types account for 96% of all detected errors (WebAIM Million 2026). Automated tools catch roughly 60–70% of WCAG issues; the remaining 30% requires human testing (TestParty remediation data across 100+ brands). ADA Title III filings rose 37% in H1 2025, and ecommerce is named in 69–77% of digital accessibility suits (Seyfarth Shaw). As of August 2026, TestParty has remediated 35 million+ accessibility issues across customer stores.

What does a one-week self-audit actually cover?

A one-week self-audit covers a representative sample of your templates against WCAG 2.2 Level AA, using automated scanners plus manual keyboard, screen-reader, and content passes. It reliably finds blockers. It does not produce a conformance claim.

A professional audit tests every applicable success criterion, by trained testers, on a documented tool matrix, with independence you can hand to a procurement reviewer or opposing counsel. A self-audit finds the barriers that stop real people from buying, booking, or signing up — which, in TestParty's remediation work across 100+ brands, is where nearly all of the lost revenue lives. Our reference on how professional accessibility audits are scoped, priced, and delivered covers the formal version; this is the version you can start on Monday.

+------------+--------------------------------------------------+------------+-------------------------+
|    Day     |                      Focus                       |    Time    |          Output         |
+------------+--------------------------------------------------+------------+-------------------------+
|     1      |     Scope: pick templates, inventory scripts     |   2 hrs    |   Test plan, URL list   |
+------------+--------------------------------------------------+------------+-------------------------+
|     2      |      Automated pass: WAVE, Lighthouse, axe       |   3 hrs    |   Raw findings export   |
+------------+--------------------------------------------------+------------+-------------------------+
|     3      |                Keyboard and focus                |   2 hrs    |       Blocker list      |
+------------+--------------------------------------------------+------------+-------------------------+
|     4      |          Screen reader on 5 core flows           |   3 hrs    |    Flow-by-flow notes   |
+------------+--------------------------------------------------+------------+-------------------------+
|     5      |   Content: alt text, headings, links, captions   |   2 hrs    |   Content defect list   |
+------------+--------------------------------------------------+------------+-------------------------+
|     6      |    Synthesis: severity × criterion × template    |   2 hrs    |    Findings register    |
+------------+--------------------------------------------------+------------+-------------------------+
|     7      |     Decisions: fix, prioritize, or hand off      |   2 hrs    |   Prioritized roadmap   |
+------------+--------------------------------------------------+------------+-------------------------+

Day 1: How do you scope the audit?

Scope by template, not by page. Pick 8–12 unique templates weighted by traffic and risk — one product page represents every product built from it, so a 5,000-item catalog can be genuinely covered by a dozen URLs.

The default list: home, category or collection, product or service detail, site search results, a lead or contact form, the full conversion flow (cart through payment confirmation, or booking through confirmation), account creation and login, and one blog or article page. Pull your top 20 landing pages from analytics and confirm each maps to a template already on your list. This mirrors W3C's WCAG-EM sampling logic — common pages, essential functionality, distinct content types.

Then inventory third-party scripts: chat widgets, review apps, popups, cookie banners, embedded video, payment iframes. These are the components you cannot fix in your own code, and you need to know that before Day 7, not after. Record every URL and state you intend to test — error states, open modals, mobile breakpoint — in a single sheet. That sheet is your scope document.

Day 2: How do you run the automated pass?

Run three scanners on every template — WAVE, Chrome DevTools' Lighthouse accessibility audit, and an axe browser extension — and export each result before moving to the next page.

Budget ten minutes per template. WAVE gives you a visual overlay, the fastest way to see where on the page a failure sits. Lighthouse gives you a score you can trend over time. axe gives the cleanest rule-to-criterion mapping for a findings register. Save screenshots or CSVs as you go — rerunning a scan after a deploy gives different output and no audit trail.

Expect the three tools to disagree, and do not treat that as a malfunction. They ship different rule libraries at different versions, they weight and score differently, WAVE separates hard "errors" from judgment-call "alerts," and each evaluates the DOM at the moment you run it — so a lazy-loaded carousel or an unopened modal is simply invisible to the scan. The union of the three is your real list; the intersection is just the easy part. Our ranked breakdown of free accessibility checkers and what each one covers explains where the libraries diverge.

Day 3: What does the keyboard pass find?

The keyboard pass is the highest-yield manual hour in the entire audit. Unplug your mouse, put your hands on Tab, Shift+Tab, Enter, Space, Escape, and the arrow keys, and walk every template start to finish.

Watch for six failures. Invisible focus: you press Tab and cannot tell where you are. Illogical order: focus jumps from header to footer and back. Unreachable controls: a menu, filter, or custom select opens on hover only. Focus traps: you enter a modal, chat widget, or video player and Escape does nothing — the classic blocker, and disproportionately a third-party script. Focus loss: you close a modal and focus dumps back to the top of the document. Ghost stops: Tab lands on something offscreen with no visible target.

Write down the template, the component, and the keystroke that broke. In TestParty's monthly expert audits of ecommerce stores, keyboard failures in navigation and checkout are the findings that most consistently correlate with abandoned purchases — and scanners almost never flag them, because the markup is technically valid. If Day 3 is the only manual day you get, it is still worth doing.

Day 4: How do you test with a screen reader?

Install a screen reader and test five flows. NVDA on Windows is free to download and is among the most widely used screen readers in WebAIM's user surveys; VoiceOver ships built into macOS and iOS (Command+F5 to toggle).

Spend twenty minutes with the basic commands first — start and stop reading, move by heading, by link, by form field, list landmarks. Then run five flows with your ears on the output: find a product or service through navigation and search; open a detail page and select an option or variant; complete the conversion flow to confirmation; submit a form with a deliberate error in it; and create or log into an account.

Listen for five things. Controls announced as bare "button" or "link" with no name. Images read out as filenames. A heading structure that jumps from level 1 to level 4, or offers no headings to navigate by at all. Error messages that appear visually but are never spoken. And silence after something changes — an item added to a cart, a filter applied, a payment declined. That last one is the failure we see most often in real stores: the card is rejected and the user hears nothing. W3C's Easy Checks is a good companion reference if you have never run assistive technology before.

Day 5: What should the content pass check?

The content pass catches everything a scanner can confirm exists but cannot judge the quality of. `alt="image123"` passes every automated check ever written and helps no one.

Work through four categories on each template. Alt text: does it convey the purpose of the image, is it empty (`alt=""`) for purely decorative graphics, and does text baked into an image appear somewhere in real text? Headings: one H1 per page, no skipped levels, headings used for structure rather than because the font looked right. Link and button text: does it make sense read out of context, or do you have twelve links that all say "Read more"? Media and tables: captions on video, transcripts for audio, real header cells on data tables, no information conveyed by color alone.

Check any PDFs you link to from the sampled templates, too — menus, price lists, spec sheets, policy documents. They are in scope, they are almost always untagged, and teams forget them until a demand letter names one specifically.

Day 6: How do you turn five days of notes into a report?

Build one findings register with a row per issue and six columns: ID, template, component, WCAG 2.2 criterion and level, severity, and evidence. That table is the audit. Everything else is a cover page.

Use a four-step severity ladder. Blocker — the task is impossible (keyboard-trapped checkout, unlabeled required field). Critical — a core function is severely impaired. Major — significant friction with a workaround. Minor — inconvenience or best-practice gap. Map each finding to its criterion so the register survives contact with a developer or a lawyer: "2.4.7 Focus Visible (AA)" is actionable; "menu is confusing" is not.

Then collapse duplicates. Thirty missing form labels across eight templates are usually one component defect in one include file, and counting them as thirty findings makes the fix look bigger than it is. Group by component, note every template affected, and cross-reference against a fixed criterion list so you can see what you did not test — our 30-point accessibility audit checklist works well as that control, and a WCAG compliance checker confirms coverage criterion by criterion.

Day 7: What do you fix first, and what do you hand off?

Fix blockers on revenue paths first, regardless of raw issue counts. One unlabeled quantity selector on your product template outranks two hundred contrast warnings in a blog archive.

Sequence the rest by legal exposure, using what actually appears in complaints. Seyfarth Shaw's ADA Title III tracking shows filings concentrated in ecommerce (69–77% of digital accessibility suits), with 46% of H1 2025 federal cases involving repeat defendants — and the alleged barriers recycle: missing alt text, unlabeled buttons and empty links, menus that cannot be operated by keyboard. Those categories go to the top of the queue, and they overlap almost exactly with the six error types behind 96% of detected failures in the WebAIM Million.

Then split the register by owner. Findings in your own theme or template code are yours to fix in source. Findings inside third-party scripts need a vendor ticket and, if the vendor will not move, a replacement decision. Findings in content belong to whoever publishes, and they return on the next upload unless the fix includes a process change. If your engineering queue cannot absorb the register, that is the moment to scope website accessibility remediation rather than let a report age in a backlog. Post-remediation benchmarks worth targeting: Lighthouse 90+, WAVE at five errors or fewer, axe at three or fewer.

When should you hire a professional auditor instead?

Hire out when the audit has to satisfy someone other than your own team: an enterprise procurement reviewer, an EU market-entry requirement under the European Accessibility Act, or an active legal matter.

A buyer asking for a VPAT or Accessibility Conformance Report needs a document your self-audit cannot produce. EAA obligations, enforceable since June 2025, run through EN 301 549 and expect documented conformance rather than a spreadsheet of blockers. And once a demand letter arrives, independence becomes the point — a dated third-party report carries weight your internal notes do not.

Market ranges as a budgeting anchor, from published agency rate cards as of August 2026: hybrid audits combining scans with expert manual testing run roughly $1,000–$5,000; full manual WCAG 2.2 AA audits of a mid-size ecommerce site run roughly $3,000–$15,000 and up; complex enterprise engagements exceed $10,000–$25,000; a VPAT or ACR adds roughly $350–$1,000 per edition. Run the self-audit first regardless — walking into a paid engagement with a scoped template list and a known blocker set makes it shorter, cheaper, and considerably more useful.

Frequently Asked Questions

Do I need to be a developer to audit my own website? No. The automated pass, keyboard pass, screen-reader pass, and content pass all run in a browser and require no code. You will need a developer to fix most findings, which is exactly why the findings register maps every issue to a WCAG criterion, a component, and a location — so the handoff does not require translation.

Which free tools should I use for a website accessibility audit? WAVE for visual, in-page identification of failures; Lighthouse in Chrome DevTools for a trackable score; an axe browser extension for clean criterion mapping; and NVDA on Windows or VoiceOver on macOS for assistive-technology testing. All are free. Together they cover roughly 60–70% of WCAG issues automatically, with the manual passes reaching the rest.

Is a self-audit enough to prove ADA compliance? No, and neither is a professional audit. No audit produces "ADA certification" — no such certification exists. What matters in a dispute is the dated record of finding issues and fixing them. A self-audit starts that record; a professional audit strengthens it when an outside party evaluates your conformance claim.

How often should I repeat the audit? Re-run the automated pass on every significant release, and repeat the full manual walkthrough quarterly — or monthly if you publish products and content continuously. Sites drift: every theme update, app install, and product upload can introduce new violations. TestParty's own operating model is daily automated scans plus monthly expert manual audits for exactly this reason.

What if the issues are in an app or widget I did not build? Log them anyway, with the vendor named as owner. You are the party a complaint names, not your chat widget provider. Open a support ticket with the specific criterion and reproduction steps, set a deadline, and treat a non-response as a procurement decision. In our experience, third-party scripts are the most common source of keyboard traps that store teams cannot fix in their own source.

This article was produced using TestParty's cyborg approach — AI-assisted research and drafting, validated and refined by our accessibility team. The analysis above represents TestParty's editorial opinions based on publicly available data. As a competitor in the accessibility market, we have a point of view — but we've cited our sources so you can verify every claim independently.