From an accessibility lawsuit to a documented remediation and monitoring program

What was happening

The accessibility work followed a lawsuit and subsequent requests to document continuing remediation. The legal context mattered because ADA Title III can be enforced through private civil actions, so a storefront accessibility defect can create legal exposure in addition to being a real customer barrier. The program deliberately avoids dismissive labels such as 'scam' or 'loophole.' Even when a business believes a demand is repetitive, aggressive, or opportunistic, the engineering response should be the same: verify the alleged defect, fix any genuine barrier, preserve dated evidence, and keep the site under review rather than arguing the legal merits inside a technical report. The storefront was an active Shopify implementation with reusable Liquid components, JavaScript-driven drawers and menus, product forms, responsive states, hosted checkout, and third-party apps. That made a one-time scan insufficient: a theme deploy, app update, new campaign script, content change, or vendor widget could introduce a regression after the original issue had been fixed. The program therefore evolved across several evidence stages: internal remediation documentation in April 2026, an insurance/broker-facing evidence summary in May, focused homepage remediation documentation, and a broader July 2026 report covering representative live pages and customer flows.

Why the obvious solution was not enough

Automated accessibility tools were useful for finding reproducible markup, contrast, naming, and structural problems, but they could not prove complete keyboard usability, focus behavior, screen-reader output, error recovery, or dynamic-widget behavior. Tool results could also disagree: a page could show 0 automatic axe issues while WAVE still exposed a broken ARIA reference that required DOM inspection. The process therefore had to separate allegations from confirmed technical defects, confirmed defects from scanner alerts that only required human review, theme-owned code from third-party/platform surfaces, and engineering evidence from legal conclusions. Unresolved manual checks stayed visible, and a clean automated scan was never presented as a compliance certificate.

How the solution works

1. Establish a remediation baseline in the Shopify theme. Review Liquid and JavaScript for form-label associations, accessible names on buttons and links, ARIA relationships, keyboard behavior, focus management and focus traps, color contrast, semantic HTML, heading structure, and invalid description-list markup such as incorrect <dl>, <dt>, and <dd> usage.
2. When a complaint, demand, or audit finding identifies a specific barrier, reproduce the exact issue before changing code. Inspect the rendered DOM, identify the affected component and state, determine whether the finding is confirmed, then document the root cause, fix, retest result, and current status. Legal questions about the claim itself stay with counsel; the engineering record stays factual and reproducible.
3. Fix defects at the source component rather than hiding symptoms with CSS. One documented cart-drawer defect used aria-labelledby="csc-drawer-title" even though no element had that ID. The visible 'Your Bag' heading was given the matching ID so the dialog had a real accessible name relationship.
4. Correct data-driven navigation output. A desktop mega-menu CTA could render as an empty link when its metaobject title and URL were blank. The Liquid logic was changed to render the CTA only when both values exist, and repeated ID-based styling was replaced with a reusable class where appropriate.
5. Treat scanner alerts as triage items, not automatic failures. Redundant links and Shopify noscript fallbacks were reviewed in context; very-small-text alerts were moved to manual zoom/readability verification instead of being changed only to silence the tool.
6. Add an Accessibility Statement page with a working reporting path so customers have a documented way to report barriers and the business has an operational feedback channel.
7. Use three independent automated signals. WAVE supports visual DOM debugging and contextual alert review; axe DevTools provides WCAG-oriented automated rule checks; Lighthouse/PageSpeed provides an additional accessibility score and regression signal. Performance scores are not treated as ADA pass/fail criteria.
8. Audit representative templates and journeys instead of blindly scanning every URL. Coverage included the homepage, main collections, primary and secondary product templates, cart drawer, hosted checkout, account, contact/FAQ/returns, blog index/article, static pages, legal pages, Accessibility Statement, opt-out, 404 behavior, and third-party controls where they render.
9. Capture responsive evidence where behavior changes. Desktop and mobile states were checked for navigation, product templates, forms, layout, and other responsive interactions rather than assuming a desktop result applied automatically to mobile.
10. Keep a structured manual-validation backlog for Tab/Shift+Tab order, Enter/Space activation, Escape behavior, visible focus, hidden-content focusability, cart-drawer focus trapping and restoration, 200% zoom/reflow, form errors, accessible names, dynamic announcements, and screen-reader spot checks.
11. Record every audit cycle as evidence: tested URL or flow, device/context, tool, issue type, root cause, remediation, current status, retest result, and date. Screenshots or exports are retained with the corresponding remediation ticket or monthly record.
12. Build a monthly regression workflow. Re-run WAVE, axe, and Lighthouse after material theme changes, app additions, new sections, or third-party script updates; retest the same representative customer journeys; compare new findings against the prior month; and keep unresolved third-party or manual items visible instead of silently dropping them.
13. Use ownership-aware remediation. Theme-owned HTML, Liquid, CSS, and JavaScript issues are fixed in the storefront code; vendor-owned iframe, hosted-checkout, or app-script findings are documented separately and escalated to the platform/vendor when a theme-only fix is not possible.

