Short answer: The accessibility problems on small business websites are mostly the same few, and most of them are quick to fix. WebAIM's 2026 scan of the top one million home pages found low contrast text on 83.9% of them, missing image alt text on 53.1% and missing form labels on 51%. Fixing text contrast, alt text, form labels, visible focus, tap target size and the page language takes about an hour on a typical five-page site. It removes the most common barriers, but it doesn't make a site fully WCAG conformant on its own.
This post walks through those fixes with the WCAG 2.2 success criterion behind each one, the code, and how to check your work. It also covers what the law does and doesn't say, because that's the first question most owners ask.
What is WCAG 2.2, and what level should a small business site aim for?
WCAG (Web Content Accessibility Guidelines) is the W3C's standard for accessible web content, and Level AA is the usual target. WCAG 2.2 was first published as a W3C Recommendation on 5 October 2023, with the current version dated 12 December 2024. It added nine success criteria and removed one (4.1.1 Parsing, now obsolete).
Each success criterion is a testable rule with a level: A (the minimum), AA (what laws and contracts usually reference) and AAA (enhanced). Two of the new AA criteria matter on almost every small site: 2.4.11 Focus Not Obscured (Minimum) and 2.5.8 Target Size (Minimum). Both are in the fixes below.
Is website accessibility legally required for US small businesses?
There's no federal regulation with detailed technical web standards for private businesses, but the ADA still applies to them. The Department of Justice's web guidance says the ADA's requirements apply to all the goods and services offered by businesses open to the public, that inaccessible website features can limit access to them, and that "the Department of Justice does not have a regulation setting out detailed standards." It describes WCAG as "helpful guidance."
The rule people often hear about is the 2024 Title II rule, which adopted WCAG 2.1 Level AA for state and local governments, not private businesses. An interim final rule published in April 2026 moved its compliance dates to April 26, 2027 for larger governments and April 26, 2028 for smaller ones.
What this means for you as the developer:
- Don't sell "ADA compliance" or anything that sounds like legal protection. You're not the client's lawyer, and nobody can promise that.
- Be wary of one-line overlay widgets that claim to fix everything. In April 2025 the FTC finalized an order requiring accessiBe to pay $1 million over claims that its plug-in could make any website WCAG compliant.
- Sell what you actually do: fixing real barriers that stop customers from reading, calling and booking.
How do you fix low contrast text? (about 10 minutes)
Make body text at least 4.5:1 against its background, and large text at least 3:1. That's 1.4.3 Contrast (Minimum), Level AA. "Large" means at least 18 point, or 14 point bold, which works out to about 24 CSS pixels regular or about 18.7 CSS pixels bold.
On small business sites the failures cluster in the same places:
- Light grey body text on white, chosen because it "looks cleaner".
- White text on a hero photo with no overlay. Contrast changes across the image, so part of the headline fails.
- Placeholder text inside form fields.
- Brand-colored buttons with white text, such as light green or yellow.
Check each color pair with a contrast checker (WebAIM's is free) or the color picker in Chrome DevTools, which shows the ratio. For hero text over photos, add an overlay rather than changing the brand color:
.hero { position: relative; } .hero::before { /* darken the photo under the headline */ content: ""; position: absolute; inset: 0; background: linear-gradient(90deg, rgb(0 0 0 / .65), rgb(0 0 0 / .2)); } .hero > * { position: relative; } body { color: #333; } /* #333 on white is well above 4.5:1 */ Icons, input borders and focus outlines fall under a separate rule, 1.4.11 Non-text Contrast (AA): at least 3:1 against adjacent colors.
How do you write alt text that actually helps? (about 15 minutes)
Give every meaningful image a short text alternative that says what it shows or does, and give decorative images an empty alt="". That's 1.1.1 Non-text Content, Level A, and missing alt text was the second most common failure in the WebAIM data.
<!-- Meaningful photo --> <img src="deck.webp" alt="Cedar deck with built-in benches, finished in 2025"> <!-- Logo that links home: describe the destination --> <a href="/"><img src="logo.svg" alt="Fictional Example Decks, home"></a> <!-- Decorative divider: empty alt, so screen readers skip it --> <img src="wave.svg" alt=""> The one we see most on local sites is worse than missing alt text: the opening hours, the menu or a price list posted only as an image or a scanned flyer. Put that information in real HTML text. It helps screen reader users, people who zoom, and search engines, and the owner can update it without opening a design app.
How do you label form fields properly? (about 10 minutes)
Every input needs a visible label tied to it with for and id. That's 3.3.2 Labels or Instructions (Level A), with 1.3.1 and 4.1.2 covering the code side. A placeholder isn't a label: it disappears when you start typing and is usually low contrast.
<label for="phone">Phone number</label> <input id="phone" name="phone" type="tel" autocomplete="tel" required> <label for="job">What do you need help with?</label> <textarea id="job" name="job" rows="4"></textarea> Page builder form widgets sometimes hide labels and rely on placeholders by default. Look for a "show label" setting before writing custom code.
How do you make keyboard focus visible and not hidden? (about 10 minutes)
Never remove the focus outline without replacing it, and make sure sticky headers and cookie banners don't cover the focused element. The first is 2.4.7 Focus Visible (AA). The second is new in WCAG 2.2: 2.4.11 Focus Not Obscured (Minimum), Level AA, which requires that a focused component "is not entirely hidden due to author-created content."
/* Replace "outline: none" in the theme with a clear indicator */ :focus-visible { outline: 3px solid #1a56db; outline-offset: 3px; } /* Keep focused elements from scrolling under a 72px sticky header */ html { scroll-padding-top: 88px; } Test it by pressing Tab from the top of the page to the footer. You should always be able to see where you are. If the cookie banner sits over the bottom of the screen, make sure focus can reach its buttons and that it doesn't cover the links behind it.
How big do tap targets need to be under WCAG 2.2? (about 10 minutes)
At least 24 by 24 CSS pixels, or spaced so that a 24 px circle around each one doesn't touch another target. That's 2.5.8 Target Size (Minimum), Level AA. There are exceptions, including links inside a sentence and controls the browser draws itself. The AAA level, 2.5.5, asks for 44 by 44 pixels, and that's a sensible design target for a site people use on their phone.
The usual offenders are the row of social icons in the footer, the close "X" on a popup, and phone and email links squeezed together in a top bar.
.social a, .popup-close { display: inline-grid; place-items: center; min-width: 44px; min-height: 44px; /* passes 2.5.8 comfortably */ } What else fits into the hour?
Three quick ones that also show up in the WebAIM top six:
- Set the page language.
<html lang="en">(ores, or whatever the site is in). That's 3.1.1 Language of Page, Level A, missing on 13.5% of home pages in the 2026 scan. - Name icon-only buttons and links. A hamburger button or a phone icon with no text is an "empty button" or "empty link" to a screen reader. Add visible text or an
aria-label. - Make link text say where it goes. "Click here" and "Read more" tell nobody anything out of context. "See our drain cleaning prices" does. That's 2.4.4 Link Purpose (In Context), Level A.
Here are all of the fixes in one place. The times are our rough estimates for a typical five-page site, not measurements:
| Fix | WCAG 2.2 criterion | Level | Rough time |
|---|---|---|---|
| Text contrast 4.5:1 (3:1 large) | 1.4.3 Contrast (Minimum) | AA | 10 min |
| Alt text, empty alt for decoration | 1.1.1 Non-text Content | A | 15 min |
| Visible, connected form labels | 3.3.2 Labels or Instructions | A | 10 min |
| Visible focus indicator | 2.4.7 Focus Visible | AA | 5 min |
| Focus not hidden by sticky UI | 2.4.11 Focus Not Obscured (Minimum) | AA | 5 min |
| Tap targets 24x24 px minimum | 2.5.8 Target Size (Minimum) | AA | 10 min |
| Page language | 3.1.1 Language of Page | A | 1 min |
| Named icon buttons, clear link text | 4.1.2 and 2.4.4 | A | 5 min |
How do you check your work?
Use one automated tool and two manual checks. Automated tools catch only part of the problems, so don't stop at a green score.
- Run WAVE (from WebAIM) or axe DevTools on each page and fix what they flag.
- Tab through every page with the keyboard only. Can you reach and see everything, and open the menu?
- Zoom the browser to 200%. Text should still be readable without content being cut off (1.4.4 Resize Text, Level AA).
When you report back to the owner, describe barriers removed, not legal status. A fictional example:
I fixed the issues that stopped some customers from using your site: the grey text on the homepage was too faint to read for many people, the quote form fields had no labels for screen readers, and the hours were only in a picture. Those are all fixed now. This isn't a full accessibility audit, but it covers the most common problems we see on small business sites.
Finding sites that need this
The manual way: search a trade and a town, run a few home pages through WAVE, and note the ones with faint text and unlabeled forms. On most local sites you'll find something within a minute.
If you'd rather start from a list, LeadReef finds local businesses whose websites are outdated, broken on mobile or missing, shows what's wrong with each one, and helps with a first mockup and outreach message. You choose who to contact and send everything yourself. The first 10 leads are free. Full disclosure: we build LeadReef. Everything above works without it.
Frequently asked questions
What WCAG level should a small business website meet?
Level AA is the usual target and what most laws, contracts and policies reference. The current version is WCAG 2.2, which adds nine new criteria to WCAG 2.1 and drops the obsolete 4.1.1 Parsing.
Is ADA website compliance required for small businesses in the US?
The DOJ says the ADA applies to the goods and services of businesses open to the public, including what they offer online, but it has no regulation with detailed web standards for private businesses. For legal questions, the owner should talk to a lawyer; your job is fixing the barriers.
What contrast ratio does WCAG require?
4.5:1 for normal text and 3:1 for large text (at least 18 point, or 14 point bold) under 1.4.3, Level AA. Icons, input borders and focus indicators need 3:1 under 1.4.11.
What is the minimum tap target size in WCAG 2.2?
24 by 24 CSS pixels under 2.5.8 Target Size (Minimum), Level AA, with exceptions for spacing, inline links and browser-drawn controls. 44 by 44 pixels is the AAA level and a good design target.
Do accessibility overlay widgets make a site compliant?
Don't count on it. The FTC finalized an order in April 2025 requiring overlay vendor accessiBe to pay $1 million over claims that its plug-in could make any website WCAG compliant. Fixing the underlying HTML and CSS is the reliable route.
Sources (checked November 2026): W3C, Web Content Accessibility Guidelines (WCAG) 2.2; W3C WAI, What's New in WCAG 2.2; W3C WAI, Understanding 2.5.8 Target Size (Minimum); WebAIM, The WebAIM Million (2026); U.S. Department of Justice, Guidance on Web Accessibility and the ADA; Seyfarth Shaw, ADA Title III blog, DOJ extends ADA Title II website accessibility deadlines (April 2026); Federal Trade Commission, FTC approves final order requiring accessiBe to pay $1 million (April 22, 2025).



