ADA website compliance: what the law asks of an online store, and how to fix a VSL page

ADA website compliance means making your site usable by people with disabilities. The Justice Department says the ADA covers what businesses open to the public offer online, though it has set no technical standard for their sites and calls WCAG helpful guidance. Don't expect an overlay widget to get you there on its own: the FTC has acted against one vendor's claim that its widget could.

The barriers DOJ's guidance names read like a VSL funnel's parts list: videos without captions, images without text alternatives, low color contrast, forms without labels or error indicators, and pages you can't use with a keyboard. The sales video, the offer block under it and the checkout after it can run into every one of them. This is a summary, not legal advice.

What ADA website compliance means for an online store

Title III of the ADA prohibits disability discrimination by businesses open to the public; DOJ's examples range from retail stores and banks to hotels and medical offices. Its web guidance, published in March 2022, says the law applies to the goods and services those businesses offer on the web, a position DOJ says it has held since 1996 (ADA.gov).

What the guidance doesn't do is set a technical standard. DOJ "does not have a regulation setting out detailed standards" for businesses. They have flexibility in how they make their online offerings accessible, but they have to make them accessible.

For the how, DOJ points to WCAG and the federal Section 508 Standards as helpful guidance. The guidance itself is informal and has no legally binding effect, and it was still posted, with no withdrawal notice, in October 2026.

The rule that does write WCAG into law is for governments. DOJ's Title II rule, published on 24 April 2024, requires the websites and mobile apps of state and local governments to meet WCAG 2.1 Level AA; private businesses aren't covered (ADA.gov).

An interim final rule of 20 April 2026 moved its deadlines to 26 April 2027 for governments with a population of 50,000 or more, and to 26 April 2028 for smaller ones and special district governments. DOJ also said it may propose changes to the rule itself (Federal Register). Many pages still give the old deadlines of April 2026 and April 2027.

Here is how the dates fit together, US and EU:

Web accessibility rules, in order

US and EU dates. The Title II deadlines apply to state and local governments, not to stores

1. 17 April 2019The EU adopts the European Accessibility ActDirective (EU) 2019/882. Member states had until 28 June 2022 to adopt the national laws that carry it out.
2. 18 March 2022DOJ publishes its web guidanceTitle III reaches businesses' online offerings. No technical standard; WCAG and Section 508 are called helpful guidance.
3. 5 October 2023WCAG 2.2 becomes a W3C RecommendationNine new success criteria. The current edition is dated 12 December 2024.
4. 24 April 2024DOJ's Title II web ruleWCAG 2.1 Level AA for state and local governments' websites and mobile apps. Private businesses aren't covered.
5. January to April 2025FTC order against accessiBeProposed 3 January, final 22 April: $1 million over claims that its widget could make any website WCAG-compliant.
6. 28 June 2025The European Accessibility Act appliesThrough national laws, e-commerce services for consumers included. Microenterprises providing services are exempt.
7. 20 April 2026Title II deadlines moveAn interim final rule extends them. DOJ says it may propose changes to the rule itself.
8. 26 April 2027Title II deadline for larger governmentsState and local governments with a population of 50,000 or more.
9. 26 April 2028Title II deadline for smaller governmentsPopulations under 50,000, and special district governments.

WCAG: the yardstick audits use

WCAG, the Web Content Accessibility Guidelines, is the W3C's standard for accessible web content. Version 2.2 became a W3C Recommendation on 5 October 2023 with nine new success criteria, and its current edition is dated 12 December 2024. Content that conforms to 2.2 also conforms to 2.0 and 2.1, so building to the newest version covers the older ones (W3C).

At the top sit four principles, which W3C names "perceivable, operable, understandable, and robust". Thirteen guidelines set the goals under them, and testable success criteria set the bar, each at one of three levels: A, the lowest, then AA, then AAA, the highest. DOJ names no version or level for businesses, while its government rule uses 2.1 Level AA. Every criterion this article mentions is at Level A or AA.

W3C's Web Accessibility Initiative made a set of short films on ten accessibility topics, from keyboard compatibility to video captions and color contrast:

7:36

Demand letters and lawsuits: what's on the record

The vendor pages that rank for this topic speak of thousands of website accessibility lawsuits without giving a source. We couldn't verify a count of lawsuits or demand letters, or how courts treat a website on its own, so this article gives no number.

What is on the record is DOJ's own work. Its guidance says the department "is committed to using its enforcement authority to ensure website accessibility", and it lists agreements it reached with businesses:

