WCAG 2.1 AA Without Excuses: Building Accessible Sites That Hold Up

If you operate a public-facing website for a U.S. small business, web accessibility is no longer a nice-to-have. It’s a business risk you carry whether you’ve thought about it or not.

ADA-related web lawsuits crossed 4,000 federal filings annually in the United States and have been growing year over year. Small businesses are now the majority of targets — not the corporate giants the law was originally designed around. The plaintiffs’ bar has industrialized the process, and the standard defense (we didn’t know, we’re small, we’ll fix it) doesn’t reliably stop a settlement demand.

The good news is that the technical work to materially reduce this risk is well-understood. We hold every site we ship to a documented standard, and we want to walk through what that actually means.

The Standard

The applicable standard, in practice, is WCAG 2.1 Level AA — the Web Content Accessibility Guidelines published by the W3C. WCAG 2.1 AA is what U.S. courts most often reference in ADA web cases, and it’s what the Department of Justice has signaled as the bar for compliance on government sites.

There is no legally binding “ADA certification” for websites. That doesn’t exist. What exists is conformance to WCAG 2.1 AA, documentation of the work, honest disclosure of any limitations, and a real response path for user-reported issues. That’s what a defensible posture looks like. Anyone selling you a “certification” or a “100% ADA compliant” guarantee is selling you a problem dressed as a product.

What Conformance Actually Requires

WCAG 2.1 AA is structured around four principles, each with concrete success criteria. The shorthand version:

• Perceivable — All content can be perceived by users regardless of sensory ability. Images have alt text. Videos have captions. Color isn’t the only way information is conveyed. Contrast ratios meet specific minimums.
• Operable — All functionality is keyboard-accessible. Focus indicators are visible. There are no keyboard traps. Animations can be paused. Sessions don’t time out without warning.
• Understandable — Navigation is consistent. Language is declared. Form errors are identified and explained. Behavior is predictable.
• Robust — Markup is valid and works with current and future assistive technology. ARIA is used correctly when needed.

These aren’t checklists you knock out once. They’re posture decisions baked into the build.

Automated Tools Are Not Enough

This is the trap most well-intentioned operators fall into. They run their site through WAVE or Lighthouse, get a 95 score, and assume they’re compliant. They are not.

Automated tools catch roughly 30–40% of WCAG failures. The other 60–70% is caught only by manual testing — keyboard navigation, screen reader spot-checks, contrast review on dynamic states, focus management on interactive components, and human judgment on whether content is genuinely accessible or just technically compliant.

A 100/100 Lighthouse accessibility score on a site that fails the basic keyboard test is not a compliant site. It’s a site with a high score.

Our internal operating standard requires both: automated scanning with WAVE, Lighthouse, and axe DevTools, plus manual keyboard testing on every page and quarterly screen reader spot-checks on master pages with NVDA or VoiceOver.

Overlays Are Not a Substitute

Accessibility overlay widgets — the kind that drop a sidebar icon on your site offering “accessibility menu” features — are not a substitute for actual conformance. They have been named in lawsuits more often than they have prevented them. We do not use them. We do not recommend them. If a vendor is selling you one as your ADA solution, get a second opinion.

Build Platform Matters

Not every platform supports full WCAG 2.1 AA conformance. We’re honest about this with clients.

Tier 1 platforms — like Astro, custom HTML, or any framework where we control the full markup output — can target WCAG 2.1 AA with no third-party widget exceptions. This is the recommended posture for any business where accessibility risk is non-negotiable.

Tier 2 platforms — like GoHighLevel and some other site builders — have known widget-level accessibility ceilings we cannot work around. The GoHighLevel multi-select form widget generates a role="combobox" without aria-expanded, which is a documented platform bug. Google reCAPTCHA has its own documented accessibility limitations.

For Tier 2 sites, we target WCAG 2.1 AA with documented exceptions for known third-party limitations — and we disclose those exceptions in the accessibility statement. This is a defensible posture, but it’s not zero-risk.

For any client where the legal posture matters most, we recommend Tier 1.

What a Defensible Posture Includes

Beyond the technical work, the documentation matters. Every site we ship gets:

• A published Accessibility Statement at /accessibility/
• The standard targeted (WCAG 2.1 AA), the build tier, the audit tools used, and the date of the most recent review
• Honest disclosure of any known third-party limitations
• A clear feedback path with a stated SLA — we commit to responding to accessibility issues within 2 business days

Plaintiffs’ firms look for sites with no statement, no disclosed posture, and no response path. A site with all three signals that the operator takes this seriously — and that’s often enough to redirect the firm to easier targets.

The Business Case

The defensive case is real, but the offensive case is bigger. Accessible sites are faster, more keyboard-friendly, more mobile-friendly, more SEO-optimized, and more compatible with assistive technology that millions of Americans use every day. There is no version of “accessible” that isn’t also “better website.”

If you want a real picture of where your current site stands, request an audit. We’ll deliver a prioritized findings report, a remediation estimate, and a draft accessibility statement — all in about a week.