Web Accessibility Is a UX and Revenue Problem, Not Just a Legal One
Almost every website fails basic accessibility, and the defects that lock out disabled users are the same ones quietly costing you conversions and search visibility. Here is the data, and what to do.
Accessibility usually gets filed under compliance, somewhere between legal and "we will get to it." That filing is the mistake. The defects that lock out a screen-reader user are, overwhelmingly, the same defects that cost you conversions, frustrate mobile users, and bury pages in search. Fixing them is not charity work. It is the highest-leverage usability work most sites are quietly ignoring.
Almost every website is failing, including yours
Every February, WebAIM runs an automated accessibility scan of the top one million home pages. The 2026 results are blunt: 95.9 percent had detectable WCAG failures, up from 94.8 percent the year before (WebAIM, 2026). The average page carried 56.1 distinct errors. And because automated tools only catch part of the picture, the true pass rate is lower than the 4.1 percent that came through clean.
Sit with that for a second. If you lined up a hundred sites at random, roughly ninety-six are failing the baseline standard for whether people with disabilities can use them. The odds your own site sits in that group are not comforting.
The failures are mundane, and that is exactly why they matter
You might picture accessibility problems as exotic edge cases. They are not. Almost all of the errors fall into six ordinary categories (WebAIM, 2026):
- Low-contrast text: 83.9 percent of pages.
- Missing alternative text for images: 53.1 percent.
- Missing form input labels: 51 percent.
- Empty links: 46.3 percent.
- Empty buttons: 30.6 percent.
- Missing document language: 13.5 percent.
Six ordinary defects cause almost all failures
Ninety-six percent of all detected errors sit in those six buckets. Now read the list again through a conversion lens instead of a compliance one. Low-contrast text is unreadable on a phone in daylight for everyone, not just low-vision users. A missing form label is the difference between a checkout that autofills cleanly and one that fights the user. An empty link is invisible to a screen reader and to a search crawler alike. Missing alt text hides your product images from assistive tech and from image search at the same time.
These are not accommodations bolted on for a small minority. They are the same fundamentals that decide whether a typical visitor can read, navigate, and buy. Curb cuts were built for wheelchairs, and they are used by everyone with a stroller, a suitcase, or a delivery cart. Accessible design works the same way.
The legal exposure is real, and climbing
If the usability case does not move the room, the legal one might. In 2025, plaintiffs filed 5,114 ADA digital-accessibility lawsuits in the United States, split across federal courts and the state courts of New York and California (UsableNet, 2025). This is now a routine category of litigation, not a rare event, and it leans heavily toward ecommerce and consumer brands whose sites are easy to test from the outside.
The uncomfortable part is that most of these suits hinge on exactly the six failure types above. The very things dragging down your conversions are the things that draw a demand letter.
How to treat accessibility like the UX work it is
Build it in, do not bolt it on
Accessibility retrofitted at the end is expensive and brittle. Bake it into design and development from the first wireframe: contrast baked into the color system, labels built into the component library, alt text as a required field in the CMS. It is far cheaper as a default than as a cleanup.
How to do it
- Define accessible color pairs in your design tokens first: run every text-on-background and UI-border combination through the WebAIM Contrast Checker and only admit pairs that clear 4.5:1 (3:1 for large text and interface components) into the system.
- Build shared components against a named ARIA Authoring Practices Guide pattern, so keyboard behavior, focus states, roles, and accessible labels ship inside the button, menu, accordion, or dialog rather than getting patched on later.
- Make alt text a required field on every CMS image and media block, and link the alt decision tree inline so authors know when to describe an image and when to mark it decorative with empty alt.
- Add contrast, visible focus, and label checks to your design and PR review gate, so nothing merges without them.
See a worked example
A team that pre-checks every text-and-background pair in its Figma color tokens to at least 4.5:1, ships buttons and menus from a component library with roles and labels already wired in, and makes alt text a required field on its CMS image block will often pass automated contrast and missing-alt checks on the first audit, instead of reopening dozens of tickets weeks after launch. The same fixes done in the design system typically cost a fraction of what they cost as post-launch retrofits.
Tools to use
Steal our AI prompt
You are an accessibility-minded design systems reviewer. Here is [paste: your list of color tokens with hex values, your core component list, and your CMS image and media field schema]. First, flag any text-on-background or UI-border color pair that likely falls below WCAG 2.1 AA contrast (4.5:1 normal text, 3:1 large text and interface components) and tell me which to fix, but note I must confirm each in the WebAIM Contrast Checker rather than trust your estimate. Second, for each component in [describe: for example button, dropdown menu, accordion, modal], name the matching ARIA Authoring Practices Guide pattern and list the roles, states, focus behavior, and accessible label it must expose. Third, review my CMS schema and tell me exactly where to add a required alt-text field and any decorative-image toggle, referencing the W3C alt decision tree logic. Do not invent WCAG numbers, tool names, or URLs; if you are unsure, say so.
Fix the six first
You do not need a year-long program to move the needle. Those six categories account for the overwhelming majority of errors. Audit for them, fix them once across your shared templates and components, and you resolve most of the legal risk and most of the daily friction in a single focused pass.
How to do it
- Scan a few representative templates (home, a form page, an article) with WAVE or the free axe DevTools extension and tally which of the six error types appear and where they originate.
- Trace each error back to its shared source instead of the page: a color token for contrast, the header or footer partial for empty links, the button and form-field components for empty buttons and missing labels, the root layout for the missing lang attribute.
- Fix at the source: raise the failing token in the WebAIM Contrast Checker until it passes AA, give inputs real labels and icon-only controls an aria-label, and set
<html lang="en">in the base layout. - Re-scan the same templates to confirm the counts drop, then spot-check one page with a screen reader (VoiceOver or NVDA) to make sure the labels read sensibly.
See a worked example
A team runs a scanner on their homepage and finds about 40 low-contrast errors, nearly all traced to one muted-gray body token (#999 on white, roughly a 2.8:1 ratio that fails AA). Darkening that single token to about #595959 (~7:1) likely clears most of them in one change, and adding an aria-label to the shared icon-only "search" button can retire every empty-button instance site-wide at once.
Tools to use
the WAVE evaluation tool, the WebAIM Contrast Checker, and the WebAIM Million report on why these six dominate.
Steal our AI prompt
I'm fixing accessibility errors across a component-based website and want to fix them once at the shared-template level, not page by page. Here is a scanner report (WAVE or axe) and the relevant component and template code: [paste report plus code for the button, link, form-field, header/footer, and root layout components, plus my color tokens]. For each of the six most common WCAG failures (low-contrast text, missing alt text, missing form input labels, empty links, empty buttons, missing document language), tell me the single shared file or token where I should fix it, give me the exact code change (including a darker AA-passing hex where a color fails contrast, an aria-label for any icon-only control, a real label element for each input, and the html lang attribute), and flag any error that is genuinely page-specific and cannot be fixed at the template level.
Test with real assistive technology and real people
Automated scanners catch only about a third of issues. Put a keyboard-only user and a screen reader through your key flows, especially checkout and forms. Nothing surfaces a broken experience faster than watching someone hit a wall your mouse never touched.
How to do it
- Unplug the mouse and Tab through the entire checkout and main lead form; confirm every field, button, and error message is reachable, shows a visible focus ring, and never traps focus.
- Run the same flows with a real screen reader (NVDA on Windows, VoiceOver on Mac) and your monitor off; check that labels read correctly and that focus jumps to validation errors when they appear.
- Recruit one or two people who use assistive technology daily and have them attempt a real purchase or signup while thinking aloud.
- Log every blocker with its flow, step, the assistive technology used, and expected versus actual behavior, then fix and re-test.
See a worked example
In a typical checkout run, an automated scan comes back clean, yet a keyboard-only pass finds that the "Apply promo code" button cannot be reached with Tab and the declined-card error never receives focus, so a screen reader user is never told the payment failed. Blocking issues like these are exactly what scanners tend to miss, since automated tools often catch only about a third of real accessibility problems.
Tools to use
Steal our AI prompt
I am manually testing my [describe flow, for example checkout or lead form] for accessibility using a keyboard and a screen reader. Here is the page markup and the click-by-click steps a user takes: [paste HTML and the flow]. Acting as an accessibility QA reviewer, give me a keyboard-only test script (the exact Tab, Shift+Tab, Enter, Space, arrow, and Esc sequence) and a screen-reader test script for both NVDA and VoiceOver that walks the whole flow. For each step, tell me what a correct experience should announce or where focus should move, and what would signal a likely WCAG failure such as an unreachable control, a missing or wrong label, focus not moving to an error message, or a keyboard trap. Do not assume anything that is not in what I pasted, and flag any step where I need to confirm behavior on real assistive technology.
Treat it as ongoing, not a one-time badge
Every new template, campaign page, and third-party embed can reintroduce failures. Accessibility is a standard you maintain, like performance or brand consistency, not a certificate you frame once and forget.
How to do it
- Add axe-core to your test suite (via Playwright or jest-axe) so every pull request scans your key templates and fails the build on new violations.
- Put Pa11y CI or Lighthouse CI in your pipeline with an accessibility score budget, so campaign pages and template edits cannot merge below your threshold.
- Keep a living list of third-party embeds (chat, forms, video, maps) and re-test each one after vendor updates, since they sit outside your codebase and your automated checks.
- Schedule a recurring keyboard-and-screen-reader spot check each release or quarter, and assign a named owner plus an escalation path.
See a worked example
A B2B team ships a relaunch with a clean audit, then a few weeks later a new webinar landing page, cloned from a duplicated template, goes live with an unlabeled email field and a chat widget embed whose text sits at roughly 2:1 contrast. An automated check wired into the deploy would likely have caught both before launch, instead of a prospect surfacing them in a support email later.
Tools to use
Steal our AI prompt
I want to make web accessibility an ongoing standard on my team, not a one-time audit. Our stack is [describe stack, for example Next.js on Vercel with CI on GitHub Actions] and our current release process is [describe how pages and campaigns ship]. Here is a list of our reusable templates, campaign page types, and third-party embeds: [paste]. Draft a lightweight accessibility maintenance plan that (1) says exactly where to add automated checks (axe-core in our test suite, plus Pa11y CI or Lighthouse CI in the pipeline) with a suggested pass or fail threshold, (2) defines a recurring manual review cadence with a named owner and an escalation path, and (3) lists which third-party embeds need re-testing after vendor updates. Map each item to who does it and when. Do not invent tools or statistics.
The same work, counted three times
Here is the reframe worth keeping. When you improve contrast, label your forms, describe your images, and make every control reachable by keyboard, you are not running a separate accessibility project off to the side. You are doing the inclusive UX work that makes the site clearer for everyone, and the autism-friendly design that reduces overwhelm for a far wider audience than you would guess.
The accessibility win, the conversion win, and the SEO win are frequently the same edit, counted three times.
That is how we approach it: not as a compliance line item, but as core UX and interface design that happens to also keep you on the right side of the law.