Research Complete

ADA Web Accessibility Compliance

research complete

Created 2026-03-12Updated 2026-03-13

Plan

Report

Spec

Disclosure

Research Brief

ADA Web Accessibility Compliance -- Research Brief

Topic: ada-compliance Last Updated: 2026-03-12

1. WHO Must Comply

The Short Answer

Almost everyone. If you have a website and operate any kind of business, organization, or government entity, you are very likely subject to ADA web accessibility requirements. The only clear exemptions are religious organizations, bona fide private clubs, and purely personal non-commercial websites.

1.1 Government Entities (ADA Title II)

ALL state and local government entities, including:

State governments and all agencies, departments, instrumentalities
Local governments: cities, towns, counties, townships, villages
Special district governments -- explicitly named in the DOJ's April 2024 final rule: water districts, sewer districts, irrigation districts, MUDs, transit authorities, hospital districts, library districts, fire protection districts, park districts
Public universities and colleges
Public K-12 school districts
Public housing authorities
Any entity receiving federal financial assistance (via Section 504)

Texas alone has 3,200+ special districts that must comply.

The organization is liable, not individual employees -- but marketing staff, web devs, and content creators are the ones whose work determines compliance. You cannot contract away liability -- if a vendor builds your website, you are still liable.

1.2 Private Businesses (ADA Title III)

Title III applies to private entities that operate "places of public accommodation." The statute defines 12 categories -- and the examples within each are illustrative, not exhaustive:

| # | Category | Statutory Examples | Also Covered | |---|----------|-------------------|--------------| | 1 | Places of lodging | Hotels, motels, inns (5+ rooms) | B&Bs, vacation rentals, hostels | | 2 | Food or drink | Restaurants, bars | Cafes, breweries, wineries with tasting rooms | | 3 | Exhibition / entertainment | Theaters, concert halls, stadiums | Streaming services (with physical presence) | | 4 | Public gathering | Auditoriums, convention centers | Conference facilities, co-working spaces | | 5 | Sales / rental | Grocery stores, shopping centers | E-commerce with brick-and-mortar, car dealers, nurseries/garden centers | | 6 | Service establishments | Banks, lawyers, accountants, barbers, pharmacies, health care providers, gas stations | Landscaping companies, plumbers, electricians, contractors, marketing agencies, financial advisors, real estate agencies, IT services, veterinary clinics | | 7 | Transportation | Bus stations, train depots | Ferry terminals, light rail | | 8 | Public display | Museums, libraries, galleries | Botanical gardens, aquariums | | 9 | Recreation | Parks, zoos, amusement parks | Water parks, campgrounds | | 10 | Education | Private schools, colleges | Trade schools, tutoring centers, online learning (with physical presence) | | 11 | Social services | Day care, senior centers, shelters | Nonprofits, community health centers | | 12 | Exercise / recreation | Gyms, health spas, golf courses | Yoga studios, swimming pools, ski resorts |

Critical facts about Title III coverage:

No minimum employee count. The 15-employee threshold in Title I applies only to employment discrimination -- not to public accommodation requirements.
No minimum revenue threshold. A sole proprietor with a website is covered if they operate a place of public accommodation.
No small business exemption. The "readily achievable" standard adjusts the scope of required changes based on resources, but does not eliminate the obligation.
77% of ADA web lawsuits target companies under $25M revenue. Businesses under $500K revenue are the most frequently sued.

1.3 Does a Business Need a Physical Location?

This depends on the federal circuit, but the trend is toward broader coverage:

| Approach | Circuits | Key States | Position | |----------|----------|------------|----------| | Broad (websites ARE public accommodations) | 1st, 2nd, 7th | NY, MA, CT, IL, WI, IN | Website-only businesses covered | | Nexus (website must connect to physical place) | 3rd, 6th, 9th | PA, NJ, CA, OR, WA, MI, OH | Physical presence + website = covered | | Narrow (websites are NOT public accommodations) | 11th | FL, GA, AL | Only physical places covered |

Bottom line: If your business has any physical presence -- an office, storefront, warehouse, even a service vehicle that goes to customer locations -- your website is covered in virtually every jurisdiction. Even website-only businesses are covered in most of the country, and state laws (California Unruh Act, New York Human Rights Law) fill the remaining gaps.

1.4 Specific Business Types

Landscaping companies, contractors, plumbers, electricians: Category 6 (Service Establishments). If you have a website where customers can request quotes or schedule services, you're covered.

E-commerce: The primary target of ADA litigation -- 77% of all web accessibility lawsuits in 2024-2025. E-commerce connected to physical stores is covered in all circuits. Pure e-commerce is covered in most.

SaaS companies: Covered through marketing websites (public-facing), application interfaces (when used by covered entities), government procurement requirements (Section 508), and contractual indemnification.

Professional services (law firms, accountants, agencies): Explicitly listed in Category 6. Unambiguously covered.

Healthcare providers: Explicitly covered under Category 6 and face additional obligations under Section 504 if accepting Medicare/Medicaid.

Banks and financial institutions: Explicitly listed in Category 6. Online banking portals, loan applications, account management are all covered.

B2B companies: Public-facing content (marketing site, blog, resources) is covered. Government clients trigger Section 508. State laws (especially California Unruh) apply regardless of the public accommodation framework.

1.5 Nonprofits and Associations

Nonprofits are covered if they operate public accommodations -- and most do. Hospitals (Cat. 6), museums (Cat. 8), schools (Cat. 10), social service centers (Cat. 11) are all explicitly listed.

Trade associations (like AWE itself) are covered if they host conferences (Cat. 4), sell publications (Cat. 5), or provide educational programs (Cat. 10).

1.6 Exemptions -- Very Narrow

| Entity | Exempt? | Caveat | |--------|---------|--------| | Religious organizations | Yes (Title III) | Section 504 applies if receiving federal funds | | Bona fide private clubs | Yes (Title III) | Lost if events/facilities open to public | | Personal non-commercial websites | Yes | No business activity | | International companies serving U.S. customers | No | ADA applies; NY courts accept cases from any website visited by a NY resident | | Small businesses | No | No size threshold | | B2B-only companies | Mostly no | Public-facing content covered; state laws apply broadly |

1.7 Individual Liability

Individuals generally cannot be sued under federal ADA law -- liability attaches to the organization
Marketing teams, social media managers, web developers: the organization is liable, not the person
Web developers face contract-based exposure (breach of contract, indemnification) and California Unruh Act risk
Vendors who build inaccessible websites for clients face contractual claims and loss of contracts, not direct ADA liability
Content creators: personal non-commercial content is not covered; monetized platforms may be

1.8 Section 508 -- Federal Agencies and Contractors

All federal agencies must make ICT accessible
Federal contractors developing ICT must meet Revised 508 Standards (incorporating WCAG 2.0 AA)
FAR Subpart 39.2 requires ICT acquisitions to meet Section 508

1.9 State Laws That Expand Coverage

| State | Law | Key Feature | |-------|-----|-------------| | California | Unruh Civil Rights Act | $4,000 minimum per violation per visit; covers any "business activity"; no physical location required | | New York | Human Rights Law | Broader discrimination definition; damages + attorney fees; accepts cases from any website visited by NY resident | | Colorado | HB-21-1110 | Specific digital accessibility requirements | | Illinois | Human Rights Act / BIPA | 745% increase in filings in 2025 |

85% of ADA web accessibility lawsuits are filed in California, New York, and Florida.

2. WHAT -- The Spec (WCAG 2.1 Level AA)

The Required Standard: WCAG 2.1 Level AA -- 50 success criteria total (30 Level A + 20 Level AA)

Four Principles (POUR)

| Principle | Key Requirements | |-----------|-----------------| | Perceivable | Alt text on images, captions on video, 4.5:1 color contrast ratio for text, content adaptable to different presentations | | Operable | All functionality via keyboard, no keyboard traps, enough time to interact, no seizure-inducing flashing, skip navigation | | Understandable | Language declared, predictable navigation, error identification and suggestions on forms | | Robust | Proper HTML semantics, ARIA used correctly, works with assistive tech |

Key Contrast Ratios

| Element | Required Ratio | |---------|---------------| | Normal text (under 18pt) | 4.5:1 | | Large text (18pt+ or 14pt+ bold) | 3:1 | | UI components / graphics | 3:1 |

How Bad Is It? (WebAIM Million 2025)

94.8% of top 1M homepages had WCAG failures
Average 51 errors per homepage
Top violations: low contrast (79%), missing alt text (19%), missing form labels, empty links, empty buttons, missing document language

3. WHEN -- Deadlines

| Entity | Deadline | |--------|----------| | Large state/local govt (50K+ pop) | April 24, 2026 | | Small state/local govt (under 50K) | April 26, 2027 | | Special districts (water, sewer, etc.) -- any size | April 26, 2027 | | Private businesses (Title III) | No formal deadline -- but lawsuits are happening now |

Special districts receive the 2027 deadline because the Census Bureau does not calculate populations for special districts.

Regulatory uncertainty note: In Feb 2026, the Trump DOJ submitted an Interim Final Rule to OIRA -- changes unknown but deadlines are currently still in effect. A Louisiana judge already ruled the ADA requires web accessibility even before these deadlines.

4. WHERE -- What Digital Content Is Covered

Covered

Websites and all pages
Mobile apps
Online bill-pay portals
Online forms (service requests, complaints, account signup)
PDFs and documents posted online (rate schedules, meeting minutes, CCRs)
Video content (board meetings, instructional videos)
Email newsletters
Social media posts (made after compliance deadline)

Exceptions (Narrow)

Archived web content (in a designated archive, pre-deadline, not updated)
Preexisting PDFs/docs -- UNLESS currently used to access services
Third-party content from unaffiliated parties (NOT contractors/vendors)
Individualized password-protected documents
Pre-deadline social media posts

Even with exceptions, you must provide accessible alternatives upon request.

5. WHY -- Carrot & Stick

The Carrot

26% of U.S. adults have some form of disability (44.1M people)
Accessible sites get better SEO (proper headings, alt text, semantic HTML = better Google ranking)
Better UX for everyone -- captions in noisy rooms, high contrast in sunlight, keyboard nav for power users
"Curb-cut effect" -- accessibility improvements help far more people than just those with disabilities

The Stick

| Penalty | Amount | |---------|--------| | First violation (Title II) | Up to $150,000 | | Subsequent violations | Up to $230,464 | | CA Unruh Act | $4,000 per violation per visit |

Lawsuit Trends

5,100+ federal ADA web lawsuits in 2025 (20% increase over 2024, 37% increase in H1)
Average settlement rose from $4,000 (2019) to $39,000 (2022)
Larger settlements: Target ($6M), Fashion Nova ($5M), Harvard ($1.575M in attorney fees alone)
142+ municipalities sued since 2011
~6% of special districts have already received fines/demand letters/DOJ complaints
Most district insurance pools do NOT cover website ADA claims

Serial Litigation -- The Business Model

ADA web lawsuits are heavily concentrated:

31 plaintiffs and 16 law firms drive 50% of all lawsuits
Those 16 firms account for 90%+ of all cases
One individual (Nelson Fernandez) filed 312 lawsuits since 2022
25% of 2024 lawsuits cited accessibility overlays as barriers -- overlays attract litigation

Notable Cases

| Case | Significance | |------|-------------| | NFB v. Target (2006-08) | $6M settlement; established retail websites are covered | | Robles v. Domino's (2016-22) | Supreme Court declined to hear appeal; websites of businesses with physical locations must be accessible | | Gil v. Winn-Dixie (2017-22) | 11th Circuit reversed trial court; websites are not public accommodations (deepened circuit split) | | NAD v. Netflix (2012) | Streaming services covered; Netflix agreed to caption 100% of content | | NAD v. Harvard/MIT (2015-20) | Consent decrees for inaccessible course materials; Harvard paid $1.575M in attorney fees | | Fashion Nova (2023-24) | $5M settlement for web accessibility violations |

Water District-Relevant DOJ Actions

Champaign-Urbana Mass Transit District -- $100K+ remediation
Four Texas counties -- settlement for inaccessible election sites
State of Alaska -- letter of findings for inaccessible elections website
222 settlement agreements with 207 localities nationwide (Project Civic Access)

6. SCORING & ENFORCEMENT -- Is It All-or-Nothing?

Conformance Is Technically Binary

