Understand conformance and reality

WCAG, the Web Content Accessibility Guidelines, is the standard almost everyone tests against. It’s organized in four principles: Perceivable, Operable, Understandable, Robust. Under them sit numbered success criteria, each with a level: A, AA or AAA. Most laws and contracts ask for level AA, which means every A and AA criterion.

I like WCAG for one reason: it gives two people a shared, testable way to say “this is broken”. Without it, every review becomes an argument about taste.

Map a barrier to a criterion

Let’s take the Register button from the previous lesson, the div that never gets focus. Two criteria describe that failure:

2.1.1 Keyboard (Level A)
  All functionality is operable through a keyboard.

4.1.2 Name, Role, Value (Level A)
  Controls expose a name, a role and their states to assistive technology.

The div fails both. It cannot be reached by keyboard, and it has no role, so a screen reader announces it as plain text “Register”, not as a button. When I write the finding, I quote the criterion number and level. The developer who fixes it can look it up, and the tester who retests it knows exactly what to check.

What a green score doesn’t tell you

Now run Lighthouse on the flawed page. In Chrome DevTools open the Lighthouse panel, tick only Accessibility, and click Analyze.

Here is the surprise:

Accessibility  100

A perfect score, on a page where a keyboard user cannot register. Automated tools check markup patterns. Nothing in the markup says the div was meant to be a button, so no rule fires. The tool is not wrong. It answers a narrower question than the one we care about.

Problems no criterion names

Conformance also misses things that are technically fine. On our page the ticket type select has a proper label, so it passes every label check:

<label for="ticket">Ticket type</label>
<select id="ticket" name="ticket">
  <option value="t1">T1</option>
  <option value="t2">T2</option>
  <option value="t3">T3</option>
</select>

Nobody knows what T1 means. A screen reader user hears “T1, T2, T3” and has to guess. No automated test flags it, and you’d struggle to pin a criterion on it. It is still a barrier, and it still goes in the report.

How I combine the three

My routine is: run the criterion-based checks, run the user tasks from lesson 1, and listen to real users when I can. Then I sort the findings by impact on the task, not by how many rules they fail. A confusing option list ranks below a button that blocks everyone.

The trap is to chase a perfect automated score and stop when the badge turns green. The badge measures the tool. The task measures the page.

Try this on your page: take one automated finding and one thing that only confused you when you used the page yourself. Write both in the same list, with the criterion where one exists and “no criterion, task impact” where none does.