Here's the thing most small business owners don't realize: your website is probably failing a meaningful chunk of your visitors right now, and you have no idea, because the failures are invisible to you. You can see the screen. You use a mouse. Your eyes parse low-contrast gray text just fine. The person using a screen reader, the person navigating by keyboard because a tremor makes a trackpad impossible, the person who bumped their phone brightness all the way down on a sunny day — they're the ones hitting the walls.
That's the human reason to care, and it's the real one. The legal reason is the one that gets attention: thousands of lawsuits and demand letters are filed every year in the US alleging that a website isn't accessible to people with disabilities, usually citing the Americans with Disabilities Act (ADA) and the WCAG 2.1 AA standard as the yardstick. Most target small and mid-sized businesses, not just big brands. You don't have to be famous to get a letter.
This guide is not here to scare you, and it is not legal advice — if you've received a demand letter, talk to a lawyer. It's here to hand you the same runnable checklist I'd hand a friend who said "I have no idea if my site is accessible — where do I even start?"
By the end you'll know:
- The eight accessibility checks that catch the majority of real problems
- What "bad" actually looks like for each one, in concrete terms
- How to test your own site for free with axe DevTools and Lighthouse
- Which problems you can fix yourself, and which need a developer
- Where the line is between "good enough to sleep at night" and "fully audited"
Part 1 — What People Actually Experience (the visual + structural checks)
These are the issues a sighted visitor can run into, and the ones you can usually spot yourself once you know what to look for.
1. Color contrast
Text needs enough contrast against its background, or people with low vision (and anyone in bright sunlight) can't read it. WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (roughly 18px bold or 24px regular and up).
What "bad" looks like: light gray text on a white background. Pale placeholder text inside form fields. White text on a light-colored button. That trendy "#999 on #fff" body copy designers love — it's about 2.8:1, well under the bar.
What to do: run your colors through a free contrast checker (WebAIM's Contrast Checker is the standard). Darken text or lighten backgrounds until you clear 4.5:1. This is usually a CSS tweak you or your designer can make in minutes.
2. Image alt text
Every meaningful image needs descriptive alt text so a screen reader can announce what it shows. Decorative images (a swoosh, a background texture) should have empty alt (alt="") so they're skipped, not announced as "image."
What "bad" looks like: product photos with no alt at all, so a blind shopper hears "image" or the file name "IMG_4471.jpg." Or the opposite — every decorative flourish narrated out loud, turning the page into noise. Alt text stuffed with keywords for SEO instead of describing the image.
What to do: write alt text the way you'd describe the image to someone on the phone. "Red leather handbag with gold clasp," not "handbag image." Leave purely decorative images with alt="". Logos should say the company name.
3. Heading structure
Headings (<h1> through <h6>) are how screen reader users skim a page — they pull up a list of headings and jump around, the way you'd scan with your eyes. The structure has to be a logical outline: one <h1>, then <h2>s under it, <h3>s under those. No skipping levels.
What "bad" looks like: a page with no <h1> at all. Three <h1>s competing. Text that looks like a heading because it's big and bold, but is actually a plain <p> styled with CSS — invisible to the outline. Jumping from <h2> straight to <h4>.
What to do: view your page's heading outline (axe and Lighthouse both report it; browser extensions like "HeadingsMap" show it visually). Make sure there's exactly one <h1> and the levels nest logically. This often overlaps with your on-page SEO — clean heading structure helps both.
4. Link text that makes sense out of context
Screen reader users often pull up a list of every link on the page, stripped of surrounding text. So the link text alone has to tell them where it goes.
What "bad" looks like: a page full of "click here," "read more," and "learn more" links. Out of context, that list is useless — read more about what? Bare URLs as link text get read out character by character. Two different links with identical "click here" text going to different places.
What to do: make link text describe the destination. "Read our refund policy," not "click here." "Download the 2026 catalog (PDF)," not "download." If you're funneling readers somewhere, the link should say so plainly.
Part 2 — Whether the Site Is Even Operable (the interaction checks)
This is where the hidden failures live. A lot of people never touch a mouse, and a lot of business owners have never once tried to use their own site without one.
5. Keyboard navigation
Everything you can do with a mouse — click links, open menus, submit forms, dismiss popups — has to be doable with the keyboard alone. Many people navigate entirely by Tab (move forward), Shift+Tab (back), Enter, and Space.
What "bad" looks like: a dropdown menu that only opens on mouse hover and can't be reached by Tab. A custom "button" built from a <div> that the keyboard skips right over. A popup or cookie banner you can't close without a mouse. A "keyboard trap" where Tab gets stuck inside a widget and can't get out.
What to do: click in your browser's address bar, then press Tab repeatedly and try to operate your whole homepage — open the menu, reach every link, submit your contact form, close any popup — without touching the mouse. If you get stuck or something's unreachable, that's a real bug. Custom widgets usually need a developer; converting fake <div> buttons to real <button> elements fixes a surprising amount.
6. Visible focus states
As you Tab through a page, there should always be a clearly visible outline or highlight showing where you are. Without it, a keyboard user is blind to their own position.
What "bad" looks like: you Tab through the page and nothing visibly changes — no ring, no highlight, no indication of which link is selected. This very often happens because someone added outline: none; to the site's CSS to "clean up" the default focus ring and never replaced it.
What to do: do the Tab test from check 5 and watch for a clear visible indicator on every step. If there's nothing, remove the outline: none; or, better, add a deliberate high-contrast focus style. This is a small CSS change with a big payoff.
7. Form labels
Every form field — name, email, search box, checkbox — needs a programmatically associated <label>. That's what tells a screen reader user which field they're sitting in.
What "bad" looks like: fields with placeholder text instead of a real label (the placeholder vanishes the moment you start typing, and many screen readers ignore it). A checkbox with text floating next to it that isn't actually linked to the input. An error message that says "invalid" with no indication of which field.
What to do: make sure every input has a real <label for="..."> tied to its id, even if you hide it visually for design reasons. Tie error messages to their fields. axe flags unlabeled inputs reliably — this is one of its most common findings.
8. Captions and media
Video with audio needs captions so Deaf and hard-of-hearing visitors can follow it. Audio-only content (a podcast embed) needs a transcript.
What "bad" looks like: an autoplaying promo video with spoken narration and no captions. A founder's-story video on your About page with no transcript. Auto-generated captions full of errors that nobody reviewed.
What to do: add captions to any video that conveys information through audio. YouTube and Vimeo both support uploading caption files; their auto-captions are a starting point but need a human pass for accuracy. Provide a transcript for audio-only media.
How to Test This Yourself in 15 Minutes
You don't need to eyeball all of this manually. Two free, trustworthy automated tools catch a large share of the issues:
- axe DevTools — a free browser extension from Deque. Open your site, open your browser's developer tools, click the axe tab, and "Scan." It lists every detected violation, maps each one to its WCAG success criterion, and explains how to fix it. It's the closest thing to an industry-standard automated checker.
- Lighthouse — built right into Chrome's developer tools (the "Lighthouse" tab). Run the Accessibility category and you get a 0–100 score plus a list of failed audits. Quick and zero-install.
Run both on your homepage and your two or three most important pages — contact, checkout, the main landing page people actually arrive on. Then do the manual keyboard test from Part 2, because no automated tool can tell you whether your site is genuinely operable without a mouse.
Here's the honest part. Automated tools and a quick self-test catch the obvious, high-frequency problems — and that's genuinely most of them. But they can't catch everything, and you shouldn't pretend otherwise.
- Automated scanners reliably detect only a portion of WCAG issues — the machine-checkable ones. Whether your alt text is accurate, whether your keyboard order is logical, whether an error message is actually helpful — those need human judgment.
- They don't test the full journey — a multi-step checkout, a logged-in dashboard, a date picker, a custom modal — the way a real screen reader user would.
- They won't tell you how your site behaves with an actual assistive technology (VoiceOver, NVDA, JAWS) reading it aloud.
- And they can't tell you where your specific legal exposure is, or what to prioritize first. (Again — this guide is informational, not legal advice.)
A real audit walks every key page, runs the full WCAG 2.1 AA ruleset, maps each violation to its exact success criterion in plain language, and hands you a prioritized fix list instead of a raw dump of error codes.
If you'd rather not install extensions, tab through every page, and decode WCAG success-criterion numbers yourself, that's exactly what a Signal Accessibility Snapshot does for you. We run a full WCAG 2.1 AA scan across your key pages, map every violation to the specific criterion it breaks, translate each one into plain English with a clear fix, and frame the legal-risk context honestly — no fearmongering, no fake urgency. You get a prioritized, do-this-first report instead of a wall of error codes.
It's $19.99, one-time — a fraction of an agency retainer, no subscription, delivered in under 24 hours. If you've ever wondered "is my site accessible?" and wanted a real answer instead of a guess, this is the fastest way to get one.
Rather have it done for you? The Accessibility Snapshot pulls the data, runs every check above, and hands you a prioritized, plain-English report in under 24 hours — a fraction of an agency retainer, no subscription, no upsell.