ADA Compliant Website: The Insurance Agency Checklist

"Compliant" is a word with no checklist behind it

Somewhere in the last few years you probably added an accessibility widget to your agency's site. A little icon in the corner, a menu of options, maybe a line in your footer that now says something like "This site is ADA compliant." It felt like closing a loop. You searched "ada compliant website," found a tool, installed it, moved on.

Here is the uncomfortable part. There is no government checklist that widget is actually checking you against. Not because the rule is buried somewhere you haven't looked, but because for a private business like an insurance agency, the rule does not exist yet in the specific, numbered way you'd expect from something with legal teeth. The Department of Justice has explained what the Americans with Disabilities Act requires of a business's website in general terms, but it has stopped short of publishing a regulation that says, line by line, what counts.

That absence is not an invitation to skip the work. It is the reason so many agencies end up with a widget instead of an actual fix, because a widget is something you can install in an afternoon and a real fix is not. This guide is the second part, the actual item by item list, written against the standard that already has the force of law behind it for government sites and that plaintiffs' attorneys already use to measure everyone else.

It also helps to say plainly what "accessible" actually buys an agency, beyond the legal framing. A screen reader user comparing three agencies in three browser tabs does not stay on the tab that reads as a wall of unlabeled buttons. A prospect with low vision does not zoom into a rate sheet that breaks when it hits 150%. An older client, who is statistically the exact person shopping for a Medicare plan on your site, often benefits from the same contrast and text sizing fixes a formal accessibility audit would flag, whether or not they'd describe themselves as having a disability at all. The checklist below is written for the legal question, because that is the question that brought most readers here, but the actual payoff shows up every day, in whether a real visitor can finish what they came to do.

Why the DOJ left Title III open

The Americans with Disabilities Act splits into titles, and the title matters more than most agency owners realize. Title II covers state and local governments. Title III covers "places of public accommodation," which is the part that reaches a private business, including an insurance agency.

DOJ's own web accessibility guidance, published March 18, 2022, states its position plainly: the ADA's requirement that businesses provide "full and equal enjoyment" of their goods and services extends to what they offer on the web². But the same guidance says DOJ has not issued a regulation spelling out detailed web accessibility technical standards for Title III businesses. It calls the Web Content Accessibility Guidelines, WCAG, and Section 508 "helpful guidance," and says businesses can choose how to comply². No named version, no named conformance level, no specific numbered checklist, for Title III.

Title II is a different story, and it is worth knowing about even though it does not bind your agency directly, because it tells you exactly which way the wind is blowing. In April 2024, DOJ finalized a rule for state and local governments that does name a standard: WCAG 2.1 Level AA, by name, as "the technical standard for state and local governments' web content and mobile apps"³. Under an interim final rule that extended the original deadlines, public entities serving 50,000 people or more have until April 26, 2027 to comply, and smaller entities and special purpose districts have until April 26, 2028³.

Put those two facts side by side and the practical answer writes itself. DOJ will not tell your agency which standard to build to. But DOJ already told itself, and every government website in the country, which standard to build to. Building your own site to that same bar, WCAG 2.1 Level AA, is the most defensible position available today, not because a law requires it of you yet, but because it is the standard the government you'd eventually answer to already had to meet.

What an accessibility lawsuit actually looks like

It is fair to ask whether any of this is a real risk for an agency your size, or a problem mostly for large companies with a national brand to protect. The 2026 litigation data says the opposite. UsableNet's midyear report projects roughly 6,176 website accessibility lawsuits filed in 2026, based on filings recorded through June 14, 2026, putting the year on track to surpass 6,000¹. Of the companies sued in the first half of 2026, 68% had annual revenue under $50 million, 22% had revenue between $50 million and $1 billion, and only 10% had revenue above $1 billion¹. This is not a large company problem.

In fairness, insurance is not the sector driving the bulk of this volume. eCommerce accounts for 79% of digital accessibility lawsuits in the same report¹, and a lot of what UsableNet tracks is retail checkout flows, not agency quote forms. But 79% still leaves 21%, and 21% of roughly 6,176 projected 2026 filings works out to about 1,297 lawsuits, by our own calculation from UsableNet's two published figures, spread across every other industry in just six months¹. Insurance sites with a PDF rate sheet, a video testimonial, and a quote form built the way most page builders generate them sit squarely inside that remaining share, not outside it.

The WCAG 2.1 AA checklist, mapped to your actual pages

WCAG organizes its success criteria into four principles, perceivable, operable, understandable, and robust, each with numbered criteria at Level A, AA, or AAA⁴. Level AA is the bar DOJ picked for government sites, and it includes everything required at Level A too, since AA conformance requires meeting every Level A criterion as well⁴. The table below is not the full standard. It is the subset that shows up, over and over, on an actual insurance agency site: the quote form, the rate PDF, the testimonial video, the carrier logo wall.

The four principles are worth knowing by name, because they explain why the checklist groups the way it does. Perceivable means a visitor can actually sense the content, which is why contrast ratios and alt text live here: information that only works at full color saturation, or only exists as pixels in an image, is not perceivable to everyone. Operable means every control can be worked, by someone using a keyboard, a switch device, or voice control, not just a mouse. Understandable means labels say what they mean and errors are explained in a way a person can act on, not a red border with no text attached. Robust means the markup is built cleanly enough that current and future assistive technology can parse it correctly, which is the principle a page builder's auto generated div soup most often fails⁴.

The A, AA, and AAA levels are not a difficulty slider so much as a scope of audience. Level A covers the items that make content unusable for some people if missing entirely, a missing text alternative, a keyboard trap. Level AA adds the items that make content difficult, not impossible, for a wider group, contrast, resize, reflow. Level AAA goes further still and is not realistically achievable across an entire site, which is why neither DOJ's own Title II rule nor most legal guidance anywhere asks for it³. AA is the bar that shows up in regulation, in litigation, and in this checklist, because it is the point where the return on the work still clearly justifies it.

