Tap Targets, Font Sizes and Mobile Layouts

The thumb is not a cursor

A mouse pointer is thin and exact. A fingertip is broad and covers the thing it presses. Designs that work perfectly with a cursor often fall apart on a touch screen: small links packed together, tiny text, menus that need hover, and wide content that spills sideways. The checks below address the most common mobile frustrations.

Tap targets

A tap target is anything a visitor can press: links, buttons, menu items, form fields, icons, checkboxes. When targets are too small or too close together, people hit the wrong one, and mistaps feel like a broken site.

Commonly cited guidance suggests targets of roughly 44 to 48 CSS pixels square, with some breathing room around them. Different guidelines give slightly different numbers, and a stricter minimum exists in some standards, so treat these as sensible rules of thumb, not hard laws. What matters in practice:

• Size. Make the clickable area large, even if the visible icon is small. Padding can enlarge the tap area without changing the look.
• Spacing. Leave a gap between adjacent targets. Two small links in the same line of text, or a row of closely packed icons, are common trouble spots.
• Distance from the edge. Targets crammed against the screen edge can be hard to reach or may trigger system gestures.
• Text links in paragraphs. A line of text with a link in it is difficult to hit precisely when lines are tight. Adequate line height helps, and so does avoiding stacked links on consecutive lines.
• Lists of links. Footer or sidebar link lists that fit many items into a small space are the classic offender. Add vertical padding.

Test by using your own thumb on a real phone, one-handed. If you ever have to retry a tap, note where it happened.

Font sizes

Body text that is too small makes people zoom, and zooming creates its own problems, such as sideways scrolling to follow each line. A base body size of about 16 CSS pixels is a common starting point on phones, with secondary text such as captions and metadata not dropping much below roughly 12 to 14 pixels. These are guidelines, not rules, and typefaces differ: some look smaller at the same nominal size.

Things to review:

• Relative units. Sizing in relative units respects the reader’s browser text-size settings, while fixed pixel sizes can override them. Accessible design generally lets people scale text.
• Line height. Slightly generous spacing between lines, often around 1.4 to 1.6 times the text size for body text, tends to improve readability.
• Line length. On a narrow screen, line length often takes care of itself, but check that it does not become too short and choppy, with one or two words per line.
• Contrast and weight. Small, thin, light text is the hardest combination. See color contrast for evaluating it.
• Form text size. Very small text inside input fields can make some phones zoom automatically on focus, as noted in mobile forms.
• Headings. Large desktop headings can wrap awkwardly or take up half the screen on a phone. Scale them down and keep the hierarchy clear, consistent with heading structure.

Readable wording matters as well as readable type. Shorter sentences and clear paragraphs help on small screens, a theme covered in plain language.

The viewport setting

For a page to render at phone width, it normally needs a viewport declaration in its head telling the browser to match the device width. Without it, many phones render a desktop-width page shrunk to fit, which makes everything minuscule. This is a quick check in the page source, and it is easy to fix. Absence of it is a strong sign of an unprepared page.

Layout checks

Good phone layouts tend to share a few traits:

• No horizontal scrolling. A page should fit the width. Common causes of overflow are fixed-width images, wide tables, embedded media, long unbroken text such as URLs, and elements with fixed pixel widths.
• Single column flow. On small screens, stacking content in a single column is usually clearer than trying to preserve side-by-side arrangements.
• Tables handled deliberately. Wide tables can scroll within their own container, or be reorganized into stacked rows. Letting them push the whole page sideways is the worst option.
• Images that scale. Images should shrink to fit and not be larger in file size than necessary. See image optimization for size considerations.
• Menus that collapse sensibly. The collapsed menu button should be large enough to tap and clearly labeled, and the opened menu should be easy to operate. Navigation patterns are discussed in breadcrumb navigation.
• Sticky elements used sparingly. Fixed headers, footers and floating buttons use up precious vertical space and may cover content or links, especially when the on-screen keyboard is open or the phone is in landscape.
• Stable layout. Content that jumps while loading, because an image or banner arrives late, causes mistaps. This is part of the layout shift measure in core web vitals.
• Important content early. Make sure the main content, not an enormous banner, appears first on the screen.

A simple test routine

1. Open a key page on a real phone in portrait orientation. Do not zoom. Can you read the body text comfortably?
2. Scroll the whole page. Is there any sideways movement?
3. Tap every link and button in the first screen or two. Count the mistaps.
4. Open menus, accordions and search. Are they easy to operate and close?
5. Rotate to landscape and repeat the quick look.
6. Increase the system text size and check that nothing breaks.
7. Repeat on a smaller and a larger phone if possible.

If you do not have many devices, use the narrow-window mode in a desktop browser’s developer tools as a rough stand-in, then confirm on a real phone. More about building a routine is in device testing.

Prioritize and recheck

Fix the issues that block tasks first: unreachable buttons, unreadable text, overflow that hides content. Then deal with comfort issues. Search engines have offered mobile usability reports at various times, and the specific reports and thresholds change, so use any such report as a prompt to look, not as a final verdict. Recheck after template changes, new plugins or banners, because they are frequent sources of new layout problems. No ranking outcome is promised, but a page that can be read and tapped without effort is a better page.