Web Content Accessibility Guidelines

Nobody argued against making products accessible. The argument started one step later, over how far a team had to go before it counted as done. Accessible enough meant one thing to the person raising the issue and something else to the person asked to fix it, and nothing sat in between to settle which reading was right. With no answer to that, review meetings turned into a contest of impressions.

The fight over grey text is the classic case. A designer posts a screen with light grey body copy, an engineer says it's hard to read, and the designer says it reads fine. Neither of them is lying. On a large monitor in front of good eyes it really is legible, and on a laptop near a sunny window or in front of eyes that have lost contrast sensitivity with age it really isn't. With no instrument to settle it, the decision went to whoever spoke loudest or ranked highest.

Support tickets died at the same spot. When a user wrote in to say the text disappeared into the background, the person reading the ticket had nothing to do with that sentence. It didn't say what to change, and it didn't say how much change would be enough. Nothing in it could be checked off, so nothing in it could be scheduled. Once a report gets filed as a matter of taste, it sinks to the bottom of the list and stays there.

What was missing was not stronger encouragement but sentences that could come out true or false. The World Wide Web Consortium (W3C) published a first edition in 1999 and reshaped the wording in version 2.0 in 2008. Instead of "make text easy to read," the guideline reads "the contrast ratio between body text and its background is at least 4.5 to 1." The first sentence invites debate; the second ends in a calculator. Two people who pull the same two colors off the same screen arrive at the same ratio, so there is no version of that argument where both of them get to be right. Version 2.1, released in 2018, added criteria for mobile screens, low vision, and cognitive differences, bringing the count of such sentences to 78.

Changing the sentences changed the workflow. A requirement you can test becomes a list item, and a list item gets an owner and a date. The grey-text argument now ends by measuring the value, writing down 3.1 to 1, and handing that line to whoever will fix it. Turning a question of taste into a row in a defect list is the largest practical change these guidelines made.

Regulation picked up the same sentences. Accessibility law requires that people with disabilities be able to use a service, and rather than inventing its own testable wording, it cites these criteria by number. Korea's national standard follows the same structure. That is why the accessibility clause in a public-sector request for proposals almost always ends in a level from this document.

The terms under WCAG fall into two groups: the principles that sort what has to be met, and the level that marks how far you went. Every criterion carries one of each. The contrast requirement sits under the first principle and at level AA. The two groups are less like separate topics than like a single list cut once horizontally and once vertically.

There are four principles, and every guideline lives under one of them. Thirteen topic guidelines sit under those four, sorted by subject, and under each guideline sit the sentences that can be judged true or false. Those sentences are called success criteria, and a criterion is the smallest unit anyone actually measures, argues over, or signs off.

1. Perceivable — information on the screen must not depend on a single sense. Images carry a text description, video carries captions, and success and failure are never marked by colored dots alone — a dot that is either green or red carries its whole meaning in hue, which leaves a user who can't separate those two hues with nothing to read. The criterion teams trip over most often lives here: contrast ratio, a calculated comparison of text brightness against its background, which demands at least 4.5 to 1 for body-sized text. Light grey on white lands around 2.8 to 1 and fails; dropping one or two steps darker in the same grey family passes.
2. Operable — every function has to be reachable in practice. Tab, Enter, and the arrow keys alone must get you to every control, the currently selected control has to be visible, and a screen with a time limit has to offer a way to extend it. The rule against anything flashing more than three times per second belongs here too, because fast flicker can trigger seizures in photosensitive users. Teams often delete the focus outline because it looks untidy in a mockup, and that deletion fails a criterion on its own. The outline is the only thing telling a keyboard user where the next press will land, so removing it leaves them moving an invisible cursor around the page.
3. Understandable — what people read and what the screen does have to be predictable. Declaring the document language is the standard example. Without it, a screen reader — software that speaks the contents of a screen aloud — reads Korean sentences with English pronunciation rules. Error messages that name which field is wrong and why belong here as well. If a signup field only turns red with no text, a user who can't distinguish the color has no way to learn what failed; one line saying the password needs at least eight characters fills that gap. So do the criteria about keeping a function in the same place on every screen and explaining unfamiliar words.
4. Robust — the page has to behave the same across browsers and assistive technologies. Where the first three principles describe what a person sees and hears, this one describes what reaches the machine. Its core demand is that every element expose a name, a role, and a state that software can read: what the control is called, what kind of control it is, and whether it is currently checked, expanded, or switched off. A box styled to look like a button is a button to the eye and a shapeless container to the machine, which is exactly where this principle catches it.

