Converge Accessibility

Introduction

Can Web Developers be Sued for the Inaccessible Sites They Create for Clients?

Can Web Developers be Sued for the Inaccessible Sites They Create for Clients?

How Did This Question Come Up?

While I was attending the Digital Accessibility Legal Summit this year after my opening keynote, an interesting question came up during one of the sessions: “can web developers be sued under the ADA for their inaccessible designs or code?”

Most of the panel said the answer wasn’t clear and, while I didn’t offer an answer (because I wasn’t on the panel), I disagreed. To me, the law was be pretty clear: people with disabilities can’t sue web developers under the ADA when they create inaccessible web sites for companies. It’s not an answer I like to give but I can’t see a way around it with our current legal structure. But, like a typical lawyer, my answer is full of caveats and exceptions.

Web Designers Can’t be Directly Liable Under Title III of the ADA

I think that, when most people ask the question about website developers and liability, they’re imagining a scenario where a private company goes to a web developer and asks her for web development services. In order to be liable, Section 302 of the ADA requires that a company has to be a “public accommodation”—that is, an entity that “owns, operates, or leases” a place of public accommodation. 42 U.S.C. § 12182. Because web developers usually don’t own, operate, or lease their customer’s websites, they can’t be sued under Title III of the ADA for those websites. Unfortunately, it’s really as simple as that.

“But I’ve heard that architects can sometimes be liable under ADA Title III,” you may say. Yes, architects can sometimes be held liable because Section 303 of the ADA states that,

as applied to public accommodations and commercial facilities, discrimination for purposes section 302(a) includes…a failure to design and construct facilities… that are readily accessible to and usable by individuals with disabilities.

42 U.S.C. § 12183(a).

I said that architects can sometimes be held liable because different courts interpret the interplay of Sections 302 and 303 differently. On the one hand, some courts have held that architects can be liable because Congress must have meant Section 303 as expanding liability beyond those who simply “own, operate, or lease” a place of public accommodation. Otherwise, these courts say, the reference to “commercial facilities” doesn't make sense because they aren't “public accommodations”? Johanson v. Huizenga Holdings, 963 F. Supp. 1175 (S.D. Fla. 1997). United States v. Ellerbe Becket, Inc., 976 F. Supp. 1262 (D. Minn. 1997). This approach makes sense to me; architects control the design of facilities and when their designs create barriers, they should be liable when a person with a disability cannot access that facility.

On the other hand, other courts have held that Congress could not have intended architects to be liable because Section 303 includes the clause, “discrimination for purposes of section 302(a)”—implies that Section 303 can’t extend liability beyond those who are covered by Section 302 (i.e. those who “own, operate or lease” a place of public accommodation). Paralyzed Veterans of Am. v. Ellerbe Becket, Inc., 945 F. Supp. 1 (D.D.C. 1996). Under this line of reasoning, if a business hires an architect to build a structure, it’s that business that is designing and constructing that building—even if it’s their architect who is doing the actual design work and their contractor who is doing the actual construction work. Thus, that business can be sued for designing or constructing that facility. And, including “commercial facilities” (which are non-public spaces such as warehouses or employee-only areas) makes sense because that company can also be sued if these non-public areas are not built correctly. The problem with this logic is that the company that “owns, operates, or leases” the facility rarely controls the actual design or construction of the building. While the owner always “approves” the designs and construction, they rely completely on the expertise of their architects and general contractor to get the job done right.

Regardless of which approach you agree with, however, Section 303 is still limited to the design and construction of facilities—and I doubt any court would expand that term beyond physical structures. Thus, I think there is little chance that a court would say that web developers are covered by Title III in the design and construction of their client’s websites.

Caveats and Exceptions

I did mention that my answer would include a bunch of caveats and exceptions. My answer above is that it would be very hard for a person with a disability to succeed in an ADA Title III lawsuit against a web developer for a website that they create for a private sector customer.

Liability under Their Contract

Of course, my answer only addresses the ADA—not the web developer’s potential liability under their contract. In this case, liability primarily rests on the contract between the web developer and her client. So if a company contracts with their developer to create an accessible website and the company gets sued, they can bring their own suit under the contract against their developer. In practice, this can be hard to do, however, because most web developers limit their liability in their contracts.

Public Sector Projects

