# How website accessibility claims get tested: what auditors and plaintiffs look for Source: https://suitshieldhq.com/blog/2026-10-20-how-accessibility-claims-get-tested.html Reviewed October 20, 2026 Accessibility lawsuits and audits do not start with your whole site. They start with a handful of standard tests on your most important flows. The checks that surface nearly every claim, and what the pattern means for your priorities. ## Nobody starts by reading your whole site Whether the tester is a plaintiff's firm, an advocacy organization, or a hired auditor, the method is similar and it is not exhaustive. They run an automated scanner over your key pages, then manually test the core flows, usually with a keyboard and a screen reader: find a product, configure it, add to cart, check out, contact you. The findings that become claims come overwhelmingly from that short route, not from your archive pages. This is useful news, because it means your highest risk surface is small and named. The homepage, search, product page, cart, checkout, and contact path are where claims are born. A store that gets those flows right has not eliminated risk, but it has addressed the places where risk is actually measured. ## The automated scan: what machines catch Scanners reliably catch a familiar list: images without alt text, form fields without labels, low color contrast, empty links and buttons, missing page structure like headings and landmarks, and duplicate IDs that break assistive technology references. On a typical untested store, a scan of the homepage alone returns dozens of violations, and that report is frequently exhibit one. Machines catch roughly a third of real barriers, but they catch the third that proves neglect. A clean scan does not mean an accessible store; a dirty one does mean an untested store, and that distinction is exactly what gets argued. Running the same free scanners the testers use, on your own schedule, removes the easiest evidence from the record. ## The manual pass: keyboard and screen reader The manual test is where claims gain their detail. A tester tabs through your flow recording where focus disappears, where a modal traps or fails to trap, where the checkout's error messages are never announced, and where a screen reader meets an unlabeled button at the moment of purchase. These are experiential barriers a scanner cannot see, and they are described in complaints in vivid, specific language because a human lived them. You can replicate a meaningful share of this test yourself in an afternoon: a keyboard, a free screen reader, and your five most important flows, with notes. It will not equal a professional audit, and it will find the failures most likely to be quoted back to you. Stores are often surprised how fixable the list is once it is written down by someone who actually tried to buy something. ## What the pattern should do to your priorities The rational response is sequencing, not panic. First, scan and fix the automated violations on your core templates, because template fixes heal hundreds of pages at once. Second, walk the purchase path with a keyboard and screen reader and fix what blocks a transaction. Third, put the core flows on a retest rhythm, because apps, banners, and theme updates reintroduce barriers continuously. Document each round: dates, tools, findings, fixes. In accessibility disputes, the difference between a store that never looked and a store running a real program is most of the argument. Claims get tested on your flows; your defense gets tested on your record. Build both. ## Related reading If this topic is useful, these earlier guides go deeper on connected questions: [WCAG 2.2 for Shopify stores: what changed and what to check](https://suitshieldhq.com/blog/2026-10-19-wcag-22-shopify-stores-what-changed.md), [Responding to an accessibility demand letter about your store](https://suitshieldhq.com/blog/2026-10-19-responding-accessibility-demand-letter-shopify-store.md), and [Planning a Shopify accessibility audit: cost, timeline, and scope](https://suitshieldhq.com/blog/2026-10-18-shopify-accessibility-audit-cost-timeline-planning.md). ## Frequently asked questions ### Do plaintiffs really test stores themselves? The standard pattern is a tester, often working with a law firm or advocacy group, attempting real tasks on the site, usually the purchase flow, assisted by automated scans. Findings in demand letters and complaints typically quote specific barriers on specific pages, which is why the core flows matter more than the long tail of your catalog. ### If I pass an automated scan, am I safe? No. Scanners detect roughly a third of accessibility barriers, mostly the mechanical ones. Keyboard traps, focus order, unannounced errors, and modal behavior need manual testing. A clean scan is a good start and a poor conclusion. Treat it as the floor of a testing program, not the ceiling. ### Which pages should I test first? The transaction path: homepage, search and category pages, a representative product page, cart, checkout, and your contact or support route. These are the pages testers use and the pages where a barrier directly costs a customer. Template level fixes there propagate across the catalog automatically. ### How often should testing repeat? After any theme change, major app install, or redesign, and on a standing rhythm of at least a few times a year for the core flows. Barriers re-enter through ordinary changes like promotional banners and new widgets, so a one time audit decays. Your testing log, kept current, is itself part of the compliance record.