• Teachers Test Prep, over complaints that its online video courses had no captions and were inaccessible to people who are deaf. It's the case closest to a VSL: video content without captions.
• H&R Block, whose website allegedly wasn't coded to work with screen readers, refreshable Braille displays, keyboard navigation and captioning.
• Peapod, the online grocery delivery service, over claims that it wasn't accessible to some people with disabilities.
• Rite Aid, over barriers in its COVID-19 vaccine registration portal.

If a demand letter does arrive, treat it as a legal matter and take it to a lawyer before you reply. Two things make that conversation shorter: a list of the specific barriers the letter names, and a dated record of what you've already fixed.

Why an accessibility overlay can't promise compliance

An accessibility overlay is a plug-in added on top of an existing site, and some are sold as automated fixes. In January 2025 the FTC announced a proposed order against accessiBe, alleging that its accessWidget plug-in "did not make all user websites WCAG-compliant", and that the company formatted third-party articles and reviews to look like independent opinions without disclosing its material connections to the reviewers (FTC). The FTC's business blog says accessiBe had marketed the plug-in as "a fully automated tool to make any website compliant with" WCAG (FTC business blog).

The final order, approved in April 2025, came with a $1 million payment. It bars accessiBe from claiming that its automated products can make any website WCAG-compliant, or keep one compliant over time, without evidence to back the claim (FTC).

Read the case for what it is. The FTC acted on accessiBe's claims, not on overlays as a category, and its blog doesn't say automated tools can't help. It's a settlement over advertising, not a ruling under the ADA.

DOJ makes the related point from its side: a clean report from an automated checker "does not necessarily mean everything is accessible". A checker can flag an image with no alt text. Whether the alt text describes the bottles in the offer, and whether the captions match what the presenter says, still takes a person.

The three approaches side by side:

Overlay, checker or fixing the page

Three things sold or done in the name of accessibility

A layer on topAn overlay alone

• A plug-in added on top of the site; some are sold as automated fixes
• The FTC said one vendor's claims that its widget made sites WCAG-compliant were deceptive
• Check what it actually changes on your own pages before relying on it

Ask any vendor for the evidence behind a compliance claim. The order against accessiBe requires it for its own claims.

Finds problemsAn automated checker

• Scans pages for what a machine can detect
• Useful for catching regressions after each change
• DOJ: a clean report "does not necessarily mean everything is accessible"

A smoke alarm, not a certificate.

Changes what buyers getFixing the page

• Captions in the video's own caption track (1.2.2)
• Alt text, labels and contrast fixed in the page and the checkout (1.1.1, 3.3.2, 1.4.3)
• Player controls that work from the keyboard (2.1.1)
• Tested by a person with a keyboard and a screen reader

The catch: it takes time, and someone who can edit the page, the player settings and the checkout.

The European Accessibility Act, if you sell into the EU

In the EU, the rules for stores come with a date. The European Accessibility Act, Directive (EU) 2019/882, applies from 28 June 2025, and the services it covers include e-commerce services: services provided at a distance, through websites and mobile device-based services, at the consumer's request, with a view to concluding a consumer contract (EUR-Lex). It's a directive, so what binds a business is each member state's national law, enforced nationally.

Two details decide a lot:

• Microenterprises are exempt. Microenterprises that provide services don't have to meet the accessibility requirements. Both limits count: fewer than 10 staff, and an annual turnover or balance sheet total of EUR 2 million or less.
• Who counts as a service provider. The definition includes anyone who "makes offers to provide such a service to consumers in the Union", and it doesn't say where that business has to be established.

Whether that brings a US store selling to EU consumers under a member state's law is a question for counsel. The text doesn't settle it either way, and the European Commission's page on the Act doesn't address it. If you have real EU sales, ask before your next push there, not after.

Fixing a VSL page, principle by principle

Here is what each of WCAG's four principles asks of a VSL page, with the success criteria that bear most directly on a sales video, its offer and its checkout:

WCAG's four principles on a VSL page

The success criteria that bear most on a sales video, its offer and its checkout

PerceivableOperableUnderstandableRobust

Buyers can see or hear all of it

In W3C's words, information and interface components "must be presentable to users in ways they can perceive."

• Captions for the whole video, not only the hook (1.2.2, Level A)
• A text alternative that serves the same purpose as each product shot, badge and offer image (1.1.1, A)
• Contrast of at least 4.5:1 for text, or 3:1 for large text, on headlines, buttons and text in posters (1.4.3, AA)
• No audio that plays by itself for more than 3 seconds without a way to stop it or a volume control of its own (1.4.2, A). A muted teaser plays none

