Back to reviews and guides

Website ADA Compliance in California: Website Requirements Explained

This article explains Website ADA Compliance in California: which laws and standards apply, who must comply, a step-by-step remediation plan, common mistakes, and how to respond to demand letters. It recommends WCAG 2.1 AA as the baseline and lists practical checks, tools and contract tips.

Quick answer: Website ADA Compliance in California

Website ADA compliance in California means making your site usable by people with disabilities and aligning with accepted technical standards. California businesses should aim for WCAG 2.1 AA as the operational baseline and treat accessibility as ongoing work, not a one-time project.

Why California is different from other states

California has state civil-rights laws that private plaintiffs use alongside federal law. Courts and demand-letter practices in California have produced many lawsuits and settlements over inaccessible websites. That makes the enforcement climate more active than in many other states.

Which laws and standards apply

  • Americans with Disabilities Act (ADA) Title III: Applies to places of public accommodation. Courts have interpreted website access in the context of the ADA when a website has a nexus with a physical place of business.
  • California Unruh Civil Rights Act: Gives a private right of action for disability discrimination. Courts have applied it to website access when ADA standards are violated.
  • California Disabled Persons Act: Provides additional state protections and remedies for people with disabilities.
  • Technical standard: Use WCAG 2.1 AA as the practical benchmark. Also follow WAI-ARIA where needed and ensure PDFs are tagged and accessible.

Who needs to make a website accessible in California

Any business that offers goods or services to the public should prioritise accessibility. That includes retailers, restaurants, professional services, entertainment, and government entities. Even if your business is online-only, you can still face demand letters and litigation, so assess legal risk with counsel.

Concrete accessibility requirements to check first

Below are the most common technical items that cause legal claims. Use them as a triage checklist.

  • Semantic HTML: headings in order, correct use of <nav>, <main>, landmarks and lists.
  • Alternative text for images: meaningful alt for content images, empty alt for decorative images.
  • Keyboard navigation: all functionality reachable by keyboard alone.
  • Focus order and visible focus indicator: logical tab order and clear focus styling.
  • Forms and labels: explicit <label> associations, clear error identification and instructions.
  • Color contrast: meet WCAG contrast ratios (for normal text aim for 4.5:1).
  • Captions and transcripts: captions for prerecorded video and transcripts where useful.
  • Accessible PDFs: tagged structure, readable text, logical reading order.
  • ARIA: use WAI-ARIA only to enhance semantics, not to replace native HTML.

Step-by-step plan to reach and keep compliance

Follow these phases in order. Each one produces artifacts you can show to counsel or a court.

1. Discovery and scope

  • List all customer-facing pages and transactions: store locators, checkout flows, booking, PDFs, apps.
  • Record platforms and third-party integrations that affect accessibility.

2. Audit (automated plus manual)

  • Run automated tools like Axe, WAVE or Lighthouse to find obvious barriers.
  • Perform manual tests: keyboard-only navigation, screen reader testing (NVDA, VoiceOver), and colour contrast checks.
  • Prioritise barriers by impact on functionality and legal exposure.

3. Remediation plan

  • Create a scoped backlog with agreed conformance targets (for example, WCAG 2.1 AA for public pages).
  • Assign owner, timeline and testing acceptance criteria for each fix.

4. Implementation and acceptance testing

  • Develop fixes using semantic HTML and accessible components.
  • Include manual QA steps: keyboard checks, screen reader passes, and user testing with people with disabilities when possible.
  • Document test results and keep a change log.

5. Accessibility statement and contact path

  • Publish an accessibility statement that declares the target standard and lists a contact method for accessibility requests.
  • Offer a clear process and reasonable response time for users to request help or report barriers.

6. Ongoing monitoring and governance

  • Automate weekly scans and schedule quarterly manual checks.
  • Train product teams to test accessibility in development and code review.
  • Maintain documentation for releases and significant changes.

Common mistakes that cause the biggest exposure

  • Relying only on automated tools. They miss keyboard and screen reader problems.
  • No documented remediation plan after an audit. That raises credibility issues in disputes.
  • Using ARIA to fix structural HTML problems. ARIA is not a substitute for correct tags.
  • Ignoring PDFs and downloadable files. They are often targeted in complaints.
  • No publicly accessible contact method or accessibility statement. That makes demand letters more likely.

How to respond to a demand letter or lawsuit in California

This is not legal advice. If you receive a demand letter, follow these practical steps while you get counsel involved:

  • Preserve evidence: screenshots, web server logs, and records of posted accessibility statements.
  • Run an immediate triage audit to identify high-impact barriers you can fix quickly.
  • Draft a remediation timeline and begin fixes that reduce immediate access barriers.
  • Consult an attorney experienced in accessibility litigation for next steps and settlement options.

Contract tips when hiring vendors for accessibility work

  • Define the success criteria: specific WCAG level, scope of pages, and acceptance tests.
  • Require evidence: test reports, user test notes, video walkthroughs and sign-off by a named tester.
  • Include maintenance terms so accessibility does not regress after launch.
  • Make security and privacy controls explicit when the vendor will view user data or logs.

Tools and resources

  • Automated scanners: Axe, WAVE, Lighthouse.
  • Screen readers: NVDA for Windows, VoiceOver for macOS and iOS.
  • Standards: WCAG 2.1 documentation and WAI-ARIA guidelines.

Practical examples businesses should prioritise now

  • Checkout and payment flows. Make sure every step is keyboard accessible and form errors are clear.
  • Booking and reservation systems. Ensure dates, seat selection and confirmation messages are announced by screen readers.
  • PDF menus, contracts and brochures. Provide tagged PDFs or HTML alternatives.

Final checklist before you call a lawyer

  • Do you have an up-to-date audit and remediation plan?
  • Is your accessibility statement visible and actionable?
  • Are critical user flows keyboard and screen reader usable?
  • Are PDFs and media captioned or otherwise accessible?

Website ADA compliance in California is both a legal risk and a customer-experience issue. Treat accessibility as continuous improvement, show documented efforts, and use WCAG 2.1 AA as your working standard. When in doubt, get an audit and specialist legal advice tailored to your business.