Touch target size.

WCAG 2.2 requires touch targets to be at least 24×24 CSS pixels at level AA and at least 44×44 CSS pixels at level AAA.

Touch target size is one of the most concrete numeric rules WCAG 2.2 introduced, and one of the most frequently broken clauses in mobile interfaces. The rule looks simple — make the target bigger — but two points get confused in practice: which level asks for which number, and which situations fall under the exceptions. Confusing either leads to unnecessary work or to missing a real violation.

Two criteria, two numbers

The source of the confusion is that two separate criteria ask for two separate numbers. 2.5.5 “Target Size (Enhanced)” has existed since WCAG 2.1 and asks for 44×44 CSS pixels — but at level AAA. 2.5.8 “Target Size (Minimum)” arrived with WCAG 2.2, sits at AA, and asks for 24×24. So 24 is enough to conform to AA; targeting 44 collects AAA as well.

In practice most design guides recommend a value around 44 pixels, and the reason is not WCAG but ergonomics: the contact area of an adult fingertip on a screen is roughly that size. So 24 is a floor for conformance; 44 is a target that works well with real fingers. The two do not conflict — one is the minimum legal threshold, the other a usability goal.

On this site the target was set at ≥44 pixels, and the verification suite measures every touchable element. The decision was a usability decision, not a conformance one — but as a by-product it also meets the AAA-level 2.5.5. Most accessibility items work this way: the design decision made correctly brings the criterion along by itself.

The exceptions: not every small target is a violation

The exception list of 2.5.8 is what makes the rule realistic, and not knowing it leads to unnecessary work. In five situations a small target is legitimate and needs no fixing.

1. Spacing — even a small target conforms if a 24×24 circle around it touches no other target. Putting space between icons yields the same result as enlarging them.
2. Inline — a link inside a block of text is exempt. Raising a link within a sentence to 24 pixels of height would break the text.
3. Equivalent alternative — if another target doing the same job, on the same page and large enough, exists, the small one conforms.
4. User agent control — if the browser determines the size and the author has not changed it, the exception applies.
5. Essential — when the target being small is required by the information itself. A location pin on a map, or a cursor position in a text editor.

The spacing exception is the most useful in practice because it intervenes least in the design. Enlarging 20-pixel toolbar icons to 24 can break the layout; putting a few pixels of space between them usually does not, and it meets the criterion. What is measured is not the icon itself but the touchable area around it.

The essential exception is the most abused. “Our design requires it” is not an essential justification; essential means cases where enlarging the target would corrupt the information. Pins on a map are genuinely essential because they represent locations; small icons in a menu are not.

What is measured is not the visual size

The most common measurement mistake is measuring the icon itself. The criterion concerns the TOUCHABLE area — the box that catches the element’s click event. A 16-pixel icon can be a 44-pixel target if it has padding around it; the icon is small but the target is large and the criterion is met.

The reverse is also true and more dangerous: a button that looks large is in reality a small target if the click event is bound only to the text inside it. The user touches the edge of the button, nothing happens, and they cannot tell why. This defect is easily caught by looking at the element box in the browser inspector.

The unit gets confused too: the rule speaks in CSS pixels, not device pixels. On a high-density screen, 24 CSS pixels is physically many more device pixels; measurements must use the CSS size the browser reports. Counting pixels on a screenshot misleads.

What is measured is not the size of the icon but the area a finger can touch.

Where it breaks

On real sites this criterion breaks repeatedly in a few typical places, all tied to mobile layout. Targets large enough on desktop drop below the threshold in a grid that narrows on mobile — and nobody notices, because testing happens on desktop.

1. Close (×) buttons — the little crosses in the corners of layers and notifications. The most frequently broken pattern.
2. Social media icon rows — small icons lined up in the footer; both small and close together.
3. Pagination numbers — page numbers that narrow on small screens.
4. Action icons inside tables — delete, edit, download. They shrink as row height tightens.
5. Checkboxes and radio buttons — custom-styled ones often drop to 16–18 pixels; making the label clickable too solves it.
6. The language switcher — two-letter abbreviations (TR, EN, DE) naturally produce small targets.

The last item received special attention on this site because the site is trilingual and the language switcher sits on every page. Turning a two-letter label into a 44-pixel target was done with padding, without visually enlarging it — and the suite measures it on every run, in the mobile breakpoint too.

As a general rule: sweeping all touchable elements once in the mobile breakpoint catches nearly all of this criterion’s defects. The sweep is done by looking at element boxes in the browser inspector — by the reported size, not by eye.

It applies on desktop too

Though the criterion is commonly called “touch target,” the WCAG text does not speak only of touchscreens; it covers all pointer input. That means it applies to desktop interfaces too, and there the rationale differs: not finger thickness but pointer precision. For a user with tremor, limited arm movement, or head/eye tracking, hitting a small target with a mouse is as hard as on touch.

Small targets are therefore a defect in desktop design too, and the most frequent breakage there is in tables and toolbars. As row height compresses, the edit and delete icons at the end of the row shrink; a sixteen-pixel trash icon looks elegant but is hard to hit — and hitting it wrongly can trigger an irreversible operation.

A practical rule: the size of a target should be inversely proportional to the consequence of missing it. Missing a link is harmless; the user tries again. Hitting a delete button by mistake loses data. Destructive operations deserve targets that are both large and far from their neighbors — there, the criterion’s minimum is a starting point, not a floor.

How to measure

Measurement happens in the browser inspector, and eyeballing is categorically not enough. When an element is selected, the inspector shows the box model; the value to check is the total width and height including padding. Not the icon’s own size — the size of the event-catching box.

1. Open the browser inspector, select the touchable element and check the total size in the box model. Below 24×24, check whether an exception applies.
2. Measure the mobile breakpoint separately — targets sufficient on desktop can narrow on small screens. Testing on desktop hides the defect.
3. Measure the spacing too — if the target is small, does the space around it hold a 24×24 circle without touching a neighboring target?
4. Automate — a short script that sweeps touchable elements and reports their sizes replaces the manual sweep and runs on every deployment.

The last item is the approach used on this site. The suite measures touchable elements in both the desktop and the mobile breakpoint, and turns red if any target drops below 44 pixels. Measuring by hand once passes and silently breaks with the next component; the guard makes the breakage visible at deployment time.