Make Your Website Accessible and Reach More Customers

Accessibility Is a Customer Decision, Not a Legal Afterthought

Accessibility is usually the last thing a small business thinks about, and almost always because someone sent a demand letter alleging Title III Americans with Disabilities Act (ADA) violations. That is an expensive way to learn a lesson that was cheap to learn up front.

One point of precision matters here, because marketing pages usually blur it. No website confers legal immunity. A business can still be sued under the ADA, the European Accessibility Act or Section 508, and a court decides what a compliant site means in a given case. What a documented accessibility effort actually does is change the odds: it gives you a dated record of the criteria you tested, the checks you ran and the issues you fixed, and that record is what your own counsel, a client auditor or an opposing attorney will look at. We do not claim that our sites comply with any particular law, and you should not assume that of anyone else. What we can show is the WCAG 2.2 AA criteria we built to, the automated check results, and the manual keyboard and screen-reader pass behind them.

We are also not going to quote you a lawsuit count or a settlement figure. Most of the numbers floating around the internet about ADA website cases come with no source attached, and a scary figure with no source is worse than no figure. If the risk matters to you, look it up: these cases are filed in federal court and the dockets are public and searchable. Check the filings for your own state and your own industry, then decide whether it is a problem for you. That takes an afternoon and replaces a rumor with a fact.

What we will tell you is the commercial side, because that is where the money is — and that side is not about defendants at all. It is about the customers who never get past your contact form.

The most common reaction to a demand letter is to install a cheap “accessibility overlay widget” (AccessiBe, UserWay and their competitors) and hope the problem goes away.

This makes the problem worse: overlays do not fix the underlying markup, interfere with the screen reader APIs the visitor is already using, and add a third-party script to every page. You can check that last part yourself: open your browser’s developer tools, filter for the widget’s script, and look at what it downloads on every visit. Nothing in that script repairs your heading structure or your button markup.

┌─────────────────────────────────────────────────────────────────────────────┐
│                    THE FALSE SAFETY OF ACCESSIBILITY OVERLAYS               │
├─────────────────────────────────────────────────────────────────────────────┤
│  WHAT THE WIDGET FINDS:   Broken markup, missing labels, no keyboard focus  │
│  ├─ A third-party script that loads on every page                           │
│  ├─ A script that tries to rewrite your markup with guesses                 │
│  ├─ A script that intercepts screen reader keys and breaks the experience   │
│  └─ A dependency you did not choose, running on every visitor's phone       │
├─────────────────────────────────────────────────────────────────────────────┤
│  WHAT WE DO INSTEAD:      Semantic HTML written in, not patched on          │
│  Native HTML5 landmarks | WCAG 2.2 AA criteria | No third-party scripts     │
│  Documented work you can show | Lighthouse accessibility target of 95+      │
└─────────────────────────────────────────────────────────────────────────────┘

At Aura Logic we build to WCAG 2.2 AA from the first line of markup, because it is a way of working that pays you back three times: more customers, less legal exposure, and pages that AI search engines can read.

1. Three Ways Accessibility Pays Back

More customers who can actually buy from you

The share of the population living with some form of disability is published every year by national statistics offices and public health agencies. Look up the current figure for your own market, then look at your own customer list and ask what it means for you. The number is not small, and a chunk of it is people who simply need a page they can finish on their own.

For a business selling services, one accessible page is the difference between a customer completing a booking alone and a customer giving up and calling you instead — or leaving.

There is a commercial reason to know the rules too: when you sell to government bodies, schools or large companies, Section 508 and the European Accessibility Act can be a mandatory prerequisite, and suppliers are asked for a VPAT (Voluntary Product Accessibility Template). A documented accessibility effort lets you answer that request with evidence instead of excuses.

AI search engines read your pages

There is an exact structural convergence between how assistive screen readers (JAWS, NVDA, Apple VoiceOver) interpret a website and how LLM crawlers (GPT-Bot, ClaudeBot, PerplexityBot) ingest it. Both rely on the Accessibility Object Model (AOM) and the semantic HTML tree.

• If a button is coded as a generic <div onclick="...">, an LLM agent cannot reliably infer its action.
• If headings jump from <h1> to <h4>, a crawler fails to map the relationships.
• When you build to WCAG 2.2 AA, you build the structure AI search systems read best at the same time.

