Web Accessibility (WCAG) for Small Businesses: Where to Start

Most small business owners we talk to agree that their website should work for everyone. Where they get stuck is the next step. Accessibility guidelines look long and technical, the legal headlines sound scary, and it is hard to know whether a site is "accessible enough" or where to start fixing it.

Here is the reassuring part: a large share of real-world accessibility problems come from a fairly short list of issues. Missing alt text, low-contrast text, forms without labels, buttons you can't reach with a keyboard. Fixing those makes a real difference to real people, and much of it is ordinary good web development.

This guide explains what WCAG is, why it matters, the quick wins we look for on every project, how to test, and a practical action plan you can follow.

Please note: this article is general information, not legal advice. Accessibility laws and how they are enforced vary by country, state, and industry. If you have specific legal concerns, talk to a qualified attorney.

What WCAG is, in plain language

The Web Content Accessibility Guidelines (WCAG) are published by the World Wide Web Consortium (W3C). They are the most widely referenced standard for making websites and apps usable by people with disabilities. The current version is WCAG 2.2, which builds on 2.0 and 2.1 and adds criteria around things like focus visibility, target sizes, and accessible authentication.

The three conformance levels

Level	What it means	Examples
A	The minimum. Failing these blocks some users entirely.	Text alternatives for images, keyboard access, no keyboard traps
AA	The common target for businesses and the level most policies reference.	Color contrast of at least 4.5:1 for normal text, visible focus, consistent navigation
AAA	The highest level. Not usually required site-wide because some criteria aren't achievable for all content.	Contrast of 7:1, sign language for prerecorded video

For most small businesses, WCAG 2.2 Level AA is a sensible goal.

The POUR principles

Every WCAG guideline sits under one of four principles. They are a useful mental model even if you never read the full specification.

• Perceivable: people can perceive the content with at least one sense. Images have text alternatives, videos have captions, text has enough contrast.
• Operable: people can use the interface. Everything works with a keyboard, nothing flashes dangerously, users have enough time to complete tasks.
• Understandable: content and behavior are predictable. Clear labels, helpful error messages, consistent navigation.
• Robust: content works with a range of browsers and assistive technologies, which mostly means using valid, semantic HTML.

Why accessibility matters for a small business

Real people use your site

Disabilities are common, and many are not visible: low vision, color blindness, hearing loss, tremors, dyslexia, or a temporary injury like a broken wrist. Add older visitors, people on small screens in bright sunlight, and people with slow connections, and accessibility starts to look like plain usability. Anyone who can't complete your contact form is a lead you never hear about.

Legal risk, in general terms

In the United States, accessibility lawsuits and demand letters involving websites have become more common, often citing the Americans with Disabilities Act. Other regions have their own rules, such as the European Accessibility Act in the EU. We are not lawyers and can't tell you what applies to your business, but we can say that a site built and tested against WCAG AA is in a much better position than one that has never been checked.

The SEO overlap

Many accessibility practices also help search engines understand your pages: descriptive alt text, a logical heading structure, meaningful link text, transcripts for video, and clean semantic HTML. Accessibility isn't a ranking trick, but the work overlaps with good technical SEO. Our technical SEO checklist covers the search side in more detail.

Quick wins that fix the most common problems

These are the issues we find most often in audits. Most can be fixed without redesigning anything.

1. Alt text on meaningful images

Every image that conveys information needs a short, descriptive alt attribute. Decorative images should have an empty alt (alt="") so screen readers skip them. Our image optimization guide includes tips on writing good alt text.

2. Sufficient color contrast

WCAG AA asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text and key interface elements. Light gray text on white is the classic failure. Check your brand colors with a contrast checker before they end up everywhere.

3. Keyboard navigation

Put your mouse aside and press Tab through your site. Can you reach every link, button, menu, and form field? Can you open and close the mobile menu or a modal? Can you get out of it again? Custom components built from generic div elements are frequent offenders; native buttons and links work with keyboards by default.

4. Visible focus states

