Mobile Usability: Fix Viewport, Tap Targets and Readable Text

Most people meet your site on a phone. If the page renders at desktop width and shrinks, if buttons sit too close together to tap, or if the text is too small to read without pinching, they leave or make mistakes. These are mobile usability problems, and each one has a concrete fix you can check.

This guide covers the three basics: the viewport meta tag, tap targets (the buttons, links and form controls people touch) and readable, resizable text. It also covers the related problem of content that forces sideways scrolling. It is for site owners and developers who want a mobile-friendly layout and a way to prove it, without relying on a tool that no longer exists.

You will end with a short test routine for a phone, correct markup and CSS for the viewport and touch targets, and a list of what to avoid.

Before you begin

You need access to the page templates or theme CSS, a real phone, and Chrome DevTools with its device toolbar. Back up the templates and stylesheet before editing. If you use a CMS or page builder, find out which settings control the viewport tag and button sizes; some themes set them, and editing the wrong layer can be overwritten on update.

A note about tools. Google's Search Central update log records that on December 1, 2023 it removed mentions of the Mobile Friendly Test and the Mobile Usability report from its documentation, as both were going away. Older guides that tell you to open that report are out of date. Use Lighthouse, DevTools and a real device instead, and see mobile Lighthouse versus desktop for how to read a mobile run.

Also keep expectations realistic. A usable mobile page is better for visitors, and it is part of making the mobile version complete for indexing (see the mobile-first indexing checklist). It does not promise any ranking or traffic change.

Step-by-step instructions

Step 1: Set the viewport meta tag

Without a viewport tag, web.dev explains, mobile browsers render the page at a desktop width, usually around 980 pixels, so text looks tiny and people have to zoom. The recommended tag goes in the <head>:

<meta name="viewport" content="width=device-width, initial-scale=1">

width=device-width tells the page to match the screen's width in device-independent pixels. MDN notes that initial-scale can usually be left out, but that adding initial-scale=1 stops the browser from automatically zooming out when content overflows. MDN also says you should usually avoid overflowing content in the first place, which is covered in Step 4.

Then, and this matters, do not turn off zooming. Avoid user-scalable=no and low maximum-scale values. MDN warns that disabling zoom stops people with low vision from reading the page, and that WCAG requires a minimum of 2x scaling, with 5x zoom the best practice. web.dev gives the same advice: it does not recommend minimum-scale, maximum-scale or user-scalable because they can prevent zooming. MDN adds that browsers can ignore those settings and that iOS 10 and later ignores them by default, but you should not rely on that.

What success looks like: View source shows exactly one viewport tag with width=device-width, without user-scalable=no. On a phone the text is at its intended size on first load, and pinch zoom works.

Step 2: Make tap targets big enough and far enough apart

A tap target is any element a finger presses: links, buttons, form fields, menu items, close icons. web.dev says a minimum recommended touch target size is around 48 device-independent pixels, roughly 9 mm, about the size of a fingertip pad, with targets about 8 pixels apart in both directions. Its guidance assumes a properly set mobile viewport.

The accessibility standard has a lower floor. WCAG 2.2 success criterion 2.5.8 (Target Size, Minimum), at level AA, requires pointer targets of at least 24 by 24 CSS pixels, with exceptions: the spacing exception (an undersized target passes if a 24-pixel circle centered on it does not touch another target), an equivalent control elsewhere on the page, inline links within a sentence, controls the browser sets, and essential presentation. Treat 24 pixels as the least you can ship and the larger size as the better target for touch.

You do not have to make icons bigger visually. Add padding around them. web.dev's example gives links a small default padding and enlarges it for touch screens:

.nav a { padding: .2em; }

@media (any-pointer: coarse) {
  .nav a { padding: .8em; }
}

any-pointer: coarse detects touch input directly, which is more reliable than guessing from the screen width, because a fine pointer means a mouse or trackpad even on a tablet. If you size with em or rem, web.dev advises checking the computed result in DevTools.

A common fix for a row of small links is to make each link a block with padding and space the list items:

.footer-links a {
  display: inline-block;
  padding: 0.75rem 0.5rem;
}
.footer-links li { margin-bottom: 0.25rem; }

Check the real result by selecting an element in DevTools and reading its computed width and height.

What success looks like: Every button, menu item and form control measures at least 24 by 24 CSS pixels (aim for around 48 where space allows) and is not touching its neighbour.

Step 3: Keep text readable and resizable

There is no single official font size to copy, so use a size that reads comfortably on a phone without zooming and test it on a real device. A few rules are well established.

