What WCAG is and where it comes from
WCAG stands for Web Content Accessibility Guidelines. It is published by the World Wide Web Consortium (W3C), the organization that maintains the HTML and CSS standards underlying every website on the internet. The W3C's Web Accessibility Initiative (WAI) develops and maintains WCAG through collaboration between disability advocates, assistive technology vendors, government bodies, and web developers.
WCAG is a technical standard incorporated into laws, not itself regulation. DOJ's 2022 ADA guidance references it without binding private-business standards. The 2024 Title II rule adopts WCAG 2.1 Level AA for state/local government. EU EN 301 549 incorporates WCAG 2.1 Level AA; federal Section 508 references WCAG 2.0 Level AA.
Three levels: A removes critical barriers; AA supports most disabled users; AAA adds often impractical universal enhancements. AA is the practical legal target, tested by auditors, cited in ADA cases, and identified by DOJ as the compliance floor.
WCAG addresses visual (blindness, low vision, color blindness), hearing, motor/mouse-use, and cognitive/learning disabilities. CDC estimates 61 million disabled American adults. Coverage spans permanent blindness to situational barriers, like six weeks of keyboard navigation with a broken arm.
Accessibility expands customers while reducing failed visits: screen-reader-incompatible forms, untappable phone numbers, and textless PDF menus exclude users. Business benefits accompany legal ones.
WCAG 2.0, 2.1, and 2.2: what changed in each version
The standard has gone through three major versions since 2008, each adding requirements that the previous version did not address. Understanding which version is being referenced matters because auditors, lawsuits, and government standards cite specific version numbers, and the differences between versions are substantive, not cosmetic.
Established the original framework across four principles. Still referenced by Section 508 and older procurement standards.
61 success criteriaMobile accessibility, cognitive disabilities, and low vision. Most ADA lawsuits reference this version's Level AA standard as of 2026.
+17 success criteriaPrimarily keyboard navigation and cognitive accessibility. Building to 2.2 is better practice and future-proofs the site.
+9 success criteriaWCAG 2.0 (2008): 61 criteria across Perceivable, Operable, Understandable, Robust. Includes alt text, captions, keyboards, contrast, labels, and semantic code. Section 508/older procurement cite 2.0 AA; backward-compatible WCAG 2.1 AA satisfies those requirements because 2.1 includes 2.0.
WCAG 2.1 (2018) adds 17 criteria beyond 2.0 for mobile, cognition, and low vision: Reflow (1.4.10), no horizontal scrolling at 320px; Non-text Contrast (1.4.11), UI borders/backgrounds; Text Spacing (1.4.12), readable spacing overrides; Content on Hover or Focus (1.4.13), tooltips/popups; Pointer Gestures (2.5.1), multipoint alternatives. Most ADA suits cite this version's AA in 2026.
WCAG 2.2 (2023) adds 9 keyboard/cognitive criteria, notably Focus Appearance (2.4.11), minimum indicator size/contrast; Target Size (Minimum) (2.5.8), 24x24 pixels; Accessible Authentication (Minimum) (3.3.8), restricting cognitive tests/CAPTCHAs. WCAG 2.2 removes 4.1.1 (Parsing), confusing given robust modern-browser parsing.
Rule of thumb
The practical recommendation: audit and build to WCAG 2.2 Level AA where feasible. The additional criteria in 2.2 are substantively important for keyboard users and people with cognitive disabilities, and building to 2.2 now avoids having to retrofit the gap later as more standards catch up to the newer version.
The four POUR principles: what they require in practice
Every WCAG success criterion belongs to one of four principles: Perceivable, Operable, Understandable, and Robust, commonly abbreviated as POUR. The principles form the framework; the success criteria are the specific, testable requirements within them. Here's what each principle requires in concrete, testable terms for a typical small business website.
Content must be perceivable: meaningful-image alt text, accurate video captions, audio transcripts, and non-color indicators. Contrast: 4.5:1 normal text, 3:1 above 18pt/14pt bold, 3:1 UI borders/states. Text-spacing overrides must work; hover/focus content must be dismissible, persistent, and hoverable.
All links, buttons, fields, dropdowns, modals, tabs, accordions, and carousels must work by keyboard: Tab/Shift+Tab move, Enter/Space activate, Escape closes, arrows navigate components. No keyboard traps or flashes above three per second. Timed sessions/forms need warning/extensions; skip links bypass repeated navigation for keyboard/screen-reader users.
Predictable, understandable content needs declared language for pronunciation, consistent navigation/structure, persistent labels rather than disappearing placeholders, field-specific errors explaining correct formats, and marked required fields. Navigation, submission, or focus changes require user intention.
Current/future assistive technologies need semantic structure: actual headings, lists, keyboard-operable buttons, and labels connected to fields. Correct code works reliably across screen-reader/browser combinations; scripted generic containers produce inconsistent, broken experiences.
Common failures that show up in ADA demand letters
ADA demand letters identify page-specific WCAG violations. Plaintiffs' firms scan thousands of sites and send templates. Reliably machine-detected failures recur most often and create disproportionate legal exposure.
Missing/inadequate image descriptions are the most common ADA violation and reliably detected. Meaningful images need spoken descriptions; linked images need destination descriptions; decorative images must be skipped. Missing text, generic "image/photo," raw-URL linked images, and charts/infographics without equivalents trigger letters.
Low contrast. AA requires 4.5:1 normal text; 3:1 large text (18pt/14pt bold) and UI. Common failures: gray-on-white templates, pale button text, faint placeholders, and varying backgrounds beneath transparent image overlays.
Unlabeled forms. Disappearing placeholder hints fail AA. Every text field, dropdown, and comment box needs a persistent, programmatically connected label. Required indicators cannot rely on color alone; errors must connect to the affected field so screen-reader users can correct it.
Uncaptioned video. WCAG 1.2.2 requires accurate synchronized prerecorded captions, including meaningful sound cues. YouTube/Vimeo auto-captions need review for names, technical terms, and overlapping dialogue; they're only a starting point.
JavaScript keyboard failures: hover-only menus, trapped/nonreturning modal focus, mouse-only tabs, and inaccessible carousels/date pickers fail WCAG 2.1.1 (Keyboard) and 2.1.2 (No Keyboard Trap). Automation catches some; reliably audit by operating every element across the entire site without a mouse.
Missing skip links. WCAG 2.4.1, Level A, requires bypassing repeated content. Without top-of-page "Skip to main content," keyboard/screen-reader users traverse every menu on every page. Many small sites omit this basic requirement.
You received a demand letter: what to do first
Demand letters aren't lawsuits: plaintiffs' attorneys allege ADA barriers and propose pre-complaint settlement, often allowing 14–30 days deliberately to create pressure. First-week actions affect costs and repeat letters next year.
The sequence below is the practical order of operations. It is general information about how these matters commonly proceed, not legal advice, and none of it replaces an attorney who handles ADA Title III defense.
-
Preserve the site exactly as it is before any fix
Before edits, preserve every cited page with full screenshots, underlying code, and timestamped scans recording the cited-date condition. Immediate fixes destroy evidence relevant to inaccurate or nonexistent allegations. Preserve first, then remediate.
-
Get counsel before you respond days 1–3
Don't contact, deny, or negotiate with the sender yourself. ADA Title III counsel knows firms, serial-filing patterns, and local resolutions. Notify liability/cyber insurers concurrently; some cover defense, and late notice can forfeit coverage.
-
Verify every claim against the pages cited
Category-wide automated templates may cite nonexistent pages, inapplicable criteria, or previously fixed problems, or be entirely accurate. Independently audit named URLs with automation, keyboard, and screen-reader testing before discussing settlement amounts.
-
Remediate regardless of what the letter got wrong
Whatever a letter's accuracy, genuine barriers remain exposure. Remediation strengthens negotiation, reduces repeat-letter risk, and supplies the requested outcome. Small-site fixes commonly cost a fraction of settlement and leave a defensible site after a one-time expense.
-
Document the remediation with dates
Date audits, findings, fixes/launched changes, and verification. Update accessibility statements with target, audit date, limitations, and barrier contact. Dated evidence carries more negotiating weight than assurances.
-
Expect the ask to be money plus a commitment five figures, generally
Most letters resolve through payment and scheduled remediation, sometimes monitoring. Public reports describe five figures before legal fees, with wide variation unsuitable as individual benchmarks. Remediation commitments bind; scope accurately before signing deadlines to avoid creating another problem.
What makes the situation worse:
- Ignoring the letter. Non-response is the most direct route from a demand letter to a filed complaint, and the cost climbs from there.
- Installing an overlay widget in a panic. It does not fix the cited violations, and its presence has been used in litigation as evidence that the business knew about the problem and bought a badge instead of a fix.
- Taking the site offline. Pulling a public-facing site down does not resolve the claim, and it costs you whatever business the site was generating in the meantime.
- Replying to the sending firm to argue the claims are wrong. Even when you are right on the facts, you are negotiating against a specialist without one of your own.
- Quietly fixing everything and saying nothing. Undocumented fixes are difficult to prove after the fact, and silence still reads as non-response.
If the deadline is close
A short response window does not require you to have the whole site remediated by the deadline. It requires a response, from counsel, that engages with the claim. Preserve the evidence, engage an attorney, and get the audit started in parallel so the remediation scope and timeline are known facts by the time anyone negotiates a schedule.
If you have a letter in hand and need the technical side handled on a compressed timeline: audit, remediation, and a written compliance report →
What automated tools catch and what they miss
Automated accessibility testing tools (axe-core, WAVE, Lighthouse's accessibility audit, Deque WorldSpace, Tenon) are valuable for establishing a baseline and finding violations that pattern-matching can reliably detect. Understanding their actual coverage and what they categorically cannot test is critical for understanding why a credible accessibility audit cannot stop at a tool report.
Research puts automated AA detection at 25%–40%, varying by tool, complexity, and failure type. WebAIM Million tests top-million pages and consistently finds more detectable failures with complex, interactive content, partly reflecting tools' uneven strengths.
What automation catches reliably:
- Images with no written description at all (though not whether the description is meaningful or accurate).
- Text-and-background color combinations that don't have enough contrast.
- Missing or duplicate page titles.
- Pages that never declare what language they're in (which makes screen readers mispronounce everything).
- Accessibility labels applied incorrectly in the code.
- Form fields with no label connected to them.
- Missing heading structure.
- Keyboard outlines that the design has deliberately hidden.
What automation cannot test:
- Whether an image description is meaningful ("photo of Dr. Smith in the clinic" vs. just "photo").
- Whether the keyboard moves through the page in a sensible order.
- Whether a custom dropdown menu responds to the arrow keys.
- Whether a popup window hands keyboard focus back where it belongs when it's closed.
- Whether a page that looks like it has a clear heading structure conveys that structure to a screen reader.
- Whether the order a screen reader reads things in still makes sense without the visual layout.
- Whether an error message is connected to the right field.
- Whether someone can navigate the whole page start to finish using only a keyboard.
Automation covers only 25–40%; the other 60–75% needs manual testing for legal defensibility: keyboard, NVDA/Windows, VoiceOver/Mac/iOS, and TalkBack/Android. Full audit and remediation →
Why accessibility overlay widgets make things worse
Accessibility overlay widgets are browser-side JavaScript products sold by companies like AccessiBe, UserWay, AudioEye, EqualWeb, and others. The pitch is consistent: add one line of script to your site, and the overlay fixes accessibility issues automatically, making your site WCAG compliant without code-level changes. The pitch is false in a specific, documentable way.
Post-load browser overlays adjust surface features: variable-quality generated alt text, some contrast, larger fonts. They cannot supply missing structure, keyboard-operable widgets, correct popup focus, or human-quality complex-image descriptions. Source accessibility remains unfixed.
Hundreds of disabled users/professionals signed #OverlayFact Sheet documenting screen-reader conflicts, sometimes making partially usable pages unusable. Overlays can override personalized browser/assistive settings without an opt-out.
AccessiBe/similar users have faced ADA settlements/judgments finding overlays insufficient, sometimes worsening plaintiffs' experience. After a demand letter, purchasing an overlay can weaken negotiation by demonstrating awareness without code-level remediation.
Overlays cost $50–$500 monthly. Small-site audits/code remediation cost once, with much smaller ongoing accessibility maintenance. Overlays therefore cost more, achieve less, and create rather than reduce legal exposure.
PDF accessibility: the overlooked gap in most remediations
PDFs are small sites' most overlooked accessibility gap and major screen-reader obstacle. Web structure enables navigation; untagged PDFs act like flat images, without headings, reading order, accessible fields, or table structure. Content becomes inaccessible throughout.
The types of PDFs most commonly found on small business sites: restaurant menus and price lists, service brochures and capability statements, intake forms and appointment request forms, terms and conditions documents, and certificates or awards. Any PDF with meaningful content that a visitor might need to read and understand needs to be accessible.
Accessible PDFs require Properties title, language, and tag trees: paragraphs, H1–H6 headings, lists, tables with header rows, figures with alt text, and decorative artifacts. Reading order must match visuals, completing columns sequentially. Forms need accessible names/tooltips.
Word, InDesign, Illustrator, and design-tool exports depend on source structure/settings. Styled Word headings plus accessible export produce reasonable tags. Unstructured InDesign graphics require complete manual Acrobat Pro remediation.
HTML menus/service lists are more accessible, faster, easier to index/rank than PDFs, and editable without regenerating/uploads. Retain properly tagged PDFs when needed for formatted printing or fillable print-and-sign forms. Habit/convenience alone favors converting to HTML.
One-time fix vs. ongoing compliance
A one-time remediation fixes the accessibility failures that exist on the site at the time of the audit. It does not prevent new failures from being introduced as the site is updated. This distinction matters because the most common pattern for accessibility regression on small business sites is not a system failure but normal content management.
Drift sources: images without alt text, incorrect new-page headings, unlabeled forms, inaccessible chat/booking/review widgets, and library/plugin carousels, FAQs, or lightboxes lacking keyboard tests.
Largely static five-page sites commonly need re-audits every 12–18 months. Review significant additions immediately; scheduled checks catch low-risk accumulated drift.
Regular menus, project photos, and blog updates warrant ongoing review. Add prepublication accessibility checks to maintenance, catching problems before accumulation or plaintiffs' automated scans.
WCAG doesn't require statements, but they're legally relevant good practice. Document WCAG 2.2 Level AA target, audit date, limitations/remediation schedule, and barrier-reporting contact. Current statements with response routes demonstrate ongoing good faith recognized differently in courts/settlement discussions.
The practical approach for most small business sites: do the full remediation, ensure ongoing site updates go through a basic accessibility check before publishing, run a periodic re-audit on schedule, and maintain an accessibility statement with contact email. This keeps the site defensible without requiring permanent compliance overhead disproportionate to the site's size.
Website maintenance plans that include accessibility monitoring →
Key takeaways
- WCAG 2.2 Level AA is the current practical conformance target for US small business websites. DOJ guidance points to WCAG as the reference standard, though it has not adopted a binding technical standard for private businesses.
- The four POUR principles (Perceivable, Operable, Understandable, Robust) structure all 86 WCAG 2.2 success criteria. Missing image descriptions, insufficient color contrast, unlabeled forms, and keyboard navigation failures are the most common violations found in demand letters.
- Automated tools catch 25–40% of WCAG failures. Manual keyboard testing and screen reader testing are required to find the rest. An audit that stops at an automated scan leaves the majority of violations in place.
- Accessibility overlay widgets (AccessiBe, UserWay, etc.) are not a compliance solution. They cannot fix accessibility at the code level, they degrade the experience of screen reader users, and they appear in lawsuits as evidence of non-compliance rather than a defense.
- PDFs on your website require their own accessibility remediation. An untagged PDF exported from Word or a design tool is effectively inaccessible to screen readers. For menus and service lists, converting to HTML is often the better solution.
- A one-time remediation addresses current failures but does not prevent new ones. Some form of ongoing accessibility review, built into the content publishing process or the maintenance plan, keeps the site defensible as it grows.
- An accessibility statement with your conformance target, last audit date, known limitations, and a contact mechanism demonstrates ongoing good-faith effort and is relevant in any legal context.
Accessibility and WCAG questions
Does my small business website legally have to be WCAG compliant?
Courts increasingly apply ADA to commercial/public-facing websites. As of 2026 no federal rule mandates WCAG for all commercial sites; DOJ's 2022 guidance confirms ADA coverage but references WCAG without binding private-business technical standards. Automated category scans generate demand letters. Publicly reported five-figure settlements vary widely, exclude legal fees, and aren't case benchmarks. Remediation costs a fraction; WCAG 2.2 Level AA is a practical target.
I received an ADA demand letter. Should I fix my site before I respond?
Preserve cited pages' screenshots, code, and timestamped scans before edits; inaccurate claims make original evidence important. Engage ADA Title III counsel before replying and notify liability/cyber insurers; late notice may forfeit covered defense. Then fix genuine barriers, strengthening negotiation and reducing repeat letters. One-time remediation contrasts with commonly cited $10,000–$50,000 settlements before fees. Date every fix. Avoid overlays: litigation has treated them as awareness without repair.
What's the difference between WCAG 2.0, 2.1, and 2.2?
WCAG 2.0 (2008): 61 criteria. WCAG 2.1 (2018): 17 additions for mobile, cognition, low vision, including reflow, UI contrast, hover/focus, spacing. WCAG 2.2 (2023): 9 additions emphasizing focus, targets, authentication. Most 2026 ADA suits cite WCAG 2.1 AA, the common regulatory floor; WCAG 2.2 is better practice. Backward-compatible 2.2 AA satisfies 2.1 AA/2.0 AA requirements.
Can an accessibility overlay widget make my site compliant?
No. AccessiBe, UserWay, AudioEye, and similar post-render toolbars cannot fix source structure, keyboard behavior, or modal focus. The National Federation of the Blind, American Council of the Blind, and hundreds of screen-reader users document harm. ADA suits cite overlays as noncompliance evidence. Over 12–24 months, subscriptions commonly exceed effective one-time code remediation costs.
What does automated accessibility testing catch?
axe, WAVE, and Lighthouse cover roughly 25–40%: missing alt text, contrast, language declarations, invalid accessibility labels, and unlabeled fields. They cannot assess meaningful descriptions, logical keyboard order, custom-widget keyboard behavior, restored popup focus, or sensible screen-reader order. Generic "photo" can pass automation while failing WCAG. Automation-only audits still cover just 25–40%.
How long does an accessibility remediation take?
For 5–15 pages, allow 3–7 business days: automated audit, manual keyboard/NVDA/VoiceOver tests, all code fixes, and written compliance report. Audits take 1–2 days. Alt text/labels are quicker than pervasive keyboard or third-party-widget problems. Disclose ADA deadlines during intake for appropriate scoping/sequencing.
Do PDFs on my website need to be accessible?
Meaningful PDFs need tags for headings, paragraphs, order, image descriptions, and table headers. Common examples: menus/prices, brochures, intake forms, terms. Acrobat Pro remediation sets titles, tags, column-aware reading order, alt text, and fields. Menus/services without print/fillable needs often suit HTML better: accessible, faster, and search-indexable.
Does accessibility remediation affect how my website looks?
Usually appearance stays unchanged: alt text, labels, keyboard order, and skip links primarily help assistive users. Contrast fixes (4.5:1 normal; 3:1 large/UI) may darken text/buttons. Visual changes require review/approval first; most sites look identical.