Your Web Developer Can Now Be Sued for ADA Violations: The $2M Case That Changed Everything

In 2017, the California Department of Parks and Recreation (DPR) launched ReserveCalifornia.com — the sole online portal for booking campsites, cabins, and tours across all 300+ California state parks. The contract to build and maintain the site was worth $66 million, awarded to Conduent State & Local Solutions (a Xerox spinoff with $5.4B in revenue and 54,000 employees) and its subcontractor US eDirect.

The contract explicitly required:
• WCAG 2.0 Level A and AA compliance
• Section 508 of the Rehabilitation Act compliance
• Federal and California state accessibility standards

What Conduent delivered:
• A website completely unusable with screen readers
• Missing page titles and headings
• Unlabeled form controls and images
• Non-compliant color schemes
• No alternatives to visual-only interface elements

The most damning detail: Conduent claimed to have run two automated accessibility checkers with zero errors. Accessibility experts noted that even basic automated tools would have flagged obvious violations — suggesting the testing was either never performed or the results were deliberately ignored.

Bryan Bashin, who relies on screen-reader software, attempted to book a camping reservation on launch day. He couldn't. Like hundreds of thousands of other blind Californians, he was completely shut out of the state's most popular recreational resource.

Bashin didn't sue the California Department of Parks. He sued the developers who built the site. His legal team at Relman Colfax PLLC and TRE Legal Practice used three groundbreaking legal theories:

1. California False Claims Act (Qui Tam) Conduent's $66M contract required accessibility compliance. Conduent certified compliance in its payment invoices to DPR. Those certifications were false. Under California's False Claims Act, any citizen can file a whistleblower lawsuit ("qui tam" action) against companies that defraud the government. Bashin reported the fraud to state authorities first. When they declined to pursue it, he filed suit on behalf of California.

2. Unruh Civil Rights Act (Aiding Denial of Access) California Civil Code Section 51(b) prohibits not just denying equal access — but also aiding or inciting the denial of access. The court found that a developer delivering an inaccessible website could constitute aiding the denial of access to a public accommodation.

3. ADA Interference (42 U.S.C. Section 12203(b)) Under the ADA, it's unlawful to "interfere" with the exercise of disability rights. Judge Brad Seligman ruled that delivering an inaccessible website constitutes interference. His exact words: *"The interference alleged is manifest — the very website that is the portal to access to the public benefit, is unavailable to persons with disabilities."*

Why This Matters: Before Bashin, web developers operated in a liability-free zone. They could promise accessibility, fail to deliver, and face zero consequences — the website owner absorbed all the risk. Bashin v. Conduent destroyed that arrangement.

Judge Evelio Grillo of the Alameda County Superior Court approved the final settlement on November 8, 2023:

• $87,500 — Bashin's 35% qui tam relator share (whistleblower reward)
• $162,500 — Recovered by the State of California
• $1,750,000 — Remaining plaintiff claims and attorney fees
• Total monetary: $2,000,000+

But that's not the full cost. The settlement also required Conduent and US eDirect to fund:
• A comprehensive accessibility audit by Prime Access Consulting (a nationally recognized firm founded by Sina Bahram, a White House Champion of Change)
• Full remediation of ReserveCalifornia.com based on audit findings
• Ongoing compliance monitoring

Legal commentators estimate the total cost to defendants — including legal fees, the audit, and remediation — reached $3.5 to $4 million.

The Lesson: A $66 million contract. A $2 million settlement. Millions more in legal fees and remediation. All because automated-only accessibility testing was treated as sufficient when it catches only about 30% of WCAG violations.

If You Build Government Websites: Every government web contract now carries personal liability risk. If you promise WCAG compliance and don't deliver, you're not just breaching a contract — you may be committing fraud under your state's False Claims Act. Any citizen can sue you as a whistleblower.