The level is a single entry. Conformance level is the A, AA, AAA marking attached to each success criterion. It measures difficulty of achievement rather than importance, so a level A criterion is not the more serious one — it is the one more products can reach. Meeting AA does not mean satisfying the AA items only; it means satisfying A and AA together. The same topic can appear twice at different levels — contrast asks for 4.5 to 1 at AA and 7 to 1 at AAA.

The working target is almost always the middle level. In version 2.1, A and AA together come to 50 criteria, which is about as much as an ordinary web product can realistically carry to completion. AAA includes items such as providing sign language interpretation or glossaries for difficult vocabulary, some of which simply don't apply to certain content, and the specification itself advises against requiring AAA for an entire site. Law and public procurement draw their line at AA for the same reason.

Judgment only works when both groups are read together. Principles alone tell you what deserves attention but not where you may stop; a level alone gives you a target with no description of what's inside it. This is where the shape of a review sheet comes from — principles split the ownership, the level trims the scope. Perceivable and understandable land mostly with design and copy, operable and robust mostly with implementation, and how far this release goes is set by the level. A row on that sheet reads something like "body contrast 4.5 to 1, perceivable, AA, Noa." With the criterion, the principle, the level, and the owner on one line, the gaps show, and the next release starts from the same table.

"This screen doesn't clear AA. The body grey measures 3.1 to 1 and the bar is 4.5."

A request to change a color, argued from a failed criterion rather than from preference.

"The RFP says version 2.1 AA, so we need to audit where we stand before we quote."

The requirement is contractual, so the size of the remediation work has to be measured first.

"We don't need to chase AAA. Let's hit AA and stop there."

Agreeing on a target level, which is also a way of deciding in advance where the work ends.

At Pagedeck the guidelines first reached the schedule through a public-sector deal. The request for proposals Sofia brought back carried one line about accessibility, and that line sent the team back through every screen. Noa took color and type, Theo took keyboard operation and markup, and they recorded the current state criterion by criterion.

The results split in two. Half were items like missing text descriptions or an undeclared page language, each an afternoon of work. The rest were items like rebuilding a hand-rolled dropdown and modal so they can be driven from the keyboard, each a matter of weeks. Looking at the list, Grace decided to meet only the A and AA items named in the contract this quarter and to push the remainder to the next one. Because every item carried a number and a level, what got deferred stayed written down, and the next planning round opened the same list.

The most common misreading is that the guidelines serve blind users only. Text descriptions and screen readers come up so often that the assumption is easy to form. In fact only some of the criteria across the four principles concern sight. Keyboard operation, time limits, error messages, and flash limits sit right beside them, addressing users with limited hand mobility, users with different cognitive profiles, and users at risk of seizures. Narrow the audience and the audit narrows with it: a team fills in every image description, then reports conformance on a checkout flow that cannot be completed from the keyboard.

Treating an automated scan as the finish line is the other frequent mistake. Run the tool, watch the error count fall to zero, and it looks finished — there's even a screenshot for the report. But a tool can only judge what a machine can verify on its own. It knows whether an image has a text description; it doesn't know whether that sentence describes the image. Writing "image" makes the error disappear. It knows whether a link has an accessible name; it doesn't know that a link named "click here" is useless in a list of links. Leave it there and you end up with a screen that passes on paper and still blocks the user, and when a legal inquiry arrives the audit record defends nothing. That is why a manual pass belongs after the scan: complete one core task using the keyboard alone, start to finish. At Pagedeck that means putting the mouse under the desk and creating a document and sharing it. The check takes ten minutes and turns up two or three blocked spots every time on screens the scanner cleared.