WCAG 2.2’s Level AA target-size rule sets a measurable minimum of 24 by 24 CSS pixels for a pointer target, with five named exceptions that each have to be checked against the actual element, never assumed.
The icon toolbar I shipped worked perfectly in every test I ran, because every test I ran used a mouse, and a mouse pointer is precise down to the pixel. The first person who opened it on a touchscreen tapped the icon next to the one they meant, twice in a row, then wrote in to ask if the button was broken. It was not broken. It was roughly eighteen pixels square with another eighteen-pixel target sitting a few pixels away, which is a fine target for a cursor and a genuinely hard one for a fingertip.
WCAG 2.2’s Success Criterion 2.5.8, Target Size Minimum, is a Level AA requirement, and it states the rule in plain, measurable terms: the size of the target for pointer inputs is at least 24 by 24 CSS pixels. Not comfortably large, not roughly thumb-sized. Twenty-four by twenty-four, a number I can measure against an actual element in an actual layout rather than a feeling I have about how cramped a toolbar looks on my own screen.
The criterion is not a blanket ban on anything smaller, though, and I nearly treated it as one before reading the rest of it properly. It carries five named exceptions: Spacing, Equivalent, Inline, User Agent Control, and Essential. Each one has its own test written into the criterion, and each test is as specific as the twenty-four itself — the Spacing exception in particular turns on a measurement rather than on whether a gap looks generous enough. None of them applies automatically just because I would like it to, which is what I had to go and read properly rather than assume from the name alone.
Going back through my own toolbar with the five exceptions actually in hand, rather than just the headline number, changed what I fixed. A couple of the small targets were genuinely inline text links inside a paragraph, which the Inline exception covers without needing to grow at all. The rest were the icon buttons that had started this whole thing, packed edge to edge with no equivalent larger control anywhere else and no spacing exception available, and those got rebuilt at the actual minimum with real gaps between them.
Growing every icon to the full minimum was not always the right fix even where none of the five exceptions applied outright, because a toolbar spaced out to fit twenty-four-pixel targets everywhere takes up noticeably more room than one built for a mouse, and that trade-off is real rather than cosmetic. Where I could add space between two adjacent small targets instead of enlarging both, the Spacing exception meant I did not have to choose between a cramped touch target and a bloated toolbar, because that exception is satisfied by distance between targets rather than by the size of each one individually. Reading the exception properly, rather than defaulting to the blanket fix of making everything bigger, kept the toolbar looking like the one I had actually designed instead of a chunkier one built for a different input method entirely, and it meant the fix cost me a layout adjustment rather than a redesign.
What I took from this, on top of the fix itself, is that target size is the same kind of check as contrast: a number you measure against an element, not an impression you form by looking at a layout on the one input device you happened to test it with. My mouse cursor was never going to surface a target that was too small, because a mouse cursor does not have the failure mode a fingertip has. The rule, and an honest use of its five exceptions rather than an assumed blanket one, is what actually catches it before a user has to write in and ask if the button is broken.