WCAG 2.1 conformance is pass/fail at the page level. Fail one success criterion on a page and that page does not conform. There is no partial credit, no percentage score, no "mostly compliant."

However, the legal reality is more nuanced than the technical standard.

Future direction: WCAG 3.0 (in development) will shift to a graduated 0-4 scoring model with Bronze/Silver/Gold conformance levels. Not yet finalized or adopted by any law.

Can You Be Sued for a Single Violation?

Yes, legally. But in practice:

Lawsuits almost always allege multiple barriers (stronger case, more settlement leverage)
Single-violation claims are susceptible to dismissal on standing grounds (plaintiff must show they were personally harmed)
A single barrier to a core government service (e.g., inaccessible bill pay) is far more legally dangerous than a missing alt text on a decorative image
Serial litigants and "tester" plaintiffs look for sites with patterns of violations -- they're volume-fishing, not targeting one-off issues

How Courts and DOJ Evaluate Compliance

| Factor | Weight | |--------|--------| | Number and severity of violations | High | | Whether core services are blocked | Very high | | Documented accessibility program (policies, training, audits) | Significant mitigator | | Remediation timeline and progress | Significant mitigator | | Responsiveness to complaints | Matters | | Whether violations are pattern vs. isolated | Matters |

Good Faith Effort

Good faith is NOT a legal defense -- the DOJ has explicitly said it will not excuse noncompliance. However, it shapes outcomes dramatically:

Entities with documented accessibility programs get case dismissals, reduced settlements, and shorter compliance timelines
The key is documentation: written policy, regular audits, staff training records, remediation plans with deadlines, a designated accessibility coordinator
Think of it like OSHA -- having a safety program doesn't prevent a violation, but it affects whether you get a warning or a six-figure fine

Building a Documented Good Faith Effort

Adopt a formal accessibility policy
Conduct regular accessibility audits (at least annually)
Create and execute a remediation plan with specific timelines
Train staff who create web content
Publish an accessibility statement with a contact method for reporting issues
Respond promptly to accommodation requests
Budget for accessibility as a recurring line item
Track and document all of the above

Safe Harbor

There is no formal safe harbor for web accessibility under the ADA. Congressional bills have been proposed but none enacted. The best protection is proactive conformance plus documentation.

Conformance vs. Compliance

| Term | Meaning | |------|---------| | Conformance | W3C technical term -- does the page meet all WCAG criteria at the specified level? | | Compliance | Legal term -- are you meeting the law's requirements? |

WCAG conformance supports but does not guarantee legal compliance. Courts care about whether people with disabilities can actually access your services -- not just whether your HTML passes a validator.

How Plaintiff Attorneys Build Cases

Automated scanning -- run scanners across target websites looking for common violations
Tester visit -- a plaintiff with a disability attempts to use the site and documents barriers
Demand letter -- citing specific violations, threatening litigation
Filing -- if no settlement, lawsuit alleging multiple barriers

Practical Guidance

Prioritize core services -- bill pay, account management, emergency alerts, public records
Fix high-severity issues first -- blocked keyboard access, missing form labels, no captions on video
Document everything -- your plan, your audits, your fixes, your training
Don't aim for perfection, aim for progress with documentation -- but know that the legal standard is full conformance

7. TOOLS

7.1 WAVE (WebAIM)

Free browser extension that overlays accessibility findings directly on the page with color-coded icons.

| Icon Color | Meaning | |---|---| | Red | Errors -- must fix (WCAG violations) | | Yellow | Alerts -- review needed (potential issues) | | Green | Features -- good (accessibility features present) | | Blue | Structural -- headings, landmarks, ARIA roles | | Purple | Contrast -- contrast ratio failures |

Free browser extension (Chrome, Firefox, Edge)
Tests one page at a time
Data stays in browser (no server upload -- safe for login-protected pages)
Limitation: Automated tools catch only ~30-40% of issues

7.2 AI Tools

Basic AI Chat (Claude, ChatGPT):

Paste code snippets, ask for WCAG evaluation -- works well for focused checks
Generate accessible HTML patterns from scratch
Explain requirements in plain language
Cannot crawl/browse your site or test interactive behaviors

Specialized AI Tools:

axe DevTools Pro -- AI auto-remediation, NLP-based labeling, $40-45/mo
AccessiMind -- VS Code extension, real-time WCAG 2.2 analysis
AccessLint -- Claude integration for development workflows

Comparison:

| Approach | Best For | WCAG Coverage | |----------|----------|---------------| | AI Chat | Explaining, reviewing snippets, generating fixes | Depends on prompt quality | | Specialized AI Tool | Developer workflow integration | ~57% automated detection | | Automated Pipeline (CI/CD) | Preventing regressions at scale | Systematic but still ~57% |

7.3 Video Editing Tools

Descript:

AI-powered auto-captioning with ~95% accuracy on clear audio (drops to 85-92% with background noise, accents, or overlapping speakers)
Exports SRT, VTT, ASS, SSA, SUB caption formats
Can burn captions directly into video or export as sidecar files
⚠️ Auto-captions alone do NOT satisfy WCAG 2.1 AA SC 1.2.2 -- the FCC benchmark is 99% accuracy (~1 error per 100 words). Descript's ~95% gives ~1 error per 20 words. Auto-captions are a starting point that always requires human review.
Does NOT generate audio descriptions, sound effect labels, or perform WCAG conformance checking

Practical workflow with Descript:

Generate auto-captions (gets you 60-80% of the way)
Human review and correction -- mandatory
Add non-speech audio descriptions ("[water flowing]", "[audience applause]")
Add speaker identification ("BOARD CHAIR:", "PUBLIC COMMENTER:")
Verify synchronization timing
Export as SRT or VTT

Professional hybrid services (AI + human = compliance-ready):

| Service | Accuracy | Cost | Audio Description | |---------|----------|------|-------------------| | 3Play Media | 99.6% | $4.15/min, 4-day turnaround | Yes | | Rev | 99%+ | $1.50/min, 24-hour turnaround | No | | Verbit | 99%+ | Custom pricing | Yes |

WCAG video requirements at AA level:

| Criterion | Level | Requirement | |-----------|-------|-------------| | SC 1.2.1 | A | Transcripts for audio-only; text descriptions for video-only | | SC 1.2.2 | A | Synchronized captions for all prerecorded video with audio | | SC 1.2.3 | A | Audio description OR full text alternative for visual content | | SC 1.2.5 | AA | Audio description required (text alternative alone not sufficient) |

Since the DOJ Title II rule requires Level AA, water districts need captions + transcripts + audio descriptions for visual-only content in video.

Video player requirements:

Must provide keyboard-navigable controls for captions and audio descriptions
Recommended players: Kaltura, Plyr, Acorn Media Player
YouTube embeds are generally accessible but verify keyboard navigation
Must not auto-play

7.4 ⚠️ WARNING: Overlay Tools (accessiBe, UserWay, AudioEye)

These are a liability, not a solution.

FTC fined accessiBe $1 million (Jan 2025) for deceptive claims that its AI product could make websites ADA compliant
1,023 companies using overlays were sued in 2024 -- overlays actively attract plaintiff attorneys (25% of all lawsuits!)
600+ accessibility professionals signed an open letter opposing overlays
National Federation of the Blind formally opposes all overlays
Overlays create a false sense of security -- they cosmetically patch surface-level issues while leaving structural violations untouched (heading hierarchy, semantic HTML, keyboard traps, complex form interactions)
Some overlays break assistive technology that was previously working
Courts have consistently rejected "we installed an overlay" as a defense

If a vendor pitches you an overlay as an ADA solution, run.

7.5 Other Notable Tools

| Tool | Type | Cost | Best For | |------|------|------|----------| | Lighthouse | Built into Chrome DevTools | Free | Quick score (0-100), one-click | | axe DevTools | Browser extension | Free tier / $500/yr Pro | Developers doing code-level fixes | | ANDI | Browser bookmarklet (by SSA) | Free | Section 508 testing | | Pa11y | Command-line / CI | Free (open source) | Automated build pipeline checks | | Siteimprove | Enterprise platform | $15K-50K/yr | Ongoing monitoring, PDF scanning | | WebAIM Contrast Checker | Web tool | Free | Checking color combinations | | NVDA | Screen reader (Windows) | Free | Manual testing (65.6% market share) | | VoiceOver | Screen reader (Mac/iOS) | Free (built-in) | Manual testing on Apple devices |

Key insight: No single tool catches everything. Layer automated tools (WAVE + Lighthouse) with AI review and manual screen reader testing.

8. WATER DISTRICT-SPECIFIC CONCERNS

What AWE Members Need to Make Accessible

| Content Type | Key Accessibility Concerns | |---|---| | Bill pay portals | Form labels, screen reader compatibility, error messages, time-out warnings | | CCRs (Water Quality Reports) | Data tables (hardest element to make accessible), PDF tagging, alt text for charts | | Meeting agendas/minutes | PDF structure, heading hierarchy, reading order | | Emergency alerts | Multi-channel delivery (text + email + voice + TTY), accessible web pages, captioned video | | Conservation materials | Infographic alt text, video captions, interactive calculator keyboard access | | Social media | Alt text on images, captions on video, contrast in graphics | | Customer service portals | Accessible forms, document upload, account management | | Video content | Captions (99% accuracy), transcripts, audio descriptions for visual-only content |

Vendor Contracts

The third-party exemption does NOT apply to contracted work. Water districts should add WCAG 2.1 AA compliance requirements to all vendor contracts and RFPs for web, video, design, and digital marketing work. Recommended provisions:

Vendor warranties of WCAG 2.1 AA conformance
Prohibition on vendors disclaiming accessibility warranties
Indemnification clauses for accessibility-related breaches
Regular accessibility auditing requirements

KEY SOURCES

Federal Law & Regulation:

Technical Standards:

Litigation & Enforcement:

Industry-Specific:

Tools & Overlays:

Legal Analysis:

Presentation Notes

ADA Web Accessibility -- Presentation Notes

Event: AWE Education and Outreach Committee (dedicated meeting) Date: Wednesday, April 2, 2026 at 1:00 PM MT Duration: 45 minutes (30 min presentation + 5 min demo + 10 min Q&A) Presenter: Scott Brady Presentation URL: labs.simplyscapes.com/topics/ada-compliance

Setup Checklist

[ ] Slide deck loaded (PPTX as backup if website has issues)
[ ] Load labs.simplyscapes.com/topics/ada-compliance on projector
[ ] WAVE browser extension installed and ready
[ ] Claude Code open in a terminal (for Q&A skill demo)
[ ] Demo page pre-loaded: labs.simplyscapes.com/topics/ada-compliance/demo
[ ] Test screen share before meeting starts

Revised Format (45 Minutes)

| Time | Section | Duration | Slide # | |------|---------|----------|---------| | 0:00 - 1:30 | Opening + Hook | 1.5 min | 1-2 | | 1:30 - 6:00 | WHO Must Comply | 4.5 min | 3-7 | | 6:00 - 10:00 | WHAT -- The Spec | 4 min | 8-11 | | 10:00 - 12:00 | WHEN -- Deadlines | 2 min | 12-13 | | 12:00 - 14:00 | WHERE -- What's Covered | 2 min | 14-15 | | 14:00 - 18:00 | WHY -- Carrot & Stick | 4 min | 16-19 | | 18:00 - 21:00 | Overlays Warning | 3 min | 20-21 | | 21:00 - 24:00 | Scoring & Enforcement | 3 min | 22-24 | | 24:00 - 28:00 | Tools | 4 min | 25-28 | | 28:00 - 30:00 | AI + Claude Skill | 2 min | 29-30 | | 30:00 - 35:00 | Live Demo | 5 min | (switch to browser) | | 35:00 - 45:00 | Q&A (AI audit runs live) | 10 min | 31 |

SLIDE-BY-SLIDE NOTES

Slide 1: Title

ADA Web Accessibility Compliance What Water Professionals Need to Know

Scott Brady | SimplyScapes Labs AWE Education & Outreach | April 2, 2026

Slide 2: Opening Hook (0:00 - 1:30)

On screen: "94.8% of the top 1 million websites fail accessibility standards."

"Quick show of hands -- how many of you manage a website for your organization? ...Okay. How many of you are confident that website is ADA compliant? ...That's usually the response I get."

"Today I'm going to walk you through who must comply -- and it's broader than you think -- what the spec actually requires, when the deadlines hit, and then I'll demo how to find and fix violations, including using AI."

