How to make your website WCAG compliant, starting with what you can fix yourself.
The honest how-to: most of it is a short checklist you can work through yourself. A free scanner helps, but it only catches about a third of the real barriers. Here’s what to fix, in plain language, what the scanner misses, and where it’s worth bringing in a person.
Published July 9, 2026
How do I make my website WCAG compliant?
Start with the handful of fixes that remove the most barriers: real alt text on meaningful images, a site you can use with only the keyboard, a visible label on every form field, enough colour contrast, headings in order, and links that say where they go. A free scanner flags the code-level misses, but automated tools catch only about a third of the real problems, so the rest need a person. Most of the list you can do yourself. The last stretch, whether a screen reader can actually finish your donation form, is what an audit is for.
A green checkmark is not the same as an open door
The usual advice is to run a free accessibility scanner and fix whatever it flags. Do run one — it’s a good first pass. Just don’t mistake a clean result for a done job. A scanner reads your code. It can’t tell whether a real person using a screen reader can actually get through your site, and that’s where most barriers live.
- An image with no alt text attribute at all
- Text colour that fails the contrast ratio by the numbers
- A form field with no label wired to it in the code
- A missing page language, or a heading level that got skipped
- A button or link with no name a screen reader can announce
- Alt text that exists but describes the wrong thing (“image123.jpg”)
- A donation form a screen reader reads out loud but can’t actually finish
- A keyboard trap that strands someone halfway down the page
- Contrast that passes the math but still washes out on a phone in sunlight
- Copy written at a reading level half your audience can’t follow
- Motion that makes someone queasy after they asked their device for less of it
What to fix, sorted by who can do it
WCAG has dozens of technical checkpoints, which is why it sounds endless. It isn’t, for a small site. Most of what actually matters comes down to the list below, split three ways: what you can do yourself today, what takes a careful eye, and the part that genuinely needs a person testing.
Fixes you can make yourself
No developer, no tools. An afternoon on a small site.
- Write real alt text. For every image that carries meaning, describe what it shows in a few plain words. If it’s just decoration, mark it so a screen reader skips it.
- Put your headings in order. One H1 per page, then H2s and H3s that nest properly, not chosen because a font looked bigger.
- Label every form field. A visible label beside each box, so it’s clear what goes where without guessing from the faint placeholder text.
- Make links say where they go. “Read our 2025 report,” not “click here.” Someone tabbing through your links hears them with no surrounding sentence.
- Give every page a clear title, and set the page language. Two lines in your site settings, and both screen readers and Google use them.
- Don’t lean on colour alone. If “required fields are red” is the only signal, add an asterisk or the word “required” too.
Fixes that take a careful eye
Still doable in-house, but check each one deliberately.
- Check contrast against your real brand palette. Body text needs a 4.5-to-1 ratio against its background; large text needs 3-to-1. A free contrast checker gives you the number.
- Make the keyboard focus visible. As you tab through the page, a clear outline should show where you are. A lot of themes hide it by default.
- Caption pre-recorded video, and add a transcript where you can.
- Honour reduced motion. If someone’s device asks for less animation, the big moving pieces should settle down.
- Write error messages in plain words. “Enter a phone number like 250-555-1234,” not “invalid input.”
Fixes that need a person testing
The part you can’t see on your own site. This is what an audit is for.
- Whether a screen reader can actually complete your donation or intake form, start to finish.
- Whether the keyboard ever gets trapped, or the tab order jumps around in a way that loses people.
- Whether the site holds up under real assistive technology, not just an automated pass.
- Whether the reading level and mental effort genuinely work for the people you serve.
Three free scanners, and the wall all three hit
You don’t need to buy anything to get started. These three are free, quick, and worth running. Just keep the ceiling in mind: each reads your code, none of them can sit down and use your site the way a person on a screen reader does.
Lighthouse
Right-click the page, choose Inspect, open the Lighthouse tab, run the accessibility check. Fast and free. Catches the obvious code-level misses, one page at a time.
WAVE
Drops icons right onto your page showing errors and warnings where they happen. The easiest way to see a contrast or heading problem in the place it lives.
axe DevTools
A stricter rule set with fewer false alarms, and the one a lot of developers reach for. Same limit as the others: it reads the code, not the experience.
Run all three and fix everything they flag, and you’ve still only cleared about a third of what WCAG covers. That’s not a knock on the tools. It’s just the line where automated checking ends and a person has to start. In our own audits, that’s where the manual pass begins: a person working through your forms with a screen reader and only the keyboard, start to finish.
The two-thirds a scanner can’t see
Once you’ve worked the checklist, the barriers that are left are the ones you can’t catch on your own site, because you already know how it’s supposed to work. Can a screen reader really finish your donation form? Does the keyboard ever get trapped? That’s what our audit tests: nine dimensions against WCAG 2.1 AA, with a real person driving a screen reader, not just a scan. It’s how we build every site by default, to WCAG 2.1 AA from day one.
Our accessibility audit: nine dimensions, from $1,500- A manual screen reader and keyboard test, the part no scanner can do
- Every finding prioritized by severity and how much work it takes to fix
- Plain-language guidance on what to change, in what order
- A funder-ready report you can keep on file or hand to a developer
What nonprofit leaders ask about going WCAG compliant
How do I make my website WCAG compliant?
Start with the fixes that remove the most barriers: real alt text on meaningful images, a site you can use with only the keyboard, a visible label on every form field, text with enough contrast, headings in order, and links that say where they go. A free scanner like Lighthouse or WAVE flags the code-level misses, but automated tools only catch roughly 30 to 40% of real barriers, so the rest need a person to check. Most of the checklist you can do yourself. The last stretch, like whether a screen reader can actually finish your donation form, is what an audit is for.
Can I make my website accessible myself?
A lot of it, yes. The first group of fixes — alt text, heading order, form labels, plain link text — needs no special tools and no developer. Where it gets harder is the testing: confirming a screen reader can complete a form, or that the keyboard never gets stuck. That part is hard to judge on your own site, because you already know how it’s meant to work, so you unconsciously use it the “right” way. That blind spot is the gap an audit fills.
What tools check if my website is WCAG compliant?
Three free ones are worth knowing: Lighthouse (built into Chrome), WAVE (a WebAIM browser extension that marks problems right on the page), and axe DevTools (a stricter extension from Deque). Each one reads your code and flags issues like missing alt attributes, contrast failures, and skipped headings. All useful, and all limited the same way: they catch about a third of real barriers and can’t tell you whether a person using a screen reader can actually get through your site.
Is there a WCAG certification I can get?
No. There’s no official WCAG certificate and no body that stamps a site “certified.” Conformance is a claim you make, ideally backed by documentation like an audit report, not a badge you buy. Be wary of anyone selling a “WCAG certified” seal. What a funder actually wants is evidence the work was done and where the site stands, which is what a proper audit report gives you.
WCAG 2.0, 2.1, or 2.2 — which version do I need?
Build to WCAG 2.1 Level AA. It includes everything in 2.0 AA and is the version most Canadian laws and funders point to. WCAG 2.2 is the newest and adds a handful of criteria, mostly around focus and mobile use; if you’ve met 2.1 AA, you’re nearly there. Ontario’s AODA still references 2.0 AA, and meeting 2.1 clears that bar too.
How long does it take to make a website WCAG compliant?
It depends on how big the site is and how it was built, but a small nonprofit site is a finite job, not an endless one. The first-group fixes are often an afternoon. Contrast, focus states, and captions take a bit longer. The real timeline comes from the human-tested part, which is why an audit gives you a prioritized list: you fix the barriers that shut people out first, and work down from there.
Do I even have to make my website accessible?
For most small Canadian nonprofits, no law forces you to yet. BC’s Accessible BC Act binds public bodies like school districts, not private charities. The reasons to do it anyway are that funders increasingly ask for it, and 27% of Canadians aged 15 and up live with a disability (Statistics Canada, 2022), which is a large share of the people you serve. We wrote the full breakdown of who the law actually covers separately.
Not sure the law even applies to you? Here’s who Canadian accessibility law actually binds, and for Ontario orgs, the plain-English guide to AODA website compliance.
A scanner tells you the code passed. A person tells you someone got in.
Book a free call. We’ll tell you honestly how far your own checklist got you, and whether it’s worth a full audit to catch the rest. No fear, no upsell.