Website accessibility, explained for small business owners

"Accessibility" gets filed under legal risk or corporate box-ticking, which is why most small business sites never get a proper pass at it. That's a shame, because the actual substance is neither abstract nor expensive: it's a specific list of things that stop a real chunk of your visitors from using your site at all — someone using a screen reader, someone navigating by keyboard because a mouse doesn't work for them, someone with low vision zooming the page, someone colour-blind trying to read a chart. None of that is a fringe case. It's a slice of every audience, on every site.

What it actually covers

Strip away the standards-body language and it comes down to four things:

• Can someone see it? — enough contrast between text and background, text that can be resized without breaking the layout, colour that isn't the only way information is conveyed.
• Can someone operate it without a mouse? — every link, button, form field and menu reachable and usable with a keyboard alone, in a sensible order.
• Can a screen reader make sense of it? — images with real descriptions, headings that describe the actual structure, form fields with labels a screen reader can announce.
• Does it behave predictably? — no content that moves, flashes or opens unannounced, no dead ends a keyboard user can't escape.

Why it's not just a legal question

There is a legal dimension — in Australia, the Disability Discrimination Act has been used to successfully challenge inaccessible websites, and that risk is real for any public-facing business. But treating it purely as liability management undersells it. A meaningful share of any audience has some degree of visual, motor, auditory or cognitive difference, and an inaccessible site simply loses that portion of it — quietly, with no error message, before they ever get to your offer. Most of the fixes involved also happen to be good practice for everyone: clearer structure, better contrast, and a site that still works when someone's connection is slow enough that images haven't loaded yet.

The failures that show up again and again

In practice, a small number of issues account for most real-world accessibility problems:

• Low-contrast text — light grey text on white, or white text over a busy photo, reads fine to some people and is genuinely unreadable to others.
• Images with no alt text — a screen reader either skips the image entirely or reads out the filename, and either way the content it carried is gone.
• Form fields with no real label — placeholder text that disappears the moment someone starts typing isn't a label, and a screen reader user is left guessing what a field wants.
• Keyboard traps and invisible focus — a custom dropdown or modal that a mouse handles fine but a keyboard can't tab into, out of, or even see is highlighted at all.
• Heading structure used for styling instead of structure — headings picked because they "look right" rather than because they describe the actual outline of the page, which is exactly what a screen reader relies on to let someone jump around.

How far you need to go

The common reference point is WCAG (the Web Content Accessibility Guidelines), scored at levels A, AA and AAA. AA is the level most businesses should aim for and the one most legal guidance points to — it covers the issues above and the bulk of everyday impact, without chasing the more exhaustive AAA criteria that are rarely practical for a typical commercial site. You don't need to memorise the standard to get most of the benefit; the failure list above covers the majority of what AA actually checks for.

How to check where your site stands

You don't need a specialist audit to get a useful first read. Free automated tools — WAVE and axe are the common ones, both available as browser extensions — scan a page and flag missing alt text, contrast failures and unlabelled fields in seconds. They won't catch everything (keyboard navigation and screen reader behaviour need a human to actually try them), but they'll surface the low-hanging fruit immediately. Tabbing through your own site with the mouse untouched, and listening to a page with your browser's built-in screen reader for five minutes, tells you more than most people expect.

Where this fits in a build

Accessibility is far cheaper to build in from the start than to retrofit — a site designed with real contrast, sensible headings and proper labels from day one barely costs anything extra, while bolting it on afterwards means re-touching almost every page. If you're briefing a rebuild, ask explicitly how accessibility is handled during design and development, not just whether it's "considered." That one question tends to separate studios that treat it as a genuine practice from ones that treat it as an afterthought.