Accessibility gets sold to small business owners as a legal scare story, or it gets ignored completely. Neither is useful. Website accessibility, in the practical sense that matters to a local business, means the people trying to hire you can actually read your prices, find your phone number and send the form, whatever device or eyesight they bring to it.
This post is the user-impact version. No legal advice, no compliance product, just what breaks, who it breaks for, and what you can check yourself in ten minutes. It ends with the results of running those checks on my own site, including the two things I failed.
Key Takeaways
- Most sites fail the basic readability bar: only 31% of mobile sites currently meet minimum colour contrast requirements (HTTP Archive Web Almanac, 2025)
- The problem is getting worse in one specific place: 67% of sites explicitly removed the default focus outline in 2025, up 14 points from 2024 (HTTP Archive Web Almanac, 2025)
- Three checks catch most of it: tab through the page, zoom to 200%, and look at your grey text on a phone outdoors.
A note on the numbers. The Web Almanac figures come from a crawl of the web at large, not a sample of Ontario local businesses, and the crawl uses automated testing that catches only part of what is wrong. The figures from my own site are from one small site and are a worked example, not a benchmark.
What Does Website Accessibility Actually Mean for a Local Business?
It means somebody can use your site to hire you without needing perfect vision, a steady hand or a mouse. That is the whole idea.
The standards industry has built an enormous vocabulary on top of it, but for a five page local business site the practical surface area is small, and most of it is decided while the site is being built rather than bolted on later. It costs almost nothing to get right during web design and development and a great deal to retrofit.
The standards themselves are plainer than their reputation. The requirement for keyboard access reads: “All functionality of the content is operable through a keyboard interface” (W3C, WCAG 2.2). The requirement for focus reads: “Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible” (W3C, WCAG 2.2).
Two things on a typical small business site carry most of the risk, and both are covered in depth elsewhere on this blog, so they get a pointer rather than a repeat here:
- Image alt text: the description a screen reader announces in place of a photo. The practical guide to writing it lives in the post on construction website images.
- Form labels: the text tied to each field, which has to be a real label rather than placeholder text that vanishes when typing starts. That is covered in the post on why nobody fills out your contact form.
Everything below is the part that gets written about least: keyboard access, focus, contrast, zoom and motion.
Who Actually Gets Locked Out of Your Website?
Mostly ordinary customers, which is the part that surprises owners. The picture people have is somebody who is completely blind using a screen reader, and that person matters, but the larger group is people whose eyes and hands are simply not what they were.
W3C is specific about why the contrast bar sits where it does. The 4.5:1 ratio exists “to account for the loss in contrast that results from moderately low visual acuity, congenital or acquired color deficiencies, or the loss of contrast sensitivity that typically accompanies aging” (W3C, Understanding Contrast (Minimum)).
Read that again with your customer list in mind. For a local trades or supply business, a large share of the people spending real money are over fifty.
The same pattern shows up on the tap target requirement, which asks for targets of “at least 24 by 24 CSS pixels” (W3C, WCAG 2.2). W3C’s explanation of who that protects is blunt: “Some people with physical impairments cannot click small buttons that are close together”, and “Disabilities addressed by this requirement include hand tremors, spasticity, and quadriplegia” (W3C, Understanding Target Size (Minimum)).
Then it adds the line that should sell this to any business owner: “Meeting this requirement also ensures that touchscreen interfaces are easier to use.”
- The person in bright sunlight: low contrast text that reads fine indoors disappears on a phone in a parking lot.
- The person with a cracked screen: a cheap or damaged display flattens subtle greys into nothing.
- The person on a tablet with a tremor: small buttons packed together produce mis-taps and abandonment.
- The person who never uses a mouse: keyboard and switch users navigate entirely by tabbing, and they need to see where they are.
- The person who gets motion sick: heavy scroll animation can genuinely make somebody feel ill and close the tab.
What Happened When I Ran the Checks on My Own Site?
I ran them on October 5, 2026 across all 50 HTML pages this site built that morning, before this post was added to it, and published the result unedited. Eight checks, six clean and two failures that are still live as you read this.
| Check | Result |
|---|---|
| Pages declaring a language | 50 of 50 |
| Pages with exactly one H1 | 50 of 50 |
| Images carrying an alt attribute | 157 of 157 |
| Links with no readable name | 0 |
Positive tabindex values |
0 |
| Form fields with a real label | 5 of 5 on the contact page |
| Pages in correct heading order | 49 of 50 |
| Pages with a skip-to-content link | 0 of 50 |
The two failures are worth naming properly rather than burying.
- No skip link anywhere: a keyboard user has to tab through the whole navigation on every page before reaching the content. Roughly 24% of pages include one (HTTP Archive Web Almanac, 2025), and this site is in the other group.
- One page jumps a heading level:
/proofgoes from the H1 straight to H3 with no H2 between. Worth saying honestly: the tool that flags this, Deque’s axe-core, files heading order under best practices rather than as a WCAG failure (axe-core rule descriptions, v4.13.0). It is untidy rather than broken.
One result needs explaining, because the raw number looks worse than it is. Of those 157 images, 121 carry a descriptive alt and 36 carry an empty one. An empty alt is not a mistake by default: it is how you tell a screen reader that an image is decoration and should be skipped.
I checked all 36 by hand, and every one sits inside a deliberately hidden wrapper: the duplicated half of a scrolling logo strip, the spinning screenshot ring on the proof page, which is marked aria-hidden with the section labelled in text instead, or the empty placeholder inside a closed image viewer, which takes its alt from the source image the moment it opens.
That is the difference between an empty alt and a missing one, and it is why an automated score on its own tells you very little.
Can Someone Use Your Website Without a Mouse?
Open your homepage and press Tab repeatedly. If you can always tell which thing is selected, and if the order makes sense, you have passed the single most revealing accessibility test there is. Most small business sites fail it somewhere in the navigation.
What to watch for as you tab:
- A visible indicator at every stop: if the highlight vanishes on any element, a keyboard user is lost at that point.
- A sensible order: focus should move roughly the way the page reads, not jump to the footer and back.
- No traps: if focus enters a menu or a popup and cannot get out with the keyboard, the page is unusable without a mouse.
- Reachable controls: anything you can click should be reachable by tabbing, including custom menus built out of
divelements. - A skip link first: ideally the very first Tab press offers to jump past the navigation.
On the tabindex attribute, which developers sometimes use to force an order: positive values appear on only 3.7% of desktop and 3.4% of mobile pages (HTTP Archive Web Almanac, 2025). That low number is the good news, because forcing a custom tab order usually makes navigation worse rather than better. This site uses none.
Why Does Almost Every Site Delete the Focus Outline?
Because designers find it ugly, and because deleting it is one line of CSS. This is the one accessibility measure that is clearly getting worse: 67% of sites explicitly removed default focus outlines in 2025, up 14 points on the year before (HTTP Archive Web Almanac, 2025). The Almanac’s own comment is that this “may impair accessibility if not replaced with effective styles”.
That last clause is the whole argument. Removing the browser’s focus ring is not automatically wrong. Removing it and replacing it with nothing is, because it leaves keyboard users with no way to tell where they are.
My own site removes it in one place, but does put something back. The only focus styling in the entire codebase is an outline: none on the contact form fields, replaced by a border colour change, so I measured whether that replacement actually holds up:
| Focus state | Contrast measured |
|---|---|
| Unfocused field border against the page background | 1.43:1 |
| Focused field border against the page background | 4.66:1 |
| Focused border against the unfocused border | 3.26:1 |
So the replacement does its job: the violet focus border is clearly visible against the dark ground and clearly different from the resting state. Everywhere else on the site there is no custom focus style at all, which means the browser default is left alone. That is the safe outcome, though it happened by omission rather than by design.
The better pattern is the one the Almanac notes is growing: :focus-visible, which shows an indicator for keyboard users without putting a ring around every button somebody clicks with a mouse. It is on about a quarter of pages, 25% on desktop and 24% on mobile (HTTP Archive Web Almanac, 2025).
Can People Actually Read the Text on Your Site?
This is where most small business sites lose people, and the number is genuinely bad: only 31% of mobile sites currently meet minimum colour contrast requirements (HTTP Archive Web Almanac, 2025). That leaves roughly seven in ten mobile sites with text that fails the automated contrast check.
The bar is specific. Normal text needs a contrast ratio of at least 4.5:1 against its background, and large text needs 3:1, where large means 18 point, or 14 point bold (W3C, WCAG 2.2).
The usual culprit is light grey body text on white. It looks restrained in a design mockup on a good monitor and it fails outdoors on a phone, which is where most local business traffic actually is.
I measured the main text pairs in the token file against the ground each one sits on:
- Headings on dark: 17.97:1, comfortably clear.
- Body text on dark: 10.10:1, comfortably clear.
- Muted captions on dark: 4.99:1, which passes but is the tightest pair in the set.
- Body text on white: 8.86:1, comfortably clear.
- Brand violet as text on white: 7.10:1, which is why it is allowed to carry text on light backgrounds.
- Brand violet as text on dark: 2.78:1, which fails, and is exactly why the design system forbids it and uses a lighter violet instead.
One correction that matters came out of that pass. The comment in my own token file describes the lighter violet used for large text on dark as 4.9:1. Measured properly it is 4.66:1.
Every other comment in that file is either exact or rounded down, which is harmless, except one that rounds up by five hundredths and is too small to matter. This one rounds up by nearly a quarter of a point, which is why it is the one worth reporting.
Nothing on the site is actually broken, though for a more specific reason than the number suggests. That token clears 4.5:1 against the main dark ground, and the only text it carries anywhere in the codebase is one hover state on the about page, which sits on that same dark ground. On a raised panel it would measure 4.49:1 and fail, which is worth knowing before anyone uses it for text.
That is the kind of thing a self-audit turns up, and the kind of thing that never appears in a report somebody is paid to make look good. If you want the rest of how I check a live site, the post on knowing whether your website is working covers the measurement side.
Does Your Site Still Work When Someone Zooms In?
Zoom to 200% in your browser and look for text that gets cut off, columns that overlap, or a menu that becomes unreachable. Plenty of people browse permanently zoomed in, and a layout that collapses at 200% quietly loses them.
A related mistake is disabling zoom outright on mobile, which some templates still do. That is less common than it used to be: 19% of mobile sites and 21% of desktop sites restrict scaling (HTTP Archive Web Almanac, 2025). It is a single attribute in the page head and there is almost never a good reason for it.
The basics around text sizing are mostly handled by modern templates:
- Viewport tag: present on 95.2% of mobile pages, which is what makes a site respond to screen width at all (HTTP Archive Web Almanac, 2025).
- Legible font size: 92% of mobile pages pass Lighthouse’s check, which flags pages where less than 60% of visible text is above 12px (HTTP Archive Web Almanac, 2025).
- Zoom left alone: the fix is removing
user-scalable=noand any restrictive maximum scale from the viewport tag.
So the easy, automatable parts of mobile readability are largely done across the web. The parts that need a judgement call, like contrast, are where the failures concentrate.
Does Your Website Respect Someone Who Gets Motion Sick?
Operating systems have a reduce motion setting, and a well built site listens to it. Browsers expose it to CSS as prefers-reduced-motion, described by MDN as the signal that a user “prefers an interface that minimizes the amount of movement or animation, preferably to the point where all non-essential movement is removed” (MDN).
This is not a fussy preference. MDN is direct about the stakes: “certain kinds of motion can be a trigger for Vestibular disorders, epilepsy, and migraine and Scotopic sensitivity”.
About half of pages now respond to the setting, 49.99% on desktop and 50.55% on mobile (HTTP Archive Web Almanac, 2025). This site honours it in eleven separate components and stylesheets, which covers the smooth scrolling, the scroll reveals, the homepage loader and the spinning ring on the proof page. That is one I can report without an asterisk.
Worth noting what the setting does not mean, since it is a common overcorrection. MDN puts it plainly: “This preference does not mean all animations must be removed”.
A fade is usually fine. Large motion tied to scrolling is the thing to cut.
Which Accessibility Checks Can You Run on Your Own Site Today?
Five, and none of them need a tool you have to buy. Do them in this order, because they go from most revealing to most automatable.
- The Tab test: press Tab through a page and confirm you can always see where you are and always escape. Two minutes, and it catches what no scanner reliably catches.
- The zoom test: zoom to 200% and look for clipped text or an unreachable menu. One minute.
- The sunlight test: open your site on a phone outside and try to read the grey text. This is the contrast check done the honest way.
- Lighthouse: open Chrome DevTools, run the accessibility audit, and read the findings rather than the score. It is free, and it runs the same axe-core engine behind the contrast figure above.
- Your own forms: fill in and submit every form on the site, from a phone, and confirm it arrives.
One caveat on the automated part, from the researchers who run that crawl at scale. Automated tools “all detect less than 50% of accessibility errors” (HTTP Archive Web Almanac, 2025), and the Almanac warns against treating the score as the goal: “When a metric becomes a target, it stops being a reliable metric. A perfect score doesn’t guarantee full accessibility.”
Which is the argument for the Tab test. A score of 100 and a page you cannot navigate by keyboard is a perfectly possible combination.
One thing not to buy while you are at it. Accessibility overlay widgets sell a one-script fix, and the research is unkind to them: they “often promise quick-fix compliance but fall short of addressing complex accessibility challenges that require manual code and design changes”, and they “generally have more usability, security, and performance drawbacks than fixing underlying code issues” (HTTP Archive Web Almanac, 2025).
The same chapter notes that the European Disability Forum has warned such tools can interfere with a user’s own assistive technology, creating conflicts that reduce accessibility rather than improving it. Fixing the markup costs less and does not expire with a subscription.
Frequently Asked Questions
Does a small business website legally have to be accessible?
That depends on where you operate and how big your business is, and it is a question for someone qualified to answer it rather than your web designer. What I can tell you is the practical side: the people who struggle with an inaccessible site are ordinary customers with ageing eyes, a sore wrist or a cheap phone in bright sunlight. Build for them and the compliance question gets a lot less frightening.
What is the most common accessibility problem on a small business website?
Low contrast text, by a wide margin. Only 31% of mobile sites currently meet the minimum colour contrast requirements according to the 2025 HTTP Archive crawl. It is usually light grey body text on a white background, which looks refined on a designer’s calibrated monitor and turns to soup on a phone screen outdoors.
How do I test my own website for accessibility?
Start with three free checks that take ten minutes. Press Tab repeatedly and confirm you can always see where you are, zoom to 200% and confirm nothing is cut off, and run the page through Lighthouse in Chrome DevTools. Automated tools only catch part of the problem, so the keyboard and zoom checks matter as much as the score.
Does website accessibility help my Google rankings?
Not as a direct ranking factor that anyone can point to. The overlap is real but indirect: alt text, proper headings, labelled form fields and readable text all help search engines understand a page for their own reasons. Treat the ranking effect as a side benefit and build it for the customers instead.
Is an accessibility overlay widget worth buying?
I would not spend money on one. These third-party widgets sit on top of a site and try to patch problems at runtime rather than fixing the markup underneath, and they generally carry more usability, security and performance drawbacks than fixing the underlying code, with the European Disability Forum warning that they can interfere with a user’s own assistive technology (HTTP Archive Web Almanac, 2025). Fixing the contrast, labels and focus styles in the actual build costs less and does not expire with a subscription.
What is a skip link and does my site need one?
A skip link is a hidden link at the very top of the page that lets a keyboard user jump straight past the navigation to the main content. Without one, somebody tabbing through your site has to pass every menu item on every page before reaching anything useful. Roughly 24% of pages include one (HTTP Archive Web Almanac, 2025), and at the time of writing my own site is in the other group.
Wrapping Up
Accessibility on a small business website is not a compliance project. It is the difference between a sixty year old customer reading your prices on a phone in a driveway, and that same customer giving up and calling somebody else.
The three checks in this post cost ten minutes and no money, and they are worth repeating whenever the site changes, which is part of what ongoing site care is for. Tab through the page, zoom to 200%, read your grey text in sunlight. If any of those go badly, you have found something worth fixing before you spend another dollar on traffic, because the traffic you already have is bouncing off the same problem.
I published my own two failures above rather than quietly fixing them first, because a self-audit that only reports wins is marketing. If you want the same pass run on your site, with the findings written out plainly whether they flatter the build or not, get a free website audit and I will send you the list.
Further reading: Why is nobody filling out your website contact form? · How do you know if your website is actually working? · What should a local business put on a service page?