What WCAG actually is, and why it's not as scary as it sounds

WCAG stands for "Web Content Accessibility Guidelines". It's a four-letter acronym that has, somehow, convinced an entire generation of charity trustees that accessibility is a complicated, expensive, lawyer-shaped problem. It isn't.

Here's the short version of what WCAG actually is, what it asks for, and which bits you genuinely need to care about as a community organisation running a website.

Who writes it, and why

WCAG is published by the W3C, the same independent body that defines what HTML is. It exists because, in the early days of the web, accessibility was an afterthought, and lots of disabled people couldn't use most websites. WCAG is the agreed-on baseline for fixing that.

The current version is WCAG 2.2, finalised in 2023. There are three "levels":

• Level A: the bare minimum. If you fail any of these, the site is unusable for someone, somewhere.
• Level AA: the practical target. This is what laws around the world refer to. UK public sector bodies are legally required to meet it.
• Level AAA: the gold standard. Not always achievable across a whole site, and not legally required of anyone.

What it actually asks for

WCAG is organised around four principles. Everything in the spec is an example of one of these. We've found that if you understand the principles, you can usually guess what the spec will say, which is much easier than memorising it.

1. Perceivable

The content must be available to your senses. Real-world examples:

• Images need a text description (alt) so a blind person's screen reader can read them.
• Videos need captions for people who can't hear, and audio descriptions for people who can't see.
• Text needs enough contrast against its background for people with poor vision to read it.
• The site needs to still work when someone zooms in to 200%.

2. Operable

People must be able to use the site, whatever they're using to navigate it. Real-world examples:

• Everything that works with a mouse must also work with a keyboard alone.
• Animations that flash quickly can trigger seizures. They shouldn't be there.
• People must have enough time to read and use things; auto-scrolling carousels are a notorious failure here.
• Every link or button must be at least 44×44 pixels, big enough to tap with a tremor.

3. Understandable

The site must make sense. Real-world examples:

• Set the language of the page in the HTML so screen readers pronounce things correctly.
• Navigation should work the same way on every page.
• Form errors should explain what went wrong and how to fix it, not just say "Invalid".

4. Robust

The site must work with current and future assistive technology. Real-world examples:

• Use real HTML elements: a <button> for a button, not a <div> with a click handler.
• Don't use custom widgets where a standard one will do.

What you actually have to do

If you're a small charity or community organisation, here's the minimum-effort, maximum-impact list:

1. Check your colour contrast (we wrote about this here).
2. Add an alt attribute to every meaningful image. For decorative images, set it to alt="".
3. Tab through every page using only the keyboard. If anything is invisible or unreachable, fix it.
4. If you have video, add captions. YouTube does a decent job automatically, just check the result.
5. Publish an accessibility statement (we have a template here) saying what you've done and how to report issues.

The bit nobody tells you

Accessibility isn't a checklist you finish. It's a way of thinking. The accessibility test the law requires is the same test you'd want if you, or your mum, or your trustee, suddenly had to use your site with one hand, in bright sunlight, on a phone that's three years old, after a sleepless night.

If you'd like an audit against WCAG 2.2 AA, we offer them free to community organisations. Tell us about your site and we'll be in touch.