Small touch target on mobile

Only at the mobile width of 390 px we measure interactive elements: links, buttons, form fields, selects and anything with a button role. The finding goes to an element that is under 44 px in both dimensions (config/design.json#thresholds.minTouchTargetPx), so an element of 342 × 24 px gets no finding even though it is short.

A link inside running text is left out. When the target is inline-level and the same block holds visible non-clickable text, its size is held by the line-height of that text, which is the “Inline” exception in both WCAG 2.5.8 and 2.5.5 (verbatim wording below). The standard does not ask for 44 × 44 px there even at level AAA, so we do not report it. A row made up of links only (pagination “1 2 3”, a bar of links) has no such exception (the wording in the standard is “non-target text”) and is reported.

Spacing is computed. For every flagged target we evaluate the “Spacing” exception of WCAG 2.5.8: a circle 24 px in diameter centred on the bounding box must not intersect a neighbouring target. It does not remove the finding (our 44 px threshold is criterion 2.5.5), but the finding text tells you how many of the flagged elements fail even the milder 24 × 24 px line including that exception.

At wider viewports the check does not run at all. With a mouse, target size does not matter in this way.

What the check does not do:

• It does not watch spacing for targets that clear our threshold. Two 44 × 44 px buttons packed together pass, even though a thumb cannot hit either reliably; spacing is computed only for elements already below the threshold.
• It does not account for a hit area enlarged via ::before/::after or padding on a parent: the element's own box is measured, so a small icon with a large invisible area gets the finding undeservedly.
• It does not weigh importance. A footer link counts the same as a “Buy” button.
• It cannot see elements that appear only after an interaction.

The finding is page-level, with an annotated screenshot; severity is warning.

For visibility in AI answers there is no effect at all. But unlike most codes in the design module, here a written standard exists, which is exactly why it is worth stating precisely what it does and does not say.

The standard asks for 24 px, not 44. WCAG 2.5.8 (Target Size (Minimum), level AA) requires a target of at least 24 × 24 CSS px, with five exceptions. The most important is spacing: an undersized target is fine if a 24 px diameter circle centred on it does not intersect the circle of another target; in practice, centres at least 24 px apart. The others are a link inside a sentence, an equivalent control elsewhere on the page, a size determined by the user agent, and a presentation that is essential.

44 × 44 px is a different criterion at a different level: WCAG 2.5.5 (Target Size (Enhanced)), level AAA. It matches Apple's guidance (the Human Interface Guidelines ask for a hit region of at least 44 × 44 pt for a button). Do not invoke Google for this threshold: Google recommends 48 dp for touch targets, not 44; this page had it wrong until 13 September 2026. The WCAG criteria were verified on 13 September 2026 directly at w3.org (sources below), the Apple and Google guidance in their own developer documentation.

Nor are those 24 px an enforceable duty in Europe yet, though this has moved. On 2 September 2026 ETSI published EN 301 549 V4.1.1, which adopts WCAG 2.2 including criterion 2.5.8. The European Commission has not yet cited it in the Official Journal, so meeting it confers no presumption of conformity; the older v3.2.1 is built on WCAG 2.1, where criterion 2.5.8 does not exist at all. Our accessibility module therefore measures 2.5.8 and counts it towards the WCAG 2.2 score, but not towards the WCAG 2.1 score (ADA Title II) or the WCAG 2.0 one (Section 508); three numbers side by side, see docs/pristupnost.md.

So the 44 px threshold in this finding is ours, not the standard's, deliberately stricter, because a thumb misses a 24 px target even where the standard stays silent. We say so plainly on purpose: passing it off as a legal requirement would be untrue, and you would rebuild a layout that does not need rebuilding.

Who it affects most: people with limited fine motor control, with tremor, people operating a phone one-handed on the move. But in truth everybody: everyone knows the repeated missing of a footer link.

What this means for your site: a DSG-05 finding on its own is not a breach of the standard. It means the element misses our stricter threshold. Before rebuilding a layout because of this finding, look at which element it is: a small footer item with enough spacing or an element at the browser's native size are fine under WCAG 2.5.8 and need no enlarging. Links inside a paragraph are not counted at all since 19 September 2026; until then they were reported, and telling you to grow them to 44 × 44 px contradicted the standard, which exempts them.

Take it in this order: first check spacing (that is what excuses a small target under the standard), and only when even that is not enough (or when you want to meet our stricter threshold), enlarge. When enlarging is visually impossible, grow the hit area without growing the appearance.

/* Honest enlargement */
.button {
  min-width: 44px;
  min-height: 44px;
}

/* Small icon with a large target: looks the same, hits bigger */
.icon {
  position: relative;
}
.icon::after {
  content: "";
  position: absolute;
  inset: -12px;
}

• Spacing is an alternative to size, not an addition. The standard excuses a small target if a 24 px diameter circle around it does not intersect a neighbour's; roughly centres at least 24 px apart. A dense list of links with enough line spacing is fine under WCAG.
• The commonest culprit is the footer: a list of links with a small line height. If you do enlarge, increase the items' padding, not the font size.
• The second commonest is an icon button (close, share, favourite). The invisible area above fits here.
• Watch out for cards that look entirely clickable. When the link wraps only the title line, the rest of the card does nothing. The defect is not the number, it is that the surface promises more than it delivers.
• Verify with a thumb, not a mouse. On a real phone, not in device mode: a mouse pointer is precise, a thumb is not.