Touchscreen kiosk UI: why mobile touch target guidelines fall short

A kiosk or point-of-sale touchscreen UI should not be built to mobile guidelines. Apple's 44 pt, Google's 48 dp and WCAG's 24 CSS pixels are minimums for a phone held in the hand, while studies of people standing in front of a fixed screen converge on buttons of about 20 mm. On top of that, a CSS pixel on a POS monitor can be anywhere from 0.17 to 0.30 mm, so the same "44 px button" comes out between 7.5 and 13 mm depending on the terminal. Below: where the popular touch target size numbers come from, what the primary sources actually say, and which browser and Electron techniques a fixed touchscreen needs.

How a fixed touchscreen differs from a phone

Mobile guidance grew out of one scenario: the device in your hand, close to your eyes, tapped with a finger or the thumb of the same hand. A screen on a stand changes almost every condition, and nearly every change hurts accuracy.

• Unsupported arm. A phone and the finger move together; a kiosk gives the arm no support. Chourasia and colleagues (2013) found that standing users miss more often and press harder than seated users, and the difference shows up specifically on buttons smaller than 20 mm.
• Viewing angle and parallax. On a large fixed screen people see the lower and side areas at an angle. In Leahy's 1990 field experiment at a grocery store kiosk (Virginia Tech), people consistently touched below the target, more so the lower the target sat on the screen, and drifted toward the sides near the edges.
• No hover. Tooltips and hover menus don't exist on a touchscreen. Feedback has to arrive at the moment of contact.
• Speed. A cashier at rush hour hits dozens of buttons in a row without looking at each one. Errors cost money: a wrong item, a double charge, a longer queue.
• Wet fingers and gloves. Projected capacitive screens respond to conductive contact. Water droplets can register as false touches, and gloves don't always work – conductive ones do best (see, for example, Juniper Systems' guidance on capacitive touchscreens).

The main takeaway: for a kiosk, mobile numbers are a floor you must not go below, not a target.

What size should touchscreen buttons be: the guidelines

First, the official recommendations side by side. Watch the units: points, dp, effective pixels and CSS pixels are not millimetres.

The 7.5–9 mm spread across platforms makes sense: they all target a screen held in the hand. WCAG isn't about comfort at all but about a minimum threshold for people with tremor and other motor impairments; the W3C explainer for 2.5.8 explicitly recommends the stricter 2.5.5 for important controls.

Microsoft's guidance contains a point the others lack, and for a till it matters more than size: targets with costly error consequences should get more padding and sit further from the edge of the content area, especially if they are pressed often.

Where "16–20 mm from the MIT Touch Lab" comes from

This number has circulated through touch target articles since 2012. Smashing Magazine and NN/g both say an MIT Touch Lab study found the average adult index finger pad to be 16–20 mm wide, and derive a button size from it. Both point to the same paper: Dandekar, Raju and Srinivasan, "3-D finite-element models of human and monkey fingertips to investigate the mechanics of tactile sense", Journal of Biomechanical Engineering, 2003.

Judging by its title and journal, that paper builds finite-element models of human and monkey fingertips to study the mechanics of touch perception. It is not about touchscreens or buttons. I could not open the PDF on the lab's site, so I couldn't check how the 16–20 mm figure appears there. Either way, it is an anatomical finger dimension, not the result of a target acquisition experiment.

Finger width is a poor basis for button size anyway. Holz and Baudisch (CHI 2010) showed that about two thirds of the touch inaccuracy usually blamed on the "fat finger problem" is explained by systematic offsets: each user and each finger posture produce their own consistent offset between where the user aimed and where the screen registers the touch. The finger doesn't "cover" the target, it lands on it with a shift. A target has to be large enough to absorb that shift, and that's something you determine by experiment, not with a ruler on a finger.

What the studies behind the guidelines measured

The most-cited paper is Parhi, Karlson and Bederson, MobileHCI 2006. NN/g names it as the basis of its 1 cm rule, and the W3C explainer for 2.5.8 links to it. Conditions: one hand, thumb, a small touchscreen device. For single taps, error rates stopped improving significantly at 9.6 mm and above; for serial taps, at 7.7 mm and above. The authors' final recommendation was 9.2 mm for discrete and 9.6 mm for serial tasks.