Example: a headline baked into the poster image is held to the same contrast as text on the page: 4.5:1, or 3:1 if it is large.

Everything works without a mouse

In W3C's words, interface components and navigation "must be operable."

• Play, pause, captions and volume all work from the keyboard (2.1.1, A)
• A visible way to pause the teaser that starts on its own (2.2.2, A, by our reading)
• A focus indicator you can see as you tab through the page (2.4.7, AA)
• Buy buttons at least 24 by 24 CSS pixels, or with enough space around them (2.5.8, AA, new in 2.2)

Example: tab from the headline to the buy button. If you lose track of where you are, so does every keyboard user.

Forms that explain themselves

The third principle covers whether buyers can understand the content and how the page behaves. On a VSL funnel, that is mostly the checkout.

• A label or instruction on every field that needs input (3.3.2, A)
• Errors that say what went wrong. DOJ lists forms without error indicators among the barriers it names
• "Don't ask for the same information twice in the same session" (3.3.7, A, new in 2.2)
• "Don't make people solve, recall, or transcribe something to log in" (3.3.8, AA, new in 2.2)

Example: a "billing same as shipping" box covers Redundant Entry for the address.

Assistive technology can read it

The fourth principle covers compatibility: code that browsers and assistive technologies, screen readers among them, can work with.

• Every button and control exposes a name and a role, custom player controls included (4.1.2, A)
• Custom controls need that information built in, which W3C's guidance says takes extra work
• Test with a real screen reader. A scanner can't hear what it announces

Example: a play button with no accessible name leaves a screen reader user guessing what it does.

Three of these fixes live in the player, and they're where a VSL page differs from an ordinary product page.

Captions. Caption the whole video, not just the hook, and check every line against the script. In RevvyScales, captions come with every plan: you upload a .vtt or .srt file for each language, one track can be on by default, and viewers get a CC button (subtitles and captions). The VSL captions guide covers writing and timing them.

Muted autoplay. A teaser that starts muted plays no audio, so the criterion on audio that starts by itself isn't triggered, and sound begins only when the viewer chooses it. RevvyScales' player starts as a muted teaser and waits for a tap to turn on the sound (player features). The moving picture still needs a visible way to pause it, by our reading of criterion 2.2.2; the autoplay guide covers the trade-offs.

Controls. Whatever you hide for cold traffic, keep pause, volume and captions, and make sure each one works from the keyboard and has a name a screen reader can announce.

Off the player, three places need the most care.

The offer block. The offer that stays hidden until the pitch is the VSL-specific trap: once it appears, a keyboard user has to be able to reach it and a screen reader has to read it, prices included. Its images need text alternatives that do the picture's job: "3 bottles, 90-day supply, $147" for a bundle shot, "60-day money-back guarantee" for a guarantee badge, never a file name. Contrast and button size are covered in the VSL landing page guide.

The checkout. Most of it is ordinary form work: labels, error messages that say what's wrong, no field asked twice. If it runs on another platform, test it the same way and send what you find to the provider.

The upsell. After the payment, the one-click upsell page is one more page to test. The yes and the no-thanks both have to be reachable from the keyboard and announced by a screen reader. A decline link that only a mouse can find isn't much of a choice.

A one-hour accessibility pass before your next launch

You don't need an auditor to find the most obvious barriers. Put the mouse away, turn on the screen reader built into your phone or computer, and buy something from your own funnel:

A one-hour accessibility pass

• Tab from the top of the page to the buy button without a mouse, and keep sight of the focus all the way
• Start, pause and unmute the video and switch captions on, all from the keyboard
• Watch the whole video muted with captions on: every line there, in sync, none missing
• Check that nothing plays sound before the viewer asks for it, and that the teaser can be paused
• Listen to the page with a screen reader: product images, badges and offer images described, every button named
• Measure contrast on the headline, the buttons and any text in the poster: 4.5:1, or 3:1 for large text
• Let the pitch reveal the offer, then reach it and hear it read, prices included, without a mouse
• Fill in the checkout by keyboard: a label on every field, errors that say what is wrong, nothing asked twice
• Run an automated checker and fix what it flags, without treating a clean report as the finish line
• Write down each fix with its date, and repeat the pass after every new page, offer or checkout change

0 of 10 done

Fix what you find in order of how many buyers it stops, and keep a dated note of each fix.

Bring in an auditor when you sell at scale, sell into the EU or a letter has arrived. Ask for testing against WCAG 2.2 Level AA on every page of the funnel, upsells and thank-you page included, by keyboard and screen reader as well as with automated tools, and for each failure to be listed by its success criterion, so the fixes can be tracked one by one.