Let people enlarge text. MDN notes that WCAG requires a minimum of 2x scaling, and recommends supporting more. Scaling is mainly the browser's job, so your job is not to block it: no zoom lock in the viewport tag, and no fixed-height boxes that cut off enlarged text.
Use relative units. Set font sizes in rem or em rather than a fixed pixel value in places where people may change their text size, and let boxes grow with the text.
Control line length by layout, not by shrinking text. On a narrow screen, one column with sensible padding reads better than a scaled-down multi-column page.
Check contrast and spacing. Our accessibility audit guide covers contrast checks.

Test by raising the browser's text size or zooming to 200 percent (the 2x minimum) and scrolling through each template. Nothing important should be clipped, overlapped or hidden.

What success looks like: At 200 percent zoom, all text is still readable, nothing is cut off, and controls still work.

Step 4: Stop horizontal scrolling

web.dev says forcing people to scroll sideways or zoom out to see the whole page is a poor experience, and lists common causes.

Fixed-width images. Images wider than the viewport force sideways scrolling. The fix web.dev gives is max-width: 100% with display: block, plus width and height attributes to reserve space and avoid layout shift.
Pixel-based layouts. Fixed pixel widths overflow small screens. Use percentages, the fr unit in CSS Grid, or flexible layouts so columns narrow with the screen.
Wide tables, code blocks and embeds. Put them in a container with overflow-x: auto, so only that block scrolls and not the page.

img { max-width: 100%; height: auto; display: block; }
.table-wrap { overflow-x: auto; }

To find the culprit, load the page in the DevTools device toolbar at 320 pixels wide and look for anything past the right edge. Remove elements one at a time in the Elements panel until the sideways scroll disappears.

Responsive layouts rely on media queries, which web.dev describes as simple filters on CSS. It recommends designing for small screens first and adding breakpoints where the layout needs to change, rather than basing them on device types or brand names.

What success looks like: At 320 pixels wide there is no horizontal page scroll on any template.

Step 5: Test on real devices and in DevTools

Open the device toolbar in Chrome, choose a phone preset, and test your key templates: home page, a content page, search, forms and checkout. Then test on at least one real phone, on a slow connection if you can. Things that only show up on hardware include tap accuracy, keyboard overlap on forms and sticky headers that hide content.

If a form field is covered by the on-screen keyboard, MDN's viewport reference describes an interactive-widget key that controls how widgets such as the virtual keyboard affect the viewport; test it before using it, since its behavior differs by value.

Run Lighthouse on a mobile profile and keep the results. Our guide to Cumulative Layout Shift helps if the page moves while you try to tap.

What success looks like: You can complete the main task on each template, using one hand on a real phone, without zooming or mis-tapping.

Final verification checklist

Each page has one viewport tag with width=device-width.
The viewport tag does not disable zoom (no user-scalable=no, no low maximum-scale).
Tap targets are at least 24 by 24 CSS pixels, ideally around 48, with space between them.
Padding, not larger icons, is used to enlarge touch areas where needed.
Text is readable on a phone without zooming and can be zoomed to at least 200 percent.
No horizontal page scroll at 320 pixels wide.
Wide tables and code blocks scroll inside their own containers.
Forms are usable with the on-screen keyboard open.
You tested on a real phone as well as in DevTools.

Common mistakes to avoid

Locking zoom to keep a layout intact. It blocks people who need to enlarge text. Fix the layout instead.
Making tap targets small and tight. Mis-taps frustrate people. Add padding and spacing.
Judging target size by how an icon looks. The clickable area is what counts. Measure the element in DevTools.
Fixed pixel widths for containers. They overflow small screens. Use percentages, max-width and flexible grids.
Testing only on a desktop browser. Touch, keyboards and slow networks behave differently on a phone.
Hiding content on mobile to simplify. If the mobile page lacks content that desktop has, it can affect indexing. Collapse it instead.
Relying on retired tools. The Mobile Friendly Test and the Mobile Usability report are gone. Use Lighthouse and your own checks.

Frequently asked questions

Is there still a Google mobile-friendly test?

Google's documentation update log says it removed mentions of the Mobile Friendly Test and the Mobile Usability report on December 1, 2023, as they were going away. Use Lighthouse, DevTools and real devices to check your pages.

What size should a tap target be?

web.dev recommends around 48 device-independent pixels, with about 8 pixels between targets. WCAG 2.2 level AA sets a minimum of 24 by 24 CSS pixels, with exceptions. Aim for the larger size where the design allows.

Is `width=device-width` enough?

It is the main requirement. web.dev recommends width=device-width, initial-scale=1. Add nothing that blocks zooming.

Does mobile usability affect search?

Pages that people can use on a phone serve your visitors, and that is the reason to do the work. No guide can promise that a usability fix changes your ranking.

How do I find what causes horizontal scroll?

Set the DevTools device toolbar to 320 pixels, find content that extends beyond the right edge, and check fixed-width images, tables, long unbroken strings and embeds.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.