Web Accessibility Is a Revenue Lever, Not a Legal Checkbox

Ask a founder about web accessibility and you’ll usually get one of two reactions: a shrug, or a nervous mention of a demand letter a competitor received. Both miss the point. Accessibility gets treated as either irrelevant or as pure legal defense, when the real story is that accessible sites are simply better sites — for disabled users, for everyone else, and for the metrics you already report on.

The legal risk is real and worth naming briefly. ADA-related web accessibility lawsuits in the US have numbered in the thousands annually for years, and the plaintiffs’ bar has gotten efficient at finding easy targets: missing alt text, unlabeled form fields, keyboard traps. But building a site to avoid a lawsuit is the wrong motivating question. The right one is: how much revenue is an inaccessible site quietly losing, and to whom?

The Business Case Nobody Runs the Numbers On

Roughly 1 in 4 adults in the US lives with some form of disability — visual, auditory, motor, or cognitive. Many of those disabilities are invisible in a sales meeting and irrelevant to a demo, but they show up the moment a real user tries to complete your checkout flow with a screen reader, or navigate your nav menu with a keyboard because a tremor makes precise mouse clicks unreliable.

That’s a meaningful slice of your addressable market being asked, silently, to work around your site rather than through it. Nobody files a support ticket saying “your color contrast made this illegible.” They just leave, and the conversion funnel shows it as unexplained drop-off — the same drop-off you might be blaming on copy or pricing.

There’s a second, less obvious payoff: most accessibility fixes are also usability and SEO fixes. Alt text that properly describes an image helps a screen reader user and gives Google’s crawler more context. Clear focus states help a keyboard user and reduce the “where am I on this page” confusion every user occasionally hits. Sufficient color contrast helps someone with low vision and helps everyone reading your site on a phone in direct sunlight. Accessibility work rarely exists in isolation — it’s UX debt that happens to have a legal name attached.

What “Accessible” Actually Means

The reference standard is the Web Content Accessibility Guidelines (WCAG), currently at version 2.2, organized around four principles: content must be Perceivable, Operable, Understandable, and Robust (POUR). Most legal and industry expectations target Level AA conformance — a reasonable, achievable bar. Level AAA is stricter and rarely required outside specific regulated contexts.

In practice, AA conformance comes down to a manageable list of concrete requirements: sufficient color contrast (4.5:1 for normal text), all interactive elements reachable and operable by keyboard alone, form fields with real associated labels (not just placeholder text), images with meaningful alt attributes, video with captions, and a logical heading structure that a screen reader can use to navigate the page like a table of contents.

None of this requires a redesign. It requires attention during design and development, and a testing pass most teams have never run.

Where Sites Actually Fail

In audits, the same handful of issues account for most of the gap:

Placeholder text used as the only label. It disappears the moment someone starts typing, and screen readers often don’t announce it consistently. Every form field needs a persistent, programmatically associated label.

Color as the only signal. Red-outlined error fields with no accompanying text or icon are invisible to colorblind users and unannounced to screen readers.

Custom components built without keyboard support. A dropdown, modal, or carousel built from <div>s instead of native elements often looks fine and is completely unusable without a mouse.

Missing or decorative-as-meaningful alt text. Either images have no alt attribute at all, or every image — including purely decorative ones — gets a verbose description that clutters screen reader output instead of helping it.

Focus states removed for aesthetics. outline: none in a CSS reset, with nothing put back in its place, is one of the most common and most damaging patterns we see. It doesn’t just fail accessibility — it makes the site harder to use for anyone navigating by keyboard, disability or not.

A Practical Starting Point

You don’t need a full audit to make meaningful progress in a week:

1. Run your homepage and one core conversion flow through an automated checker like axe DevTools or WAVE. These catch roughly 30–40% of issues — a real start, not a finish line.
2. Tab through your site using only the keyboard. If you lose track of where focus is, or can’t reach something with a mouse-only interaction, that’s a fix.
3. Check contrast on your primary CTA buttons and body text against your actual background colors, not the values in your design file.
4. Audit your forms specifically — labels, error messaging, and required-field indicators are the highest-traffic accessibility surface on most sites.

Automated tools won’t catch everything; a manual pass and, ideally, testing with real assistive technology users closes the rest of the gap. But most SMB sites haven’t done even the automated pass, and that alone recovers a surprising share of the ground.

---

PNK WORKS builds sites and products with accessibility treated as a design requirement, not an afterthought. Talk to us.