If a shopper cannot use your store, you lose the sale and risk an ADA claim

Accessibility failures are silent. There is no error log for a customer whose screen reader announced your variation dropdown as an unlabeled group, no support ticket from someone who could not tab to the add-to-cart button, no bug report from a shopper who could not read a light gray sale price on a phone in daylight. The CDC's disability prevalence estimates put roughly one in four US adults as living with some disability, and the practical population is wider still: older shoppers with declining vision, people with a broken wrist using a keyboard, anyone on a small screen in bad light. None of them tell you what went wrong. They buy elsewhere.

The ADA itself does not publish technical web rules. In practice, settlements, consent decrees, procurement contracts and Department of Justice guidance all converge on the same reference: the Web Content Accessibility Guidelines, version 2.1, at level AA. It is not a design style and it does not require an ugly site. It is a set of testable conditions organized under four ideas — perceivable, operable, understandable, robust — that describe whether a page can be used by someone who cannot see it, cannot use a mouse, or cannot process a moving carousel. Level A is the floor, AAA is largely aspirational, and AA is the level nearly every reference point in the US names. Read the four principles as questions about your store, not as a checklist to hand off.

• Perceivable: text alternatives, captions, and contrast that survives a bright screen
• Operable: everything reachable and usable with the keyboard alone
• Understandable: predictable navigation, labeled inputs, errors that say what to fix
• Robust: markup that assistive technology can interpret without guessing

Catalog sites fail in patterns. Product photography arrives with alt text that is empty, duplicated across a gallery, or auto-filled with a filename. Variation pickers, price sliders and filter panels are built from styled divs that a mouse can operate and a keyboard cannot. Form fields are labeled only by placeholder text that vanishes the moment someone types, so a screen reader reaches an anonymous box halfway through checkout. Each of those maps to one criterion — 1.1.1 for the alt text, 2.1.1 for the keyboard, 3.3.2 for the labels — which is why an audit comes back as a list and not as an opinion. Sale badges and secondary text sit below the required contrast ratio. Quick-view modals and cart drawers open without moving focus into them, or trap focus so escape is impossible. Product videos autoplay without captions. None of these are exotic; they are the default behavior of most commercial themes, which is exactly why accessibility has to be tested. Assuming it is how the defaults survive. On WooCommerce the same failures trace back to specific components, swatch plugins, side carts and checkout field editors, and the WooCommerce WCAG guide goes through them one at a time.

• Product images with missing, empty or auto-generated alt text
• Variation dropdowns and price sliders that ignore the keyboard entirely
• Fields labeled only by placeholder text that disappears on typing
• Cart drawers and quick-view modals that lose focus or trap it

Overlay widgets are sold as one line of JavaScript that makes a site compliant overnight. Accessibility practitioners have criticized them consistently; the Overlay Fact Sheet, signed by hundreds of accessibility professionals including people who build assistive technology, is the widely cited statement of that position. The mechanism explains why. An overlay runs after your page loads and guesses. It cannot know what a product photo depicts, cannot rewrite a custom dropdown into a real control, and can interfere with the screen reader the visitor already runs. Overlays have themselves appeared in claims, and in January 2025 the FTC settled with an overlay vendor over its claim that the product made websites WCAG-compliant, the clearest signal available that buying one is not the same as fixing the site. Before hiring anyone, spend an afternoon: tab through your own checkout without touching the mouse, turn on VoiceOver or NVDA, run a contrast checker. If your theme is standard and the gaps are alt text and contrast, that is editorial work your own team can do this month, at no cost. Budget for real remediation only where components are genuinely custom.

Start with an automated scan — axe, Lighthouse or WAVE — because it is free, fast and catches a real category of defects: contrast ratios, missing alt attributes, missing form labels, invalid ARIA. Then accept its limits. A scanner can confirm that alt text exists but not that it describes the product, can see a heading but not that the order is nonsense, can find a label but not that the error message is incomprehensible. The rest is manual. A keyboard-only pass through the journeys that make money, in order: home, category, filter, product, variation, cart, checkout, payment. Then the same paths with a screen reader, then at 200% zoom, then with measured contrast. The output is not a score. It is a list of failures, each mapped to a WCAG success criterion, with severity and location. If you want a second read on yours, a short review is a sensible first step.

Products, stock, orders, coupons, tax rules, payment gateways and your plugin stack stay exactly where they are in WooCommerce, and your team keeps working in the WordPress admin they already know. Alt text is content, not code. It lives in the media library and product data, and writing it stays with the people who know the products. What changes is the customer-facing layer, because that is where the structural failures live — heading order, focus management, the custom dropdown, the slider, the modal. Rebuilding the storefront as a Next.js storefront makes those components replaceable with accessible ones without renegotiating checkout logic. Where the native Woo checkout stays in place, its accessibility is bounded by the plugins that render it, which is worth knowing before anyone promises full conformance.

Trying to reach zero findings everywhere at once is how remediation stalls. Triage on two axes: does this block a purchase, and does it sit on the path to revenue. A checkout field with no label blocks a purchase; a low-contrast caption on an about page does not. Work outward from the transaction, keep the broad theme-level changes running in parallel because they are cheap and touch every template, and record the date each item is closed. A documented plan that is visibly progressing is better for shoppers than a widget, and it is a more honest answer than a compliance badge. Scope depends on how custom the storefront is and how much of it survives the audit; pricing shows where engagements start.

• First: anything that blocks a purchase — checkout fields, errors, focus traps
• Second: the browse path — filters, sorting, variation pickers, cart drawer
• Third: content-level fixes such as alt text, heading order and captions
• In parallel: contrast and visible focus styles, usually one theme-wide change

Documentation is part of the deliverable. Publish an accessibility statement that names the standard you are working to, gives a contact route and states how quickly you respond. Keep the audit report with its dates, a remediation log showing what was fixed and when, a list of known outstanding issues with target dates, and a schedule for retesting after each release — accessibility regresses the moment a new plugin renders new markup. If you sell to businesses or public bodies, expect requests for a VPAT or conformance report. One clear caveat. This page is general information about how accessibility work is done, not legal advice. Exposure in the US depends on the ADA, state statutes, your sector and the specific claim, and a qualified attorney should review your position. Engineering can make a site usable; only your lawyer can advise on risk.