A dense data table renders three icon-only action buttons per row - edit, duplicate, delete. Each button's hit area is 16 by 16 CSS pixels with 2 pixels between them. Phone users report hitting the wrong action, and one of the three is destructive. The buttons have correct accessible names and work with a keyboard. Which change fixes this at the right level?

The mechanism

A pointer target is hit with a finger, not a cursor, and the finger's contact patch is far larger than 16 pixels. Targets smaller than the pointer's accuracy produce mis-taps at a rate that rises as spacing falls, and here spacing is 2 pixels - so the neighbouring target is well inside the error radius. One of the three actions is destructive, which converts an accuracy problem into a data-loss problem.

The fix people resist is the one that costs nothing visually: the visible icon and the hit area are different boxes. Padding, or a pseudo-element that extends the hit area past the visual bounds, grows the target while the table looks exactly as dense as before. The usual objection - "the rows will get fat" - is false.

What the standard actually requires

WCAG 2.2 became a W3C Recommendation on 5 October 2023 and added success criterion 2.5.8 Target Size (Minimum) at level AA: pointer targets at least 24 by 24 CSS pixels, with five exceptions - spacing, equivalent, inline, user agent control and essential.

The spacing exception is the one that matters here, and it fails: it requires that a 24-pixel-diameter circle centred on each undersized target not intersect another target's circle. At 16 pixels with 2-pixel gaps, the circles overlap heavily. The stricter 2.5.5 Target Size (Enhanced) sits at level AAA and asks for 44 by 44, which is the right number for destructive or in-motion use.

Why the other options fail

• Accessible names and tooltips. Correct and probably already done, and it addresses a different barrier. A screen-reader user knows what the button is; the person mis-tapping delete can see it perfectly well. This is the most common substitution in accessibility work - treating a motor-accuracy requirement as a labelling one.
• Scaling the icon glyph. Would help if the button were sized by its content, but the stated box stays at 16 pixels, so the target does not change. It makes the problem look addressed, which is worse than leaving it, because the next audit finds it and the team believes it was fixed.
• One row menu instead of three buttons. A legitimate design for crowded rows, and it does not remove the requirement - the menu trigger and every item in the menu are targets subject to the same floor. It also charges every user an extra tap for every action, which is a product decision being made to satisfy a styling constraint.

Where the fix belongs

In the shared button component, because dozens of tables across the product inherit it, and a per-table patch is the thing that regresses next quarter. Set the floor once, add a lint rule or a computed-size assertion so a consumer cannot shrink it back, and the whole class of finding disappears from the next audit rather than being re-filed.

When a small target is allowed, and when not

Links inside running text are covered by the inline exception, and a 16-pixel control with 24 pixels of clear space around it - a lone close button in a corner - passes through the spacing exception. The decision rule for a component library: 24 pixels as the floor everywhere, 44 for anything destructive or used one-handed while moving.