Website Accessibility for Small Businesses: What You Actually Need

Yes, your small business website needs to meet accessibility standards. Courts have consistently applied the Americans with Disabilities Act to websites, not just storefronts, and the volume of demand letters targeting small businesses has grown every year since 2018. The good news is that the fixes are concrete, the standard is clear (WCAG 2.1 AA), and an accessible site also performs better in search. This is a systems issue, not just an ethics one.

This post is part of the website foundation guide, which covers everything your site needs to function as a real business asset. Accessibility sits alongside performance and security as a foundation requirement, not an optional upgrade.

Does the ADA apply to small business websites?

Courts have ruled yes, repeatedly. The ADA prohibits discrimination on the basis of disability, and federal courts have found that "places of public accommodation" include websites, particularly when those sites are connected to a physical business. Small businesses are not exempt. The Department of Justice issued guidance in 2022 affirming that websites must be accessible under Title III of the ADA, and it specifically named WCAG 2.1 Level AA as the benchmark.

The legal exposure tends to catch owners off guard because the first contact is usually a demand letter, not a lawsuit. Law firms that specialize in these claims run automated scans across thousands of websites and send letters to those that fail the most common checks. One letter can ask for several thousand dollars in legal fees plus a commitment to fix the site within a short window. Most small business owners either pay or scramble to fix things under pressure.

A small winery we became aware of received exactly this kind of letter. Their site, built on a template a few years prior, had 40 product images with no alt text and a contact form where every field used only placeholder text instead of a real label. Two of the most common failures, and both would have shown up on any automated scan in under a minute.

What does WCAG 2.1 AA actually require?

WCAG 2.1 AA covers four areas: your content must be perceivable, operable, understandable, and robust. For most service business sites, that translates to a practical checklist of about a dozen items. Here is what matters most in practice.

Perceivable: can every user receive the information?

Every image needs alt text, a plain-language description of what the image shows or conveys. A photo of a finished kitchen remodel might have alt text like "newly renovated kitchen with white shaker cabinets and quartz countertops." A decorative divider line can use an empty alt attribute (alt="") so screen readers skip it. The point is that someone using a screen reader gets the same information a sighted user would.

Videos need captions. If you embed a testimonial clip or a how-it-works walkthrough, it needs synchronized text so a deaf viewer can follow along.

Color contrast must meet a ratio of at least 4.5:1 for normal-size text and 3:1 for large text (18pt or 14pt bold). Light gray text on a white background, a common template default, almost always fails this check. You can verify any color pair with a free contrast checker; the pass or fail is binary.

Operable: can every user control the site?

All interactive elements, buttons, links, form fields, menus, must be reachable and usable with a keyboard alone. Some users cannot use a mouse. Tab order should move logically through the page, and focus states (the visible outline that shows which element is currently selected) must be visible. Many sites remove focus outlines with CSS because they find them visually distracting. That is a mistake. It makes the site unusable for keyboard-only users.

If you have any content that auto-plays, spins, or flashes, users need a way to pause or stop it. The WCAG threshold for flashing content that can trigger seizures is specific: nothing should flash more than three times per second.

Understandable: does the site behave predictably?

Form fields need real labels. This is the failure we see most often across the service business sites we audit. A contact form where "First Name" appears as placeholder text inside the input field looks clean visually, but the moment someone starts typing, the label disappears. Screen readers announce the field by its label, not its placeholder, so a field with only placeholder text gets announced as "unlabeled" or skipped entirely. The fix is a proper <label> element tied to its input via a matching for and id attribute pair. It is a two-minute code change with significant impact.

Error messages need to identify the problem specifically. "Please correct the errors" is not sufficient. "Please enter a valid phone number" is. Users who rely on assistive technology need the error to be associated with the field it describes.

Robust: does the site work with assistive tools?

Your HTML needs to be written so that screen readers and other assistive technology can interpret it correctly. That means using real semantic elements: <button> for buttons (not a styled <div>), <nav> for navigation, proper heading hierarchy from <h1> through <h6>. Landmark regions (header, main, footer, nav) help screen reader users jump to the part of the page they need without tabbing through everything.

What are the most common accessibility failures on service business sites?

