A WCAG 2.1 AA checklist in plain language

What the acronym is made of

WCAG is the Web Content Accessibility Guidelines, published by the World Wide Web Consortium — the standards body behind HTML itself. Version 2.1 is what the U.S. Department of Justice named in its ADA Title II rule, and Level AA is the conformance level it named. (For the deadlines, and which one applies to a town your size, see where the rule actually stands — the dates moved in 2026 and much of what's online is now wrong.)

"Level AA" is cumulative: all 30 Level A criteria plus all 20 Level AA criteria, 50 in total. Level AAA exists, is hard, and is not what anyone is asking of you. What follows is not all 50 — it is the ones that break on municipal websites.

Perceivable — can people take the information in?

1.1.1 Non-text Content

If information is carried by an image, chart, map or icon, that information must also exist as text a screen reader can speak.

Broken: the scanned PDF of the council minutes. Someone signed the paper copy, ran it through the scanner, posted the result. To you it looks like a document; to a computer it is a photograph of one, with no text in it at all. A blind resident's screen reader reaches it and says nothing — and nobody can search it or quote from it. It is the commonest serious failure on small municipal sites. The interactive zoning map with no text alternative is the same criterion: nobody expects a pixel-by-pixel description, but a resident who cannot use the map needs another route to the answer — a written summary, a parcel-and-zone table, or a phone number a human answers.

Who fixes it: you can. Alt text is typed into a box; scanned PDFs need re-exporting from the original file rather than scanning from paper.

1.4.5 Images of Text

Use real text, not a picture of text: real text can be enlarged, recoloured and read aloud; a JPEG cannot. Broken: the boil-water notice posted as a screenshot of a Word document; the parade poster whose date exists only inside the image. Who fixes it: you can — retype it on the page.

1.3.1 Info and Relationships

If something looks like a heading it must be a heading in the markup; if it looks like a data table it must be a real table with row and column headers. Screen reader users navigate by structure, jumping heading to heading the way you skim with your eyes.

Broken: the agenda whose section titles are merely bold, centred, 18-point text. Or the agenda table used purely for layout — item number in one cell, description in another, no header row — so a screen reader announces disconnected fragments instead of a legible agenda. Who fixes it: you can. Use your editor's Heading 2 and Heading 3 styles instead of bolding text, and use tables for data, not for arranging a page.

1.4.3 Contrast (Minimum)

Normal-size text needs a contrast ratio of at least 4.5:1 against its background. Large text — 18 point and up, or 14 point and up if bold — needs at least 3:1. You don't judge this by eye; free tools compute the ratio.

Broken: the emergency alert banner in red text on a dark background — the cruellest failure on a municipal site, because it is the content that matters most, and red-on-dark is close to unreadable for exactly the older residents most affected by a water main break. Who fixes it: depends where the colour came from. If you picked it in the editor, you can. If it comes from the theme, you cannot: that is a developer change, and if the platform won't permit it, it is a platform problem.

1.4.1 Use of Color

Colour must never be the only signal, because roughly one man in twelve cannot reliably tell red from green. Broken: the permit-status table where green means approved and red means denied and nothing else distinguishes them. Add a word, an icon, an asterisk — anything that survives being printed in black and white. Who fixes it: you can, in content; a developer, in templates.

1.2.2 and 1.2.4 Captions

Recorded video needs captions (1.2.2); live-streamed meetings need live captions (1.2.4), and captions must convey what the audio conveys.

Broken: the council meeting on YouTube with automatic captions and nothing else. Auto-captions are a starting point, not a finish line: they mangle exactly the words a council meeting turns on — surnames, street names, motion numbers, dollar figures — and they don't identify speakers, which in a room with nine voices is most of the meaning. Who fixes it: you can, and it is the highest-value hour on this list. Correct the auto-caption track in your video platform's editor: twenty minutes a meeting, and your minutes get easier to write as a side effect.

1.4.4 Resize Text and 1.4.10 Reflow

Text must enlarge to 200% without losing content or function (1.4.4), and content must reflow into a narrow column — the equivalent of a phone screen, 320 pixels wide — without forcing the reader to scroll sideways and down to read a sentence (1.4.10).

Broken: zoom to 200% and the navigation slides off the right edge, the footer lands on the copyright line, or a fixed-width table forces horizontal scrolling on every paragraph. Who fixes it: a developer, always — layout lives in the theme. It is also the clearest sign of a fundamentally old site: reflow was added in WCAG 2.1, and sites built before responsive layout became normal tend to fail it comprehensively.

1.4.11 Non-text Contrast

It isn't only text: interface components and meaningful graphics need at least 3:1 contrast against what's next to them, so a button's edge, a field's outline, a checkbox, are visible at all. Broken: the pale grey search box on a white header. It is there; a resident with low vision cannot see that it is there. Who fixes it: a developer.

Operable — can people use it?

2.1.1 Keyboard and 2.1.2 No Keyboard Trap

Everything that works with a mouse must work with a keyboard alone (2.1.1) — many people with motor disabilities, and every screen reader user, navigate by Tab, Enter and the arrow keys. And once focus goes into a component it must be able to come back out (2.1.2). A component you can enter but not leave is a keyboard trap: it doesn't degrade the visit, it ends it.

Broken: the PDF permit form that can't be filled in from the keyboard, because its "fields" are decorative rectangles rather than real ones — there is nothing to Tab to. The dropdown that only opens on hover. The embedded map that swallows focus, so the only way out is closing the tab. Who fixes it: a developer, mostly: you or your document software can add real fillable-PDF fields, but hover-only menus and keyboard traps are code.

2.4.4 Link Purpose (In Context)

A link's text must say where it goes. Broken: "To view the 2026 budget, click here." Screen reader users routinely pull up a list of every link on a page and navigate from it; on many municipal sites that list reads "click here, click here, read more, click here, more info." Write "the 2026 budget (PDF, 2.4 MB)" instead. Who fixes it: you can — pure editing, and the easiest real improvement on this page.

2.4.7 Focus Visible and 2.4.3 Focus Order

When you Tab through a page you must be able to see where you are — a visible ring or highlight on the focused element (2.4.7) — and focus must move in an order that makes sense, following the reading order rather than jumping header to footer to middle (2.4.3). Broken: Tab through your own homepage and watch. If nothing visibly changes, the focus indicator has been switched off because someone thought the ring was ugly. It is the equivalent of removing the mouse cursor. Who fixes it: a developer.

Understandable — can people make sense of it?

3.3.2 Labels or Instructions, and 3.3.1 Error Identification

Every form field needs a real label programmatically tied to it — not just text nearby that looks like a label (3.3.2). And when a form rejects something it must say in text which field was wrong and what was wrong with it (3.3.1), not merely turn the box red.

Broken: the dog-licence form whose fields are announced as "edit, blank; edit, blank; edit, blank" — the resident has no idea what to type where. Missing form labels turn up on around half the home pages WebAIM tests, year after year. Who fixes it: a developer, in the templates — unless your CMS has a form builder that gets labels right by itself, which is exactly the thing to test before you buy a platform.

1.3.5 Identify Input Purpose

Fields asking for the user's own information — name, email, address, phone — must be marked up so the browser knows what they are, which is what makes autofill work: a real accessibility feature for people with motor or cognitive disabilities. Related: 3.1.1 requires the page to declare its language, so a screen reader speaks it in the right voice — one attribute in the template, right on every page or wrong on every page. Who fixes both: a developer.

Robust — will it work with assistive technology?

4.1.2 Name, Role, Value

Every control must tell assistive technology what it is (a button), what it's called ("Search"), and what state it's in (expanded, collapsed, checked). Ordinary HTML does this for free; custom widgets built from styled <div> elements do not, and have to be told how — that is what ARIA attributes are for. Broken: the hamburger menu a screen reader announces as nothing at all. Who fixes it: a developer. ARIA is easy to add and easy to add wrongly — bad ARIA is worse than none.

4.1.3 Status Messages

When the page tells you something without moving you anywhere — "Your request has been submitted," "3 results found" — a screen reader user has to hear it. If the message merely appears on screen, they will never know it happened. Who fixes it: a developer.

So which half is yours?

The left column is work you can do next week with no budget and no vendor. The right column is not a matter of effort: no amount of careful publishing will fix it, because it lives underneath the content.

If your problems are mostly in the left column, you have a training problem, and training is cheap. If they are mostly in the right column, you have a platform problem, and diligent publishing will never get you to conformance. That distinction decides whether to remediate or replace, and we work the arithmetic through in what it actually costs to fix an inaccessible website.

The uncomfortable truth about automated scanners

You will be sold, or given free, an automated accessibility scanner. Run it — it will find real problems in minutes. Then be careful what you conclude.

Automated tools find only the failures a machine can recognise. A machine can measure a contrast ratio and see that an image has no alt attribute. It cannot tell you whether the alt text you wrote is a useful description or the word "image," whether your headings describe the sections beneath them, whether your captions match what the councillor actually said, or whether the tab order makes sense to a human being. The W3C's own guidance is blunt: evaluation tools "can not determine accessibility, they can only assist in doing so," and "human judgement is required."

So a clean automated report is not a compliant site. It is a site with no machine-detectable errors — a real achievement, and a fraction of the job. The rest needs manual keyboard testing and screen-reader testing by a person. We say that knowing it is against the commercial interest of every company selling a scanner, and against ours: it would be far easier to sell a website by waving a green report at you. The green report is not the standard. The standard is whether a resident who cannot use a mouse can renew her dog licence.

For scale, WebAIM's annual survey of the top million home pages found detectable WCAG failures on 95.9% of them, with government home pages averaging roughly 36 detectable errors each — and those are only the ones a machine can see. You are not behind your peers; the sector is collectively behind.

What you can do this afternoon, for free

No budget, no vendor, no permission needed. Four tests, an hour or two, and you will know more about your website than most people who have paid for a report.

1. Unplug your mouse. Seriously — pull the cable out. Open your homepage and press Tab repeatedly. Can you see where you are on every press? Can you reach the navigation, the search box, every link, the form? Can you open the menu with Enter? Can you get back out of the map embed? Then complete one real task — find the date of the next council meeting — without touching the mouse. Whatever stops you, stops a real resident every day.
2. Zoom to 200%. Press Ctrl and + (or Cmd and +) until the browser reads 200%. Does the text get bigger, or does the page just get blurry? Does anything disappear, overlap, or slide off the edge? Then keep going to 400% and see whether the content reflows into one readable column.
3. Check the contrast of your worst-looking text. Take the emergency alert banner, the footer, and any grey-on-grey text; put the two colour values into a free contrast checker and see whether you clear 4.5:1. Start with the alert banner. That's the one that matters at 6am during a water main break.
4. Open your last ten PDFs and try to select the text. Drag across a sentence. If it highlights, it's real text and you're in reasonable shape. If nothing highlights — if you can only draw a box over it — that document is a photograph, and to a blind resident it is a blank page. Count how many of the ten fail. That number is the beginning of your real remediation scope.

Write down what you find — not for us, but for the next time someone asks where the town stands, or a vendor tells you their platform "is compliant." You'll be able to ask them, specifically, whether it survives being Tabbed through.

Where we come into it, honestly

Most of this you can act on without ever speaking to us, and we'd rather you did. The left column of that table is genuinely yours, and a clerk who works through it has improved her town's website for nothing.

The right column is the honest limit. If the theme's contrast is wrong, if focus rings were designed away, if the templates emit unlabelled forms, the ceiling on your conformance is set by the platform rather than by you. Munikit is built to WCAG 2.1 AA and tested on every page, not scanned once at launch; it is $17,500 to $27,500 all-in as a one-time cost, and takes six to eight weeks. Read what's in it, or how we approach accessibility — and if you'd like us to look at your current site and say which column your problems are really in, ask us, including when the answer is that they're all in the left column and you don't need us at all.

This page is maintained. It is a practical guide, not legal advice, and it is no substitute for testing your own site with real assistive technology and, where you can, with real users.