Mobile First in 2026: What to Check in Design, Forms and Brief

Mobile First is a working order: you design the narrow screen, the thumb and the weaker processor first, then widen the layout for tablets and desktops. One detail often gets lost: worldwide phones lead, but Ukrainian statistics tell a different story. Below: how to judge what the mobile version means for your own site, what Google asks for, and what to check before launch.

≈ 59 %

of worldwide traffic is mobile

September 2026

≈ 32 %

of traffic in Ukraine is mobile

the rest is mostly desktop

24 × 24 px

minimum target size in WCAG 2.2 (AA)

web.dev suggests about 48 px

How many of your visitors are on phones

According to Statcounter, mobile devices accounted for about 59 % of worldwide traffic in September 2026. For Ukraine the same service shows about 32 %, with desktop making up most of the rest. We will not guess at the reason: Statcounter’s sample may differ from the audience of a particular business. The takeaway for an owner is simple: do not assume, check your own analytics.

In practice we suggest three steps:

• split traffic and leads by device category in GA4 and compare the share of leads each device produces, not just sessions;
• look at paid clicks separately in the ad account, since the ad audience can differ a lot from organic visitors;
• watch conversion: many mobile visits and few mobile leads almost always point to usability, not to the audience.

Even a third of visits is every third potential customer, and a person on a phone usually wants something specific: a number, an address, a price. If that takes more than a couple of taps, they go to a competitor.

Mobile First vs a responsive site

A responsive layout adapts to the viewport width through a fluid grid, media queries and scalable type. A site can be responsive and still be desktop-first: the full desktop design comes first and is then squeezed onto a phone.

Mobile First is about order: base styles target the narrow screen, and @media (min-width: …) rules add layout for wider ones. You get less unused CSS on phones and a clearer content priority.

The technical foundation is the viewport tag. Without <meta name="viewport" content="width=device-width">, some mobile browsers render the page in a virtual viewport wider than the screen (MDN gives 980 px as an example) and then shrink the result. Your media queries for narrow screens never fire.

The opposite mistake is disabling zoom with user-scalable=no. MDN warns that it hurts people with low vision, and WCAG expects content to scale at least twice. Browsers often ignore it anyway; iOS has by default since version 10.

What Google asks of the mobile version

Google indexes and ranks a site using its mobile version. The documentation lists concrete requirements, and sites with a stripped-down mobile version trip over them most often:

• the primary content on mobile must be equivalent to desktop; with less content, Google warns of possible traffic loss;
• the same structured data, title, description, robots meta tags and image alt text;
• do not load primary content only after a user action such as a swipe, click or typing, because Google will not load it;
• accordions and tabs on mobile are fine, as long as the content is equivalent to desktop.

That last point defuses a common worry. Collapsing long text into an accordion is acceptable; trouble starts when a block disappears from the phone version entirely. This is our reading, but it follows the documentation’s wording. Speed and Core Web Vitals deserve a separate article.

Touch targets: sizes people do not miss

A touch target is anything a finger presses: a button, menu item, icon or checkbox. The two documents differ, and it helps to know both:

Source	Target size	Note
WCAG 2.2, criterion 2.5.8 (level AA)	at least 24 × 24 CSS pixels	exceptions: enough spacing, links inside text, an equivalent control
web.dev recommendation	about 48 × 48 px (roughly 9 mm)	about 8 px between targets

You do not have to enlarge the icon itself. Web.dev suggests adding padding so the tap area grows to 48 px while the icon stays at, say, 24 px, and limiting the larger area to touch devices with @media (any-pointer: coarse).

Our advice: start with what gets pressed most: the call button, menu items, the modal close icon, messenger icons in the header and footer, form checkboxes. Small targets hurt leads most there.

Forms: where mobile sites lose most leads

On a phone the form is where ad spend is won or wasted. The web.dev guidance boils down to a few rules:

• every field has a label, not just a hint inside the field;
• correct type and autocomplete values so the browser can autofill; for numbers nobody increments (a card number, for instance), avoid type="number" and use a text field with inputmode="numeric";
• disable the submit button after a tap to avoid duplicate leads;
• validate while the user types and ask only for data you need, with a name in a single field.

For small businesses in Ukraine we would add: type="tel" for the phone, an input mask that survives pasting a number, and an alternative for people who dislike forms, such as a one-tap call and a messenger button.

Modern CSS: fewer breakpoints, more flexibility

A dozen magic widths in your media queries signal weak layout work. Choose breakpoints by content, where a line gets too long or a grid breaks, not by device names. Two techniques help:

• container queries (@container) change a component by its container’s width rather than the window’s, so a card behaves the same in a narrow sidebar and in a full-width row;
• svh and dvh units account for the browser bar that hides while scrolling, so a full-screen block is not eaten by the address bar.

Common mistakes

• Treating mobile as scaled-down desktop: unreadable text, forms spilling off the screen.
• Hover as the only way to open a menu or hint: touch screens have no hover.
• A full-screen pop-up right on arrival, before the visitor has seen the page.

How to check the mobile version before launch

1. 1
   Content and priorities
   what a visitor must see first on a narrow screen
   ↓ →
2. 2
   Base styles
   a narrow-screen layout without media queries
   ↓ →
3. 3
   Expansion
   tablet and desktop through min-width
   ↓ →
4. 4
   DevTools test
   device mode with network and CPU throttling
   ↓ →
5. 5
   Real phones
   Android, iPhone and at least one older device

Diagram is the author’s; testing steps follow Chrome for Developers documentation

Device mode in Chrome DevTools shows the screen size and can throttle the network and CPU, with a Mid-tier mobile preset (fast 3G, CPU 4 times slower) and a Low-end mobile preset (slow 3G, 6 times slower). The documentation calls it a first-order approximation: your code does not run on a real phone, so do the final check on actual devices.

A short acceptance checklist:

1. No horizontal scrolling on a narrow screen (aim for roughly 320 to 360 px).
2. Every button and link is easy to hit with a thumb.
3. The form works with the on-screen keyboard open, and the field does not hide under it.
4. A call and a messenger are one tap away.
5. Zoom is not disabled, and the mobile version carries the same primary content as desktop.

What to put in the brief

• Target widths and the devices used for acceptance testing.
• Minimum touch target sizes and spacing, at least to WCAG AA.
• How forms, filters and tables rearrange on a narrow screen.
• Performance expectations in mobile mode.
• PWA as a separate decision, not a default.

These points are easiest to write into the brief when you order a responsive company website, so the mobile version does not become an afterthought at the end of the project.

What to do next

Start with your own analytics: mobile share and conversion by device. Then open the home page and a form page on a real phone and go through the checklist above. Fix in this order: forms, touch targets, the first screen.

Want us to look at your site on a phone and tell you what to fix first? Get in touch.

Author: Sergey Filatyev, founder of the Veb-Dev boutique studio.