Web accessibility and compliance

A plain-language guide to what web accessibility is, the WCAG standard, the laws behind ADA demand letters, and how a site is actually brought into compliance.

The 30-second version. Websites must be usable by people with disabilities - blind users on screen readers, people who cannot use a mouse, and others. The international rulebook is WCAG. In the U.S., the ADA (a civil-rights law) is used to sue businesses whose sites do not meet it. Thousands of businesses get legal demand letters every year, often triggered by an automated scan. The real fix is changing the website’s code - not installing a “quick-fix” widget, which does not work and can make you a bigger target.

What is web accessibility?

Web accessibility means building a site so that people with disabilities can perceive, understand, navigate, and use it - with the same success as everyone else.

Think of it like a wheelchair ramp for a building. A physical store adds ramps, wide doors, and braille signage so everyone can shop. A website needs the digital equivalent: text a screen reader can read aloud, menus you can operate with a keyboard, captions on videos, and colors with enough contrast to read.

When those things are missing, real people get locked out. A blind customer literally cannot complete a purchase if the “Add to Cart” error is not read aloud. That is the digital version of a locked front door, which is exactly why the law gets involved.

Who does it help?

Accessibility is not a niche concern. Roughly 1 in 4 adults in the U.S. lives with some disability, and it covers far more than blindness:

Type	Examples	What the site must do
Visual	Blindness, low vision, color blindness	Work with screen readers, have alt text, strong contrast, resizable text
Motor / physical	Cannot use a mouse, tremors, paralysis	Be fully operable by keyboard; large, clear clickable areas
Auditory	Deaf or hard of hearing	Captions and transcripts for audio/video
Cognitive	Dyslexia, ADHD, memory, learning	Clear language, consistent layout, helpful error messages

Bonus: it helps everyone. Captions help in noisy places. Good contrast helps in bright sunlight. Keyboard support helps power users. Clear structure helps Google rank you. Accessibility overlaps heavily with good SEO and usability, so the work pays off beyond compliance.

What is WCAG?

WCAG stands for Web Content Accessibility Guidelines - the globally accepted technical rulebook, published by the W3C through its Web Accessibility Initiative (WAI). It is a long checklist of testable “success criteria” (for example, every image that conveys meaning must have a text alternative). Laws and courts point to WCAG as the definition of an accessible site, even when the law itself does not spell out the details.

WCAG 2.0 (2008) - the original, still referenced by some laws.
WCAG 2.1 (2018) - adds mobile, low-vision, and cognitive criteria. This is today’s practical legal target.
WCAG 2.2 (2023) - the current version; adds a few more criteria. Smart to aim for, as it is where the standard is heading.
WCAG 3.0 - an early draft, years from being a requirement. Do not worry about it yet.

The four principles: POUR

All of WCAG is organized under four ideas. If you remember nothing else, remember POUR:

Principle	Means	Example failure
Perceivable	Users can sense the content (see or hear it)	An image with no alt text - a blind user perceives nothing
Operable	Users can operate the controls	A menu that only opens on mouse hover - a keyboard user is stuck
Understandable	Content and behavior are clear	An error appears but does not explain what went wrong
Robust	Works with assistive tech now and later	Custom buttons a screen reader cannot tell are buttons

Conformance levels: A, AA, AAA

A - Minimum. The most basic must-haves. Failing these is severe.
AA - The target. What laws, courts, and settlements almost always require. “WCAG 2.1 AA” is the phrase you will see everywhere.
AAA - Highest. Gold standard; not expected for an entire site and rarely legally required.

The number to remember. When someone says “make the site compliant,” they almost always mean WCAG 2.1 Level AA - which includes all Level A criteria plus all Level AA criteria.

The laws behind the legal notices

WCAG is a technical standard, not a law. The legal force comes from disability civil-rights laws that point to WCAG. Which one applies depends on where you and your customers are.

Law	Where	Applies to
ADA (Americans with Disabilities Act)	USA	The big one for private business. Courts treat the sites of businesses open to the public as covered “places of public accommodation.”
Section 508	USA (federal)	U.S. government agencies and many of their vendors.
State laws (e.g. Unruh Act, CA)	USA (state)	Often added on top of ADA - California and New York are hotspots.
AODA	Ontario, Canada	Provincial accessibility requirements.
European Accessibility Act	EU	Enforced from June 2025; covers e-commerce selling into the EU.
Equality Act 2010	UK	Requires reasonable adjustments for disabled users.

Why the ADA hits online stores. The ADA (1990) predates the web, so it never mentions websites. But U.S. courts have repeatedly ruled that a retailer’s site is an extension of its “public accommodation,” and in 2022 the Department of Justice reaffirmed that the ADA applies to the web. Because the ADA lists no technical spec, courts fill the gap with WCAG 2.1 AA. That combination - broad law plus specific standard - is what plaintiffs use.

Who gets legal notices - and why

This surprises most first-timers. You usually do not get sued because a specific customer complained. A whole legal ecosystem actively looks for non-compliant sites.

