Website Accessibility for Small Business Sites: What’s Required vs What’s Overkill

Most website redesign briefs cover branding, page speed, and mobile layout in detail, then handle accessibility with a single line: “make sure it’s accessible.” That line usually means nothing gets built for it, and the site launches with contrast issues, missing form labels, and a keyboard trap or two baked into the new navigation menu. Nobody notices until a customer using a screen reader can’t complete a checkout, or a demand letter shows up referencing the ADA.

Accessibility work on a business website isn’t really optional anymore, but it also isn’t the compliance minefield a lot of agencies make it sound like. Most of what matters is a short list of concrete fixes, most of them cheap, and knowing which ones actually move the needle changes how you plan a build or a redesign from the wireframe stage instead of scrambling to patch it in after launch.

There’s no single accessibility law for websites, and that’s the confusing part

The Americans with Disabilities Act doesn’t mention websites. It was written for physical spaces. But U.S. courts have spent the last decade applying Title III of the ADA to business websites anyway, treating them as “places of public accommodation” in the same way a storefront is, and the Web Content Accessibility Guidelines (WCAG) have become the de facto yardstick courts and settlements point to — specifically WCAG 2.1 or 2.2 at the AA conformance level.

In Australia, the Disability Discrimination Act 1992 requires businesses that provide goods and services, websites included, not to discriminate against people with disability, and the Australian Human Rights Commission’s digital accessibility guidelines point to WCAG as the benchmark. The best-known Australian case, Maguire v SOCOG in 2000, found the Sydney Olympics website unlawfully inaccessible to a blind user. So whether you’re in Australia or the US, the practical target is the same: WCAG 2.2 AA.

In the US, that gap between “no explicit law” and “courts consistently reference one standard anyway” is exactly why so many business owners either ignore accessibility entirely or panic and buy the first widget that promises to fix it. Neither is the right move. The practical target is WCAG 2.2 AA, treated as a design and development standard rather than a legal checkbox, because it also happens to produce a site that works better for slow connections, older phones, and anyone filling out a form in a hurry.

The fixes that actually matter, in order of impact

Every site build has a limited budget of hours. These are the items worth spending them on first, because they’re the ones that get flagged in an audit, cause real friction for real users, and are relatively inexpensive to build in from the start:

• Color contrast. Body text needs a contrast ratio of at least 4.5:1 against its background; large headings can drop to 3:1. Light-gray-on-white body copy and low-contrast button states are the single most common failure on marketing sites, and they’re a five-minute fix in CSS once someone runs the check.
• Alt text on meaningful images. Decorative background graphics don’t need it. Product photos, screenshots, and infographics that carry information do. “Image of a laptop” is not useful alt text; “Dashboard showing monthly traffic up from the redesign” is.
• Forms with real labels. A placeholder that disappears once you start typing is not a label. Every field needs a persistent, programmatically associated label, and error messages need to say which field is wrong and why, not just turn the border red.
• Keyboard navigation. Every interactive element — nav links, dropdown menus, modal close buttons, the “back to top” arrow — has to be reachable and operable using only the Tab and Enter keys, in a sensible order, with a visible focus outline. Custom dropdown menus and modals built without keyboard support are the most common way sites fail this outright.
• Heading structure that reflects the actual outline. One H1 per page, headings used in order, and headings chosen because they mark a section, not because a designer liked how a font size looked.
• Link and button text that means something out of context. A screen reader user often jumps between links on a page without reading the surrounding text. A page full of “click here” and “read more” links gives them nothing to go on.
• Captions on video. Any hosted video with spoken content needs captions, not just for accessibility but because most people watch marketing video muted anyway.

Why overlay widgets aren’t the shortcut they’re sold as

A whole category of plugins exists that promise to bolt accessibility onto a finished site with one script tag — an icon in the corner that lets visitors adjust font size, contrast, and spacing. They’re appealing because they’re fast to install and cheap compared to an actual audit.

The problem is that these tools sit on top of the page and adjust its presentation without fixing what’s underneath. They can’t add a missing form label, can’t fix a keyboard trap in a custom dropdown, and can’t rewrite alt text that was never written. Accessibility auditors and disability advocacy groups have been consistently critical of overlay-only approaches for exactly this reason, and several of the best-known overlay vendors have themselves been named in accessibility complaints. An overlay can be a reasonable add-on for visitors who want on-the-fly font or contrast adjustments. It is not a substitute for building the underlying markup correctly.

A practical audit you can run this week, no consultant required

Before commissioning a full audit, three checks will surface most of the real problems on a typical business site:

• The keyboard test. Put the mouse away. Tab through the homepage and your main conversion page — contact form, booking page, whatever matters most. Can you reach every link, button, and form field? Can you always see where focus currently is? Can you close any popup or menu you open?
• An automated scan. Free browser extensions like WAVE or axe DevTools will catch missing alt text, contrast failures, and unlabeled form fields in a couple of minutes per page. They won’t catch everything — automated tools miss a meaningful share of real-world issues, particularly around logical reading order and whether alt text is actually descriptive — but they’re a fast way to find the obvious problems.
• A screen reader spot check. Turn on VoiceOver (built into macOS and iOS) or NVDA (free, for Windows) and navigate your homepage and one deeper page by ear. You don’t need to be fluent with the tool. You just need to notice if anything is unlabeled, unreachable, or announced in a way that makes no sense.

What’s genuinely overkill for a small site

Not every business needs the same level of rigor. A five-page local service site doesn’t need a dedicated accessibility statement page, a VPAT document, or a full WCAG 2.2 AAA conformance push — AAA includes criteria, like sign language interpretation for all video, that are appropriate for large public institutions, not a plumbing company’s homepage. That level of investment makes sense for e-commerce platforms, SaaS products, healthcare portals, and larger organizations with real legal exposure and a broad, high-volume user base.

For most small business sites, the seven fixes above, checked with the three tests above, cover the overwhelming majority of real risk and real user friction. Spending a redesign budget chasing AAA-level conformance on a low-traffic marketing site is money that would do more good spent on the content or conversion path itself.

Build it in from the wireframe, not after launch

The cheapest time to handle every item on this list is before a single line of CSS gets written. Contrast ratios belong in the color palette decisions made during design, not caught in a post-launch scan. Form structure and labeling belong in the component library, not patched field-by-field after a complaint. Keyboard behavior belongs in how a developer builds a dropdown menu the first time, not retrofitted into a menu that was never meant to work that way.

Treating accessibility as a design and development requirement from day one, rather than a legal checkbox handled after the fact, is what actually keeps it cheap. It’s also, not incidentally, what makes a site easier to use for every visitor having a bad day on a slow connection — which is most visitors, most of the time.