If You Rely on Automated Testing Only: Conduent claimed "zero errors" from automated testing. The court didn't care. Automated tools catch roughly 30% of WCAG issues. If your accessibility QA consists of running an automated scan and calling it done, you're building the same legal exposure Conduent had.

If You Use Overlay Widgets: Overlay vendors have already faced their own legal reckoning (AccessiBe's $1M FTC fine). If you deploy an overlay on a government site and claim compliance, you've potentially made a false certification on a government contract.

What You Should Do:
• Include genuine accessibility testing (manual + automated) in every project
• Never certify WCAG compliance based solely on automated scans
• Build accessibility into your development process from the start
• Carry professional liability insurance that covers accessibility claims
• Document your testing methodology thoroughly
• Consider engaging accessibility specialists for government contracts

Bashin v. Conduent offers both a warning and a weapon for government entities:

The Warning:
• Your vendor's accessibility promises may be worthless
• "We tested with zero errors" may mean they never actually tested
• You're still liable as the website owner — even if your vendor failed you
• Automated-only testing is not sufficient for contract compliance

The Weapon:
• Strong accessibility requirements in contracts create leverage
• Vendor indemnification clauses can shift liability
• If your vendor falsely certified compliance, you may have your own False Claims Act case against them
• Post-breach, you can require vendor-funded remediation (like the Bashin settlement)

Contract Provisions You Need:
• Explicit WCAG 2.1 Level AA compliance requirements
• Manual + automated testing mandates (not just automated)
• Third-party accessibility audit provisions
• Vendor indemnification for accessibility violations
• Regular compliance reporting with verifiable methodology
• Right to independent accessibility testing at vendor's expense

With the April 2026 deadline approaching, government entities need to audit both their websites AND their vendor contracts. If your vendor promised accessibility and didn't deliver, Bashin shows you the remedy.

The California False Claims Act that enabled the Bashin case has equivalents in 29 other states plus DC. Government web developers in any of these jurisdictions face the same risk:

High Litigation Volume States (Highest Risk):
• California, New York, Florida, Illinois, Texas

States With Active False Claims Acts:
• Colorado, Connecticut, Delaware, Georgia, Indiana, Iowa, Maryland, Massachusetts, Michigan, Minnesota, Montana, Nevada, New Hampshire, New Jersey, New Mexico, North Carolina, Oklahoma, Rhode Island, Tennessee, Vermont, Virginia, Washington, plus DC

The federal False Claims Act also applies to federally-funded websites and programs, extending potential liability nationwide.

What Triggers Exposure:
• Government web development contract with accessibility requirements
• Certifications of compliance (explicit or implicit) in invoices or deliverables
• Actual accessibility failures discoverable by any user
• A motivated individual willing to file a qui tam complaint

The combination of the April 2026 ADA deadline forcing government entities to demand WCAG compliance in contracts, and the Bashin precedent showing developers can be held liable, creates a perfect storm. Developers who promise and don't deliver are now squarely in the crosshairs.

Testing:
• Combine automated tools with manual testing (screen reader, keyboard-only navigation)
• Never certify compliance based solely on automated scan results
• Test with actual assistive technology users when possible
• Document your testing methodology in detail

Contracts:
• Be honest about what you can certify and what requires specialist review
• Include accessibility testing scope and limitations in contracts
• Don't promise WCAG compliance if you haven't verified it manually
• Consider partnering with accessibility consultants for government work

Process:
• Build accessibility into design and development from day one
• Train your team on WCAG 2.1 Level AA requirements
• Include accessibility acceptance criteria in your QA process
• Maintain detailed logs of all accessibility testing performed

✅ For Government Entities Hiring Developers:

• Require both manual and automated accessibility testing in RFPs
• Include third-party accessibility audit rights in contracts
• Mandate regular compliance reporting with methodology details
• Include indemnification clauses specifically for accessibility violations
• Verify vendor claims independently — run your own scan
• Don't accept "zero errors" from automated testing as proof of compliance