Automated scanning. Law firms and plaintiffs run free or commercial scanners (AudioEye is one example) across thousands of sites to flag accessibility errors - missing alt text, unlabeled buttons, keyboard traps.
A demand letter arrives. A formal legal notice (often before any lawsuit) alleging the site violates the ADA, listing example barriers, and asking you to fix them and frequently to pay a settlement.
“Illustrative and not exhaustive.” The letter lists a few barriers but says there are more - so fixing only the named ones is not enough; the whole site must be brought into conformance.
Deadline / settlement pressure. These are usually settled rather than litigated, because fighting costs more than fixing.

Who the targets are. Mostly e-commerce and consumer-facing businesses of every size - not just big brands. Smaller stores are common targets precisely because they are less likely to have remediated and more likely to settle quickly. Industry trackers report 4,000-5,000+ such claims in the U.S. every year, concentrated in New York, California, and Florida courts.

It is rarely personal. If your site has machine-detectable barriers and sells to the public, it can show up in a scan. Keyboard-inaccessible menus, duplicate image alt text, and unannounced form errors are classic, easily-scanned patterns that appear on a large share of stores.

What happens if you ignore it

It escalates. A demand letter can become a filed lawsuit.
Settlements plus legal fees. Even “small” cases commonly settle in the thousands to tens of thousands of dollars, plus your own legal costs.
You still have to fix it. Settlements almost always require the remediation anyway - so ignoring it means paying and fixing.
Repeat exposure. If the site stays non-compliant, a different plaintiff can target it again.

The trap to avoid. Do not panic-install an “accessibility widget” and assume you are covered. As the next section explains, that often makes things worse legally. The reliable response is: get proper legal counsel for the letter, and fix the actual code.

Common accessibility barriers

Here are the issues that show up most often, mapped to the WCAG principle they break.

Barrier	Principle	The fix (in code)
Menus that need a mouse	Operable	Make dropdowns work with Enter/Space/Escape/arrow keys, with a visible focus outline
Images with no / duplicate alt text	Perceivable	Give each meaningful image unique, descriptive alt text; mark decorative ones to be ignored
Errors not announced	Understandable / Robust	Use ARIA live regions / `role="alert"` so screen readers speak the message
Icon buttons with no label	Robust	Add an accessible name via visible text or `aria-label`
Form fields with no label	Understandable	Connect each input to a `<label>` so its purpose is announced
Low color contrast	Perceivable	Ensure text/background contrast meets 4.5:1 (3:1 for large text)
Icon-only / empty links	Operable	Give links descriptive text a screen reader can read

A single automated scan on a typical store routinely flags dozens of these - unnamed SVG icons, unlabeled buttons and fields, vague buttons, empty links - on top of the few barriers a demand letter names by hand.

The overlay-widget myth

You will be tempted by cheap plug-ins (accessiBe, UserWay, AudioEye, EqualWeb) that promise instant compliance with one line of JavaScript. They do not make you compliant, and they can increase your legal risk.

They do not fix the code. An overlay layers scripts on top of the page. Screen readers and keyboards read the underlying source code, which the overlay does not change. The real barriers remain.
Regulators have cracked down. In 2025 the U.S. FTC ordered accessiBe to pay $1,000,000 for deceptive advertising that its widget made sites WCAG-compliant.
They attract lawsuits. In 2025 roughly one in four businesses sued over accessibility already had an overlay installed. Courts have not accepted “we installed a widget” as a defense.

What an overlay can legitimately do. Provide optional display preferences - let a visitor enlarge text, switch to high-contrast, or change fonts. That is a nice convenience, but it is not what brings a site into conformance. The page’s own structure, alt text, keyboard support, and contrast still have to be correct in the code.

How to actually fix a site

Real remediation is a process, not a button. A defensible program has three phases:

Phase	What happens
1 · Audit	Run automated scanners and do manual testing (keyboard-only plus screen reader) on every page type to produce a confirmed, prioritized list of real issues.
2 · Remediate	Fix the issues in the theme’s HTML/CSS/JavaScript: keyboard support, alt text, ARIA, labels, contrast. Priority paths (navigation, product pages, checkout) first.
3 · Validate	Re-test with real assistive technology (NVDA, VoiceOver, keyboard), check for regressions, and write a short conformance report for your records and counsel.

Automated scans are not the whole story. Automated tools reliably catch only about 30-40% of WCAG issues. The keyboard-and-screen-reader manual pass is what proves the site works - and what holds up if challenged. Beware anyone promising “100% compliant” from a scan alone.

Tools you will hear about

Automated testers (find issues fast)

axe DevTools (Deque) - browser extension, industry standard.
WAVE (WebAIM) - visual, beginner-friendly browser extension.
Lighthouse - built into Chrome DevTools; gives an accessibility score.
Pa11y - command-line tool you can run in a build pipeline.
WebAIM Contrast Checker - paste two colors to test the 4.5:1 ratio.

Screen readers (test like a real user)

