Web Accessibility and ADA Compliance: What California Businesses Need to Know

Back to Blog

California businesses face a disproportionate share of ADA website accessibility lawsuits. The state accounts for a substantial portion of all federal ADA Title III web accessibility litigation in the United States — a pattern driven by California's plaintiff-friendly legal environment and the high concentration of businesses that operate primarily through digital channels.

The legal exposure is real and growing. Courts have repeatedly ruled that websites constitute "places of public accommodation" under Title III of the Americans with Disabilities Act, meaning that inaccessible websites expose businesses to the same legal liability as a physical location with an inaccessible entrance. Settlements typically range from $5,000 to $25,000 plus remediation costs, and serial litigants have made web accessibility lawsuits a systematic practice targeting small businesses.

Beyond the legal risk, accessibility is also simply the right practice — approximately 26% of American adults live with some form of disability. An inaccessible website excludes a significant portion of your potential customers.

The Legal Framework: ADA Title III and Web Accessibility

The Americans with Disabilities Act was enacted in 1990, before the commercial internet existed. The statute itself does not mention websites. The Department of Justice has consistently interpreted Title III to cover websites of businesses that offer goods or services to the public, and courts have largely followed this interpretation — though there has been variance in how different federal circuits apply the law.

In 2024, the DOJ finalized a rule explicitly requiring state and local government websites to meet WCAG 2.1 AA standards. While this rule directly governs government entities, it reinforces WCAG 2.1 AA as the de facto legal standard for web accessibility across all sectors. Plaintiffs' attorneys use this standard as the benchmark in litigation against private businesses as well.

WCAG 2.1 AA: What It Requires in Practice

The Web Content Accessibility Guidelines (WCAG) 2.1 AA is the international technical standard for web accessibility, published by the W3C. It is organized around four principles: content must be Perceivable, Operable, Understandable, and Robust (POUR). AA is the middle conformance level — above A (minimum) and below AAA (enhanced, which is often impractical to achieve for all content).

In practical terms, WCAG 2.1 AA compliance requires your website to meet the following categories of requirements:

Color Contrast Ratios

Normal text (under 18pt or 14pt bold) must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt+ or 14pt+ bold) requires at least 3:1. This requirement exists because low-contrast text is difficult or impossible to read for users with low vision or color blindness. Many common design choices — light gray text on white backgrounds, gold text on light backgrounds, colored buttons with insufficient contrast — fail this requirement.

Contrast ratios are measurable with free tools. The WebAIM Contrast Checker, axe browser extension, and Chrome DevTools accessibility inspector all calculate contrast ratios automatically. There is no reasonable excuse for shipping a website with contrast failures in 2026 — the tooling is trivial to use.

Keyboard Navigation

Every interactive element on your website — navigation links, buttons, form fields, modal dialogs, dropdown menus — must be reachable and operable using only a keyboard, without requiring a mouse. This is essential for users with motor disabilities who cannot use a pointing device, as well as screen reader users who navigate primarily by keyboard.

The visible focus indicator is the most commonly failed keyboard navigation requirement. Many websites suppress the default browser focus ring (the blue outline around focused elements) for aesthetic reasons, leaving keyboard users with no visual indication of where they are on the page. This is a WCAG 2.1 AA failure and is one of the most commonly cited issues in accessibility lawsuits.

Screen Reader Compatibility

Screen readers — assistive technology used by blind and low-vision users — read web page content aloud and allow navigation through keyboard commands. They rely on the semantic structure of HTML to understand and communicate page content. Accessibility failures that are invisible visually are exposed immediately when a screen reader attempts to navigate the page.

Key requirements for screen reader compatibility include:

• Semantic HTML: Use proper heading hierarchy (H1 through H6) to structure content. Use <nav>, <main>, <aside>, and <footer> landmark elements to define page regions.
• ARIA labels: Interactive elements that lack descriptive text (icon-only buttons, image links) must have ARIA labels that describe their purpose. A search button that contains only a magnifying glass icon must have aria-label="Search".
• Form labels: Every form input must be programmatically associated with a visible label using the for attribute or aria-labelledby. Placeholder text is not a sufficient substitute for a label.
• Live regions: Dynamic content updates (error messages, success notifications, loading states) must be announced to screen readers using aria-live regions.

Alternative Text for Images

Every image that conveys information must have descriptive alternative text in the alt attribute. Screen readers read this text aloud in place of the image. Alt text describes what is visually present and relevant — not "image of" (the screen reader already knows it's an image) but a description of what the image communicates in context.

Decorative images — background textures, dividers, icons that are supplementary to visible text — should have empty alt attributes (alt=""), which instructs the screen reader to skip them.

Captions and Transcripts

Video content with audio requires synchronized captions (closed captions). Audio-only content (podcasts, phone recordings) requires transcripts. This requirement serves users who are deaf or hard of hearing, as well as users who prefer to read content in a noisy environment or who are not native speakers of the language.

Common Accessibility Tools for Testing and Auditing

"Automated accessibility tools catch roughly half of WCAG violations. The other half require human judgment — navigating the site by keyboard, testing with a real screen reader, and evaluating the experience from the perspective of someone who depends on these tools every day."

IT Center Accessibility Audits and Remediation

IT Center provides web accessibility audits for California businesses that need to understand their current WCAG 2.1 AA compliance status and reduce legal exposure. Our audit process combines automated scanning (axe DevTools, Lighthouse) with manual testing using keyboard navigation and screen reader evaluation on both desktop and mobile viewports.

The output is a prioritized remediation report that distinguishes between critical failures (likely to appear in litigation), significant failures (WCAG 2.1 AA violations that affect specific user groups), and best practice recommendations. We then offer remediation services — fixing the identified issues in code — and post-remediation verification to confirm compliance before the audit is closed.

For businesses building new websites or web applications, incorporating accessibility requirements into the initial design and development process is dramatically less expensive than retrofitting a completed site. Every website IT Center builds is developed with WCAG 2.1 AA compliance as a standard requirement, not an add-on.