"We actually ran a WCAG audit on our own SimplyScapes Labs site while preparing this. We found 41 violations. We're a tech company. So if you're thinking 'my website is probably fine' -- it's probably not. And that's okay. Almost nobody passes."

Slides 3-7: WHO Must Comply (1:30 - 6:00)

Slide 3: "Who Must Comply? Almost Everyone."

Three columns:

Title II -- Government: State/local govt, special districts, public universities
Title III -- Private Business: Any "place of public accommodation" (12 categories)
Section 508 -- Federal: Agencies and their contractors

"Let's start with the one that hits this room directly. Water districts are explicitly named in the DOJ's April 2024 final rule. Not interpreted -- named. Water districts, sewer districts, irrigation districts, MUDs."

Slide 4: "The 12 Categories of Public Accommodation"

Show the table of all 12 categories with landscaping companies, contractors, plumbers highlighted under Category 6.

"But it's not just government. Look at Category 6 -- service establishments. That's banks, lawyers, accountants, barbers, healthcare providers... and landscaping companies, plumbers, electricians, contractors. If you have a website where customers can request a quote or schedule service, you're covered."

Slide 5: "No Small Business Exemption"

Big stat: 77% of lawsuits target companies under $25M revenue Sub-stat: Businesses under $500K revenue are the most frequently sued.

No minimum employee count (the 15-employee rule is Title I employment only)
No minimum revenue threshold
A sole proprietor with a website is covered

"There is no small business exemption. The 15-employee threshold people cite is for employment discrimination. It does not apply to websites."

Slide 6: "You Can't Contract Away Liability"

If a vendor builds your website, YOU are still liable
Third-party exemption does NOT apply to contracted work
Put WCAG 2.1 AA requirements in every web/video/design contract and RFP

"This is the one that catches people. If you hired someone to build your website and it's not accessible -- that's your problem, not theirs. You need WCAG requirements in your vendor contracts."

Slide 7: "State Laws Expand the Net"

| State | Law | Key Feature | |-------|-----|-------------| | California | Unruh Act | $4,000 per violation per visit | | New York | Human Rights Law | Covers any website visited by NY resident | | Colorado | HB-21-1110 | Digital accessibility requirements |

85% of ADA web lawsuits filed in CA, NY, and FL.

"Even if there's a gap in federal coverage, state laws fill it. California's Unruh Act is $4,000 per violation, per visit. That adds up fast."

Slides 8-11: WHAT -- The Spec (6:00 - 10:00)

Slide 8: "WCAG 2.1 Level AA -- 50 Success Criteria"

The four POUR principles as quadrants:

Perceivable -- can users perceive the content?
Operable -- can users navigate and interact?
Understandable -- can users understand the content?
Robust -- does it work with assistive technology?

"The standard is WCAG 2.1 Level AA. 50 success criteria organized around four principles. You don't need to memorize them -- just remember POUR."

Slide 9: "The Most Common Violations"

WebAIM Million 2025 findings:

Low contrast text: 79% of sites
Missing alt text: 19% of sites
Missing form labels
Empty links / empty buttons
Missing document language

Average: 51 errors per homepage

"These aren't obscure technical requirements. This is 'does your image have a description' and 'can someone read your light gray text on a white background.' 79% of websites fail on contrast alone."

Slide 10: "Good vs. Bad -- Side by Side"

Show 4 examples with code:

