What Happens When Developers are Liable for Accessibility, Part 2

Also in this series

1. What Happens When Developers are Liable for Accessibility (Part 1)
2. What Happens When Developers are Liable for Accessibility, Part 2
3. What a new accessibility class action lawsuit means for agencies

Beware false claims

Last year, we explored the concept of developer liability for creating accessible websites. California’s state legislature was considering a bill, AB-1757, that would make it illegal for a web developer or agency to create or maintain a website that is not accessible. (The bill did not pass last year but it has been amended and is back under consideration in this year’s legislative session.)  Without taking a position on the merits of this specific law, we continue to believe that enshrining a professional duty to create accessible experiences is an opportunity for designers, developers and agencies to to invest in accessibility subject matter expertise.

Even without this affirmative legal obligation, web developers have been found to have liability for accessibility in at least some circumstances. In Bashin v. Conduent, a California state court ruled that the developer of the Reserve California website was in violation of the False Claims Act when it delivered an inaccessible website in spite of contractual requirements that the site be accessible.  The plaintiff and state were able to recover $2 million in damages and penalties from the developer for misrepresenting the website as in compliance with accessibility requirements.

There are a number of details that are unique to the case, but it is an important reminder that developers (or accessibility consultants for that matter) who make accessibility conformance claims should be prepared to back them up.

This is not legal advice

We are not attorneys and this blog post is not intended as legal advice. We encourage you to bring your legal questions to qualified professionals who can offer advice relevant to your circumstances.

But we can offer some practical advice on how to set appropriate expectations with clients around digital accessibility and build better processes to deliver the accessible websites and digital experiences that clients expect.

Be precise and honest

In public sector contracts, like the Bashin v. Conduent case, there shouldn’t be much ambiguity about the expected accessibility standards. But it’s not unusual for companies to request “ADA compliant” websites, which can be a bit more ambiguous. It’s in your interest to clarify what standards you will meet (e.g. WCAG 2.2 Level AA) and how you intend to achieve this goal. How is accessibility incorporated into your processes? What kind of testing will you perform?

By the same token, you should also be clear about what you cannot guarantee. For example, if there are client project requirements or third party products that break accessibility, what will you do? There are often exceptions that are out of your control. Ideally you can convince the client to make the necessary adjustments but there needs to be an agreed-upon process for handling these questions in a way that protects you.

And finally, you should be honest about your capabilities. For example, you may have a strong understanding of accessibility design and development principles but don’t have the ability to provide screen reader testing as part of the QA process. That may (or may not) be a dealbreaker for procurement but it’s better not to overpromise and underdeliver especially when you are making a contractual commitment.

Shift left

The earliest stages of a website project, starting with UX and design, are where you make sure that all requirements are accounted for. You wouldn’t build something first and only then check to see if it met the requirements. Accessibility is no different. Waiting until development is complete to start thinking about accessibility is a recipe for lots of rework along with budget and schedule overruns.

Designs should be built with accessibility principles and best practices in mind. And technical documentation for developers (whether that is design annotations, requirements, or full technical specifications) should inform accessibility considerations as the site is developed. By following these processes, you can ensure that accessibility testing during the QA and UAT phases will go smoothly.

Create processes to maintain accessibility

Websites are not frozen in stone and accessibility decay must be a concern for any actively updated and maintained site. Creating systems and processes to ensure that accessibility is maintained is always a good idea but it should be a requirement for clients that expect their developer to vouch for the site’s accessibility.

1. Train content and marketing teams on how to create and update pages without introducing accessibility bugs
2. Collaborate on accessibility checklists tailored to your client
3. Build automated testing into code reviews and deployments
4. Set up sitewide accessibility scanning and monitoring
5. Schedule regular manual reviews especially following major releases

Find help where you need it

While accessibility should already be a core part of designing, building and testing a website, you have to start somewhere. And if you aren’t yet in that position, it’s better to bring in support so that you can deliver an accessible experience with confidence. When it comes to fulfilling contractual obligations, it’s risky to make a claim that you are not sure you are delivering. And even if you already take accessibility into account when building a site, it can be beneficial to have a third party expert validate the website for any undiscovered accessibility bugs.