Another exception arises when the client a public sector entity. The Federal government and many states have “false claims” laws that make lies or misstatements in government contracts illegal and subject to criminal or civil liability. And, often these false claims lawsuits can be brought by private citizens who are affected by that lie or misstatement. Here, the lead case is Bashin v. Conduent, RG18888208 (Cal. Super. Nov. 5, 2019)(available at https://www.relmanlaw.com/cases-bashin). In this case, a blind citizen sued a web developer under the Unruh Civil Right Act, California’s False Claim Act, and Title II of the ADA because the developer falsely promised the state of California that it would make the website used for making campground reservations accessible. The court denied defendant’s motion to dismiss, addressing all three possible causes of action.

And Then There is Always Unruh… Sort Of…

The last “little” wrinkle in my answer arises if a web developer is sued by a person with a disability under Unruh. This law prohibits discrimination against people with disabilities in any business activity—and that would certainly include designing or creating an inaccessible website. But, as I blogged about earlier, there are two basic ways to create an Unruh violation—either establish an ADA violation or prove intentional discrimination. I’ve already talked about why I think ADA Title III is a dead end. And proving intent may be very difficult unless the facts of the case suggest that the web developer had a real indifference to web accessibility.

What Can Companies Do To Make Their Web Developers Responsible?

If you run a private company, it probably seems unfair that you can be sued under the ADA for your web developer’s mistakes. There are, however, a few simple things that you can do to make sure that your web developers take web accessibility seriously.

Build WCAG into Your Contracts

The most obvious thing you can do is to build WCAG into the terms of your contract with your web developer. Here, it’s important to state exactly what level of WCAG compliance your developer will be required to meet. For instance, you may include a clause such as,

The Developer agrees that all web content created under this Agreement will meet all fifty (50) level A and AA Success Criteria of the W3C’s Web Content Accessibility Guidelines (WCAG) 2.1 (June 5, 2018 draft available at https://www.w3.org/TR/WCAG21/).

Promising to meet WCAG is one thing; actually standing behind your work is another. I would also try to make sure that my web developer understood that they really need to make their content accessible by asking that they make any fixes that are identified later on down the road. This can mean trying something to have a clause like this one inserted into a contract.

Developer also agrees that, if any areas of non-compliance with WCAG are identified within two years of delivery of all deliverables under this contract, the Developer shall remediate all content to ensure such compliance within three months of being notified of non-compliance and that such work will be performed on a no-cost basis.

Build Independent Testing into Your Contracts

No one likes to have potential hidden issues that can crop up years down the road—and web developers are no exception. Thus, it’s pretty unlikely that a web developer would happily agree to fix a web site years from now if a problem is identified.

A compromise position taken by many large organizations is to build in third-party independent testing. This is also used a lot in public-sector IT procurements. Under this approach, a company builds in testing by an industry-accepted third party—and requires the developer to fix any problem either before deployment or within an acceptable time frame after deployment.

At Converge Accessibility, we perform work like this all the time for larger clients. In fact, we just finished a sizeable project of this nature for the California State University, which maintains a list of “trusted vendors” that can evaluate vendors products for accessibility.

Developer must submit an Accessibility Conformance Report (ACR) based on the ITI VPAT 2.4 WCAG (available at https://www.itic.org/policy/accessibility/vpat). This ACR must be prepared by one of the following organizations that specializes in web and digital accessibility:

Prior to award of this contract, vendors will be required to satisfactorily meet all requirements in the ACR or develop an acceptable remediation plan. Failure to meet any deadline in such remediation plan will constitute a default under this contract by the vendor.

Require Your Developer to Document Their Accessibility Progress

Unfortunately, while usually highly accurate, third-party testing can be expensive because it requires carefully reviewing all components in a web-based application. Also, documenting accessibility features (or the lack of accessibility features) in an ACR takes a considerable amount of time. Such testing makes sense for system-wide deployments of pre-built web-based applications across large organizations like CSU, but it may be impractical for ad-hoc web development projects in smaller organizations.

When web content is being developed to order for a client, it is important to make sure that web developers consider web accessibility from the earliest stages of the design process so that the final code is built around accessibility. In this case, organizations can combine careful documentation with a very light degree of third-party testing. Here, organization turn to our WebAlign product, which clear role-based checklists, over 80 on-demand training modules, and a complete knowledgebase of design, development, and testing strategies that require no expertise in assistive technology.

Developer will be required to document all pre-production, production, and QA/testing accessibility efforts using WebAlign (www.webalign.net) and satisfactorily meet all WCAG 2.1 provision according to the following schedule:

Combined Pre-Production Checklist: Due 60 days after award

Combined Production Checklist: Due 120 days after award

Combined QA/Testing Checklist : Due 150 days after award

Using WebAlign is highly cost-effective (typically $360/user/year) and really zeroes web development efforts around meeting WCAG 2.1. It also makes it easy to design, develop, and test content to meet WCAG without a high degree of expertise. This means that organizations can “spot test” a developer’s efforts and still have a high-degree of confidence that web content will meet WCAG. So, in addition to using WebAlign, our customers can include a light degree of accessibility testing just to verify that everything was designed properly.

Prior to deployment, Developer agrees to make all deliverables available for review on a public server. Developer further agrees to make any code changes or corrections within 30 days that are identified by Client within two weeks of being notified of such review.

Contact Us Today!!!

If you are thinking of reworking your website but you're concerned about meeting WCAG and not being sued, contact us today! At Converge Accessibility, our focus is improving digital accessibility in the most efficient way possible. Reach out to us today!

Disclaimer

Nothing in this post should be interpreted as legal advice or as forming an attorney-client relationship. It is offered for educational purposes only. You should always contact a qualified attorney in your area to discuss your legal rights and responsibilities.

Want to See More Content Like This?

Want the latest blog posts, videos, white papers, and announcements? Sign up for our mailing list and stay in the loop!

We're Here to Help When You're Ready

Take a deep breath. Then feel free to reach out to our team when you're ready to discuss your accessibility needs.

1 comment on “Can Web Developers be Sued for the Inaccessible Sites They Create for Clients?

  1. You never cease to make my head spin, Ken. Things do get a little frightening when you get down to the level of a web developer. I suppose if you use an individual contractor you can run that risk. Good food for thought.

Leave a Reply

Your email address will not be published. Required fields are marked *