Kofi sells coffee and Ghanaian pastries from a cargo bike in Rotterdam. Regulars pre-order on his website so their flat white is waiting when they pass.
A customer stands at a tram stop in the rain. Umbrella in her left hand, phone in her right. She opens the order page with her thumb. The pickup times are a grid of tiny boxes: 7:30, 7:45, 8:00, packed together like a spreadsheet. She aims for 8:00 and gets 7:45. She tries to zoom in. The page will not zoom.
The phone number field opens a full alphabet keyboard, so she hunts for the digits. The "Order" button sits in the top-left corner, as far from her thumb as the screen allows. Her tram arrives. She will buy coffee at the station instead.
Kofi and his customer are imagined. The research, standards and laws below are real.
Nothing on Kofi's page was broken. It was designed on a large monitor, with a mouse, by someone sitting down. His customers meet it standing up, in weather, with one thumb. This chapter is about closing that gap.
Most visits are phones
According to StatCounter, phones accounted for 58.99% of worldwide web page views in September 2026, against 39.26% for desktop and 1.76% for tablets. In Europe, the mobile share for the same month was 55.41%.
Those are averages across all kinds of sites, measured by page views. Your own split may be very different. A B2B software company may see mostly desktop traffic during office hours. A café, a hairdresser or a local plumber may see 80% phones. Open your analytics and look at your own number before you decide anything.
Search engines settled the question for everyone else. Google announced in October 2023 that its move to mobile-first indexing was essentially complete: it uses the mobile version of your pages, crawled as a smartphone, to index and rank them. In a June 2024 follow-up, it said the last sites still crawled by its desktop crawler would move to the smartphone crawler after 5 July 2024, and that content not accessible on mobile would no longer be indexable.
In practice, your mobile page is your page as far as Google is concerned. If something exists only in the desktop layout, assume it does not exist.
What to do: check the device split in your analytics. Then review your site on a real phone, standing up, one-handed, before you ever look at it on a laptop.
How people hold phones
The most quoted study on this is refreshingly low-tech. Over two months ending in January 2013, mobile designer Steven Hoober and a few colleagues watched people using phones in public: on streets, at bus stops, in airports, cafés and on trains. They noted how each person was holding the device. He published the results in UXmatters.
They logged 1,333 observations. Of those, 780 people were actually touching the screen; the rest were talking, listening or just looking.
Among one-handed users, 67% used the right thumb and 33% the left, a split Hoober himself found surprising, since only around a tenth of people are left-handed. People also switched grips constantly, sometimes every few seconds, depending on what they were doing.
That last finding matters more than the percentages. There is no single "mobile user grip" to design for. The same person reads one-handed, cradles the phone to type, and turns it sideways to watch a video. The observations come from phones of late 2012, the largest being a Samsung Galaxy Note 2, and from public places only, without notes on what people were doing. Phones have grown since. Treat the numbers as a picture of variety, not a fixed ratio.
What to do: make every important control usable with a thumb from either hand. Avoid designs that only work when held one particular way.
The thumb zone, revised
From the 2013 study came the famous "thumb zone" charts: a phone with a green arc in the lower area where the thumb rests comfortably, yellow above it, and red in the far corners. They spread across countless design blogs, often with the advice to put everything important at the bottom.
Hoober kept researching, and in 2017 he publicly revised the picture. In "Design for Fingers, Touch, and People", drawing on over 1,300 public observations across several countries plus 651 more in schools, offices and homes, he called the common thumb-sweep chart incorrect. People shift their grip to reach. They tap the top of the screen all the time.
His main finding: people prefer to look at and touch the center of the screen. And they are more accurate there. In his data, targets near the center could be as small as about 7 mm and still catch 95% of taps, while targets in the corners needed about 12 mm.
This does not mean the bottom of the screen is useless. A sticky "Order" or "Call" bar at the bottom is easy to reach and easy to find. It means the corners are the hardest places for both reach and accuracy, and the center is the best real estate on the page, for content and for taps.
What to do: keep primary content and the main action near the middle of the screen as people scroll. Give anything in a corner, like a close icon or a menu button, a generous tap area.
Fitts's law on glass
The time to hit a target grows with its distance (D) and shrinks with its width (W). Fitts had people tap a stylus back and forth between two plates as fast as they could, crossing four distances with four target widths, and found movement time rose steadily with the logarithm of distance over width. The form above is the "Shannon formulation" that Scott MacKenzie argued for in 1992; it is the version most HCI researchers use today.
In plain words: big and close is fast. Small and far is slow. Doubling a button's width buys about the same speed as halving the distance to it. And the speed-up flattens: going from tiny to normal helps a lot, from big to huge helps little.
Fingers add a twist that a stylus or mouse does not have. A fingertip is wide and soft, it covers the very thing you are aiming at, and the phone guesses a single point from a smudge of contact. In 2013, Xiaojun Bi, Yang Li and Shumin Zhai of Google published "FFitts law", which models finger touch as two kinds of error: the normal speed–accuracy trade-off, plus a fixed imprecision of the finger that does not go away however slowly you tap. Their model fitted touch data better than classic Fitts.
That fixed imprecision is why small targets on phones do not just slow people down. They cause wrong taps, like the 7:45 pickup that should have been 8:00. On a desktop, a small link costs a moment. On a phone, it can cost an order.
Tap or click the dot as fast as you can. Ten dots per round. Try a round with small 24 px targets, then large 48 px ones, and compare time and misses. Works best with a finger on a phone.
Press a start button. This demo needs JavaScript.
| Targets | Average time per dot | Misses |
|---|---|---|
| Small, 24 px | – | – |
| Large, 48 px | – | – |
A toy, not a study: distances are random and your device, hand and patience all count. Keyboard users can play with Tab and Enter, but that measures something other than pointing.
What to do: make the main action big and put it where the thumb already is, in the flow of the content or in a bottom bar. Do not make people travel to a corner for the most important button on the page.
How big should a tap target be?
Here the research, the platform makers and the accessibility standard give different numbers, because they answer different questions.
The research. In 2006, Pekka Parhi, Amy Karlson and Benjamin Bederson at the University of Maryland tested target sizes for one-handed thumb use. They concluded that 9.2 mm was large enough for single taps and 9.6 mm for sequences of taps, such as typing a number, without hurting performance or preference. Hoober's later field data suggests about 7 mm can work in the center and about 12 mm is needed at the edges.
You will also often read that "the average fingertip is 8–10 mm wide, according to MIT's Touch Lab". That figure usually traces back to a 2003 MIT paper modelling the mechanics of fingertips for touch sensation, not touchscreen tapping. We could not confirm the number in the original, so we leave it out. The tapping studies above are the better guide anyway.
The platforms. Apple's Human Interface Guidelines give a default control size of 44×44 points on iOS and iPadOS, with 28×28 points as the minimum, and suggest about 12 points of padding around bezeled controls and about 24 around controls without a visible edge. Google's Android accessibility guidance, based on Material Design, recommends targets of at least 48×48 dp with 8 dp between them, which it notes is about 9 mm whatever the screen.
The standard. WCAG 2.2 has two criteria. 2.5.8 Target Size (Minimum), new at Level AA, requires pointer targets of at least 24×24 CSS pixels, with exceptions. 2.5.5 Target Size (Enhanced), Level AAA, asks for 44×44.
Notice what WCAG's 24 pixels is: a floor, not a goal. A CSS pixel on a phone is roughly the size Apple calls a point, so 24 px is a bit over half of Apple's default 44. It is the minimum below which a control fails accessibility at AA; it is not what a comfortable button looks like. For anything people tap often, such as buttons, form controls and menu items, aim for 44 to 48 px.
Spacing beats squeezing
Size is half the story. The other half is the gap between targets, because a slightly off tap that lands on empty space does nothing, while one that lands on a neighbour does the wrong thing.
WCAG 2.5.8 builds this in. Its spacing exception lets a target be smaller than 24×24 if a 24 px circle centred on it does not intersect any other target or another small target's circle. In other words, small is allowed if it has room around it. There are also exceptions for links inside a sentence of text, for an equivalent larger control elsewhere on the page, for controls the browser draws and you have not restyled, and for cases where the small size is essential or legally required.
Pick a pickup time
About 20 px tall, 1 px apart. A wrong tap selects the neighbour.
Pick a pickup time
48 px tall, 8 px gaps, fewer times on screen with "later times" below.
What to do: check every tappable thing on your phone layout. Buttons and form fields: 44–48 px tall. Small icons: pad the tap area to at least 44 px even if the icon is 24. Footer and inline link lists: give them line height and gaps so neighbours do not touch.
Summon the right keyboard
On a phone, every form field comes with a keyboard, and the page decides which one. Get it wrong and you make people hunt for the @ sign or switch to the number row for every digit. Get it right and the phone does half the work.
Three HTML attributes do almost everything:
type says what the data is. type="email" brings up a keyboard with @ and a dot; type="tel" brings up a phone dial pad. inputmode picks a keyboard without changing validation: inputmode="numeric" gives digits only, useful for a postcode or a one-time code. autocomplete tells the browser what to fill in from the person's saved details: name, email, tel, postal-code, one-time-code and more.
| Field | Attributes | Why |
|---|---|---|
| Name | type="text" autocomplete="name" | One tap to fill from saved details. |
type="email" autocomplete="email" | @ and dot on the first keyboard screen. | |
| Phone | type="tel" autocomplete="tel" | Dial pad, and the saved number. |
| Postcode | autocomplete="postal-code", plus inputmode="numeric" only if all your postcodes are digits | Dutch and UK postcodes contain letters; German and Hungarian ones do not. |
| SMS code | inputmode="numeric" autocomplete="one-time-code" | Digits pad, and many phones offer the code from the message. |
| Quantity | inputmode="numeric" | Digits without the fiddly spinner arrows of type="number". |
The autocomplete attribute is also an accessibility requirement. WCAG 1.3.5 Identify Input Purpose, Level AA, asks that fields collecting information about the user have a purpose that software can determine. Using the standard autocomplete values is how you meet it, and it helps people with memory or motor impairments most. The lead forms chapter covers which fields to ask for at all.
What to do: open each form on your phone. For every field, check that the keyboard fits the data and that the browser offers to fill it. Add the missing type, inputmode and autocomplete attributes.
Never lock the zoom
Kofi's customer tried to pinch-zoom and could not. Somewhere in the page's code was a line like this:
<!-- Don't do this -->
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">Designers add it to stop layouts wobbling or inputs zooming on focus. The cost is that anyone with low vision, tired eyes or a cracked screen loses their main tool. The widely used axe accessibility checker flags it as a failure of WCAG 1.4.4 Resize Text if user-scalable=no is present or maximum-scale is below 2. Some mobile browsers ignore the instruction, but you cannot count on all of them doing so.
The safe line is short:
<meta name="viewport" content="width=device-width, initial-scale=1">Two WCAG criteria describe what the page must survive. 1.4.4 Resize Text (AA): text can be enlarged to 200% without losing content or function. 1.4.10 Reflow (AA): content works at a width equal to 320 CSS pixels without scrolling in two directions. That is the width of a small phone, and also what a 1,280 px desktop window becomes at 400% zoom. If your layout works at 320 px with no sideways scroll, you have made life easier for small phones and zoomed desktops at the same time.
If form fields zoom in when tapped on iPhone, the usual cause is text smaller than 16 px in the input. Fix the font size, not the viewport.
What to do: search your code for user-scalable and maximum-scale and remove them. Set input text to at least 16 px. Shrink your browser window to 320 px wide and fix anything that scrolls sideways.
The EAA makes it law
Since 28 June 2025, accessibility on mobile is not only good practice in the EU. It is a legal requirement for a large share of businesses that sell online.
The Act covers e-commerce services provided to consumers (Art. 2(2)(f)), defined as services provided at a distance through websites and mobile device-based services (Art. 3(30)). National laws apply from 28 June 2025 (Art. 31). Microenterprises providing services, meaning fewer than 10 employees and annual turnover or balance sheet of no more than €2 million, are exempt (Art. 4(5), Art. 3(23)). Penalties are set by each country and must be effective, proportionate and dissuasive (Art. 30).
Source: EUR-Lex, Directive (EU) 2019/882. General information, not legal advice. National transpositions differ; check your own country's law.
In practice, compliance is measured against the European standard EN 301 549. The version in use since 2021, V3.2.1, references WCAG 2.1 Level A and AA. That version does not include the new 24 px target size criterion, which arrived in WCAG 2.2. EN 301 549 V4.1.1, published on 2 September 2026, moves to WCAG 2.2 Level A and AA, and becomes the presumption-of-conformity benchmark once it is cited in the EU's Official Journal. Plan for 2.2 now; it is where the rules are heading.
Everything else in this chapter, zoom, reflow, input purpose, already sits in WCAG 2.1 AA. If you sell to consumers in the EU and you are not a microenterprise, those are not nice-to-haves. Even if you are exempt, your customers are not exempt from small screens and shaky thumbs. The accessibility chapter goes deeper on scope and what an audit involves.
What to do: if you sell online in the EU, check whether you fall under the EAA. Either way, test against WCAG 2.2 AA so you are ready when the new standard is cited.
What to change tomorrow
Look at your own device split
Open analytics, find the phone share, and review the site on a real phone, standing, one-handed.
Keep the action near the thumb
Main button in the flow of content or a bottom bar. Nothing essential only in a top corner.
Size targets at 44–48 px
Treat 24 px as the legal floor, not the goal. Pad small icons. Use the center for anything precise.
Space neighbours apart
Give adjacent buttons and links at least 8 px of gap so a near miss lands on nothing.
Fix every form keyboard
Correct
type,inputmodeandautocompleteon every field; inputs at 16 px or larger.Unlock zoom and test reflow
Remove
user-scalable=noand lowmaximum-scale. Check the page at 320 px with no sideways scroll.Check your EAA status
If you sell to EU consumers and are not a microenterprise, test against WCAG 2.1 AA now and 2.2 AA next.
Kofi's fix took an afternoon: bigger time slots with room between them, a dial pad for the phone number, an "Order" bar at the bottom, and one deleted line in the page header. The customer at the tram stop still has an umbrella in one hand. Now she only needs the other.
What the research supports
Strong: Fitts's law (big and close is faster) is one of the most replicated findings in human–computer interaction, and finger touch adds imprecision on top. Solid: Parhi et al.'s 9.2–9.6 mm for thumb taps; platform guidance converges on roughly 9 mm. Observational, not experimental: Hoober's grip counts and his center-accuracy findings. Weak or unverified: the "8–10 mm fingertip" figure, and rigid thumb-zone charts. Legal requirements under WCAG and the EAA are clear; the shift to WCAG 2.2 under EN 301 549 is published but awaiting official citation.
Sources
- Fitts, P. M. (1954). The information capacity of the human motor system in controlling the amplitude of movement. Journal of Experimental Psychology, 47(6), 381–391. Consulted with MacKenzie's description of the tapping experiments.
- MacKenzie, I. S. (1992). Fitts' law as a research and design tool in human-computer interaction. Human–Computer Interaction, 7(1), 91–139. Author's copy consulted for the Shannon formulation.
- Bi, X., Li, Y. & Zhai, S. (2013). FFitts law: modeling finger touch with Fitts' law. CHI 2013, 1363–1372. Consulted for the dual-distribution model.
- Parhi, P., Karlson, A. K. & Bederson, B. B. (2006). Target size study for one-handed thumb use on small touchscreen devices. MobileHCI 2006, 203–210. Abstract consulted for the 9.2 mm and 9.6 mm recommendations.
- Hoober, S. (2013). How do users really hold mobile devices? UXmatters. Consulted for method, counts, grip shares and caveats.
- Hoober, S. (2017). Design for fingers, touch, and people, Part 1. UXmatters. Consulted for the center preference and 7 mm / 12 mm accuracy findings.
- StatCounter Global Stats. Desktop vs mobile vs tablet market share worldwide and Europe. September 2026 figures consulted.
- Google Search Central (2023). Mobile-first indexing has landed; (2024) Mobile-indexing vLast final final. Consulted for completion and the 5 July 2024 switch.
- Apple. Human Interface Guidelines: Accessibility. Consulted for default and minimum control sizes and padding.
- Google. Touch target size (Android Accessibility Help). Consulted for 48 dp, 8 dp spacing and the ~9 mm equivalent.
- W3C (2024). WCAG 2.2. Consulted for 1.3.5, 1.4.4, 1.4.10, 2.5.5 and 2.5.8 including exceptions.
- Deque. axe rule: meta-viewport. Consulted for the zoom-blocking failure conditions.
- European Union. Directive (EU) 2019/882 (European Accessibility Act). EUR-Lex text consulted for Arts. 2, 3, 4, 30, 31 and 32.
- Davis Wright Tremaine (2026). New technical standard for European Accessibility Act compliance released. Consulted for EN 301 549 V4.1.1 publication and status.
Sources checked 18 October 2026. We could not verify the widely repeated "average fingertip 8–10 mm (MIT Touch Lab)" claim in its original source and left it out of the advice. Kofi, his customer and the pickers are fictional; all figures are original illustrations.