type FindingStatus =
  | 'open'
  | 'fixed'
  | 'retested'
  | 'manual-review'
  | 'third-party';

type AccessibilityFinding = {
  page: string;
  component: string;
  standardTarget: 'WCAG 2.1 AA';
  source: 'WAVE' | 'axe' | 'Lighthouse' | 'manual';
  issue: string;
  rootCause: string;
  remediation: string;
  status: FindingStatus;
  testedAt: string;
};

const representativeCoverage = [
  'homepage',
  'collection',
  'primary-product',
  'secondary-product',
  'cart-drawer',
  'checkout',
  'account',
  'contact',
  'faq-and-returns',
  'blog',
  'static-content',
  'legal-and-accessibility-statement',
  '404',
];

const remediationLog: AccessibilityFinding[] = [
  {
    page: 'homepage',
    component: 'cart drawer',
    standardTarget: 'WCAG 2.1 AA',
    source: 'WAVE',
    issue: 'Broken ARIA reference',
    rootCause: 'aria-labelledby referenced a missing title ID',
    remediation: 'Attach the referenced ID to the visible drawer heading',
    status: 'retested',
    testedAt: '2026-07-29',
  },
];

// Release rule: a clean automated scan closes only the automated
// finding. Manual keyboard, focus, zoom/reflow and screen-reader
// checks remain separate requirements and are never auto-cleared.

What should be verified before shipping

• For any lawsuit, demand, complaint, or external audit item, record the allegation separately from the engineering finding. Mark it confirmed only after reproducing the issue in the relevant page, state, or component.
• Verify each confirmed finding has an exact page/flow, component, test method, date, root cause, remediation, status, and retest result instead of only a screenshot score.
• Reproduce WAVE or axe findings in the rendered DOM and trace them to the Liquid/JavaScript source before changing the theme.
• For ARIA relationships, confirm every aria-labelledby, aria-describedby, and aria-controls target exists, is unique, and points to the intended visible or programmatic element.
• Test all modal/drawer/menu interactions with keyboard only: logical Tab order, Enter/Space activation, Escape dismissal, visible focus, focus containment where required, and focus restoration after close.
• At 200% browser zoom, verify the storefront remains usable without clipped controls, overlapping content, or loss of information; review small-text alerts in that context.
• For forms and product controls, verify visible/programmatic labels, fieldset/legend grouping where required, meaningful error text, and appropriate announcement of validation or dynamic state changes.
• Retest representative desktop and mobile states after remediation. A component that is shared globally should be checked in the states most likely to exercise different responsive or dynamic behavior.
• Keep WAVE alerts classified as accepted, fixed, or manual-review. Do not convert alert count into a failure count without inspecting the context.
• Recheck third-party components such as reviews, size guides, recommendations, chat, marketing forms, and other app-injected controls after vendor updates because their markup can change independently of the theme.
• Maintain conservative reporting language: automated remediation evidence can show improvement and risk reduction, but it does not replace a complete manual WCAG evaluation, assistive-technology testing, legal advice, or counsel's assessment of a claim.

What changed

The work moved from isolated ADA fixes into a documented accessibility operating process. The April baseline recorded a WAVE AIM score of 9.6/10 with 0 errors and 0 contrast errors, Lighthouse accessibility around 94–97 depending on the run, and 0 automatic axe issues in the captured homepage scan. By the July 29 evidence cycle, the audit covered 20 live URLs or hosted flows plus the global cart drawer, included 84 final evidence screenshots, showed 0 automatic axe issues on all 16 pages/flows with supplied axe evidence, and recorded Lighthouse accessibility scores of 97–100 on tested public pages. The report still kept identifiable follow-up work open, including a Contact-page ARIA reference, Supply Chain empty-heading/contrast findings, product-template contrast/form-grouping alerts, About-page contrast/heading items, heading review on FAQ/Returns/404, and broader manual keyboard and screen-reader validation. That distinction is important: the result is a traceable remediation program and a stronger factual response to future accessibility concerns, not a claim that the storefront can never regress or that every future legal allegation is automatically valid or invalid.

Reusable lesson

Accessibility should be managed like release quality and security hygiene: identify the defect, fix the source component, verify the behavior with more than one method, preserve evidence, keep unresolved manual and third-party items visible, and repeat the same representative checks after changes. When legal pressure is involved, avoid arguing whether a claimant is 'taking advantage' inside the engineering record. A stronger response is evidence: reproduce the allegation, fix confirmed barriers, document what was tested, and show an ongoing process that reduces both user friction and preventable legal exposure.

How I would evaluate this today

Recommended operating model: keep monthly evidence for the same representative templates, run an additional review after material theme/app/script changes, maintain the Accessibility Statement and reporting path, assign theme-owned findings to engineering, escalate vendor-owned findings when necessary, and schedule periodic manual assistive-technology testing. If a new demand or lawsuit arrives, counsel should assess the legal claim while engineering independently verifies the cited barrier and preserves the test evidence. This case study documents engineering remediation and evidence methods; it is not legal advice or certification of ADA/WCAG compliance.