Website Accessibility for Small Business: How to Build a Site Everyone Can Use

Most business owners first hear the phrase “web accessibility” in one of two ways: a demand letter from a law firm, or a customer who quietly gives up on the contact form and calls a competitor instead. Both are expensive. The second one is worse, because you never find out it happened. We’ve seen sites that rank beautifully, load fast, and convert badly for one unglamorous reason — a meaningful share of visitors physically could not complete the thing the page was asking them to do.

The good news is that website accessibility for small business is not the vague, bottomless project it gets made out to be. There’s a published standard, the majority of real-world problems fall into about eight recurring categories, and most of them are cheap to fix if you catch them during a build or a redesign rather than after a complaint. This guide covers what the standard actually says, which fixes deliver the most benefit per hour, why the popular “accessibility widget” shortcut tends to disappoint, and how to keep a site compliant once it’s live.

What Web Accessibility Actually Means

Accessibility means people can perceive, operate, and understand your site regardless of how they’re using it. That includes people who are blind or have low vision, people who are deaf or hard of hearing, people with motor conditions who navigate by keyboard or switch device rather than a mouse, and people with cognitive or attention differences who need clear structure and forgiving forms.

It also includes a much larger group nobody counts: someone with a broken wrist, someone reading on a phone in bright sunlight, someone on a noisy job site who can’t play audio, someone whose eyesight is simply getting older. Accessibility work is permanent-disability work and situational-limitation work at the same time. That’s why it so often improves conversion rates for everyone.

The technical standard almost everyone references is the Web Content Accessibility Guidelines (WCAG), published by the World Wide Web Consortium. The version most often cited in legal settlements and procurement requirements is WCAG 2.1 Level AA, with WCAG 2.2 the current published update. Level AA is the practical target — Level A is too permissive to be a real goal, and Level AAA includes criteria that aren’t realistic for every kind of content.

Accessibility isn’t a feature you bolt on at the end. It’s a property of how the page was built — and building it correctly the first time costs a fraction of retrofitting it later.

The Legal Landscape, Without the Scare Tactics

Here’s the honest version. The Americans with Disabilities Act predates the modern web and does not contain a line-by-line technical spec for commercial websites. Courts have generally treated the websites of businesses open to the public as covered under Title III, and plaintiffs’ firms have brought a large and steady volume of claims on that basis. The Department of Justice has also issued a rule setting WCAG 2.1 Level AA as the technical standard for state and local government entities under Title II, which reinforces WCAG as the reference point everyone converges on.

Some states add their own layer. In California, for example, accessibility claims are frequently brought under state civil rights law in addition to federal law, which is part of why California businesses see a disproportionate share of demand letters.

We are not attorneys and this is not legal advice — if you receive a demand letter, get a lawyer who handles these specifically. But the practical takeaway is stable and uncontroversial: conform to WCAG 2.1 AA, document your efforts, and give people a clear way to report a barrier. That posture is both the right thing to do and the strongest defensible position.

The Eight Issues That Cause Most Real-World Failures

When we audit a small business site, the same problems come up over and over. Fix these and you’ve handled the bulk of what automated scanners flag and what actual users complain about.

1. Missing or useless alt text

Every meaningful image needs a text alternative describing what it conveys. “image_4837.jpg” helps nobody. Neither does stuffing keywords into alt attributes. Decorative images — dividers, background flourishes — should carry an empty alt attribute so screen readers skip them instead of announcing noise.

2. Low color contrast

Light gray text on white looks refined in a design mockup and is genuinely hard to read on a laptop outdoors. WCAG AA asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. This is the single most common failure we see, and it’s usually a five-minute change to a brand color variable.

3. Keyboard traps and invisible focus

Try it yourself right now: open your own site and navigate using only the Tab key. Can you see where you are on every step? Can you open and — critically — close every menu, modal, and popup? If a cookie banner or newsletter popup can be tabbed into but not out of, keyboard users are stuck. If your CSS removed the focus outline because it looked “ugly,” you’ve made the site unusable for a whole category of visitors.

4. Forms without real labels

Placeholder text is not a label. It disappears the moment someone types, and assistive technology handles it inconsistently. Every field needs a programmatically associated <label>. Error messages need to say what went wrong in plain language and be announced, not just turn the border red.

5. Headings used as styling

Screen reader users navigate by heading structure the way sighted users skim a page. When H2 and H3 are chosen because of how big the text looks rather than what the content hierarchy is, that navigation collapses. One H1 per page, then a logical nesting underneath it.

6. Link text that says nothing

A page full of “click here” and “read more” is a page that reads, out of context, as a list of identical links. Write link text that describes the destination. This also happens to be better for search engines.

7. Video and audio without captions or transcripts

Auto-generated captions are a starting point, not a finish line — they mangle names, jargon, and prices. If you publish video, budget a few minutes to correct the transcript. Most viewers watch with sound off anyway.

