skip to content

On a hotel booking site's mobile filters, why should tapping a checkbox's label toggle it, and how should links inside that label be handled?

level: juniorimportance: should knowfreq 44%

answer

  1. the box is tiny
  2. bigger and nearer is faster
  3. the whole row is the target
  4. two targets fighting in one row
  5. move the link beside the label

basics

~20 s

Making the label part of the target turns a tiny box into a whole row, which is faster and easier to hit, especially on touch screens. A link inside that label competes for the same tap, so move it beside or below the label.

solid answer

~50 s

A checkbox's box is small; its label is large. When tapping the label toggles the box, the target grows from a fingertip-sized square to the whole row, which **Fitts's law** predicts is faster to hit and which forgives tremor, motion and imprecise thumbs on a mobile filter list. It also means the text people read is the thing they touch, and it keeps the visible label and the control's name the same text, which voice-control users rely on. Links inside that label, such as 'I agree to the **cancellation policy**', create two targets in one row: a tap meant to check the box opens the policy, or a tap meant to read the policy checks the box. The spec should keep label text plain, put the link just outside the label, beside or below it, and make sure neighbouring rows' targets do not overlap.

go deeper

for a junior

Recall that the label should toggle the checkbox, making the whole row the target, and that links should not sit inside that label.

for a middle

Explain the reasoning with Fitts's law and motor and touch needs, and how a visible label doubling as the control's name helps voice-control users.

for a senior

Audit a filter panel or consent row for nested targets, overlapping hit areas and labels that differ from names, and write the row spec that prevents them.

for a principal

Set one row-level target rule across web and native so product teams stop re-deciding hit areas, links in labels and info icons per screen.

## Why the label should be part of the target A **click target** (or hit area) is the region that responds to a pointer or touch. A checkbox's box is typically drawn small so it fits neatly beside text, but the **label** beside it is usually many times larger. When the label toggles the checkbox too, the target becomes the whole row. - **Fitts's law** says the time to hit a target depends on its distance and size: bigger and nearer targets are faster to acquire. A full-width row beats a small square every time. - **Touch and motor impairments.** On a phone, a thumb covers more than the box. People with tremor, or anyone using the site on a moving train, miss small targets. - **Reading and acting in one place.** People tap the words they read. A row where only the box responds produces 'nothing happened' taps on the text. - **Name and target agree.** Using the label as the control's name keeps visible text and accessible name identical, which voice-control users depend on when they say 'tap Free parking'. How that association is expressed is a platform matter. WCAG 2.2 2.5.8 Target Size (Minimum), level AA, sets a 24-by-24 minimum for pointer targets, with exceptions such as adequate spacing; a whole-row target is a straightforward way to stay well clear of that floor. ## Designing the row | Row element | Recommendation | |---|---| | **Box** | Visible, with a clear checked mark; aligned with the first line of the label | | **Label text** | Plain, concise text that names the option: 'Free parking' | | **Supporting meta** | Counts such as '(38 hotels)' can sit inside the target | | **Row hit area** | Spans box plus label, with a pressed or hover state across the whole row | | **Spacing** | Rows separated so adjacent targets do not overlap | ## Links inside labels: two targets in one row A consent row such as 'I agree to the cancellation policy', with 'cancellation policy' as a link, puts two actions in the same space: 1. A guest taps the link text to read the policy, and depending on the platform the checkbox may toggle as well, or only the link fires while the guest expected the box to check. 2. A guest taps the row to agree and lands on the policy page instead, losing their place in the booking. 3. Screen-reader users meet a link nested inside a control's name, which reads awkwardly and is easy to activate by mistake. The robust pattern is to keep the label plain, 'I agree to the cancellation policy', and put the link **outside** the target: on its own line below, as 'Read the cancellation policy', or beside the row. The same applies to info icons that open help: give them their own target, clear of the label. Where legal review insists the link stays inside the sentence, keep that sentence as helper text beside a short label such as 'I agree', so the checkbox's target and name stay free of the link. ## Other things the spec should say - Labels sit on the **same side** consistently, usually after the box in left-to-right layouts, mirrored in right-to-left. - Labels wrap onto several lines rather than truncating; the whole wrapped block remains the target. - The pressed state covers the whole row, so people can see that the text is live. - Row height grows with the platform's text-size setting instead of clipping the label. - A disabled option keeps its label readable and says why it is unavailable where possible. - Long lists of filters stay scannable: group them under a visible group label, such as 'Amenities', so each option does not have to repeat the context. ## Across platforms Native mobile settings rows commonly make the entire row the target by default, while web checkboxes only gain the label as a target when the two are associated. A design system should specify the **outcome**, the whole row toggles and nested actions live outside it, so both platforms converge on the same behaviour.

  • What if the label is long, several lines of explanatory text?
    Keep the short, decisive part as the label and move the explanation into helper text below it. The label stays the target and the control's name; the helper adds detail without making every screen-reader announcement a paragraph. The helper can still be tied to the control as its description.
  • Should a whole card of hotel details be the target for a 'Compare' checkbox on it?
    Usually not. A card typically has its own primary action, such as opening the hotel page, so making it toggle a checkbox too creates the same two-targets conflict as a link in a label. Give the checkbox its own row-sized target within the card and keep the card's main action separate.

A checkbox whose label is not clickable is like a doorbell button the size of a grain of rice beside a large nameplate: visitors keep pressing the nameplate. Making the label clickable wires the nameplate to the bell.

saying these in an interview costs you the question

  • Only the box should be clickable, so the label text can be selected and copied.
  • A link inside a checkbox label is fine because the link wins the tap.
  • The box alone is big enough if it meets the visual design grid.
  • Info icons belong inside the label so they stay close to the option.
  • Touch users are the only ones who benefit from a larger target.