Two small businesses bought overlay subscriptions and were sued over inaccessible websites anyway. A small online florist filed a class action against UserWay, and a small skin care dermatology practice filed a similar action against AccessiBe. The details of each case are still developing, but the pattern matters to your risk register now: a monthly overlay fee is not a defensible control.
This checklist is built for risk managers who need to determine whether an overlay is standing in for a real accessibility program, and what to put in its place. Each item has a done or not-done state and a description of what good looks like.
Prerequisites
Before you start, gather these:
- A list of every public-facing domain, subdomain, mobile app, and third-party embed your organization operates
- Contracts and marketing claims for any overlay or "automated compliance" product in use
- Any existing Accessibility Conformance Reports, audit results, or remediation logs
- Names of the executive owner, legal contact, and technical lead for accessibility
- Your complaint and demand-letter history related to digital accessibility
Plan on one to two weeks of coordination. The technical work comes later; this checklist is about governance and evidence.
Checklist Items
1. Inventory every overlay and "automated compliance" tool.
Done: you have a written list of each product, which properties it runs on, who bought it, and what the vendor promises. Not done: nobody can say with certainty where overlays are installed.
What good looks like: A single register, owned by one named person, reviewed Assistive Technology least annually.
2. Compare vendor claims against your legal exposure.
Done: legal has reviewed marketing language such as "compliant" or "protected" against the actual contract terms, including indemnification, liability caps, and disclaimers. Not done: the product Web Accessibility Specialist approved on a sales deck.
What good looks like: A memo confirming whether the vendor accepts any liability if you are sued. Treat any gap between marketing and contract as a finding.
3. Define your conformance target in writing.
Done: a policy names a specific standard and level. WCAG 2.1 Level AA is the common baseline; WCAG 2.2 is the current version. If you serve public entities, the DOJ Final Rule (2024) under ADA Title II references WCAG 2.1 AA. If you operate in the EU, the European Accessibility Act and EN 301 549 may apply.
What good looks like: One approved target, mapped to each applicable law, signed off by legal.
4. Commission an independent Conformance Testing audit.
Done: a qualified auditor has tested representative templates and key user journeys (account creation, checkout, forms, search) against your target, using manual methods and Assistive Technology, not only an automated scan. Not done: your only evidence is a vendor dashboard score.
What good looks like: A written report listing each failure by WCAG success criterion, severity, and location.
5. Include Screen Reader Testing and keyboard-only testing.
Done: testers have completed critical tasks with Assistive Technology least one screen reader and with keyboard navigation alone, and documented the results. Automated tools catch only a portion of WCAG failures; the rest need human evaluation.
What good looks like: Task completion records, not pass/fail checkboxes. A user who cannot finish checkout has failed the test, whatever the scanner says.
6. Test the site with the overlay turned off.
Done: you have documented how the site behaves without the overlay script, since that is the code assistive technology users and plaintiffs' experts may evaluate directly. Not done: no one has ever seen the unmodified site.
What good looks like: A baseline audit of the underlying code. If the baseline fails, the overlay is masking defects rather than removing them.
7. Remediate in source code.
Done: defects are fixed in templates, components, and content, including semantic HTML, correct use of WAI-ARIA, and attributes such as aria-label and aria-describedby where native elements fall short. Not done: fixes exist only as runtime patches injected by a third-party script.
What good looks like: Every audit finding has a ticket, an owner, a due date, and a verified retest.
8. Set remediation priorities by risk.
Done: findings are ranked by user impact and legal exposure, with transactional paths and authentication addressed first, including Accessible Authentication under WCAG 2.2.
What good looks like: A dated roadmap the executive owner has approved, with interim milestones.
9. Build accessibility into Accessible Procurement.
Done: purchasing requires an Accessibility Conformance Report based on the Voluntary Product Accessibility Template for any third-party tool, plus contract language on remediation duties.
What good looks like: Vendors that cannot produce evidence are escalated before signature, not after launch.
10. Establish Accessibility Governance.
Done: a policy, an executive owner, a training plan, and a budget line exist. Staff who design, build, and publish content know their responsibilities. Certifications from the International Association of Accessibility Professionals, such as Certified Professional in Accessibility Core Competencies or Web Accessibility Specialist, can validate in-house expertise.
What good looks like: Accessibility is a release criterion, with defects tracked like security issues.
11. Provide a working feedback and escalation channel.
Done: users can report barriers and receive a response within a stated timeframe, and reports reach people who can fix them.
What good looks like: A log showing intake, triage, resolution, and follow-up with the reporter.
12. Keep an evidence file.
Done: audits, remediation records, policies, training logs, and retests are stored in a retrievable repository.
What good looks like: If you receive a demand letter, you can produce a dated, good-faith record of your efforts within days.
Common Mistakes
- Treating a subscription as a control. Recurring payment shows spending, not conformance.
- Relying on automated scores alone. A passing scan can coexist with an unusable checkout.
- Describing status loosely. Terms like "Partial Conformance" invite scrutiny. Use Partial Conformance and state exactly which criteria fail.
- Ignoring third-party components. Chat widgets, payment forms, and cookie banners inherit your exposure.
- Skipping the vendor contract review. The indemnity clause matters more than the feature list.
- Auditing once. Sites change weekly; conformance decays without retesting.
Next Steps
- Complete items 1 and 2 this week; they cost little and reveal your exposure fastest.
- Schedule the independent audit (items 4 through 6) and brief legal on the results.
- Decide whether the overlay stays as an optional user-preference tool or is retired, and never as your compliance claim.
- Present the roadmap and evidence plan to your executive owner for approval.
The legal pattern is still unfolding, and you should consult counsel on your specific obligations. What you can control now is the quality of your evidence. A documented audit, a source-level remediation plan, and clear governance will serve you far better than a monthly subscription ever could.