8. Motion, autoplay, and time limits

Carousels that advance on their own, video that autoplays with sound, and sessions that expire without warning all create barriers. Give people controls: pause, stop, extend.

Why Accessibility Overlay Widgets Disappoint

You’ve seen the pitch: install one line of JavaScript, get a floating accessibility icon, become compliant overnight. We understand the appeal. But the disability community has been broadly and vocally critical of these tools, and many accessibility professionals will tell you the same thing we will — an overlay sits on top of a broken page and tries to guess at what the markup should have said.

Overlays can genuinely help with a narrow set of user-preference features: contrast toggles, text resizing, reduced motion. What they cannot reliably do is invent accurate alt text, repair a form that has no labels, or fix a custom dropdown that was never keyboard-operable. Some overlays also interfere with the screen readers and browser settings people have already configured for themselves.

Treat an overlay as an optional convenience layer, never as the compliance strategy. If a vendor tells you their script makes you legally compliant, ask them to put that in writing, then ask what happens when the underlying HTML is the problem.

A Realistic Remediation Plan

You don’t need to fix everything at once. You need to fix the highest-traffic, highest-stakes paths first, then work outward on a schedule.

Phase	Focus	Typical effort
1. Audit	Automated scan plus manual keyboard and screen reader testing on key templates	Days
2. Critical paths	Homepage, primary service pages, contact form, checkout, booking flow	1–2 weeks
3. Templates	Blog layout, archive pages, global header, footer and navigation — fix once, inherit everywhere	1–3 weeks
4. Content backlog	Alt text, headings, link text, PDFs and documents	Ongoing
5. Governance	Publishing checklist, training, accessibility statement, periodic re-testing	Ongoing

One important caveat on tooling: automated scanners reliably catch only a portion of accessibility issues — contrast, missing attributes, structural errors. They cannot judge whether your alt text is accurate or whether a workflow makes sense. Automated testing is the floor, not the ceiling. Real manual testing, including tabbing through the site and listening to it with a screen reader, is where the meaningful problems surface.

The Business Case Nobody Puts in the Demand Letter

Set the legal exposure aside for a moment. The disability community represents an enormous amount of purchasing power, and accessible sites are simply easier to use for everyone. The same fixes that satisfy WCAG — clean semantic structure, readable contrast, labeled forms, descriptive links, captioned media — tend to improve comprehension, reduce form abandonment, and give search engines and AI systems a clearer understanding of your content.

There’s overlap with performance work, too. Sites built on clean, semantic markup are usually lighter and faster, and page speed has its own direct effect on conversion. If you’re already planning improvements, it’s efficient to pair accessibility with a round of website speed optimization rather than opening the code twice.

The cheapest accessibility work happens during design and development. The most expensive happens after a lawyer’s letter arrives.

How to Keep It From Regressing

Accessibility is not a project you complete. It’s a property you maintain — and the most common way a compliant site becomes non-compliant is ordinary publishing. Someone adds a new landing page with a low-contrast button. Someone uploads twenty product photos with no alt text. A plugin update changes the markup of your menu.

Build a small amount of governance into how the site runs:

• A publishing checklist. Alt text, heading order, descriptive link text, captions on video. Five items, every time.
• Design tokens that pass contrast. Lock brand colors into combinations already verified at 4.5:1 so nobody has to re-litigate it page by page.
• Keyboard testing after major changes. Tab through the top templates after any theme or plugin update.
• An accessibility statement. A short page stating your conformance target, known limitations, and a real contact method for reporting barriers.
• Scheduled re-testing. Fold it into whatever you already do for a website maintenance plan — quarterly is reasonable for most small business sites.

If you’re planning a redesign or a new build, that’s the ideal moment to get this right. Accessibility requirements baked into the design system and component library cost almost nothing extra; the same requirements applied to a finished site mean revisiting every template. It’s one of the things we account for from the start in our web and mobile app development work, because retrofitting is where budgets go to die.

Start With One Hour

If this all feels like a lot, here’s a concrete first step that costs you sixty minutes. Open your site. Tab through the homepage and your main contact or checkout flow using only the keyboard, and write down every point where you get lost, stuck, or can’t tell where you are. Then run any free automated checker on those same pages and note the contrast failures and missing labels. That short list is almost certainly your real priority queue — and it’s usually shorter than people expect.

Good website accessibility for small business isn’t about perfection or a badge in the footer. It’s about making sure that every person who wants to hire you, buy from you, or contact you actually can.

If you’d like a second set of eyes on your site — accessibility, performance, or the whole picture — we’re happy to take a look. Frozen Crow offers a free, no-obligation consultation with no pressure and no jargon. Reach out at frozencrow.com and let’s talk about what your site is doing well and where it’s quietly losing customers.