Inline links are a common exception and need careful handling
Aliases: inline link exception · body-text links · paragraph links
What it is
Text links running inside paragraph prose are often allowed to sit under the target-size floor: turning every word into a 24-pixel-tall button would break line height and reading rhythm. That is an exception, not a default. Tag clouds, footer link columns, “related reading” chips, text in navigation, text inside buttons — none of these are “inline” in the original sense. Spreading the exception to every clickable thing that looks like type makes the floor vanish at the most used entries.
Careful handling means: prove it is truly embedded in running prose before accepting a shorter hit height; and still deal with adjacent links that touch each other.
Why it happens
The exception exists because body text is constrained by reading, not by a toolbar. Line height is set by type size and paragraph rhythm. Forcing inline links to become independent targets inserts a control grid into the sentence. The cost: fingertips and tremor were already bad at landing on an in-line chain, and short links (“here”, “more”) have almost no vertical surplus.
The real danger is generalising the exception. A design system makes “text link” a component and uses it on card titles, filters and breadcrumbs. Those spots have no paragraph leading to protect them, yet they inherit “text links may be small”. On the other side, two links in a paragraph separated by a single space stack a size exception on a spacing failure, and the wrong destination fires. The exception relaxes size duty. It does not relax “do not hit the neighbour”.
Studying it
Split clickable text into two classes: embedded in a complete sentence, versus sitting in lists, toolbars, cards or footers. Apply the exception only to the first. Measure the second as ordinary clickable objects for size and spacing. Inside the first class, count pairs of adjacent links on the same line and note whether only a whitespace character sits between them.
Walk an article page dense with body links using both touch and mouse. Failures should distinguish “could not hit this word” from “hit the neighbouring word” — the latter is still a spacing problem even where the exception applies.
Where it stops holding
Legal prose, papers and news body copy are the exception’s home ground. Application UI almost never has true inline links: settings rows, table cells, tags and badges return to the full-set floor. If the product turns body links into block buttons to grow the hit area, it has left the exception and is measured as a button. Print styles or reading mode that turn links into plain text remove the action; the exception no longer applies — that is a different failure. When children or people with motor disabilities are the primary audience, avoid short links even in prose and offer a nearby block action, rather than leaning on the exception.
Applying it
- Reserve the exception for links embedded in sentences. Text links in cards, footers, navigation, chips and filters get ordinary size and spacing.
- Put a perceivable gap or a line break between adjacent body links. Do not let “here” and “here” sit flush.
- Prefer turning a short inline link into a block action (“Download this report” as a button) rather than depending on a two-character hit area.
- How to check: sample one article page and one settings page. Any “words that look like links” on the settings page that sit under the floor cannot be excused as inline.
Related
- Same group: J3.04.1 The size floor applies to every clickable control · J3.04.2 Spacing and size must both hold
- Nearby: J2.03 Colour is not the only cue · C2.02 Minimum touch target size · J3.09 Accidental activation and undo
- Search terms:
inline link exception·target size exception·text link hit area