The most common failures are missing alt text on images, form fields that rely on placeholder text instead of real labels, insufficient color contrast, and missing skip-navigation links. When we run accessibility audits on service business sites, the form label failure is almost always present. It is not that owners decided to skip it; page builder templates simply do not implement labels by default, and most people building a site are focused on how it looks, not how it reads to a screen reader.

Missing skip-navigation links are a close second. A skip link is a small piece of code that lets keyboard users jump past the main navigation directly to the page content. Without one, every user has to tab through every nav item on every page load before they can get to the article or the contact form. It is a one-line HTML change at the top of the page, and it matters a lot to anyone navigating without a mouse.

Does making a site accessible help with SEO?

Yes, and the overlap is substantial. Alt text on images feeds Google Image search and gives the page additional keyword signals. Proper heading structure (h1, h2, h3) is the same structure search crawlers use to understand what a page is about. Logical reading order, clean semantic HTML, and fast keyboard-navigable pages all contribute to better Core Web Vitals scores, which are a direct ranking factor.

AI-driven search results add another layer. When a system like ChatGPT or Perplexity pulls information from your site to answer a question, it parses your HTML the same way a screen reader does. A page with proper structure, real labels, and descriptive alt text is easier for those systems to read accurately. Think about how customers find businesses today: more of that discovery happens through AI assistants, voice search, and zero-click results. Those channels all depend on a site that is built to be read by machines, not just displayed in a browser.

The sites that rank well and get cited by AI search tend to share the same characteristics as accessible sites: clear structure, descriptive text, and content organized for comprehension rather than decoration.

How do you audit your site for accessibility?

Start with a free automated tool. WAVE (from WebAIM) and Google Lighthouse are both free and run in a browser. Lighthouse is built into Chrome DevTools: open any page, right-click, choose Inspect, go to the Lighthouse tab, and run an Accessibility audit. It will score you on a scale of 0 to 100 and list specific failures with links to documentation explaining how to fix each one.

Automated tools catch the most common structural failures: missing alt text, contrast ratios below the threshold, duplicate IDs, missing form labels, and empty links. They will not catch everything. Some issues require a human to evaluate, like whether the alt text on an image is actually descriptive or just a file name, or whether the reading order makes sense. But automated audits catch the majority of what law firms scan for, and fixing those items removes your site from the easiest target pool.

After running Lighthouse, try tabbing through your own site with only the keyboard. Press Tab to move forward through elements, Shift+Tab to move back, Enter to activate a link or button. If you get stuck anywhere, or if you cannot tell which element is focused because the outline is invisible, those are failures that need fixing.

Which fixes matter most for a small business with a limited budget?

If you need to prioritize, fix these first. They cover the majority of what automated enforcement scans look for, and most can be addressed in an afternoon if you have access to your site's code or a developer who does.

• Add alt text to every image. For product or service images, describe what is shown. For logos, use the business name. For purely decorative images, use alt="".
• Replace placeholder-only form labels with real labels. Every input field needs a <label> element tied to it. The label can be visually hidden with CSS if you want to preserve a clean look, but it must exist in the HTML.
• Check color contrast. Paste your text color and background color into a free contrast checker. Any failing pair needs to be darkened or lightened until it passes 4.5:1.
• Add a skip navigation link. Place a visually hidden link at the very top of the page that becomes visible on focus and points to the main content: <a href="#main" class="skip-link">Skip to main content</a>.
• Restore focus outlines. If your CSS includes outline: none or outline: 0 on interactive elements, remove those lines or replace them with a visible focus style.

These five changes address the most commonly cited failures and the most commonly litigated ones. From there, a full WCAG 2.1 AA pass covers a longer checklist, but starting here puts you in a materially better position than most small business sites.

What does an accessible site look like in practice?

It looks exactly like a well-built site. The changes are almost entirely structural: they live in the HTML rather than in the visual design. A sighted user browsing normally will not notice the difference between a site with proper form labels and one without. What they might notice is that the site loads cleanly, does not have faded gray text they strain to read, and behaves predictably when they interact with buttons and forms.

When we build sites at Lyfework, accessibility is part of the foundation layer, the same way HTTPS and structured data are. Every form gets real labels. Every image gets alt text. Every interactive element gets a keyboard-accessible focus state. That is not a separate accessibility project; it is just how the site gets built. The result is a site that serves every visitor, ranks better, and does not generate a demand letter six months after launch.