How WCAG works
WCAG stands for the Web Content Accessibility Guidelines, published by the World Wide Web Consortium. It is not a law and not a piece of software; it is a set of testable statements about web content, written so that two people checking the same page should reach the same verdict.
Everything hangs off four principles, usually shortened to POUR. Content must be perceivable, so people can take it in whether they are reading, listening or using a screen reader. It must be operable, so it can be driven by keyboard as well as by mouse or touch. It must be understandable, with predictable navigation and errors explained in plain terms. And it must be robust, meaning the markup is sound enough for assistive technology to interpret reliably.
Under those sit the success criteria, each assigned a conformance level: A for the baseline, AA for the level most organisations and procurement rules aim at, and AAA for criteria that cannot reasonably be met by every kind of content. The guidelines are versioned, and later versions such as WCAG 2.1 and 2.2 add criteria mainly around mobile use, low vision and cognitive load.
Why WCAG matters
The first reason is the obvious one: a page that cannot be read by someone using a screen reader, or operated by someone who cannot use a mouse, excludes customers. That includes temporary and situational cases — a cracked screen, bright sunlight, one hand on a bus.
The second is practical. Whether accessibility is legally required depends on where you and your customers are, and rules differ by country and sector, so that is worth checking locally rather than assuming. But if you sell to government bodies, universities, banks or large international companies, Level AA tends to appear in their procurement paperwork regardless of your own jurisdiction.
The third is that most of the work helps everyone. Readable contrast, sensible headings, labelled form fields, captions and descriptive link text improve the page for ordinary visitors and for search engines at the same time.
Where WCAG goes wrong
Overlay widgets are the biggest trap. Scripts that promise to make a site compliant by adding a toolbar do not fix the underlying markup, are widely criticised by disabled users, and have not prevented complaints. Treat any product claiming instant conformance with suspicion.
Automated scanners are the second. They are useful, and they find real faults, but a large share of the criteria — whether alternative text is meaningful, whether the reading order makes sense, whether an error message explains what to do — can only be judged by a person. A clean automated report is not conformance.
The third is treating it as a single audit. Accessibility breaks the way anything else breaks: a new template, an embedded form, a video added without captions.
How to act on it
Aim at Level AA and start with the faults that block people outright: content that cannot be reached by keyboard, images carrying information with no alt text, form fields with no label, colour used as the only way to convey meaning, and text that is too faint to read comfortably.
Then build the checks into how you work. Run an automated scan on key templates, follow it with a manual pass using only the keyboard, and test one real journey with a screen reader. Write accessibility into the brief for any new template or supplier, and keep a short record of what you checked and when — that record is what you will need if anyone ever asks.