My site is responsive, so isn't it already mobile-friendly?

Not necessarily. A responsive layout adapts to the available space, but it can still have tiny controls, unreadable text, awkward forms, inaccessible menus, or overlays that fight the visitor. Responsive layout is one part of mobile usability — touch ergonomics, zoom, keyboard access, reflow and readable content are the rest.

How big should tap targets be?

Big enough to activate reliably and spaced to avoid accidental taps. WCAG 2.2 AA uses 24x24 CSS pixels as its baseline — as size or sufficient spacing, with defined exceptions for inline links and equivalents — while the enhanced AAA target is 44x44. Larger targets are usually the safer practical choice, and cramped link clusters are among the easiest mobile problems to fix.

Why do input types matter on mobile?

The right type gives the field proper semantics and usually helps the device offer a convenient on-screen keyboard; inputmode is the explicit keyboard hint when you need one. Choose carefully though — types also affect validation and desktop controls, and type="number" belongs only on real numeric quantities, never on phone numbers, postal codes or other digit identifiers that may carry leading zeros. Test the important forms; keyboards vary by device.

Is your site genuinely usable on phones and touch devices?

Your site can be fully responsive and pass every cross-browser check and still be a chore to use on a phone. Responsive design helps the layout adapt to the space; cross-browser testing finds the differences that would break appearance or operation. Neither guarantees the site is pleasant to operate with a thumb, one-handed, on the move — that's touch ergonomics, and it's its own discipline.

Design for the thumb — without designing out everyone else

Touch is the primary input on most phones — but not the only one: keyboards, screen readers, voice control, styluses and switches all drive phones too, so build for fingers while keeping the rest working.

Make tap targets large enough to hit reliably and spaced apart. WCAG 2.2's AA baseline is 24×24 CSS pixels (as size or sufficient spacing, with defined exceptions); 44×44 is the stronger AAA target and a good default for important controls.
Use a readable default text size — and never disable zoom: some visitors need heavy magnification whatever your default, and enlarged text must not overlap or vanish.
Make sure menus and forms work with a thumb, including controls near the top of a tall screen.
Don't make key content or actions depend on hover — many touch users can't hover, browsers fake hover-taps inconsistently, and hybrid devices blur the line. Menus and tooltips must open by tap or click and work with keyboard focus too.

Let the layout reflow, not scroll sideways

On a narrow screen, content should reflow into a simple layout — often one column — that reads straight down. Ordinary reading and form content shouldn't force page-level horizontal scrolling: a fixed-width image or desktop-pinned element pushes the whole page sideways and feels broken. Genuinely two-dimensional content — a wide data table, a map, a diagram — belongs in its own clearly scrollable container. Prevent page-level overflow, confine sideways scrolling to the elements that need it, and test reflow at narrow widths and high zoom.

Bring up the right keyboard, and tame the overlays

Choose input types that match the data — they give fields the right semantics and usually summon a convenient on-screen keyboard; add inputmode where an explicit hint helps:

<input type="email"  name="email"  autocomplete="email">
<input type="tel"    name="phone"  autocomplete="tel">
<input type="number" name="quantity" inputmode="numeric">

Reserve type="number" for genuine quantities — digit identifiers (postal codes, account numbers) get a text or tel type with an inputmode, or leading zeros and formatting break. And test the forms on a device: the exact keyboard is the browser's choice, not yours.

Be wary of intrusive full-screen pop-ups that cover content on arrival — they obscure the page, frustrate visitors, and send people away. When a dialog is genuinely necessary (consent, sign-in), make it behave: clear label, keyboard focus moved in and kept in while open, an obvious close control with a decent target size, and focus returned when it closes.

Test on real devices, both ways up

An emulator won't reveal how a thumb feels on glass. Test core tasks on at least one real phone, in portrait and landscape (and don't lock orientation unless it's truly essential) — then widen coverage with more devices or emulators for other viewport sizes and browser engines, plus zoom, larger text settings, keyboard operation, and what happens when the on-screen keyboard opens over your form.

What to do

Enlarge and space tap targets — 24×24 CSS pixels as the WCAG AA floor, 44×44 the better default for key controls.
Keep the page free of sideways scrolling; reflow content simply and contain genuinely wide elements in their own scrollable boxes.
Choose input types honestly (quantities vs. identifiers), add inputmode hints, and test the forms on a device.
Kill hover-only interactions and gratuitous overlays; make necessary dialogs accessible and easy to dismiss.
Keep default text readable and zoom fully available.
Test real devices in both orientations, plus zoom, keyboard, and assorted screens — responsive gets the layout onto the screen; touch ergonomics is what makes people glad they visited on a phone.