Practical guidance for accessibility compliance

Automated accessibility testing tools have improved substantially over the past several years and now form a standard part of many development workflows. Their limitations, however, are less widely understood than their capabilities, and organizations that rely on them exclusively tend to have a false sense of their compliance posture.

Automated tools are effective at identifying a specific category of accessibility failures: those that can be detected by analyzing the structure and attributes of HTML without any understanding of context or meaning. Missing image alt text, form fields without labels, insufficient color contrast ratios, and certain keyboard navigation failures all fall within what automated tools handle well.

Studies consistently find that automated tools can detect somewhere between 25 and 35 percent of WCAG 2.1 AA failures. The figure varies depending on the product and the tool, but the ceiling is well below 50 percent for any tool currently available.

The majority of WCAG failures require human judgment to identify.  Whether an image description is accurate and meaningful, whether a complex interactive component is usable with a screen reader, whether the reading order of a page makes sense when navigated non-visually, whether error messages are clear and helpful: none of these can be evaluated by analyzing code alone.

Automated tools also cannot replicate the experience of an actual user with a disability using assistive technology. A form may pass every automated check and still be completely unusable to a screen reader user because of how focus is managed or how dynamic content is announced.

Automated scanning is a useful part of an accessibility program, particularly for catching regressions early in the development cycle. It is not a substitute for manual testing, and scan results alone should not be used to draw conclusions about a product's overall compliance  posture.

Organizations that report scan results to leadership as evidence of compliance are providing an incomplete picture. A product that passes all automated checks may still have significant accessibility failures that expose the organization to legal and reputational risk. Compliance claims should be based on testing programs that include both automated  and manual evaluation by qualified reviewers.

Most organizations focus accessibility efforts on content and functionality they build and control directly. Third-party scripts, widgets, and embedded tools receive far less scrutiny, and in many cases none at all. This is a significant gap, because legal responsibility for accessibility does not end at the boundary of internally developed  code.

Under both the ADA and Section 508, organizations are generally responsible for the accessibility of their digital properties as a whole, including components provided by third-party vendors. A chat widget that is inaccessible to keyboard users, a cookie consent banner that traps screen reader focus, or an analytics-driven personalization script that disrupts assistive technology: these are your organization's accessibility problems, not the vendor's, from a legal standpoint.

This does not mean organizations are powerless. It means the responsibility for ensuring third-party components meet accessibility standards sits with the organization procuring them, not with the vendor alone.

Live chat widgets are among the most frequently cited third-party accessibility failures. Many inject DOM elements that interrupt screen reader navigation, trap keyboard focus, or use custom interactive patterns that do not work with assistive technologies. Cookie consent and privacy compliance tools present similar problems. They are often added late in a development cycle by non-technical teams, and tend to receive minimal accessibility review.

Embedded video players, social sharing components, advertising scripts, and A/B testing tools are also frequent sources of accessibility failures. These tools are often chosen for commercial reasons with no consideration of accessibility at all.

The most effective approach is to treat third-party tools as subject to the same procurement standards as any other vendor product: require accessibility documentation before integration, test new components before deployment, and establish a process for reviewing accessibility when vendors release major updates.

For organizations with a large existing inventory of third-party scripts, a useful first step is a simple audit of what is running on your pages and whether any of it has been evaluated for accessibility at all. In most cases, a handful of high-traffic, high-interaction components represent the bulk of the risk and are the right place to start.

Digital accessibility litigation has grown significantly over the past decade. Understanding the cases that shaped current expectations can help organizations assess their own exposure and make more informed decisions about where to invest compliance effort.

Guillermo Robles, who is blind, sued Domino's after being unable to order food through their website and mobile app using a screen reader. The Ninth Circuit ruled that the ADA applies to websites and apps that have a nexus to a physical place of public accommodation, rejecting Domino's argument that applying the ADA to digital properties required clearer regulatory guidance from Congress or the DOJ. The case established a durable precedent that private businesses with physical locations cannot treat their digital presence as outside the ADA's reach.

The implication for most organizations: having a physical presence and an inaccessible website is a clear exposure. Domino's eventually settled, and the case has been cited in hundreds of subsequent lawsuits.

Albert Rizzi, a blind New York nonprofit founder, sued Morgan Stanley after being unable to access his own retirement accounts through their website using screen reader software. Before filing, Rizzi offered his organization's accessibility services to Morgan Stanley free of charge to fix the issues. They never responded. The case, filed in federal court in Brooklyn, sought $9 million in damages and alleged that the bank's inaccessible online wealth management tools violated the ADA. Morgan Stanley settled, with terms kept confidential.

The case is notable for extending ADA exposure into financial services, where inaccessibility carries consequences beyond mere inconvenience. A client who cannot independently read their own statements or monitor their retirement savings is shut out of managing their financial life entirely.

The National Association of the Deaf sued both Harvard and MIT in 2015 after finding that their publicly available online course content either lacked closed captions or featured captions too inaccurate to be useful. Both universities fought the cases for years, losing multiple motions to dismiss along the way. Harvard settled in 2019 and MIT in 2020, with both consent decrees requiring comprehensive captioning across lectures, live-streamed events, and content hosted on platforms like YouTube and SoundCloud.

The settlements are widely cited as the most comprehensive online accessibility requirements ever imposed on higher education institutions. For any organization that publishes video or audio content publicly, the cases established that the ADA's reach follows that content regardless of where it is hosted.

ADA Title III website accessibility lawsuits grew from a few hundred per year in the mid-2010s to several thousand per year by the early  2020s. A small number of law firms drive a significant portion of this volume, targeting organizations with inaccessible websites, sending demand letters, and filing suit when organizations do not respond or remediate promptly.

The organizations that navigate this environment best tend  to have two things in common: a documented compliance program that  demonstrates good-faith effort, and a process for responding promptly and constructively when accessibility complaints are received. Neither requires perfect conformance. Both require treating accessibility as an ongoing organizational commitment rather than a one-time project.