| Violation | Bad | Good | |-----------|-----|------| | Alt text | <img src="..."> | <img src="..." alt="Drip emitter watering a rose bush"> | | Contrast | Light gray (#AAA) on white | Dark gray (#333) on white | | Form label | <input type="email"> | <label for="email">Email</label><input id="email"> | | Link text | "Click here" | "View water conservation tips" |

"Let me show you what these actually look like in code. On the left, the violation. On the right, the fix. Notice how simple the fixes are."

Slide 11: "Contrast Ratios -- The Numbers"

| Element | Required Ratio | |---------|---------------| | Normal text | 4.5:1 | | Large text (18pt+ or 14pt+ bold) | 3:1 | | UI components / graphics | 3:1 |

Visual: Show a color swatch failing (2.4:1) vs passing (4.5:1)

"The ratio that matters most: 4.5 to 1 for normal text. If you remember one number from today, that's the one."

Slides 12-13: WHEN -- Deadlines (10:00 - 12:00)

Slide 12: "The Clock Is Ticking"

| Entity | Deadline | |--------|----------| | Large state/local govt (50K+) | April 24, 2026 -- already passed! | | Small state/local govt | April 26, 2027 | | Special districts (water, sewer) | April 26, 2027 | | Private businesses | No deadline -- lawsuits are happening NOW |

"Large governments -- their deadline was last week. Water districts: April 2027. That's 12 months. Private businesses? There's no deadline because 5,100 lawsuits were already filed last year."

Slide 13: "Regulatory Note"

In Feb 2026, the Trump DOJ submitted an Interim Final Rule to OIRA -- changes unknown
Deadlines remain in effect today
A Louisiana judge ruled ADA requires web accessibility even before these deadlines
Don't wait.

"Some of you may be thinking 'the current administration might roll this back.' Maybe. But a federal judge has already ruled web accessibility is required under the ADA regardless of these deadlines. And the lawsuits aren't waiting."

Slides 14-15: WHERE -- What's Covered (12:00 - 14:00)

Slide 14: "It's Not Just Your Website"

8 icons in a grid:

Websites
Mobile apps
Bill-pay portals
Online forms
PDFs and documents
Video content
Email newsletters
Social media

"If you're thinking 'it's just our website' -- it's not. Your PDFs, your board meeting videos, your social media posts, your customer portal, your online bill pay. If it's digital and public-facing, it's covered."

Slide 15: "Exceptions -- They're Narrow"

Archived web content (designated archive, pre-deadline, not updated)
Preexisting PDFs -- UNLESS currently used to access services
Third-party content from unaffiliated parties (NOT your vendors)
Pre-deadline social media posts

Even with exceptions: must provide accessible alternatives upon request.

"There are exceptions, but they're narrow. The biggest misconception: 'our old PDFs are exempt.' They're not -- if someone uses that PDF to access a service today, it needs to be accessible."

Slides 16-19: WHY -- Carrot & Stick (14:00 - 18:00)

Slide 16: "The Carrot"

26% of U.S. adults have some form of disability (44.1M people)
Accessible sites rank better on Google (headings, alt text, semantic HTML = SEO)
"Curb-cut effect" -- captions help in noisy rooms, contrast helps in sunlight, keyboard nav helps power users
Better UX for everyone, not just people with disabilities

"Let's start with the positive. 44 million Americans have a disability. That's your customers, your ratepayers. And accessibility improvements help everyone -- captions in a noisy break room, high contrast in sunlight."

Slide 17: "The Stick"

| Penalty | Amount | |---------|--------| | First violation (Title II) | Up to $150,000 | | Subsequent violations | Up to $230,464 | | CA Unruh Act | $4,000 per violation per visit |

"Now the stick. $150,000 first violation under Title II. California's Unruh Act: $4,000 per violation per visit. That compounds fast."

Slide 18: "The Lawsuit Machine"

5,100+ lawsuits in 2025 (20% increase YoY)
Average settlement: $39,000 (up from $4,000 in 2019)
Big cases: Target ($6M), Fashion Nova ($5M), Harvard ($1.575M in attorney fees)
~6% of special districts already hit with fines/demand letters
Most district insurance pools do NOT cover website ADA claims

"5,100 lawsuits last year. The average settlement is $39,000. And here's the kicker -- most district insurance pools don't cover this."

Slide 19: "It's a Business Model"

31 plaintiffs and 16 law firms filed 50% of all lawsuits
Those 16 firms account for 90%+ of all cases
One individual filed 312 lawsuits since 2022
They scan websites with automated tools, find violations, send demand letters

"This is industrialized litigation. One person filed 312 lawsuits. 16 law firms drive 90% of all cases. They run automated scanners, find low-hanging violations, and send demand letters. It's a business model."

Slides 20-21: Overlays Warning (18:00 - 21:00)

Slide 20: "WARNING: Overlay Tools"

Big red warning treatment.

accessiBe, UserWay, AudioEye -- "one line of code" widgets that promise compliance.

The reality:

FTC fined accessiBe $1 million (Jan 2025) for deceptive claims
1,023 companies using overlays were sued in 2024 -- that's 25% of ALL lawsuits
600+ accessibility professionals signed open letter opposing overlays
National Federation of the Blind formally opposes them

"If a vendor walks in here and says 'add this one line of JavaScript and you're ADA compliant' -- that vendor is selling you a lawsuit magnet."

Slide 21: "False Sense of Security"

What overlays actually do:

Cosmetically patch surface-level issues
Leave structural violations untouched (heading hierarchy, semantic HTML, keyboard traps)
Some break assistive technology that was previously working
Courts have consistently rejected "we installed an overlay" as a defense

"Overlays are the opposite of compliance. They attract plaintiff attorneys who specifically look for that overlay widget as a signal the site has problems. 25% of all lawsuits last year cited overlays as barriers."

Slides 22-24: Scoring & Enforcement (21:00 - 24:00)

Slide 22: "Is It All-or-Nothing?"

Technically: Yes. WCAG conformance is pass/fail per page. Fail one criterion = page doesn't conform.

Legally: Context matters. Courts evaluate the totality:

| Factor | Weight | |--------|--------| | Number and severity of violations | High | | Whether core services are blocked | Very high | | Documented accessibility program | Significant mitigator | | Remediation timeline and progress | Significant mitigator |

"WCAG is technically pass/fail. But courts don't look at it that way. They look at the whole picture -- how many violations, how severe, do they block core services, and do you have a plan?"

Slide 23: "Good Faith Is Not a Defense -- But It Shapes Outcomes"

DOJ has explicitly said good faith will NOT excuse noncompliance
BUT entities with documented programs get: case dismissals, reduced settlements, shorter timelines
Think of it like OSHA: a safety program doesn't prevent a violation, but it determines whether you get a warning or a six-figure fine

Your documentation checklist:

Formal accessibility policy
Regular audits (at least annually)
Remediation plan with timelines
Staff training records
Accessibility statement on website
Log of accommodation requests and responses

"Good faith is not a defense. But it's the difference between a warning and a six-figure fine. Document everything."

Slide 24: "What To Do First -- Monday Morning"

Run WAVE on your homepage (5 minutes, free)
Publish an accessibility statement with a contact method (30 minutes)
Designate an accessibility coordinator (name on a page)
Start a remediation log (spreadsheet is fine)

"These four things take less than a day and they begin building your documented good-faith effort. You can start Monday."

Slides 25-28: Tools (24:00 - 28:00)

Slide 25: "WAVE -- Free Browser Extension"

Screenshot of WAVE in action (or describe what it shows).

| Icon Color | Meaning | |---|---| | Red | Errors -- must fix | | Yellow | Alerts -- review needed | | Green | Features -- accessibility features present | | Blue | Structural -- headings, landmarks | | Purple | Contrast failures |

Free, one-click, data stays in your browser
Catches ~30-40% of issues (need manual testing too)

"WAVE is the tool I'd recommend everyone install today. Free. One click. Shows you exactly where your violations are."

Slide 26: "Lighthouse -- Built Into Chrome"

Open Chrome DevTools → Lighthouse → Accessibility
Gives a 0-100 score
Good for a quick pulse check
Already on your computer

"You already have this. Right-click, Inspect, Lighthouse tab. It gives you a score out of 100."

Slide 27: "Video Accessibility -- Descript & Captions"

Descript: AI auto-captioning at ~95% accuracy
Exports SRT/VTT files for web players
Auto-captions alone do NOT satisfy WCAG -- FCC requires 99% accuracy
Always: human review after auto-caption
For compliance-critical video (board meetings): consider 3Play Media ($4.15/min, 99.6% accuracy) or Rev ($1.50/min, 99%+)

WCAG AA requires: captions + transcripts + audio descriptions for visual-only content.

"Descript is a great starting point for captions. But 95% accuracy means one error every 20 words. The standard is 99%. Always do human review. For board meetings, consider a professional service."

Slide 28: "Tool Stack Summary"

| Tool | Cost | Best For | |------|------|----------| | WAVE | Free | Visual error overlay | | Lighthouse | Free (built into Chrome) | Quick score | | axe DevTools | Free / $500/yr Pro | Developers | | WebAIM Contrast Checker | Free | Color testing | | VoiceOver (Mac) / NVDA (Win) | Free | Screen reader testing | | Descript | Subscription | Video captions (starting point) | | 3Play Media / Rev | Per-minute | Compliance-ready captions |

"No single tool catches everything. Layer WAVE plus Lighthouse for automated checks, a screen reader for manual testing, and Descript or a pro service for video."

Slides 29-30: AI + Claude Skill (28:00 - 30:00)

Slide 29: "AI for Accessibility"

Three tiers:

AI Chat (Claude, ChatGPT) -- paste code, get WCAG evaluation. Good for spot checks.
Specialized tools (axe DevTools Pro, AccessiMind) -- integrated into developer workflow.
Claude Code Skill -- a reusable AI expert you can run against your entire site.

"AI is getting genuinely useful for accessibility. You can paste code into Claude or ChatGPT and get a WCAG evaluation. But there's a more powerful approach..."

Slide 30: "The ADA Compliance Skill"

Show the skill file concept:

It's a Markdown file that tells Claude to act as a WCAG expert
Audits HTML against all 50 success criteria
Reports violations with severity, affected element, and how to fix
Generates corrected code

"This is a Claude Code skill. It's just a text file that says 'you are a web accessibility expert.' You point it at your website and it audits every element, reports every violation, and generates the fixed code. I'm going to run this live during Q&A."

Live Demo (30:00 - 35:00)

Switch from slides to browser.

Step 1: Show Splash Valley (1 min)

Open labs.simplyscapes.com/topics/ada-compliance/demo

"This is Splash Valley Water District -- a fictional water district site we built for this demo. It looks like a normal water district website. It's got a conservation message, a newsletter signup, some staff bios. Notice anything wrong? ...Probably not. Let's see what WAVE finds."

Point out the subtle humor as you scroll:

"Chief Hydration Officer"
"Every Drop Counts (Especially the Ones You're Wasting)"
"Get drip tips straight to your inbox"

Step 2: Run WAVE (1.5 min)

Click the WAVE extension. Icons flood the page.

Walk through:

Red errors: missing alt text, missing form labels, empty button
Yellow alerts: "click here" link, skipped heading levels
Purple: contrast failures on light text

"This page had [X] errors. And it looked totally normal 30 seconds ago. This is what 94.8% of websites look like under WAVE."

Step 3: Live Editor Fixes (2.5 min)

Open the embedded code editor on the demo page.

Fix 1: Add alt text to an image. Violation count drops. (~45 sec)
Fix 2: Fix contrast -- change a hex value. Count drops. (~45 sec)
Fix 3: Add a form label to the newsletter signup. Count drops. (~45 sec)

"Three changes. Under a minute each. We just eliminated [X] violations. This is not rocket science -- it's attention to detail. And it's exactly the kind of thing AI can automate."

Slide 31: Q&A (35:00 - 45:00)

On screen: "Questions?" with key resources listed:

labs.simplyscapes.com/topics/ada-compliance
WAVE: wave.webaim.org
ADA.gov First Steps: ada.gov/resources/web-rule-first-steps
WebAIM Contrast Checker: webaim.org/resources/contrastchecker

During Q&A: Kick off the Claude ADA audit skill against Splash Valley. Let it run in the background. When results come in, share screen to show the full audit output.

Anticipated questions:

Q: "What if we can't afford to fix everything?" A: Prioritize core services -- bill pay, account management, emergency alerts. Document your plan and progress. The "readily achievable" standard considers your resources. And many fixes are free -- alt text, contrast changes, form labels.

Q: "Do we need to redo our entire website?" A: No. Start with an audit (WAVE, 5 minutes). Prioritize the biggest issues. Many fixes are trivial. Work through a remediation plan. Courts care about documented progress.

Q: "What about PDFs?" A: Pre-existing PDFs are exempt unless they're currently used to access services (rate schedules, meeting minutes often are). New PDFs need proper tagging. Adobe Acrobat Pro has a built-in accessibility checker.

Q: "Does this apply to our social media?" A: Posts made after the compliance deadline must be accessible. Add alt text to images, captions to videos, ensure contrast in graphics. The platforms provide these tools -- you just need to use them.

Q: "What about our vendors?" A: You're liable for vendor-built content. Add WCAG 2.1 AA requirements to all contracts and RFPs. Include indemnification clauses. Don't let vendors disclaim accessibility warranties.

Q: "Are there any overlays or quick fixes that actually work?" A: No. The FTC fined the leading overlay company $1 million. 25% of lawsuits last year cited overlays as the barrier. There is no shortcut. The fixes are simple but they have to be real.

Key Stats Quick Reference

| Stat | Value | |------|-------| | U.S. adults with disability | 26% (44.1M) | | Sites failing WCAG | 94.8% | | Avg errors per homepage | 51 | | Lawsuits filed 2025 | 5,100+ | | YoY increase | 20% (37% H1) | | First violation fine (Title II) | Up to $150,000 | | CA Unruh per violation | $4,000/visit | | Average settlement | $39,000 | | Special districts already hit | ~6% | | Overlay users sued 2024 | 1,023 (25% of all lawsuits) | | FTC overlay fine | $1 million | | Water district deadline | April 26, 2027 | | Serial plaintiff record | 312 lawsuits (one person) | | Firms driving litigation | 16 firms = 90%+ of cases | | Small business targets | 77% of lawsuits < $25M revenue | | Normal text contrast ratio | 4.5:1 | | SimplyScapes Labs audit | 41 violations found |

Closing Line

"Accessibility isn't a one-time project -- it's an ongoing commitment. But the good news is: the fixes are often simple, the tools are mostly free, and AI can do the heavy lifting. The worst thing you can do is nothing. The best thing you can do is start tomorrow."

Website Execution Plan

Website Execution Plan -- Labs Homepage + ADA Compliance Topic

Topic: ada-compliance Created: 2026-03-12 Status: Draft -- execute in separate session with full context

Overview

Two connected deliverables:

Labs Homepage (labs.simplyscapes.com/) -- redesign from placeholder to a polished research lab landing page
ADA Compliance Topic (labs.simplyscapes.com/topics/ada-compliance) -- multipage interactive presentation site that doubles as the AWE talk on March 17

Both are Next.js App Router pages in the existing src/app/ tree. Tech stack: React 19, Next.js 15, Tailwind 4, TypeScript.

Part A: Labs Homepage Redesign

Vision

Labs is SimplyScapes's public innovation arm. The homepage should feel like walking into a design-forward research lab -- clean, confident, a little unexpected. SimplyScapes pitches itself as your Innovation Partner.

Brand Messaging

SimplyScapes creates beautiful, sustainable communities by connecting homeowners, landscaping professionals, and institutions. Our vision: beauty and sustainability go hand-in-hand.

SimplyScapes Labs is where that vision gets tested. We research, prototype, and publish ideas at the intersection of landscape technology, sustainability, and community infrastructure.

Page Structure

┌──────────────────────────────────────────────────┐
│  NAV: SimplyScapes Labs • [Topics ▾]  [About]    │
├──────────────────────────────────────────────────┤
│                                                  │
│  HERO: Full-viewport                             │
│  "Your Innovation Partner"                       │
│  Tagline about beauty + sustainability           │
│  Subtle animated background (particle/gradient)  │
│  CTA: "Explore Our Research →"                   │
│                                                  │
├──────────────────────────────────────────────────┤
│                                                  │
│  MISSION SECTION: Short manifesto                │
│  Three pillars with icons:                       │
│    🏡 Homeowners                                 │
│    🌿 Landscaping Professionals                  │
│    🏛 Institutions                               │
│                                                  │
├──────────────────────────────────────────────────┤
│                                                  │
│  TOPICS GRID: Cards for each published topic     │
│  Each card = image + title + one-liner + status  │
│  Currently:                                      │
│    • ADA Web Accessibility Compliance            │
│    • Automated Turf Irrigation Scheduling        │
│    • Plant-Specific Drip Irrigation Intelligence │
│    • Landscape Health Diagnostics                │
│    • Generative AI Chat Interface                │
│    • Vector Embeddings Platform                  │
│    • PDF Template System                         │
│    • Rapid Iterative Development                 │
│                                                  │
├──────────────────────────────────────────────────┤
│  FOOTER: SimplyScapes • GitHub • Contact         │
└──────────────────────────────────────────────────┘

Design Direction

Dark/light mode toggle (practice what we preach for ADA)
Clean sans-serif typography (Inter or similar)
Green/earth-tone accent palette (sustainability)
Subtle CSS/JS animations (intersection observer reveals, not heavy)
Fully WCAG 2.1 AA compliant (leading by example)

Route Structure

src/app/
  page.tsx                    → Labs homepage
  topics/
    page.tsx                  → Topics index (optional, could redirect to /)
    ada-compliance/
      page.tsx                → ADA topic landing page
      layout.tsx              → Shared layout for ADA subpages
      who/page.tsx            → WHO must comply
      what/page.tsx           → WHAT is the spec
      when/page.tsx           → WHEN are deadlines
      where/page.tsx          → WHERE does it apply
      why/page.tsx            → WHY comply (carrot & stick)
      scoring/page.tsx        → Scoring & enforcement
      tools/page.tsx          → Tools overview
      overlays/page.tsx       → Overlay warning
      demo/page.tsx           → Interactive demo page
      skill/page.tsx          → Claude skill appendix

Part B: ADA Compliance Topic Site

Concept: "The 5 W's" as a Scrolling Journey

The landing page (/topics/ada-compliance) is a single-page scrolling experience with hero sections for each W. Each section is a full-viewport or near-full-viewport block with:

Bold typographic treatment of the W word
Key stat or fact as a large animated counter/reveal
2-3 bullet takeaways
"Dive deeper →" link to the full subpage
Ambient animation or illustration

Section flow:

| # | Section | Hero Stat | Animation Idea | |---|---------|-----------|----------------| | 1 | WHO | "3,200+ special districts in Texas alone" | Animated map pins appearing across TX | | 2 | WHAT | "94.8% of sites fail" | Percentage counter animating from 0 → 94.8 | | 3 | WHEN | "April 26, 2027" | Countdown timer ticking live | | 4 | WHERE | "8 content types covered" | Icons appearing: web, mobile, PDF, video, forms, email, social, portals | | 5 | WHY | "$115,231 first offense" | Dollar amount ticking up dramatically | | 6 | ⚠️ OVERLAYS | "1,023 sued" | Red/warning treatment, distinct from other sections | | 7 | TOOLS | Tool cards | Interactive tool comparison | | 8 | SCORING | "Pass/Fail — but context matters" | Scale/balance animation |

Interactive ADA Examples -- Good vs. Bad

Embedded directly in the WHO/WHAT sections. Side-by-side panels:

┌─────────────────────┬─────────────────────┐
│  ❌ BAD EXAMPLE     │  ✅ GOOD EXAMPLE    │
│                     │                     │
│  <img src="...">    │  <img src="..."     │
│                     │    alt="A drip       │
│  (no alt text)      │    emitter watering │
│                     │    a rose bush">    │
│                     │                     │
│  WAVE: 1 error 🔴   │  WAVE: 0 errors ✅  │
└─────────────────────┴─────────────────────┘

Examples to include:

| Violation | Bad Code | Good Code | |-----------|----------|-----------| | Missing alt text | <img src="..."> | <img src="..." alt="..."> | | Low contrast | Light gray on white | Dark text on white | | Missing form label | <input type="text"> | <label for="x">Name</label><input id="x"> | | "Click here" link | <a href="#">Click here</a> | <a href="#">View water conservation tips</a> | | Skipped headings | h1 → h4 | h1 → h2 → h3 | | Missing lang | <html> | <html lang="en"> | | Images of text | Image of a rate table | Real HTML <table> |

Live HTML Editor -- The Showstopper Feature

Goal: An embedded code editor where Scott can type HTML, see it render live, and watch WCAG violations appear/disappear in real time.

Recommended library: CodeMirror 6

Lightweight, modular, works great in React
npm: @codemirror/view, @codemirror/state, @codemirror/lang-html
Accessible itself (ironic if the accessibility demo editor weren't accessible)
Alternative: Monaco Editor (VS Code engine) -- heavier but more feature-rich

Architecture:

┌────────────────────────────────────────────────────────┐
│  LIVE ADA EDITOR                                       │
├───────────────────────┬────────────────────────────────┤
│                       │                                │
│  CodeMirror editor    │  Live preview (iframe or div)  │
│  with HTML syntax     │  Renders the HTML in real time │
│  highlighting         │                                │
│                       │                                │
├───────────────────────┴────────────────────────────────┤
│                                                        │
│  VIOLATION PANEL                                       │
│  🔴 Error: img missing alt text (line 3)               │
│  🔴 Error: contrast ratio 2.1:1 (need 4.5:1) (line 7) │
│  🟡 Alert: skipped heading level (line 12)             │
│  ✅ 0 errors remaining → WCAG 2.1 AA PASS             │
│                                                        │
└────────────────────────────────────────────────────────┘

Implementation approach:

CodeMirror 6 for the editor pane
dangerouslySetInnerHTML in a sandboxed div or srcdoc iframe for live preview
Client-side WCAG checker using axe-core (@axe-core/react or run axe.run() against the preview DOM)
Violation panel updates on every keystroke (debounced ~500ms)
Preload with the "bad" water conservation HTML -- presenter fixes it live

Packages needed:

codemirror / @codemirror/view / @codemirror/state / @codemirror/lang-html
axe-core (client-side WCAG validation engine -- the same engine behind axe DevTools)

Overlay Warning Page (`/topics/ada-compliance/overlays`)

Full-page warning treatment. Red/amber design language. Content from research brief Section 7.4. Key elements:

"$1 million FTC fine" as hero stat
"1,023 companies using overlays were sued" counter
Explanation of what overlays actually do (and don't do)
Quote: "If a vendor pitches you an overlay as an ADA solution, run."
Link to the overlay fact sheet / open letter

Scoring Page (`/topics/ada-compliance/scoring`)

Content from research brief Section 6. Visual treatment:

Binary pass/fail visual (thumbs up/down) with nuance explanation
"Good faith" as a spectrum/slider visualization
Table of court evaluation factors
"Conformance vs. Compliance" side-by-side

Part C: Claude Skill Appendix (`/topics/ada-compliance/skill`)

Purpose

A how-to guide for running ADA compliance audits using Claude Code skills. This is the "teach them to fish" page -- attendees walk away knowing how to use AI for accessibility work.

Content Outline

1. What is a Claude Skill?

A reusable prompt file (Markdown) that lives in your project
Claude Code loads it when you invoke it with /skill-name
Think of it as a specialized expert you can summon

2. The ADA Compliance Skill

Full skill source code displayed in a code block (the actual SKILL.md content)
What it does: audits a webpage or HTML file against WCAG 2.1 AA, reports violations, generates fixes
What it doesn't do: replace manual testing with screen readers

3. How to Set It Up

Step 1: Install Claude Code (link)
Step 2: Create .claude/skills/ada-audit/SKILL.md in your project
Step 3: Paste the skill content
Step 4: Run: /ada-audit <url-or-file>

4. Example Session

Screenshot/recording of running the skill against the demo page
Before/after output

5. The Actual Skill

---
name: ADA Compliance Audit
description: Audit HTML for WCAG 2.1 AA violations and generate fixes
---

# ADA Compliance Audit Skill

You are a web accessibility expert. When given a URL or HTML file:

1. **Audit** the content against WCAG 2.1 Level AA (all 50 success criteria)
2. **Report** each violation with:
   - WCAG criterion number and name
   - Severity (Error / Warning)
   - Affected element (line number if available)
   - Why it fails
   - How to fix it (specific code change)
3. **Generate** a corrected version of the HTML with all violations fixed
4. **Summarize** the results:
   - Total violations found
   - Violations by category (Perceivable / Operable / Understandable / Robust)
   - Estimated conformance level before and after fixes

## Key checks:
- All images have meaningful alt text (or alt="" for decorative)
- Color contrast ratios meet 4.5:1 (normal text) and 3:1 (large text)
- All form inputs have associated labels
- Heading hierarchy is sequential (no skipped levels)
- Page language is declared (<html lang="en">)
- All interactive elements are keyboard accessible
- Link text is descriptive (no "click here")
- Skip navigation is present
- ARIA roles are used correctly
- Video/audio has captions and transcripts
- Data tables have proper headers and scope
- Focus indicators are visible
- No content flashes more than 3 times per second

Part D: Demo Page (Vanilla HTML)

Purpose

A standalone vanilla HTML page at /topics/ada-compliance/demo that:

Delivers a water conservation message (relevant to AWE)
Contains intentional WCAG violations for the live audit
Includes subtle humor for presentation talking points
Is plain HTML (no React/JSX) so fixes are simple and visible to non-technical audience

How to Serve Vanilla HTML from Next.js

Option A: Put the HTML file in public/topics/ada-compliance/demo.html -- Next.js serves it statically, no framework wrapper. This is the best option because:

It's truly vanilla HTML (no React hydration, no JSX)
Presenter can open the file in any editor, make changes, and the site serves the updated version
WAVE and Lighthouse see raw HTML, not React-rendered DOM

Option B: A Next.js page that renders an iframe pointing to the static HTML. Useful if we want the topic site's nav around the demo.

Recommendation: Option A for the HTML file, Option B for the demo page that embeds it alongside the live editor.

Demo Page Content Concept: "Splash Valley Water District"

A fictional water district homepage with a conservation theme. Subtle humor woven in:

Headline: "Every Drop Counts (Especially the Ones You're Wasting)"
A water usage calculator that says "Congratulations! Your lawn drinks more than a camel"
Newsletter signup: "Get drip tips straight to your inbox"
Emergency banner: "URGENT: Local man caught watering driveway at 2pm. Again."
Staff directory with titles like "Chief Hydration Officer" and "VP of Puddle Avoidance"
Footer: "© 2026 Splash Valley Water District. All drips reserved."

Intentional Violations to Bake In

| # | Violation | Where | Fix Complexity | |---|-----------|-------|---------------| | 1 | Missing lang attribute | <html> tag | Trivial | | 2 | Missing page <title> | <head> | Trivial | | 3 | Missing alt text (3 images) | Hero, staff photos, infographic | Easy | | 4 | Low contrast text | "Tips" section -- light blue on white | Easy | | 5 | Missing form labels | Newsletter signup | Easy | | 6 | "Click here" link text | "For more info, click here" | Easy | | 7 | Skipped heading levels | h1 → h4 (skipping h2, h3) | Easy | | 8 | Missing skip navigation | No skip-to-content link | Easy | | 9 | Image of text | Rate schedule as a screenshot | Medium | | 10 | No focus indicators | outline: none on all elements | Easy | | 11 | Auto-playing background video | Decorative water video with no controls | Medium | | 12 | Missing table headers | Water usage data table | Easy | | 13 | Empty button | Icon-only button with no label | Easy |

This gives WAVE plenty to find (red errors + yellow alerts + purple contrast failures) while keeping every fix understandable to a non-developer audience.

Presentation Flow (Revised -- 30 Minutes)

| Time | Section | What Happens | |------|---------|-------------| | 0:00-1:00 | Opening | Load labs.simplyscapes.com/topics/ada-compliance on projector | | 1:00-8:00 | The 5 W's | Scroll through hero sections. Click into subpages as needed for detail. Spend extra time on WHO (water districts named!) and WHY ($$$). | | 8:00-9:00 | Overlays | Navigate to /overlays. The $1M fine. "If a vendor pitches you an overlay, run." | | 9:00-10:00 | Scoring | Navigate to /scoring. Binary but context matters. Document everything. | | 10:00-12:00 | Tools | Navigate to /tools. WAVE walkthrough. Mention Descript for video. | | 12:00-15:00 | Live Demo -- WAVE | Open /demo (Splash Valley). Run WAVE extension. Walk through errors on screen. | | 15:00-18:00 | Live Demo -- Manual Fix | Open the live editor. Fix 2-3 violations (alt text, contrast, form label). Show WAVE error count drop in real time. | | 18:00-20:00 | Claude Skill | Navigate to /skill. Show the skill. Explain how it works. | | 20:00-30:00 | Q&A | Answer questions. During Q&A, kick off the Claude skill against the full demo page. Show results as they come in. |

Implementation Dependencies

NPM packages to add:

codemirror @codemirror/view @codemirror/state @codemirror/lang-html
axe-core
framer-motion (for scroll animations)

Execution notes:

Execute in a separate session with the research brief loaded as context
The labs homepage redesign and ADA topic can be built in parallel by separate agents if desired
The vanilla HTML demo page (public/topics/ada-compliance/demo.html) is independent and can be built first for testing
The live editor component is the most complex piece -- build and test it standalone before integrating

Files to Create

src/app/
  page.tsx                                    → Labs homepage (redesign)
  topics/
    ada-compliance/
      page.tsx                                → ADA landing page (5 W's scroll)
      layout.tsx                              → Shared nav/layout
      who/page.tsx
      what/page.tsx
      when/page.tsx
      where/page.tsx
      why/page.tsx
      scoring/page.tsx
      tools/page.tsx
      overlays/page.tsx
      demo/page.tsx                           → Embeds vanilla HTML + live editor
      skill/page.tsx                          → Claude skill how-to guide
  components/
    labs/
      hero.tsx                                → Reusable hero section
      topic-card.tsx                          → Topic grid card
      stat-counter.tsx                        → Animated number counter
      countdown-timer.tsx                     → Live countdown to deadline
    ada/
      code-editor.tsx                         → CodeMirror wrapper
      live-preview.tsx                        → Sandboxed HTML preview
      violation-panel.tsx                     → axe-core results display
      good-bad-example.tsx                    → Side-by-side comparison
      wave-legend.tsx                         → WAVE icon color guide

public/
  topics/ada-compliance/
    demo.html                                 → Vanilla HTML demo page (Splash Valley)

Wcag 2.1 2.2 Aa Reference

WCAG 2.1 & 2.2 AA Compliance Reference

Topic: ada-compliance Last Updated: 2026-03-13

Overview

This document provides a comprehensive reference for all WCAG 2.1 and 2.2 success criteria at Level A and Level AA. AA conformance is the standard required by most accessibility regulations worldwide, including the ADA Title II final rule (April 2024), Section 508, and EN 301 549.

Key facts:

WCAG 2.2 (released October 2023) supersedes WCAG 2.1 and is backward-compatible
WCAG 2.2 AA conformance requires meeting 56 success criteria (32 Level A + 24 Level AA)
WCAG 2.2 added 9 new criteria (2 at Level A, 4 at Level AA, 3 at Level AAA) and removed 1 (4.1.1 Parsing)
The DOJ Title II rule references WCAG 2.1 AA, but conforming to WCAG 2.2 AA meets that requirement plus additional protections

What Changed from WCAG 2.1 to 2.2 (at A/AA levels)

| Criterion | Level | Change | |-----------|-------|--------| | 2.4.11 Focus Not Obscured (Minimum) | AA | NEW in 2.2 | | 2.4.13 Focus Appearance | AAA | NEW in 2.2 (not required for AA) | | 2.5.7 Dragging Movements | AA | NEW in 2.2 | | 2.5.8 Target Size (Minimum) | AA | NEW in 2.2 | | 3.2.6 Consistent Help | A | NEW in 2.2 | | 3.3.7 Redundant Entry | A | NEW in 2.2 | | 3.3.8 Accessible Authentication (Minimum) | AA | NEW in 2.2 | | 3.3.9 Accessible Authentication (Enhanced) | AAA | NEW in 2.2 (not required for AA) | | 4.1.1 Parsing | -- | REMOVED in 2.2 (obsolete; modern browsers handle malformed HTML) |

Organizations already conforming to WCAG 2.1 AA need to address 6 new criteria to reach WCAG 2.2 AA (the 4 new AA criteria plus the 2 new A criteria).

Principle 1: Perceivable

Information and user interface components must be presentable to users in ways they can perceive.

Guideline 1.1 -- Text Alternatives

Provide text alternatives for any non-text content so that it can be changed into other forms people need.

1.1.1 Non-text Content (Level A)

Requirement: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose. Exceptions exist for controls/input (name describes purpose), time-based media (at least descriptive identification), tests (text alternatives would invalidate the test), sensory experiences (at least descriptive identification), CAPTCHA (text alternatives identify and describe purpose, with alternative forms provided), and decoration/formatting/invisible content (implemented to be ignored by assistive technology).

Common failures in web applications:

Images missing alt attributes entirely
Decorative images not marked with alt="" or role="presentation", causing screen readers to announce file names
Icon buttons (hamburger menu, close X, search magnifying glass) with no accessible name
CSS background images conveying meaningful information with no text alternative
SVG icons without <title> elements or aria-label
Image alt text that is unhelpful ("image1.jpg", "photo", "click here")
Complex charts or infographics with no text summary
CAPTCHAs with no accessible alternative

Guideline 1.2 -- Time-based Media

Provide alternatives for time-based media.

1.2.1 Audio-only and Video-only (Prerecorded) (Level A)

Requirement: For prerecorded audio-only content, a text transcript is provided. For prerecorded video-only content (no audio), either a text alternative or an audio track describing the video is provided.

Common failures:

Podcast episodes with no transcript
Silent demonstration videos with no text description
Audio recordings of meetings posted without transcripts

1.2.2 Captions (Prerecorded) (Level A)

Requirement: Captions are provided for all prerecorded audio content in synchronized media (video with audio), except when the media is a media alternative for text and is clearly labeled as such.

Common failures:

Videos with no captions at all
Auto-generated captions that were never reviewed (accuracy below 99% threshold)
Captions missing non-speech audio cues ("[applause]", "[phone rings]", "[music playing]")
Captions not synchronized with audio
Captions missing speaker identification when multiple speakers are present

1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A)

Requirement: An alternative for time-based media or an audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

Common failures:

Training videos where on-screen text or visual demonstrations are not described in audio
Presentations where the speaker says "as you can see here" without describing what is shown

1.2.4 Captions (Live) (Level AA)

Requirement: Captions are provided for all live audio content in synchronized media.

Common failures:

Live-streamed board meetings or webinars with no real-time captioning
Live events using only auto-captions without CART (Communication Access Realtime Translation) services

1.2.5 Audio Description (Prerecorded) (Level AA)

Requirement: Audio description is provided for all prerecorded video content in synchronized media. This goes beyond 1.2.3 by requiring audio description specifically (a text alternative alone is insufficient at AA).

Common failures:

Videos where important visual information is never described in audio
Relying on a text transcript alone instead of providing audio description track
Board meeting recordings where displayed slides, charts, or documents are not described

Guideline 1.3 -- Adaptable

Create content that can be presented in different ways without losing information or structure.

1.3.1 Info and Relationships (Level A)

Requirement: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. For example, headings are marked up as headings, lists as lists, tables as tables, form fields with labels, and regions with landmarks.

Common failures:

Using <div> or <span> styled to look like headings instead of proper <h1>-<h6> tags
Skipping heading levels (e.g., <h1> followed by <h4>)
Data tables without <th> elements or scope attributes
Using layout tables for page structure
Form inputs without associated <label> elements (missing for/id pairing or wrapping)
Lists styled with CSS but marked up as <div> elements instead of <ul>/<ol>/<li>
Required fields indicated only by color (red asterisk) without programmatic indication (aria-required="true" or required)
Related form fields not grouped with <fieldset> and <legend> (e.g., radio button groups)
Missing landmark roles (<main>, <nav>, <header>, <footer>, <aside>)
Visual groupings (cards, sections) with no semantic structure

1.3.2 Meaningful Sequence (Level A)

Requirement: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

Common failures:

CSS positioning (float, position: absolute, flexbox order, grid) creating a visual order that differs from DOM order
Multi-column layouts where screen readers read across columns instead of down them
Content reordered visually for different breakpoints without matching DOM order

1.3.3 Sensory Characteristics (Level A)

Requirement: Instructions for understanding and operating content do not rely solely on sensory characteristics such as shape, color, size, visual location, orientation, or sound.

Common failures:

"Click the green button to submit" (relies on color alone)
"The options on the left" / "the sidebar on the right" (relies on visual location)
"Click the round icon" (relies on shape)
Error messages that only use a red border to indicate invalid fields

1.3.4 Orientation (Level AA)

Requirement: Content does not restrict its view and operation to a single display orientation (portrait or landscape), unless a specific display orientation is essential (e.g., a piano app, a bank check deposit).

Common failures:

Mobile web apps that force portrait mode via CSS or JavaScript
Using orientation: portrait in CSS media queries to hide content in landscape
Content that only functions correctly in one orientation

1.3.5 Identify Input Purpose (Level AA)

Requirement: The purpose of each input field collecting information about the user can be programmatically determined when the input field serves a purpose identified in the WCAG input purposes list (name, email, address, phone, etc.). This is typically achieved through the HTML autocomplete attribute.

Common failures:

Form fields for name, email, phone, address lacking appropriate autocomplete attribute values
Using generic autocomplete="on" instead of specific values like autocomplete="given-name", autocomplete="email", autocomplete="tel"
Custom form components that do not expose input purpose to assistive technology

Guideline 1.4 -- Distinguishable

Make it easier for users to see and hear content, including separating foreground from background.

1.4.1 Use of Color (Level A)

Requirement: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Common failures:

Links distinguished from surrounding text only by color (no underline, bold, or other visual indicator)
Form validation errors indicated only by turning the field border red
Charts/graphs where data series are distinguished only by color
Status indicators (online/offline, success/error) using only green/red with no icon, text, or pattern
Required fields indicated only by red color

1.4.2 Audio Control (Level A)

Requirement: If any audio on a web page plays automatically for more than 3 seconds, either a mechanism to pause/stop the audio is available, or a mechanism to control audio volume independently from the system volume is available.

Common failures:

Auto-playing video with audio on page load
Background music that cannot be paused
Audio that plays automatically with no visible controls

1.4.3 Contrast (Minimum) (Level AA)

Requirement: The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for: large text (at least 18pt or 14pt bold), which requires 3:1; incidental text (inactive components, purely decorative, not visible to anyone); and logotypes.

Common failures:

Light gray text on white backgrounds (extremely common, especially in placeholder text)
White text on light-colored images or gradients without a text-shadow or overlay
Placeholder text in form fields with insufficient contrast
Disabled button text that still needs to be readable
Text overlaid on photographs without sufficient contrast overlay
Brand colors that do not meet contrast requirements when used for text
Links that blend into surrounding text due to similar color

1.4.4 Resize Text (Level AA)

Requirement: Text can be resized without assistive technology up to 200% without loss of content or functionality. This applies to browser zoom, not just text-only scaling.

Common failures:

Fixed-height containers that cause text to overflow and be clipped when zoomed
Horizontal scrolling required at 200% zoom (text not reflowing)
Navigation menus that break or become unusable at larger text sizes
Absolute positioning that causes text overlap when zoomed
Content hidden behind overflow: hidden on containers with fixed dimensions

1.4.5 Images of Text (Level AA)

Requirement: If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text. Exceptions: the image of text can be visually customized to the user's requirements, or a particular presentation of text is essential to the information being conveyed (e.g., a logotype/brand name).

Common failures:

Hero banners containing text rendered as images
Infographics using image-based text instead of HTML/SVG text
Buttons or navigation items rendered as images of text
Social media graphics with text embedded in the image and no text alternative

1.4.10 Reflow (Level AA)

Requirement: Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions, at widths equivalent to 320 CSS pixels (for vertical scrolling content) and heights equivalent to 256 CSS pixels (for horizontal scrolling content). Exceptions: content where two-dimensional layout is essential (data tables, maps, diagrams, video, toolbars).

Common failures:

Layouts that require horizontal scrolling at 320px viewport width
Fixed-width containers that do not reflow
Content cut off or overlapping at narrow viewport widths
Navigation that collapses into an inaccessible state on small screens
Data tables that do not offer a responsive alternative (scrollable container, stacked cards)

1.4.11 Non-text Contrast (Level AA)

Requirement: Visual information required to identify UI components and their states (focus indicators, borders of form inputs, toggle switches) and graphical objects (icons, chart elements) has a contrast ratio of at least 3:1 against adjacent colors.

Common failures:

Form input borders that blend into the background
Custom checkbox/radio buttons with insufficient contrast
Icon-only buttons where the icon lacks sufficient contrast
Focus indicators with contrast below 3:1
Chart elements (bars, lines, pie slices) that cannot be distinguished from their background
Custom toggle switches where the on/off state is not visually distinct

1.4.12 Text Spacing (Level AA)

Requirement: No loss of content or functionality occurs when users override text spacing to all of the following: line height (leading) to at least 1.5 times the font size; spacing following paragraphs to at least 2 times the font size; letter spacing (tracking) to at least 0.12 times the font size; word spacing to at least 0.16 times the font size.

Common failures:

Fixed-height containers that clip text when spacing is increased
Text overlapping other elements when letter/word spacing is increased
Buttons or navigation items that break when text spacing changes
Content disappearing behind overflow: hidden when text spacing is adjusted
Inline styles that override user text spacing preferences

1.4.13 Content on Hover or Focus (Level AA)

Requirement: Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true: Dismissible -- a mechanism exists to dismiss the additional content without moving pointer hover or keyboard focus (typically Escape key); Hoverable -- if pointer hover triggers the content, the pointer can be moved to the additional content without it disappearing; Persistent -- the additional content remains visible until the hover/focus trigger is removed, the user dismisses it, or the information is no longer valid.

Common failures:

Tooltips that disappear when the user moves the mouse toward them
Tooltips that cannot be dismissed with the Escape key
Custom dropdown menus that close when the mouse moves between the trigger and the menu
Hover content that obscures other content with no way to dismiss it
Tooltip content that disappears on a timer

Principle 2: Operable

User interface components and navigation must be operable.

Guideline 2.1 -- Keyboard Accessible

Make all functionality available from a keyboard.

2.1.1 Keyboard (Level A)

Requirement: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g., freehand drawing).

Common failures:

Custom JavaScript controls (dropdowns, sliders, carousels, tabs, accordions) that only respond to mouse clicks
onClick handlers on <div> or <span> elements without keyboard event handlers or proper role and tabindex
Drag-and-drop interfaces with no keyboard alternative
Hover-activated menus with no keyboard-accessible equivalent
Custom video players with controls that cannot be activated by keyboard
Canvas-based or WebGL interactions without keyboard alternatives
Swipe-only carousels on touch interfaces with no button controls

2.1.2 No Keyboard Trap (Level A)

Requirement: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface. If moving focus away requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

Common failures:

Modal dialogs that trap focus but do not cycle focus back to the beginning when Tab reaches the last focusable element
Embedded content (iframes, embedded maps, rich text editors) that captures keyboard focus with no way to exit
Third-party widgets (chat, social media embeds, video players) that trap keyboard focus
Focus entering a content area with no way to tab out (infinite tab loop)

2.1.4 Character Key Shortcuts (Level A)

Requirement: If a keyboard shortcut is implemented using only letter, punctuation, number, or symbol characters, then at least one of the following is true: the shortcut can be turned off; the shortcut can be remapped to use a modifier key (Ctrl, Alt); the shortcut is only active when the relevant UI component has focus.

Common failures:

Single-key shortcuts (e.g., pressing "s" to search) that conflict with speech recognition software or screen reader commands
Keyboard shortcuts that cannot be disabled or remapped
Global keyboard shortcuts that fire even when focus is inside form fields

Guideline 2.2 -- Enough Time

Provide users enough time to read and use content.

2.2.1 Timing Adjustable (Level A)

Requirement: For each time limit set by the content, at least one of the following is true: the user can turn off the time limit; the user can adjust the time limit to at least 10 times the default; the user is warned before time expires and given at least 20 seconds to extend the time (at least 10 times); the time limit is a real-time event (auction) where no alternative is possible; the time limit is essential; or the time limit exceeds 20 hours.

Common failures:

Session timeouts that log users out without warning
Auto-advancing slideshows/carousels with no pause control
Timed quizzes or forms that cannot be extended
Shopping cart timeouts that expire without notification

2.2.2 Pause, Stop, Hide (Level A)

Requirement: For moving, blinking, or scrolling content that starts automatically, lasts more than 5 seconds, and is presented in parallel with other content, a mechanism exists for the user to pause, stop, or hide it. For auto-updating content that starts automatically and is presented in parallel with other content, a mechanism exists for the user to pause, stop, hide, or control the frequency of updates. Exception: where the movement, blinking, scrolling, or auto-updating is essential.

Common failures:

Auto-scrolling news tickers or marquees with no pause button
Animated hero banners or carousels that cannot be paused
Background video loops with no stop control
Live data feeds (stock tickers, social feeds) that cannot be paused
CSS animations that run indefinitely without respecting prefers-reduced-motion

Guideline 2.3 -- Seizures and Physical Reactions

Do not design content in a way that is known to cause seizures or physical reactions.

2.3.1 Three Flashes or Below Threshold (Level A)

Requirement: Web pages do not contain anything that flashes more than three times in any one-second period, or the flash is below the general flash and red flash thresholds.

Common failures:

Video content with rapid flashing or strobing effects
Animated GIFs with rapid frame changes
JavaScript animations with rapid color or brightness changes
Auto-playing video ads with flashing content

Guideline 2.4 -- Navigable

Provide ways to help users navigate, find content, and determine where they are.

2.4.1 Bypass Blocks (Level A)

Requirement: A mechanism is available to bypass blocks of content that are repeated on multiple web pages (e.g., navigation, headers).

Common failures:

No "skip to main content" link
Skip links present in HTML but hidden without proper implementation (not revealed on focus)
No use of landmark roles (<main>, <nav>, <header>, <footer>) for assistive technology navigation
Single-page applications where repeated content cannot be bypassed

2.4.2 Page Titled (Level A)

Requirement: Web pages have titles that describe topic or purpose.

Common failures:

All pages sharing the same generic <title> (e.g., "My App")
Page titles that do not update on client-side route changes in SPAs
Titles that do not reflect the current page content (e.g., "Home" on every page)
Missing <title> element entirely

2.4.3 Focus Order (Level A)

Requirement: If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

Common failures:

Modals that open without moving focus into the modal
Modals that do not return focus to the trigger element when closed
tabindex values greater than 0 creating unexpected focus order
Visually reordered content (CSS Grid, Flexbox order) where DOM order does not match visual order
Dynamically inserted content that does not receive focus or is not in a logical tab position
Off-screen elements that receive focus when they should not

2.4.4 Link Purpose (In Context) (Level A)

Requirement: The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context (surrounding paragraph, list item, table cell, or heading).

Common failures:

Links that say only "Click here", "Read more", "Learn more" with no context
Multiple "Read more" links on a page that all look identical to screen readers
Links with no text content (image links without alt text)
URLs used as link text ("Visit https://example.com/page?id=123")
Icon-only links without accessible names

2.4.5 Multiple Ways (Level AA)

Requirement: More than one way is available to locate a web page within a set of web pages, except where the page is the result of, or a step in, a process. Examples: site search, site map, table of contents, navigation menus, and links between related pages.

Common failures:

Websites with only a navigation menu and no search functionality or site map
SPAs with no breadcrumbs, search, or alternative navigation

2.4.6 Headings and Labels (Level AA)

Requirement: Headings and labels describe topic or purpose.

Common failures:

Headings that are vague or generic ("Section 1", "Details", "Info")
Form labels that do not clearly describe what information is expected
Heading used for styling purposes rather than structure
Sections with no heading at all

2.4.7 Focus Visible (Level AA)

Requirement: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

Common failures:

CSS outline: none or outline: 0 applied globally without a custom replacement focus style
Focus styles that are visually indistinguishable from the unfocused state
Custom focus styles that lack sufficient contrast (below 3:1 against adjacent colors)
Focus indicators removed from specific elements for "cleaner" design
Browser default focus rings overridden with no replacement

2.4.11 Focus Not Obscured (Minimum) (Level AA) -- NEW IN WCAG 2.2

Requirement: When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content. At least a portion of the focused element must remain visible.

Common failures:

Sticky headers or footers that cover focused elements as the user tabs through the page
Cookie consent banners that overlay content and obscure focused elements
Chat widgets that float over page content and hide focused items
Modal overlays that do not fully trap focus, allowing focus to move to obscured elements behind the modal
Fixed-position notification bars that cover focused links or buttons

Guideline 2.5 -- Input Modalities

Make it easier for users to operate functionality through various inputs beyond keyboard.

2.5.1 Pointer Gestures (Level A)

Requirement: All functionality that uses multipoint or path-based gestures for operation can also be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential. Examples: pinch-to-zoom must have + / - button alternative; swipe must have arrow button alternative.

Common failures:

Pinch-to-zoom as the only way to zoom on maps or images (no + / - buttons)
Swipe-to-navigate carousels with no button controls
Complex multi-touch gestures with no single-pointer alternative
Path-based drawing required for authentication (pattern unlock)

2.5.2 Pointer Cancellation (Level A)

Requirement: For functionality operated using a single pointer, at least one of the following is true: no down-event (activation occurs on the up-event/release); the function can be aborted or undone after completion; the up-event reverses any outcome of the preceding down-event; completing the function on the down-event is essential.

Common failures:

Actions that trigger on mousedown/touchstart instead of mouseup/touchend/click
Drag operations that cannot be cancelled by releasing outside the target
Buttons that fire on pointer down with no way to abort

2.5.3 Label in Name (Level A)

Requirement: For user interface components with labels that include text or images of text, the accessible name contains the text that is presented visually.

Common failures:

A button visually labeled "Submit" but with aria-label="Send form data"
A link visually showing "Contact Us" but the accessible name is "Get in touch"
Icon buttons where the visual text says one thing but the aria-label says something different
aria-label completely overriding visible text instead of matching it

2.5.4 Motion Actuation (Level A)

Requirement: Functionality that can be operated by device motion or user motion can also be operated by user interface components, and responding to the motion can be disabled to prevent accidental actuation. Exceptions: the motion is essential for an accessible interface; the motion is used in a supported accessibility context.

Common failures:

"Shake to undo" with no button alternative
Tilt-to-scroll features with no conventional scroll alternative
Device rotation as the only way to trigger an action

2.5.7 Dragging Movements (Level AA) -- NEW IN WCAG 2.2

Requirement: All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.

Common failures:

Drag-and-drop list reordering with no up/down buttons or select-based alternative
Custom slider controls operable only by dragging (no click-on-track, no +/- buttons, no keyboard support)
Kanban boards (task cards between columns) with no non-drag interface
Map panning that only works via drag (no arrow keys or pan buttons)
File upload that only works via drag-and-drop (no file picker button)
Sortable tables where column reordering requires dragging

2.5.8 Target Size (Minimum) (Level AA) -- NEW IN WCAG 2.2

Requirement: The size of the target for pointer inputs is at least 24x24 CSS pixels, except when: the target has sufficient spacing (the offset between the target and every adjacent target is at least 24px); there is an equivalent control that meets this size; the target is inline within a sentence or block of text; the target size is determined by the user agent and not modified by the author; a particular presentation of the target is essential.

Common failures:

Small icon buttons (close X, menu dots, action icons) under 24x24 pixels
Dense navigation links packed tightly together
Inline action icons (edit, delete, settings) in table rows that are too small
Footer links crammed into a small space
Mobile tap targets that are too small or too close together
Custom checkbox/radio inputs smaller than 24x24px

Principle 3: Understandable

Information and the operation of the user interface must be understandable.

Guideline 3.1 -- Readable

Make text content readable and understandable.

3.1.1 Language of Page (Level A)

Requirement: The default human language of each web page can be programmatically determined (via the lang attribute on the <html> element).

Common failures:

Missing lang attribute on the <html> element (one of the most common WCAG failures found by automated tools)
Incorrect lang value (e.g., lang="en" on a page written in Spanish)
Using an invalid language code

3.1.2 Language of Parts (Level AA)

Requirement: The human language of each passage or phrase in the content can be programmatically determined, except for proper names, technical terms, words of indeterminate language, and words that have become part of the vernacular of the surrounding text.

Common failures:

Foreign language quotes or phrases without a lang attribute on the containing element
Multilingual content where language switches are not marked up
Product names in other languages not marked (usually acceptable as proper names)

Guideline 3.2 -- Predictable

Make web pages appear and operate in predictable ways.

3.2.1 On Focus (Level A)

Requirement: When any user interface component receives focus, it does not initiate a change of context (e.g., submitting a form, opening a new window, moving focus to another component).

Common failures:

Select dropdowns that navigate to a new page on focus/change without a submit button
Form fields that submit the form when receiving focus
Links or buttons that open new windows on focus (before activation)

3.2.2 On Input (Level A)

Requirement: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

Common failures:

Select dropdowns that navigate on change without a "Go" button
Radio buttons that submit a form or navigate when selected
Checkboxes that trigger page navigation
Form fields that auto-submit when a value is entered
Filtering controls that reload the page on every keystroke without warning

3.2.3 Consistent Navigation (Level AA)

Requirement: Navigational mechanisms that are repeated on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

Common failures:

Main navigation items appearing in different order on different pages
Footer links rearranged between pages
Utility navigation (search, login, cart) moving to different positions across pages

3.2.4 Consistent Identification (Level AA)

Requirement: Components that have the same functionality within a set of web pages are identified consistently. For example, a search icon should always be labeled "Search" (not "Find" on some pages and "Search" on others).

Common failures:

A search function labeled "Search" on some pages and "Find" on others
Print icons labeled differently across pages
Inconsistent labels for the same action ("Submit" vs. "Send" vs. "Go" for the same form action)

3.2.6 Consistent Help (Level A) -- NEW IN WCAG 2.2

Requirement: If a web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple web pages within a set of web pages, they occur in the same relative order to other page content unless a change is initiated by the user. The help mechanisms covered are: human contact details, human contact mechanism, self-help option, and a fully automated contact mechanism.

Common failures:

A "Contact Us" link appearing in the header on some pages and the footer on others
Chat widget appearing in the bottom-right on some pages and bottom-left on others
Help phone number placed in different locations across the site
FAQ link position changing between pages

Guideline 3.3 -- Input Assistance

Help users avoid and correct mistakes.

3.3.1 Error Identification (Level A)

Requirement: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

Common failures:

Form validation that only highlights the field in red with no text message
Error messages that do not identify which field has the error
Errors announced only visually (red border) with no programmatic association to the field
Generic error messages ("Something went wrong") without identifying the specific field or issue
Errors that appear only at the top of a long form with no way to navigate to the specific field

3.3.2 Labels or Instructions (Level A)

Requirement: Labels or instructions are provided when content requires user input.

Common failures:

Form fields with only placeholder text and no visible label (placeholders disappear when the user starts typing)
Group of radio buttons or checkboxes with no group label (<fieldset>/<legend>)
Complex input formats (phone, date, SSN) with no format instructions
Required fields not indicated before the form

3.3.3 Error Suggestion (Level AA)

Requirement: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.

Common failures:

"Invalid email" without specifying what is wrong (e.g., "Email must include an @ symbol")
"Invalid date" without showing the expected format
Password validation that just says "Invalid password" without listing requirements
Autocomplete suggestions not provided when input is close to a valid value

3.3.4 Error Prevention (Legal, Financial, Data) (Level AA)

Requirement: For web pages that cause legal commitments or financial transactions for the user, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: submissions are reversible; data entered is checked and the user is given an opportunity to correct it; a mechanism is available for reviewing, confirming, and correcting information before finalizing.

Common failures:

One-click purchase with no confirmation step
Account deletion with no confirmation dialog
Financial transactions that cannot be reviewed before submission
Form submissions that cannot be corrected after submission
No "Are you sure?" confirmation for destructive actions

3.3.7 Redundant Entry (Level A) -- NEW IN WCAG 2.2

Requirement: Information previously entered by or provided to the user that is required to be entered again in the same process is either auto-populated or available for the user to select. Exceptions: when re-entering the information is essential (e.g., confirming a password), when the information is required to ensure security, or when previously entered information is no longer valid.

Common failures:

Multi-step forms that ask for the same information on different steps (name, email, address)
Checkout processes that require re-entering billing address as shipping address with no "same as" option
Account registration flows that require re-typing data from a previous step
Application forms that ask for the same contact information in multiple sections

3.3.8 Accessible Authentication (Minimum) (Level AA) -- NEW IN WCAG 2.2

Requirement: A cognitive function test (such as remembering a password, solving a puzzle, performing a calculation) is not required for any step in an authentication process, unless at least one of the following is true: an alternative method is available that does not rely on a cognitive function test; a mechanism is available to assist the user in completing the cognitive function test (e.g., password managers can auto-fill, copy/paste is allowed); the cognitive function test is to recognize objects (image CAPTCHA with common objects); the cognitive function test is to identify non-text content the user provided (pick your uploaded photos).

Common failures:

Login forms that block password managers from auto-filling (preventing autocomplete)
Login forms that prevent pasting into the password field
CAPTCHA that requires transcribing distorted text with no accessible alternative
Two-factor authentication that requires memorizing and manually typing a code (rather than allowing copy/paste)
Authentication that requires solving math problems or logic puzzles
Custom authentication widgets that do not support browser autofill

Principle 4: Robust

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

Guideline 4.1 -- Compatible

Maximize compatibility with current and future user agents, including assistive technologies.

4.1.1 Parsing (REMOVED IN WCAG 2.2)

Note: This criterion existed in WCAG 2.0 and 2.1 (Level A) and required that content implemented using markup languages have elements with complete start and end tags, be nested according to specifications, not contain duplicate attributes, and have unique IDs. It was removed in WCAG 2.2 because modern browsers and assistive technologies handle HTML parsing errors robustly, making this criterion obsolete. Organizations conforming to WCAG 2.1 still need to meet this criterion; those conforming to WCAG 2.2 do not.

4.1.2 Name, Role, Value (Level A)

Requirement: For all user interface components (including form elements, links, and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

Common failures:

Custom components (dropdowns, tabs, accordions, modals, sliders) built with <div> and <span> without ARIA roles, states, and properties
Toggle buttons that do not convey pressed/unpressed state (aria-pressed)
Expandable sections that do not convey expanded/collapsed state (aria-expanded)
Custom checkboxes/radio buttons missing role="checkbox" or role="radio" and aria-checked
Tab interfaces missing role="tablist", role="tab", role="tabpanel", and aria-selected
Modal dialogs missing role="dialog" and aria-modal="true"
Dynamic content updates that do not notify assistive technology (missing aria-live regions)
Custom form controls where the programmatic value does not match the displayed value
Menu buttons that do not indicate a menu will appear (aria-haspopup)
Links styled as buttons (or vice versa) without proper role

4.1.3 Status Messages (Level AA)

Requirement: In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus. This means status updates, success messages, error messages, and progress indicators must be announced to screen readers automatically.

Common failures:

Toast notifications that appear visually but are not in an aria-live region
Form success/error messages that appear after submission but are not announced to screen readers
Search results count updates ("Showing 15 results") not announced
Shopping cart item count updates not announced
Progress indicators (loading spinners, progress bars) not communicated to assistive technology
"Added to cart" confirmations that are only visual
Inline validation messages not associated with aria-live or role="alert" / role="status"

Summary: Complete WCAG 2.2 AA Criteria Count

Perceivable (Guideline 1)

| # | Name | Level | WCAG Version | |---|------|-------|-------------| | 1.1.1 | Non-text Content | A | 2.0 | | 1.2.1 | Audio-only and Video-only (Prerecorded) | A | 2.0 | | 1.2.2 | Captions (Prerecorded) | A | 2.0 | | 1.2.3 | Audio Description or Media Alternative (Prerecorded) | A | 2.0 | | 1.2.4 | Captions (Live) | AA | 2.0 | | 1.2.5 | Audio Description (Prerecorded) | AA | 2.0 | | 1.3.1 | Info and Relationships | A | 2.0 | | 1.3.2 | Meaningful Sequence | A | 2.0 | | 1.3.3 | Sensory Characteristics | A | 2.0 | | 1.3.4 | Orientation | AA | 2.1 | | 1.3.5 | Identify Input Purpose | AA | 2.1 | | 1.4.1 | Use of Color | A | 2.0 | | 1.4.2 | Audio Control | A | 2.0 | | 1.4.3 | Contrast (Minimum) | AA | 2.0 | | 1.4.4 | Resize Text | AA | 2.0 | | 1.4.5 | Images of Text | AA | 2.0 | | 1.4.10 | Reflow | AA | 2.1 | | 1.4.11 | Non-text Contrast | AA | 2.1 | | 1.4.12 | Text Spacing | AA | 2.1 | | 1.4.13 | Content on Hover or Focus | AA | 2.1 |

Total Perceivable at AA: 20 criteria (10 Level A + 10 Level AA)

Operable (Guideline 2)

| # | Name | Level | WCAG Version | |---|------|-------|-------------| | 2.1.1 | Keyboard | A | 2.0 | | 2.1.2 | No Keyboard Trap | A | 2.0 | | 2.1.4 | Character Key Shortcuts | A | 2.1 | | 2.2.1 | Timing Adjustable | A | 2.0 | | 2.2.2 | Pause, Stop, Hide | A | 2.0 | | 2.3.1 | Three Flashes or Below Threshold | A | 2.0 | | 2.4.1 | Bypass Blocks | A | 2.0 | | 2.4.2 | Page Titled | A | 2.0 | | 2.4.3 | Focus Order | A | 2.0 | | 2.4.4 | Link Purpose (In Context) | A | 2.0 | | 2.4.5 | Multiple Ways | AA | 2.0 | | 2.4.6 | Headings and Labels | AA | 2.0 | | 2.4.7 | Focus Visible | AA | 2.0 | | 2.4.11 | Focus Not Obscured (Minimum) | AA | 2.2 | | 2.5.1 | Pointer Gestures | A | 2.1 | | 2.5.2 | Pointer Cancellation | A | 2.1 | | 2.5.3 | Label in Name | A | 2.1 | | 2.5.4 | Motion Actuation | A | 2.1 | | 2.5.7 | Dragging Movements | AA | 2.2 | | 2.5.8 | Target Size (Minimum) | AA | 2.2 |

Total Operable at AA: 20 criteria (14 Level A + 6 Level AA)

Understandable (Guideline 3)

| # | Name | Level | WCAG Version | |---|------|-------|-------------| | 3.1.1 | Language of Page | A | 2.0 | | 3.1.2 | Language of Parts | AA | 2.0 | | 3.2.1 | On Focus | A | 2.0 | | 3.2.2 | On Input | A | 2.0 | | 3.2.3 | Consistent Navigation | AA | 2.0 | | 3.2.4 | Consistent Identification | AA | 2.0 | | 3.2.6 | Consistent Help | A | 2.2 | | 3.3.1 | Error Identification | A | 2.0 | | 3.3.2 | Labels or Instructions | A | 2.0 | | 3.3.3 | Error Suggestion | AA | 2.0 | | 3.3.4 | Error Prevention (Legal, Financial, Data) | AA | 2.0 | | 3.3.7 | Redundant Entry | A | 2.2 | | 3.3.8 | Accessible Authentication (Minimum) | AA | 2.2 |

Total Understandable at AA: 13 criteria (7 Level A + 6 Level AA)

Robust (Guideline 4)

| # | Name | Level | WCAG Version | |---|------|-------|-------------| | 4.1.2 | Name, Role, Value | A | 2.0 | | 4.1.3 | Status Messages | AA | 2.1 |

Total Robust at AA: 2 criteria (1 Level A + 1 Level AA)

Note: 4.1.1 Parsing (Level A in WCAG 2.0/2.1) was removed in WCAG 2.2.

Grand Total: 55 criteria for WCAG 2.2 AA conformance

(32 Level A + 23 Level AA = 55 total)

Note: Some published sources cite 56 criteria at AA. The discrepancy is because WCAG 2.2 removed 4.1.1 Parsing from 2.1's 50 A/AA criteria, then added 6 new A/AA criteria, yielding 55. Sources that count 56 may be including 4.1.1 for backward-compatibility tracking or counting differently across versions.

Quick Reference: Criteria New in WCAG 2.1 (vs 2.0)

These criteria were added in WCAG 2.1 (2018). If your baseline is WCAG 2.0 AA, these are the additions you need at A/AA level:

| # | Name | Level | |---|------|-------| | 1.3.4 | Orientation | AA | | 1.3.5 | Identify Input Purpose | AA | | 1.4.10 | Reflow | AA | | 1.4.11 | Non-text Contrast | AA | | 1.4.12 | Text Spacing | AA | | 1.4.13 | Content on Hover or Focus | AA | | 2.1.4 | Character Key Shortcuts | A | | 2.5.1 | Pointer Gestures | A | | 2.5.2 | Pointer Cancellation | A | | 2.5.3 | Label in Name | A | | 2.5.4 | Motion Actuation | A | | 4.1.3 | Status Messages | AA |

Total: 12 new criteria in WCAG 2.1 (5 Level A + 7 Level AA)

Quick Reference: Criteria New in WCAG 2.2 (vs 2.1)

| # | Name | Level | |---|------|-------| | 2.4.11 | Focus Not Obscured (Minimum) | AA | | 2.5.7 | Dragging Movements | AA | | 2.5.8 | Target Size (Minimum) | AA | | 3.2.6 | Consistent Help | A | | 3.3.7 | Redundant Entry | A | | 3.3.8 | Accessible Authentication (Minimum) | AA |

Total: 6 new A/AA criteria in WCAG 2.2 (2 Level A + 4 Level AA)

Plus 4.1.1 Parsing was removed.

ADA Web Accessibility Compliance

ADA Web Accessibility Compliance -- Research Brief

1. WHO Must Comply

The Short Answer

1.1 Government Entities (ADA Title II)

1.2 Private Businesses (ADA Title III)

1.3 Does a Business Need a Physical Location?

1.4 Specific Business Types

1.5 Nonprofits and Associations

1.6 Exemptions -- Very Narrow

1.7 Individual Liability

1.8 Section 508 -- Federal Agencies and Contractors

1.9 State Laws That Expand Coverage

2. WHAT -- The Spec (WCAG 2.1 Level AA)

Four Principles (POUR)

Key Contrast Ratios

How Bad Is It? (WebAIM Million 2025)

3. WHEN -- Deadlines

4. WHERE -- What Digital Content Is Covered

Covered

Exceptions (Narrow)

5. WHY -- Carrot & Stick

The Carrot

The Stick

Lawsuit Trends

Serial Litigation -- The Business Model

Notable Cases

Water District-Relevant DOJ Actions

6. SCORING & ENFORCEMENT -- Is It All-or-Nothing?

Conformance Is Technically Binary

Can You Be Sued for a Single Violation?

How Courts and DOJ Evaluate Compliance

Good Faith Effort

Building a Documented Good Faith Effort

Safe Harbor

Conformance vs. Compliance

How Plaintiff Attorneys Build Cases

Practical Guidance

7. TOOLS

7.1 WAVE (WebAIM)

7.2 AI Tools

7.3 Video Editing Tools

7.4 ⚠️ WARNING: Overlay Tools (accessiBe, UserWay, AudioEye)

7.5 Other Notable Tools

8. WATER DISTRICT-SPECIFIC CONCERNS

What AWE Members Need to Make Accessible

Vendor Contracts

KEY SOURCES

ADA Web Accessibility -- Presentation Notes

Setup Checklist

Revised Format (45 Minutes)

SLIDE-BY-SLIDE NOTES

Slide 1: Title

Slide 2: Opening Hook (0:00 - 1:30)

Slides 3-7: WHO Must Comply (1:30 - 6:00)

Slides 8-11: WHAT -- The Spec (6:00 - 10:00)

Slides 12-13: WHEN -- Deadlines (10:00 - 12:00)

Slides 14-15: WHERE -- What's Covered (12:00 - 14:00)

Slides 16-19: WHY -- Carrot & Stick (14:00 - 18:00)

Slides 20-21: Overlays Warning (18:00 - 21:00)

Slides 22-24: Scoring & Enforcement (21:00 - 24:00)

Slides 25-28: Tools (24:00 - 28:00)

Slides 29-30: AI + Claude Skill (28:00 - 30:00)

Live Demo (30:00 - 35:00)

Slide 31: Q&A (35:00 - 45:00)

Key Stats Quick Reference

Closing Line

Website Execution Plan -- Labs Homepage + ADA Compliance Topic

Overview

Part A: Labs Homepage Redesign

Vision

Brand Messaging

Page Structure

Design Direction

Route Structure

Part B: ADA Compliance Topic Site

Concept: "The 5 W's" as a Scrolling Journey

Interactive ADA Examples -- Good vs. Bad

Live HTML Editor -- The Showstopper Feature

Overlay Warning Page (/topics/ada-compliance/overlays)

Overlay Warning Page (`/topics/ada-compliance/overlays`)

Scoring Page (`/topics/ada-compliance/scoring`)

Part C: Claude Skill Appendix (`/topics/ada-compliance/skill`)