Website Accessibility Checklist for Small Businesses

A customer who uses a screen reader tries to book a service on your site and can't get past the date picker. Another can't read your gray-on-white prices. Neither one calls to complain. They just leave.

Accessibility is about making sure people with disabilities can use your website the same way everyone else does. It's also a legal question for many businesses. The good news is that most of the work is ordinary, fixable website hygiene.

What ADA and WCAG mean in plain terms

The Americans with Disabilities Act (ADA) is a US civil rights law. Title III covers businesses that are open to the public, like stores, restaurants, clinics and service companies. The law was written before the modern web, so it doesn't spell out website rules.

Even so, the Department of Justice has said that it views the websites of businesses open to the public as covered, and many US courts have agreed in cases brought against businesses. Courts haven't all ruled the same way on every question, and there is no regulation that sets one technical standard for private business websites. But when a standard comes up, it is usually WCAG.

The Web Content Accessibility Guidelines (WCAG) are published by the W3C, the group that maintains web standards. Version 2.2 is the current one. Each guideline has a level: A, AA or AAA. Level AA is the benchmark most organizations aim for, and it includes everything in level A.

This is a practical guide, not legal advice. If you've received a demand letter or have specific compliance questions, talk to a lawyer.

The checklist

These are common issues on small business sites, and you can check most of them yourself.

Images and alt text

• Every meaningful image has alt text that describes what it shows or does, like "Technician installing a water heater" or "Search."
• Decorative images use empty alt text so screen readers skip them.
• Text baked into images, like a sale banner, is also available as real text.

Color contrast

• Normal body text has a contrast ratio of at least 4.5:1 against its background.
• Large text, roughly 18 point or 14 point bold, needs at least 3:1.
• Buttons, form field borders and icons that carry meaning need at least 3:1.
• Color isn't the only signal. A required field or an error needs a word or icon, not just red.

Keyboard navigation and visible focus

• You can reach and use every link, button, menu and form with the Tab, Shift+Tab, Enter and Space keys.
• There's always a visible outline or highlight showing where you are on the page.
• That focus indicator isn't hidden behind a sticky header or cookie banner. WCAG 2.2 added this as a specific requirement.
• Pop-ups and menus can be closed with the keyboard, and focus doesn't get trapped.
• Buttons and links are big enough to tap. WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels, with some exceptions.

Forms, labels and errors

• Every field has a visible label tied to it in the code, not just placeholder text that disappears when you type.
• Errors say what went wrong and how to fix it, like "Enter a phone number with 10 digits."
• Errors are announced to screen readers, not only shown in red.
• Logins don't depend on solving a puzzle or remembering something, and people can paste passwords. WCAG 2.2 addresses this too.

Video and audio

• Prerecorded videos have accurate captions. Auto-generated captions are a starting point, but check them for errors.
• Audio-only content, like a podcast, has a transcript.
• Videos don't autoplay with sound.

Motion and animation

• Anything that moves, blinks or scrolls automatically for more than five seconds has a way to pause or stop it.
• Nothing flashes more than three times per second.
• Large animations respect the "reduce motion" setting in people's operating systems, which helps visitors who get dizzy from motion.

Headings and structure

• Each page has one main heading, and sections use headings in order, without skipping from H2 to H5 for styling.
• Headings are actual headings in the code, not bold text that looks like one. Screen reader users jump between headings to scan a page.
• The page language is set, and each page has a clear, unique title.

Link text

• Links make sense on their own. "View our service area" is better than "Click here" or "Learn more" repeated six times.
• Links that open a new tab or download a file say so.

How to test your own site

No single tool catches everything. A good routine combines automated scans with a few minutes of hands-on testing.

Automated tools flag issues like missing alt text, low contrast and unlabeled fields:

• WAVE, from WebAIM, is a browser extension that marks issues directly on your page.
• Lighthouse is built into Chrome's developer tools and includes an accessibility score along with performance and SEO.
• axe DevTools, from Deque, is a browser extension built on the open-source axe-core engine that many other tools use.

Automated checks can't tell whether your alt text is accurate, whether your focus order makes sense or whether a booking flow is actually usable. A clean score is a good sign, not a guarantee.

Manual tests fill that gap:

1. Put your mouse away and try to complete your main task, such as requesting a quote, using only the keyboard.
2. Turn on a screen reader and listen to your homepage and one form. VoiceOver is built into Mac and iPhone, Narrator into Windows and TalkBack into Android. NVDA is a widely used option for Windows.
3. Zoom your browser to 200 percent and make sure nothing is cut off or overlapping.
4. Turn on "reduce motion" in your device settings and reload the page.

Why overlays are not a fix

You may have seen ads for a single line of code that makes your site "compliant" by adding an accessibility widget. These are called overlays.

Overlays don't fix the underlying code. They try to patch problems in the browser after the page loads, and they often conflict with the screen readers and settings disabled visitors already use. Many accessibility practitioners and disability advocates have spoken out against them, businesses using overlays have still been sued, and the Federal Trade Commission has taken action against one overlay vendor over its compliance claims.

Accessibility is fixed in the site itself, not layered on top of it.

If your site is built on Shopify, BigCommerce or WordPress, many issues live in the theme or in third-party apps. Choosing an accessible theme and reviewing apps before you install them goes a long way. Our web development work treats this as part of building the site, not an add-on.

Where to start

You can make real progress this week without a big project:

1. Run WAVE or Lighthouse on your homepage, your main service page and your contact or checkout page.
2. Fix the easy wins first: missing alt text, unlabeled form fields and low-contrast text.
3. Complete your most important form using only the keyboard and note where you get stuck.
4. Check that your videos have accurate captions.
5. Remove any accessibility overlay and put that effort into fixing the source.
6. Add an accessibility statement with a phone number or email so people can tell you about problems.

If your site needs deeper work, like a rebuilt booking flow or a customer portal that works with assistive technology, you can get in touch and we'll help you sort out what to fix first.

General information only, not legal, tax or financial advice. Examples and figures are illustrative.