Accessibility Audit Checklist: 30 Points, Organized by Audit Phase

Last updated: September 13, 2026

This accessibility audit checklist covers 30 points across five phases: prep, automated pass, manual pass, ecommerce-specific checks, and output. Each item gives what to test and the condition that counts as a pass. Copy it into your tracker and work in order.

Key numbers: 95.9% of the top one million home pages had detectable WCAG 2 failures in 2026, averaging 56.1 errors per page (WebAIM Million 2026). WCAG 2.2 defines 86 success criteria across three conformance levels (W3C). In TestParty's audit work, automated tools detect roughly 60–70% of issues; the remaining 30% require manual expert testing. ADA Title III federal filings rose 37% in H1 2025, and ecommerce accounts for 69–77% of digital accessibility suits (Seyfarth Shaw).

How is this accessibility audit checklist organized?

Five phases in order, each depending on the last: prep scopes the work, the automated pass clears the noise, the manual pass finds the rest.

+---------------------------+------------+----------------------------------------------------+
|           Phase           |   Items    |                  What it produces                  |
+---------------------------+------------+----------------------------------------------------+
|          1. Prep          |     5      |  A scoped template list, tools, a dated baseline   |
+---------------------------+------------+----------------------------------------------------+
|     2. Automated pass     |     6      |     Machine-detectable failures mapped to WCAG     |
+---------------------------+------------+----------------------------------------------------+
|       3. Manual pass      |     10     | Keyboard, screen reader, zoom, interaction findings |
+---------------------------+------------+----------------------------------------------------+
|   4. Ecommerce-specific   |     5      |     Findings on components that carry revenue      |
+---------------------------+------------+----------------------------------------------------+
|         5. Output         |     4      |   A dated report developers and counsel can use    |
+---------------------------+------------+----------------------------------------------------+

For audit types, pricing, and scope, see our guide to the accessibility audit process.

Phase 1: What do you do before running a single scan?

Prep decides whether the audit is useful or merely long. Sites are audited by template and flow, not page count — turning thousands of URLs into 10–50 things to test.

1. Define scope as templates and flows. List templates and customer tasks, not URLs. Pass: scope names every template, the purchase path, and its states — empty cart, errors, modals, mobile.

2. Inventory third-party apps and widgets. Catalog everything injecting markup you do not control. Pass: each app is listed with where it renders and who owns fixes.

3. Pull analytics to rank priority pages. Sort templates by sessions and revenue. Pass: the top five templates by business impact are tested first.

4. Pick your tools and record versions. One browser extension, one CI-capable engine, one screen reader per OS. Pass: tool and assistive-technology versions are in the scope document — WAVE for in-page inspection.

5. Run a dated baseline scan. Capture the starting state before anyone fixes anything. Pass: a dated export is archived where legal can find it — our free accessibility checker guide compares no-cost tools.

Phase 2: Which WCAG failures can automated tools catch?

Automated scanning detects roughly 60–70% of issues in TestParty's audit work, in minutes. Six checks cover what a scanner can legitimately decide alone.

6. Color contrast (SC 1.4.3, 1.4.11). Test text and components against their backgrounds. Pass: body text at 4.5:1; large text, UI components, and meaningful graphics at 3:1.

7. Image alt text (SC 1.1.1). Check every image for a text alternative. Pass: informative images have descriptive alt, decorative images `alt=""`, and no alt is a filename.

8. Form labels (SC 1.3.1, 3.3.2, 4.1.2). Check that fields are programmatically tied to labels. Pass: every input, select, and textarea has a real label; placeholders are never the label.

9. Headings and landmarks (SC 1.3.1, 2.4.6). Check the outline and region markup. Pass: one h1, no skipped levels, and header, nav, main, and footer landmarks per template.

10. Links and buttons (SC 2.4.4, 4.1.2). Check accessible names out of context. Pass: zero empty links or buttons; icon-only controls carry names.

11. ARIA validity and page language (SC 4.1.2, 3.1.1). Check ARIA usage and the declared language. Pass: no invalid roles or attributes, no `aria-hidden` on focusable elements, valid `lang` on html.

Six categories dominate: low-contrast text on 83.9% of home pages, missing alt text 53.1%, form labels 51%, empty links 46.3% (WebAIM Million 2026). Our analysis of common WCAG violations covers fix costs.

Phase 3: What does the manual pass have to cover?

The remaining 30% needs a human: those failures are judgments about meaning, not markup. A scanner confirms alt text exists; a person confirms it says anything.

12. Full keyboard walkthrough. Work every sampled flow with Tab, Enter, Space, and arrows only. Pass: the purchase path completes without a mouse, and focus never gets trapped.

13. Focus visibility and order (SC 2.4.3, 2.4.7). Watch where focus goes. Pass: a visible indicator appears on every interactive element; tab order follows reading order.

14. Screen reader on the top five templates (SC 4.1.2). Use NVDA or JAWS on Windows, VoiceOver on Apple. Pass: home, collection, product, cart, and checkout each complete by ear alone.

15. Zoom to 200% and reflow (SC 1.4.4, 1.4.10). Magnify and narrow the viewport. Pass: nothing is lost at 200% and no two-dimensional scrolling appears at 320 CSS pixels.

16. Forms and error handling (SC 3.3.1, 3.3.3). Submit forms wrong on purpose. Pass: each error is described in text, tied to its field, and announced, not just colored.

17. Media captions and audio control (SC 1.2.2, 1.4.2). Review video and automatic audio. Pass: prerecorded video has synchronized captions; audio over three seconds has a pause control.