It's good work – about phones. Fixed screens have their own data.

Touch target size for kiosks and POS terminals: standing studies

Colle and Hiszem (Ergonomics, 2004) had 20 participants stand at a capacitive touchscreen kiosk and enter 1, 4 or 10 digits on an on-screen numeric keypad. Keys were 10, 15, 20 and 25 mm with 1 or 3 mm spacing. Smaller keys meant longer entry times and more errors, but there was no significant difference between 20 and 25 mm. Participants preferred 20 mm to all smaller sizes and were indifferent between 20 and 25 mm. Spacing of 1 vs 3 mm had no measurable effect.

Chourasia, Wiegmann, Chen, Irwin and Sesto (Human Factors, 2013) compared sitting and standing with 15 participants with motor-control disabilities and 15 without. Buttons ranged from 10 to 30 mm in 5 mm steps, with 3 or 5 mm gaps. Standing participants missed more and took longer, but only on buttons under 20 mm; at larger sizes posture made little difference. They also pressed harder while standing.

In a related study by the same group (Chen et al., Applied Ergonomics, 2013; 38 participants with motor-control disabilities and 15 without), gap size also didn't affect performance.

For kiosks and tills, the working target is about 20 mm per side for frequently used buttons. When space is tight, spend it on bigger buttons rather than bigger gaps: in both experiments a few extra millimetres of gap bought nothing, while size did.

Limits of this evidence: numeric keypads, lab conditions, small samples. I couldn't find studies of real cashiers at rush hour. But the direction of the error is clear: haste, fatigue and wet hands make conditions worse than the lab, not better.

How many millimetres is a CSS pixel on your terminal

This is what touch target size articles usually skip. WCAG defines the CSS pixel as a visual angle of about 0.0213 degrees, based on the CSS reference pixel: 1/96 inch, about 0.26 mm, viewed at arm's length. But the browser and OS don't know how far the user stands or the panel's real dimensions. In practice, on a desktop-class monitor a CSS pixel is a device pixel multiplied by the OS scaling factor.

So "a 44 px button" on a till is not a size. I calculated the physical size of a CSS pixel for several common POS monitor diagonals and resolutions at 100% OS scaling (devicePixelRatio = 1): density is the diagonal in pixels divided by the diagonal in inches; pixel size is 25.4 mm divided by density.

My own calculation, ignoring bezels and non-square pixels. At 125% OS scaling, multiply every millimetre value by 1.25: 44 px on a 15.6″ Full HD screen becomes 9.9 mm.

What follows from this:

• Define button size as a token derived from the real screen. With a uniform fleet, one value checked with a ruler on a real device is enough. With mixed hardware, tie the base size to the monitor model or OS scaling.
• The same build can get worse on a new monitor. Swapping a 15″ 1024×768 screen for a 15.6″ Full HD one shrinks every button by a factor of 1.65 without a single code change.
• The mobile minimum of 44–48 px on a Full HD till is 8–9 mm – half of what the standing studies suggest.

CSS mm and cm units don't solve this: the spec ties them to the pixel (1 inch = 96 px), so 20mm in your stylesheet is 75.6 CSS px, not 20 real millimetres on the glass.

Techniques for the browser and Electron

The 300 ms delay and double-tap

Mobile browsers used to wait 300–350 ms after a tap to see whether a second tap for zoom would follow. According to the Chrome team, since Chrome 32 (2014) that delay is gone on pages with <meta name="viewport" content="width=device-width">, and Firefox, Edge and Safari on iOS 9.3 followed. touch-action: manipulation achieves the same per element: per MDN it allows panning and pinch zoom but disables non-standard gestures like double-tap to zoom, and it is an alias for pan-x pan-y pinch-zoom.

Electron adds a detail: visual (pinch) zoom is disabled by default and must be enabled explicitly via setVisualZoomLevelLimits. For a till that's usually what you want – an accidental two-finger gesture won't zoom the UI mid-order. For a kiosk with text people need to read, decide deliberately whether zoom should be available.

touch-action: none only where you handle the gesture yourself

touch-action: none disables all browser panning and zooming on the element. Use it on surfaces where your code handles gestures: a signature pad, a slider, drag-to-reorder. MDN warns that it can prevent low-vision users from zooming and recommends narrower values such as pan-y when you only need to take over a horizontal gesture. Set it up front: changing touch-action after a gesture starts has no effect on that gesture.