None of these are exotic. Every one of them is a markup decision, how a form field is coded, whether a video has a captions track, whether a color pairing was checked against a ratio, not a design decision that forces your site to look different. A site can meet every row in this table and still look exactly like the one you have now.

Who this doesn't reach as hard

It would be dishonest to write a checklist like this and pretend every row carries the same weight for every agency. A solo producer running a mostly informational site, a bio page, a licensed states list, a contact form with three fields and nothing else, has a much smaller surface area of risk than an agency running video testimonials, an embedded PDF rate sheet library, and a multi step quote funnel. Fewer moving pieces means fewer places for 1.2.5 Audio Description or 3.3.4 Error Prevention to even come into play.

That is not an argument for skipping the basics. Contrast, alt text, real form labels, and a visible focus state cost almost nothing to build correctly from the start and apply to every site regardless of size. It is an argument against over engineering a simple site to a standard built for a complex one, and against assuming the inverse, that a complex funnel with a lot of interactive pieces can coast on the same five minute fix that works for a static bio page. The fifteen minute test below will tell you honestly which category your own site falls into, rather than a generic rule guessing for you.

Why an overlay widget doesn't check these boxes

It is worth being specific about why the accessibility widget most agencies already installed does not satisfy the table above, because the honest answer is more useful than a blanket "widgets don't work."

An overlay script runs in the browser, after your page has already loaded, and tries to patch things it can detect: boosting contrast on the fly, guessing at alt text for an image that has none, trying to reorder a tab sequence it did not build. It can genuinely help with a handful of surface level items. What it cannot do is rewrite the underlying HTML your page was built with. A quote form missing real <label> elements is still missing them underneath the widget's menu. A video with no captions track does not gain one because a script runs on the page around it. A PDF rate sheet saved as a flat image is still a flat image.

That is the structural reason items like 2.1.1 Keyboard, 1.3.1 Info and Relationships, and 1.2.5 Audio Description in the table above are rarely things a widget actually fixes, regardless of what its marketing claims. They are decisions made in the code the page ships with, not patches applied after the fact. If a widget is currently your agency's entire accessibility plan, treat this table as the honest list of what it is probably not covering, and read the companion guide on how these lawsuits actually start for the litigation side of that same gap⁹.

Test your own site in fifteen minutes

You do not need to hire anyone to find out where your own site actually stands today. Two checks, done back to back, cover most of what matters.

The reason this three part check works is that it splits the problem the way the research splits it. Deque Systems measured automated testing catching 57% of accessibility issues across a dataset of more than 13,000 pages, well above the 20 to 30% estimate the company says is commonly cited for automated tools generally⁶. Lighthouse catches a meaningful share. The keyboard and screen reader passes catch most of what automation structurally can't, because both are checking whether a real human using real assistive technology can actually get through your site, not whether a rule engine can detect the absence of an attribute.

How we build this into the foundation

This section sticks to what is documented on our own live pages, verified this session, not a general promise. We build agency sites on Astro, which ships pages as static, semantic HTML rather than a runtime that assembles markup from a page builder theme at request time⁷. Real headings, real labels, and real alt text on every image are part of how a page is built the first time, the same markup decisions the table above is made of, not a remediation pass added after something went wrong.

That is a difference in starting point, not a guarantee of a specific legal outcome, and we are not going to promise you one. What we can say plainly: every Digital Foundation plan includes AI CLI access, so changes to your own site, including fixes to a specific label, alt attribute, or focus order, go through Claude Code or Codex on your own account, with a preview link before anything goes live⁸.

Every subscription tier is month to month with a 14-day free look period, verified live on the Digital Foundation page this session⁸. If your current site is on a page builder and the fix means rebuilding markup you don't control, that is the more realistic starting point than trying to patch a theme's output criterion by criterion.

It is fair to ask whether a full rebuild is worth it if your current site is otherwise working fine. For a lot of the table above, the contrast ratios, the form labels, the alt text, a developer can fix the specific failing items on your existing site without a rebuild, and the fifteen minute test above will tell you how many items you're actually dealing with. The case for rebuilding the foundation gets stronger when the keyboard test fails broadly across the whole site, because that usually means the underlying theme or page builder, not a handful of individual pages, is the actual source of the problem.

What you get

Strip away the legal framing and the outcome is narrow and concrete. A visitor using a screen reader can actually fill out your quote form instead of abandoning it at the first unlabeled field. A visitor navigating by keyboard, which includes people with motor impairments and a meaningful share of power users who simply prefer it, can tab through your site instead of getting stuck. A rate PDF someone zooms into on a phone stays usable at 200%. None of that requires your site to look different. It requires the code underneath it to be built the way the table above describes, once, instead of patched after a letter arrives.

There is a second benefit that shows up even if nobody using assistive technology ever visits your site. Several of the criteria in the checklist above, real headings, real alt text, a logical heading structure, real labels, are the exact same signals an AI answer engine or a search crawler reads when it tries to understand what your page is about. A site built to be understandable by a screen reader is, by construction, also a site built to be understandable by the systems increasingly deciding whether your agency gets found and cited at all.

There is a third benefit that is easy to miss because it never shows up as a line item: fewer broken pages for everyone, not just visitors using assistive technology. A form with real labels is also a form that autofills correctly in a browser. A table built as a real <table> is also a table Google can read and potentially surface as a direct answer. A video with captions is also a video someone can follow with the sound off on a phone in a waiting room. None of the work in this checklist is accessibility shaped work that happens to also help everyone else. It is the same work, done once, that every visitor to your site benefits from whether they notice it or not.

Questions agents ask