Better design, not uglier design

There is a persistent myth that accessible design means ugly, utilitarian pages. In truth, the objects people keep for decades — Braun electronics, Leica cameras — are celebrated for their clarity and their obvious affordances. Disciplined contrast, generous tap targets and visible focus indicators are hallmarks of good craft, not of good intentions.

2. What WCAG 2.2 Actually Asks For

In October 2023 the W3C published WCAG 2.2. Unlike older versions it focuses on modern mobile and dynamic interaction patterns.

┌───────────────────────┬──────────────────────────┬─────────────────────────────────┐
│ WCAG 2.2 CRITERION    │ WHAT IT MEANS            │ HOW WE BUILD IT                 │
├───────────────────────┼──────────────────────────┼─────────────────────────────────┤
│ 2.4.11 Focus Not      │ The keyboard focus ring  │ CSS scroll-margin-top and       │
│ Obscured (Minimum)    │ must not be hidden by a  │ fixed header offsets on         │
│                       │ sticky header or footer  │ all interactive nodes           │
├───────────────────────┼──────────────────────────┼─────────────────────────────────┤
│ 2.5.8 Target Size     │ Tap targets must be at   │ Minimum 44x44px bounding        │
│ (Minimum)             │ least 24x24px, or have   │ box with visual padding         │
│                       │ 24px of spacing          │ for all mobile buttons          │
├───────────────────────┼──────────────────────────┼─────────────────────────────────┤
│ 3.3.7 Redundant       │ Data you typed before    │  Local form persistence and     │
│ Entry                 │ must not be typed again  │ autocomplete attributes         │
│                       │ on a later step          │ on all inputs                   │
├───────────────────────┼──────────────────────────┼─────────────────────────────────┤
│ 3.3.8 Accessible      │ No memory puzzles, no    │ WebAuthn passkeys, magic        │
│ Authentication        │ image CAPTCHAs, no       │ links, password manager         │
│                       │ cognitive test           │ autofill compatibility          │
└───────────────────────┴──────────────────────────┴─────────────────────────────────┘

3. Two Patterns You Can Copy

Pattern A: Focus Not Obscured via scroll-padding

When keyboard users navigate with Tab, a sticky header frequently covers the active focus ring. CSS solves it natively:

/* Guarantees keyboard focus is never obscured by sticky headers */
html {
  scroll-padding-top: 100px; /* Exact height of fixed navigation header */
  scroll-behavior: smooth;
}

:focus-visible {
  outline: 2px solid var(--accent-acid, #A3FF20);
  outline-offset: 4px;
  border-radius: 2px;
  transition: outline-offset 0.15s ease;
}

Pattern B: Real Buttons for Real Actions

Never use non-interactive elements for actions:

<!-- Antipattern: a div is not a button, and a keyboard user cannot press it -->
<div class="service-card" onclick="openModal()">
  <span>View the details</span>
</div>

<!-- A real button, announced correctly and operable from the keyboard -->
<button 
  type="button" 
  class="service-card" 
  aria-haspopup="dialog" 
  aria-controls="details-modal"
  aria-label="View the details for this service"
>
  <span class="card-title">Website design and build</span>
  <span class="action-affordance" aria-hidden="true">↗</span>
</button>

4. What It Changes for the Business

┌──────────────────────────┬──────────────────────────┬─────────────────────────────┐
│ WHAT YOU CARE ABOUT      │ BEFORE                   │ AFTER                       │
├──────────────────────────┼──────────────────────────┼─────────────────────────────┤
│ Legal exposure           │ Untested, undocumented   │ Reduced, not removed        │
│ Selling to larger buyers │ A VPAT request blocks it │ Answered with evidence      │
│ Customers you can serve  │ Some blocked by design   │ More can finish alone       │
│ AI search readability    │ Harder for crawlers      │ Semantic, readable          │
│ How the site feels       │ Fragile, patchy          │ Solid, considered           │
└──────────────────────────┴──────────────────────────┴─────────────────────────────┘

Conclusion

Accessibility is not a constraint on good design. It is one of the ways good design gets made.

Built on WCAG 2.2 AA standards, your site is more usable, easier for AI crawlers to read, and ready for the larger buyers who audit vendors before signing — along with the documented evidence that the work was really done. It reduces legal risk; it does not remove it, and no studio can honestly promise you that.