When you tab through a page, you should always see where you are. Many sites remove the browser's focus outline because a designer found it ugly. Restyle it instead of removing it. WCAG 2.2 adds criteria that make focus visibility even more important.

5. Form labels and errors

Every input needs a visible label connected to it, not just placeholder text that disappears as you type. Error messages should say what went wrong and how to fix it, in text, not only with a red border.

6. A logical heading structure

Use one main heading per page, then headings in order to create an outline. Screen reader users often navigate by headings, so choose heading levels for structure, not for font size.

7. Descriptive link text

"Click here" and "Read more" mean nothing out of context. Links like "Read our pricing guide" or "Download the 2026 menu (PDF)" tell everyone, and search engines, where they lead.

8. Captions and transcripts

Videos with speech need accurate captions. Auto-generated captions are a starting point, but review them, especially for names and technical terms. Podcasts and audio benefit from transcripts.

How to test your site

No single tool catches everything. Automated tools are good at finding certain problems, such as missing alt text or low contrast, but they can't judge whether alt text is meaningful or whether a flow makes sense. Combine automated and manual checks.

Tool	Type	Good for
Lighthouse (built into Chrome DevTools)	Automated	Quick accessibility score and a list of common issues
axe DevTools browser extension	Automated	Detailed, developer-friendly reports with few false positives
WAVE by WebAIM	Automated, visual	Seeing issues overlaid directly on the page
Keyboard only	Manual	Finding focus, menu, and modal problems
Screen readers (VoiceOver on Mac and iOS, NVDA on Windows, TalkBack on Android)	Manual	Hearing how your content is actually announced

A perfect Lighthouse score does not mean a site is fully accessible. Treat it as a floor, not a finish line.

Why overlay widgets are not a fix

You've probably seen tools that promise instant compliance with a single line of JavaScript, usually showing a floating accessibility icon. They are tempting because they are cheap and quick. In our view, they don't solve the problem.

• They can't reliably fix the underlying code, such as unlabeled custom controls or broken keyboard flows.
• Many disabled users already have assistive technology configured the way they like, and overlays can interfere with it.
• Many accessibility practitioners and disability advocates have publicly criticized overlays, and using one is not a guarantee against complaints.

Some overlay features, like letting users resize text, are harmless on their own. But the fix for accessibility issues is fixing the site itself.

A realistic action plan

1. Pick your key pages and flows. Home, main service or product pages, contact form, checkout, booking. These matter most.
2. Run automated checks with axe or WAVE on each and record the issues.
3. Do a keyboard pass through each flow and note anything you can't reach or see.
4. Try a screen reader for ten minutes on your most important page. It is eye-opening.
5. Fix in priority order: blockers first (can't submit the form, can't open the menu), then contrast and labels, then polish.
6. Fix the design system, not just pages. Update colors, button styles, and form components once so every new page inherits the fix.
7. Train whoever publishes content to add alt text, use headings correctly, and write descriptive links.
8. Publish an accessibility statement with a way for visitors to report problems, and respond when they do.
9. Re-test regularly, ideally with automated checks in your development workflow and a manual review after major changes.

FAQ

Is my website legally required to meet WCAG?

It depends on where you operate, your industry, and who you serve, and the rules continue to evolve. This is a question for an attorney. Practically speaking, WCAG 2.2 AA is the benchmark most organizations work toward.

How long does an accessibility cleanup take?

For a typical small business site, the quick wins above can often be addressed in days to a few weeks. Complex web applications or stores with many custom components take longer.

Do I need to rebuild my site?

Usually not. Most issues can be fixed in place. A rebuild makes sense only if the site has deeper problems, such as an outdated theme that is hard to maintain.

Can I rely only on automated tools?

No. They catch a useful portion of issues, but manual keyboard and screen reader testing is needed to catch the rest.

Getting help

We build accessibility into every project from the start, because it is far cheaper than retrofitting it. If you'd like your current site reviewed, take a look at our web development services or get in touch and we'll tell you honestly where you stand.