AI lets anyone ship a website in an afternoon. WCAG is the standard that decides whether everyone can actually use it.
WCAG stands for the Web Content Accessibility Guidelines. It is a set of rules, published by the W3C (the group that maintains the standards behind the web), for making websites and apps usable by people with disabilities. That includes people using a screen reader, people who navigate with a keyboard instead of a mouse, people who need captions, and people who zoom the text to 200%.
One idea sits under all of it: can everyone use this, not just someone who sees and clicks the way you do.
The four principles: POUR
Every WCAG rule traces back to four words. The acronym is POUR.
- Perceivable. People can take in the content. Images have text alternatives, video has captions, text has enough contrast against its background.
- Operable. People can use it. Everything works with a keyboard, nothing flashes hard enough to trigger a seizure, people get enough time to read and act.
- Understandable. People can follow it. Text is readable, the site behaves predictably, errors tell you what went wrong and how to fix it.
- Robust. It holds up. The code is clean enough that assistive technology, like a screen reader, can interpret it reliably now and as tools change.
If you remember nothing else, remember POUR. Most accessibility work is just one of those four words applied to a specific thing.
The three levels: A, AA, AAA
WCAG sorts its rules into three conformance levels.
- Level A is the floor. Miss these and the site is broken for whole groups of people.
- Level AA is the real-world target. This is what most laws and contracts mean when they say "accessible."
- Level AAA is the highest bar. Useful to aim parts of a site at, rarely required across a whole site.
When someone says a site should be "WCAG compliant," they almost always mean AA. That is the number to hold in your head.
Which version
WCAG is versioned like software. 2.0 (2008), 2.1 (2018), and 2.2 (2023) are the ones in use. Each version mostly builds on the last: 2.2 added nine new rules and retired one outdated one (4.1.1 Parsing, which modern browsers made unnecessary). When you target WCAG today, target 2.2 at level AA, and you have effectively covered the earlier versions too.
Why this matters in Norway
This is not only good practice, it is law, and the law is written in WCAG's own terms. Norway's regulation on universal design of ICT (forskrift om universell utforming av IKT-løsninger) does not invent its own rules, it points at WCAG. So learning WCAG and complying with Norwegian law are the same task. It is enforced by uu-tilsynet (Tilsynet for universell utforming av IKT), the authority under Digitaliseringsdirektoratet.
The bar depends on who you are:
- Private sector (most businesses, a small clinic, a solo operator's site): WCAG 2.0 at level A and AA, 35 success criteria. That is the 38 in 2.0 AA minus three media criteria (pre-recorded and live audio and video) that the regulation excepts.
- Public sector: the stricter EN 301 549 standard, which pulls in WCAG 2.1 at A and AA, twelve more criteria than the private-sector floor. Public bodies must also publish an accessibility declaration (tilgjengelighetserklæring) via uustatus.no, and a selected body that fails to produce one within 15 working days faces a daily fine of 5,000 kroner.
Then there is what is coming. The European Accessibility Act has applied across the EU since 28 June 2025 and pulls far more private-sector digital products and services into scope. As of June 2026, Norway has not formally brought it into the fold: it is not yet written into national law. That work is underway and is expected to build on the Equality and Anti-Discrimination Act, so for now this is the direction of travel rather than a live Norwegian duty. Building to the higher bar today is the cheap way to be ready for it.
Here is the leverage. Because the law is defined in WCAG, you do not have to learn two things. Hit WCAG 2.2 at level AA and you clear today's Norwegian private-sector floor (2.0 AA) with room to spare, and you are already standing where the European Accessibility Act is moving everyone. One standard, learned once, covers the practice and the law.
The AI part most people skip
Here is the part that connects to everything else I teach. AI tools, including the no-code builders, will happily generate a site that looks finished and is quietly inaccessible. The button has no label a screen reader can read. The contrast is too low. The form gives no error a keyboard user can reach. The site looks right on your screen and fails for the person it most needs to work for.
Automated checkers (Lighthouse, axe, WAVE) catch maybe a third to a half of WCAG issues. They are worth running. They are not the answer. The rest needs a human to verify, the same habit that runs through everything practical-AI: do not trust the output because it looks done, check the thing the tool cannot see.
A few checks anyone can do today, no code required:
- Unplug the mouse. Tab through your site with the keyboard only. Can you reach and use everything, and can you see where you are?
- Run one automated scan. Install the free axe or WAVE browser extension and read what it flags.
- Check contrast. Use a contrast checker on your main text and buttons. Aim for the AA ratios.
- Read your alt text. Every meaningful image should describe what it shows, not say "image."
None of that makes you an accessibility expert. It does move your site from "looks done" to "works for more people," which is the whole point of WCAG in one sentence.
What you can automate, and what you can't
You do not want to run those checks by hand every time you change something. The repeatable parts should run themselves. Here is what that looks like in practice, from least to most setup.
- Scan on every deploy. Wire an accessibility checker into the step that publishes your site, so every change gets scanned before it goes live. The common tools are axe-core, Lighthouse CI, and pa11y. Set it to flag any new AA violation. You change a button, the check runs, you find out immediately instead of three weeks later.
- Scan on a schedule. If you build on a no-code platform and there is no deploy step to hook into, put the check on a timer instead. A small automation, a tool like n8n is built for exactly this, can visit your pages once a week, run the scan, and email you a plain-language summary of what changed. Set it once and forget it.
- Turn scan output into fixes with AI. A raw accessibility report reads like error codes. Paste it into Claude and ask it to explain each issue in plain English and propose the specific change. Use the same move for the tedious parts: draft alt text for a batch of images, or have Claude review a single component for accessibility problems before you ship it.
Then the boundary, because this is where most "we automated accessibility" claims quietly fall apart. Automation reliably catches the machine-checkable issues: missing labels, low contrast, broken structure, the third-to-half from earlier. It is much weaker at judging whether your labels make sense, whether the keyboard flow is sane, or whether a screen-reader user can actually complete the task. That part stays human, at least for now, and even as the tools get better at it, the call to trust the result stays yours.
So the pattern is three steps, and only the middle one is new: detect automatically, fix with AI assistance, verify by hand. The machine flags, the AI drafts the fix, the person confirms it actually works. That is the reliable-AI habit applied to accessibility: automate the repeatable part, route the judgment to a person, and never let the green check stand in for someone who tabbed through it.
I will follow this with a short walkthrough, how to check your own site against WCAG in about 20 minutes, and how to wire the automatic scan so you only do the manual pass when something actually changes. If that is useful to you, that is the next one to read.