Hebble & Stone

6 min read

Accessibility icons for mobility, vision and hearing.

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.
  • Tap targets need room. WCAG 2.2 asks for at least 24×24 pixels at AA; 44×44 is the comfortable target, and the size a shaky hand actually needs.

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:

  • Buttons and links should be the real thing, not lookalikes built to look right. A screen reader can announce a real button and a keyboard can reach it; a fake one, it often can't even see.
  • If the browser already does something for free, use it. A home-made pop-up box is one of the most common ways a site quietly stops working for someone who can't use a mouse.

If you'd like to see how these go wrong on the developer-side, we pulled together the developer shortcuts that quietly break accessibility here.

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.

Back to all posts