Pointer Events instead of separate mouse and touch handling

Pointer Events give one event model for finger, pen and mouse, with the device type in pointerType. That helps on a till, where someone may plug in a mouse, for example for maintenance.

Mind pointercancel. Per MDN, the browser fires it when it decides no more pointer events are coming: it started panning or zooming, palm rejection kicked in, the screen orientation changed, or there were too many simultaneous touches. It is followed by pointerout and pointerleave, but not pointerup. A button that enters its pressed state on pointerdown and leaves it only on pointerup can get stuck pressed forever. Reset state on pointercancel too.

Don't detect touchscreens with pointer: coarse

The pointer and hover media features describe only the primary input as chosen by the browser. As Patrick Lauke shows on CSS-Tricks, on a laptop or all-in-one with a touchscreen the trackpad or mouse is usually primary, so pointer: coarse is false even while the user is jabbing the screen. any-pointer: coarse is more reliable: it's true if any available input is coarse. And for a terminal whose touchscreen is the only standard input, it's simpler not to adapt via media queries at all and always design for the finger.

Guard against double submission

An unsupported arm and the harder presses of standing users (the Chourasia finding) produce bounce: two touches instead of one. A double tap on "Pay" or "Add" isn't a zoom, it's a second order. The minimum:

• disable the button immediately after the first activation and re-enable it on the server response, not on a timer;
• send an idempotency key with payment and receipt requests so the server can recognise a retry even if the client sent it twice;
• treat the same item added twice within a fraction of a second as a reason for explicit feedback ("×2"), not a silent duplicate.

Feedback without hover

With no hover, the "you pressed me" state has to appear on contact and be visible around the finger: a change in the whole button's background, not a thin outline the finger hides. Trigger the action on release so the user can slide off and change their mind. The exception is digit keys, where speed matters and errors are cheap to fix.

Screen layout: where to put what matters

Leahy's finding that touches drift downward and toward the edges gives a simple rule for large screens: put the most frequent and most error-costly actions closer to the centre and away from the bottom edge. It matches Microsoft's advice to keep high-consequence targets away from the edge.

Three more rules that follow from the above:

• Keep dangerous actions away from frequent ones. "Cancel order" should not sit right next to "Add". Per the experiments, a 1–3 mm gap doesn't help; a button's width of distance or the opposite side of the screen does.
• Non-standard gestures only with a button fallback. Swipe to delete, long press and two-finger gestures aren't discoverable without training. On a till every function should be reachable with a plain tap.
• Extend small elements with an invisible hit area. An icon can look small, but its touch area should match your base size. Material and Android describe exactly this: a 24 dp icon with a 48 dp touch target.

What this looks like in a real terminal

I designed in Figma and built the barista terminal on Electron that runs in 210 coffee shops of a chain, along with a separate UI library with design tokens on CSS custom properties and component variants. That combination is what makes the calculation above practical: if the base button size lives in a token, a new monitor model means changing one value instead of a hundred components.

The other property of a chain of locations is updates. The terminal at every coffee shop updates itself without staff involvement, so every UI change reaches all baristas at once. A wrong button size or placement doesn't stay in one shop; it ships to the whole network. One more reason to check sizes with a ruler on the real monitor before release, not in a developer's browser.

Key takeaways

• Mobile guidelines (44 pt, 48 dp, 7.5 mm, WCAG's 24 and 44 CSS px) are minimums for a handheld phone. For a screen on a stand, standing-user studies point to keys of about 20 mm.
• "16–20 mm according to MIT" is a finger width from a paper on fingertip models, not a button experiment. Touch inaccuracy comes mostly from systematic offset, not finger size.
• A CSS pixel on a POS monitor ranges from 0.17 to 0.30 mm. Convert your buttons to millimetres for every monitor in the fleet and drive the base size from one token.
• In the browser and Electron: touch-action: manipulation on buttons, touch-action: none only on surfaces with custom gestures, Pointer Events with pointercancel handling, any-pointer instead of pointer.
• Disable the button until the server responds and send an idempotency key: double touches while standing are normal.
• Keep frequent and dangerous actions near the centre and far from each other: a couple of extra millimetres of gap doesn't help, size and distance do.