18. Motion and animation (SC 2.2.2, 2.3.1). Check carousels, banners, parallax, video backgrounds. Pass: motion can be paused, `prefers-reduced-motion` is honored, nothing flashes over three times per second.

19. Touch target size (SC 2.5.8). Measure interactive targets, especially on mobile. Pass: every target is at least 24 by 24 CSS pixels or equivalently spaced — new at Level AA in WCAG 2.2.

20. Popups, modals, and drawers. Open every dialog, including newsletter and age gates. Pass: focus moves in, stays contained, returns to the trigger on close; Escape dismisses it.

21. Checkout end to end (SC 2.4.3, 3.3.1). Place a real order by keyboard with a screen reader. Pass: shipping, payment, promo code, and every error state complete and are announced. In TestParty's monthly expert audits, checkout is where the highest-severity findings cluster — and the failure is almost always silent.

Phase 4: What extra checks does an ecommerce site need?

Storefronts fail in ways generic checklists miss: they are built from widgets that change content without a page load. These five sit directly on revenue.

22. Variant swatches and option selectors (SC 1.4.1, 4.1.2). Select every option combination by keyboard. Pass: selected state is conveyed by more than color; price and stock updates are announced.

23. Filters and faceted navigation (SC 4.1.3). Apply, combine, and remove filters. Pass: controls are labeled, the result count is announced, and filters clear without a mouse.

24. Cart drawer and mini-cart (SC 2.4.3, 4.1.3). Add, update, and remove items in the slide-out cart. Pass: focus enters on open and returns on close; cart actions are announced.

25. Promo banners and countdowns (SC 2.2.1, 2.2.2). Review anything timed or auto-dismissing. Pass: banners are dismissible, countdowns do not re-announce on a loop, and timed offers can be extended.

26. Third-party widgets. Test reviews, chat, loyalty, subscriptions, and size guides. Pass: each passes keyboard and screen-reader testing, or a vendor ticket exists with a fallback.

Shopify's theme requirements cover roughly 16–22% of WCAG criteria and apps are not reviewed for accessibility before listing; per TestParty's analysis, Dawn ships with 30–100 detectable violations, premium themes 100–350. Shopify's theme accessibility best practices cover theme code, not the apps on top — see our Shopify audit walkthrough.

Phase 5: What turns findings into a usable report?

An audit is worth what its output enables. Four requirements separate an actionable report from a scan export with a cover page.

27. Severity classification. Rate findings by how completely they block a task. Pass: every finding is blocker, critical, major, or minor, with user impact in a sentence.

28. WCAG criterion mapping. Tie every finding to the standard. Pass: each finding carries a criterion number and conformance level, such as 1.4.3 (AA).

29. Fix specifications. Write remediation a developer can implement without interpretation. Pass: each finding gives location, the code-level change, and how to verify it.

30. A dated report for the compliance file. Preserve the evidence. Pass: the report records test date, scope, tool and assistive-technology versions, and tester, and is filed with the remediation record — see our guide to accessibility compliance documentation.

What do you do with the failures you find?

Three things with every failure: fix it in source, monitor so it does not return, document both dates. A fix without a record has no evidentiary value; a record without a fix is a written admission.

Remediate in code, not in a layer over it — overlay widgets leave the underlying code unchanged. Sequence by severity on revenue paths: a keyboard-trapped checkout outranks a hundred footer contrast failures. Then monitor: sites regress with every theme update and app install. TestParty runs daily scans plus monthly expert manual audits for that reason, and has remediated 35 million-plus issues across customer stores as of August 2026. Post-remediation targets: Lighthouse 90 or above, WAVE errors under five, axe under three.

When should you bring in professional auditors instead?

Bring in professional auditors when a conformance claim, a legal demand, or a procurement requirement makes independence part of the deliverable. This checklist gives an internal team a genuine picture of its site; it is not a third-party conformance statement.

Four situations call for outside help: a demand letter has arrived, a buyer requires a VPAT, you are publishing a formal conformance claim, or nobody tests fluently with a screen reader. Independence also matters — internal testers inherit the assumptions baked into the code they wrote.

Frequently Asked Questions

How long does it take to work through a 30-point accessibility audit checklist? For a mid-size ecommerce site, budget about one day for prep and the automated pass, then two to four days for the manual and ecommerce phases across five to ten templates. Screen-reader testing is the slow part, and teams new to assistive technology should double that estimate.

Does completing this checklist make a site WCAG 2.2 AA conformant? No. It covers the failure patterns behind most real-world barriers, but WCAG 2.2 contains 86 success criteria, and a conformance claim means testing every applicable one and documenting the method. Treat a clean run as evidence of good practice, not a conformance statement.

Which single check catches the most issues? The full keyboard walkthrough. It needs no special software, takes under an hour per template, and surfaces focus traps, invisible focus indicators, unreachable controls, and broken modals — the failures most likely to make a purchase impossible rather than irritating.

Can automated tools handle the ecommerce-specific checks? Only partly. Scanners flag unlabeled filter controls and low-contrast swatches, but they cannot tell whether a price update was announced, whether a selected variant is distinguishable without color, or whether focus returned after a cart drawer closed. Those behaviors need a person with a screen reader.

How often should this checklist be re-run? Run the automated pass at every deploy, the ecommerce checks after any theme or app change, and the full manual pass twice a year. Sites regress: every app install, theme update, and seasonal campaign can reintroduce failures already fixed.

Humans + AI = this article. TestParty uses a cyborg approach to content — combining human accessibility expertise with AI capabilities to produce accurate, comprehensive guides. This content is for educational purposes and reflects our analysis of publicly available information as of the publication date. TestParty competes in the digital accessibility market, and we encourage readers to evaluate all solutions independently based on their specific needs.