WCAG Without the Jargon: What Actually Matters for Small Sites

The first time a small-business owner opens the Web Content Accessibility Guidelines, something predictable happens. They see a document organized into principles, guidelines, success criteria, and conformance levels, written in the careful language of a standards body, cross-referenced like a legal code. They conclude accessibility is a specialist discipline requiring a consultant and a budget. Then they close the tab and do nothing. The document designed to make the web more accessible ends up, for this reader, making accessibility feel less accessible.

This is a shame, because the intimidating structure hides a small, humane core. WCAG has to be exhaustive because it’s a standard: it must cover video players and single-page apps and CAPTCHAs and things a five-page site for a bakery will never contain. But exhaustiveness is a property of standards, not of your obligations. A small site triggers a small subset of the rules, and that subset is mostly common sense once someone translates it. So let me translate.

The whole document rests on four ideas, and they fit in one sentence: people must be able to perceive your content, operate your controls, understand what things mean, and use it all from whatever browser or assistive tool they’ve got. Perceivable, operable, understandable, robust. Everything else is elaboration. The conformance levels, A, AA, and AAA, are just how strict you’re being; AA is what laws and contracts nearly always mean when they say “accessible,” and it’s the sensible target.

Now the translation into practice. Perceivable, for a small site, mostly means two things. First, images that carry information need alt text, a written description in the HTML that says what the image says. Second, text needs enough contrast against its background to be read by eyes that aren’t young and perfect. The guidelines quantify this as a ratio, 4.5 to 1 for normal text at the AA level, but you don’t need to compute anything; free contrast checkers take two colors and give you a pass or fail. Most failures are the same failure anyway: fashionable light gray text on white, which is hard to read for everyone and impossible for some.

Operable mostly means the keyboard. Everything you can do with a mouse, someone must be able to do with the Tab and Enter keys, because that’s how people who can’t use a mouse navigate, and it’s also how screen readers drive a page. The test costs five minutes: put the mouse out of reach and try to use your own site. Tab through the links, open the menu, submit the form, close the popup. While you’re at it, check that you can see where you are; the little outline that marks the focused element is the keyboard user’s cursor, and a distressing amount of CSS in the wild deliberately removes it because a designer thought it looked untidy.

Understandable, on a small site, is mostly about forms and language. Every input field needs a label that’s properly attached to it in the HTML, not just placeholder text that vanishes when you click, because the label is what a screen reader speaks and what stays visible while you type. Error messages should say what went wrong and how to fix it, near the field that has the problem. And the page should declare its language in the HTML, one attribute on one tag, so that screen readers pronounce your words with the right voice instead of reading English text with, say, French pronunciation rules.

Robust is the most technical-sounding principle and the simplest in practice: use HTML for what it’s for. A button should be a button element, not a div with a click handler. A heading should be a heading tag, not big bold text. Assistive technology understands real HTML elements natively; it gets their names, their roles, and their keyboard behavior for free. Fake elements need all of that reconstructed by hand, and almost nobody does the reconstruction. The lazy path and the accessible path are, for once, the same path.

That’s the core: alt text, contrast, keyboard operation, visible focus, labeled forms, honest HTML. It won’t make you formally compliant by itself, and if you face genuine legal exposure you should get a real audit. But it covers a large majority of what actually goes wrong on small sites, because the same handful of mistakes recur everywhere. I see this pattern constantly in GazeSite’s accessibility scans, which is partly why I’m confident the short list is the right list: the findings on small sites are monotonous, and monotony is good news, because it means the fixes are learnable.

The perfect is the enemy of the shipped here, more than almost anywhere in software. A site that gets the short list right serves real people better today. A site whose owner is waiting until they understand all of WCAG serves them never. Standards are written to be complete. You don’t have to read them that way. Start with the sentence, not the spec.