NVDA - free, Windows. The most common testing screen reader.
VoiceOver - built into macOS and iPhone/iPad (free).
JAWS - Windows, paid; widely used by blind professionals.
TalkBack - built into Android.

Try it yourself in 2 minutes. Open the site and, without touching the mouse, press Tab repeatedly. Can you reach and open every menu, and always see where you are? Then turn on VoiceOver (Mac: Cmd+F5) and try to add a product to the cart. You will feel the barriers immediately.

How to stay compliant after the fix

Conformance is a snapshot in time - it drifts as you add products and change code. Keep it with a light maintenance layer:

Periodic audits: automated scan monthly/quarterly; a manual plus screen-reader audit annually or after any major redesign.
Catch regressions in the build: add an automated check (axe-core / pa11y-ci) so a change that breaks accessibility fails before it ships.
New-product checklist: unique alt text on every image, proper heading order, descriptive link text, labeled options, sufficient contrast on banner text.
Publish an Accessibility Statement page with a contact method - viewed favorably and gives users a path other than a lawsuit.
Vet third-party apps before installing; many re-introduce barriers.
Train whoever adds content with a one-page guideline.

Notes for e-commerce and BigCommerce

Online stores are the most-targeted category because the checkout funnel is where exclusion costs a sale. A few platform-specific realities:

The theme is where most fixes live. On BigCommerce (Stencil), accessibility lives in the theme’s Handlebars templates, SCSS, and JavaScript - not in a setting you can toggle. There is no “make me compliant” switch.
Alt text is partly content work. Product image alt text is usually entered per-image in the store admin, so fixing it is part code (templates) and part content (writing good descriptions).
Checkout matters most. Navigation, product pages, cart, and checkout are the priority paths - a barrier there blocks revenue and is what plaintiffs test first.

How Codinative handles an active demand. We pair this guide with a store-specific audit, a remediation proposal (concrete scope and timeline), and a plain-language Q&A for the client - turning the general picture above into a fix plan for one storefront.

Glossary

Accessibility (a11y): Designing so people with disabilities can use a product. “a11y” = “a” + 11 letters + “y.”
ADA: Americans with Disabilities Act - the U.S. civil-rights law used in most web-accessibility lawsuits.
WCAG: Web Content Accessibility Guidelines - the technical standard (by the W3C) that defines an accessible site.
Level AA: The middle, “target” tier of WCAG that laws and courts require.
POUR: The four WCAG principles: Perceivable, Operable, Understandable, Robust.
Screen reader: Software that reads a page aloud for blind/low-vision users (NVDA, VoiceOver, JAWS).
Alt text: A text description of an image that a screen reader announces.
ARIA: Accessible Rich Internet Applications - extra HTML attributes that tell assistive tech what a custom control is or when something changed.
Overlay / widget: A third-party script claiming to auto-fix accessibility. It does not change the underlying code.
Demand letter: A formal legal notice alleging violations and usually seeking a fix and a settlement.
Remediation: The actual work of fixing accessibility issues in the code.
VPAT: Voluntary Product Accessibility Template - a document reporting how a product conforms to accessibility standards.
Conformance: Meeting a defined set of WCAG success criteria at a chosen level (e.g. conforms to WCAG 2.1 AA).

FAQ

Is there a single setting or app that makes my store compliant?

No. Compliance comes from correct code across the site. Any product promising instant compliance is overstating - that is exactly what the FTC fined accessiBe for.

If the letter lists only 3 problems, can I just fix those 3?

No. These letters say the list is “illustrative and not exhaustive.” You need the whole site brought to WCAG 2.1 AA, which is why a full audit comes first.

Do I really need a lawyer?

For an active demand letter, yes - engage ADA-experienced counsel to handle deadlines and the legal response. Developers fix the site; lawyers handle the claim.

My site looks fine to me. How can it be inaccessible?

Most barriers are invisible to sighted mouse users. They only appear when you navigate by keyboard or listen with a screen reader - which is how disabled users (and the scanners) experience your site.

How long does fixing it take?

For a typical custom store, a few weeks of focused development plus testing. The exact scope depends on the audit.

Once fixed, am I done forever?

No - every new product or code change can introduce new issues. That is why ongoing checks and a launch checklist matter.

Sources and further reading

W3C WAI - Introduction to Web Accessibility (the official starting point)
WebAIM - Introduction to Web Accessibility
W3C WAI - WCAG Overview
WCAG Quick Reference (filtered to 2.1) - the full, testable checklist
ADA.gov - Guidance on Web Accessibility and the ADA (U.S. DOJ)
Section508.gov - U.S. federal accessibility law and resources
W3C WAI - Web Accessibility Laws and Policies worldwide
Deque axe DevTools · WAVE · NVDA · WebAIM Contrast Checker
BigCommerce - WCAG compliance levels for Stencil themes

Disclaimer. This is an educational, plain-language overview prepared by Codinative. It explains technical concepts and general industry practice - it is not legal advice. Laws vary by jurisdiction and change over time. For any specific legal demand, deadline, or risk question, consult a qualified attorney experienced in ADA / accessibility law.