Skip to content

U.S. e-commerce accessibility / Case 30

Auditing representative e-commerce templates and user journeys instead of blindly scanning every URL

The storefront had too many products and content URLs for a useful manual review of every page, so the audit was organized around unique templates, shared components, important states, and real purchase journeys.

Accessibility auditaxe DevToolsWAVELighthouseQA

Plain-English summary

What this solved for the business or user

Testing every product URL would create a large report without necessarily testing more unique behavior. The audit focused on the pages and interactions customers actually depend on, then reused those findings across shared theme components.

01 / Real situation

What was happening

The July accessibility report covered 20 live URLs or hosted flows plus the global cart-drawer component. Representative areas included homepage, multiple collection/product states, cart and hosted checkout, customer account, contact, FAQ, returns, blog content, policies, accessibility statement, and 404 behavior. Shared header, footer, navigation, cart, app, and theme components were evaluated where they appeared rather than counted as separate systems on every URL.

02 / Constraint

Why the obvious solution was not enough

Automated scanners make it easy to create hundreds of nearly identical URL results while still missing the difficult parts: dynamic drawers, menus, variant controls, filters, forms, modal focus, zoom/reflow, and checkout-adjacent state. The audit needed breadth without confusing URL count with coverage quality.

03 / Implementation

How the solution works

  1. Build the page list from unique templates and customer journeys first. Add another URL only when it introduces a materially different component or state.
  2. Capture desktop and mobile evidence where the responsive implementation changes navigation, layout, or component behavior.
  3. Use WAVE to inspect errors, contrast, headings, labels, alternative-text prompts, and ARIA-related findings in context. Treat alerts as review prompts rather than automatic failures.
  4. Run axe DevTools as a second automated rule engine so a finding from one scanner can be checked against another implementation perspective.
  5. Record Lighthouse/PageSpeed accessibility scores on public pages, but do not turn the score into a compliance claim. Performance results can be useful regression evidence but are not ADA pass/fail criteria.
  6. Add manual interaction checks around keyboard order, visible focus, menus, cart drawer, modals, form validation, hidden-content focusability, 200% zoom/reflow, and accessible names.
  7. Track discrepancies between tools as investigation items. For example, a page can show 0 axe automatic issues while WAVE still exposes a broken ARIA reference that needs direct DOM inspection.
  8. Retest the shared component after remediation on at least one representative page and on any special state where its behavior changes.
Representative coverage model
const auditMatrix = [
  { area: 'home', states: ['desktop', 'mobile'] },
  { area: 'collection', states: ['filters', 'empty'] },
  { area: 'product', states: ['variant', 'sale', 'bundle'] },
  { area: 'cart', states: ['empty', 'populated', 'drawer-open'] },
  { area: 'forms', states: ['default', 'error', 'success'] },
  { area: 'account', states: ['logged-in'] },
  { area: 'content', states: ['article', 'policy', '404'] },
];

04 / Release checks

What should be verified before shipping

  • Confirm each unique shared component appears in at least one tested page/state.
  • Do not mark an area complete because one scanner reports zero issues; compare tools and inspect the DOM where results disagree.
  • Keep desktop/mobile evidence where the navigation or layout materially changes.
  • Record which hosted or third-party surfaces are platform-controlled so responsibility is clear.
  • Keep a separate manual backlog for checks automation cannot determine, especially screen-reader behavior and complete keyboard journeys.
  • When a shared header, drawer, or form is fixed, retest the component in the states most likely to expose regressions.

05 / Result

What changed

The July evidence set was broad enough to expose site-level patterns without pretending every URL had been manually certified. In the supplied evidence, axe DevTools showed 0 automatic issues on the 16 pages or flows where axe screenshots were captured, Lighthouse accessibility scores were generally 97–100 on tested public pages, and WAVE was clean on most pages while still identifying specific follow-up items that remained in the backlog.

Reusable lesson

Accessibility coverage should follow behavior, not URL count. A smaller matrix of unique templates, states, and journeys usually teaches more than a giant spreadsheet of duplicate product pages.

References

Official documentation and standards