Responsive Web Design: A Checklist That Goes Beyond "It Shrinks on a Phone"

Responsive web design began as a technical idea: use flexible grids, flexible images and media queries so one page adapts to many screens. Years later, plenty of sites technically qualify and still frustrate people on phones. When we review a site, we do not ask whether it shrinks; we use a checklist that reflects what visitors actually struggle with. Try it on your own pages with a real handset in your hand.

Check the foundations

Make sure the page declares a viewport so mobile browsers render it at device width, rather than pretending to be a desktop and scaling everything down. Design the smallest layout first, then add enhancements as space allows, an approach known as mobile first. Choose breakpoints where your content breaks rather than at the widths of particular phones, because new devices arrive every year. If a sentence becomes awkwardly long or a card looks lost, that is where a layout change belongs.

Text that people can read

Body text smaller than about 16 pixels forces pinching and zooming. Keep line lengths between roughly 45 and 80 characters, give lines generous spacing and avoid centred paragraphs, which are tiring to read. Let people zoom: disabling pinch zoom in the viewport settings is an accessibility failure. The WCAG guidance expects content to reflow in a window equivalent to 320 CSS pixels wide, without needing to scroll sideways, so test narrow widths and text enlarged to 200 percent.

Touch targets and thumbs

A mouse pointer is precise; a thumb is not. WCAG 2.2 introduced a minimum target size of 24 by 24 CSS pixels at level AA, and larger targets of 44 or 48 pixels are friendlier in practice. Space links apart so that neighbouring taps do not collide, and do not rely on hover effects, which do not exist on touchscreens. Keep primary actions within comfortable reach in the lower half of the screen where you can.

Images and media

Large images are the most frequent cause of slow mobile pages. Serve different sizes with the srcset attribute so a phone downloads a small file, use modern formats such as WebP or AVIF where supported and lazy load images below the first screen. Reserve space with width and height attributes so the page does not jump when images arrive, which improves the layout stability score Google measures. For video, avoid autoplay with sound and provide captions.

Navigation that behaves

Collapsed menus are fine, but check that they open reliably, can be closed again, work with a keyboard and a screen reader, and do not hide the most important links three taps deep. Sticky headers that occupy a quarter of a small screen steal reading space; make them slim or let them disappear while scrolling down. Search, phone number and basket should stay easy to find.

Tables, forms and the awkward bits

Wide tables need a deliberate plan: scrolling inside a container, stacking rows as cards or hiding low-priority columns. Forms should use the right input types so the correct keyboard appears, and labels should stay visible. Embedded maps and iframes often overflow, so constrain their width. Test pop-ups and cookie banners on the smallest screen too, because a banner that covers the whole page can make a site unusable.

Test on real devices and in real conditions

Performance is part of responsiveness

A layout that adapts beautifully but takes ten seconds to appear on a train is not responsive in any sense that matters. Mobile visitors often have weaker processors as well as slower connections, so every script you ship costs them more than it costs you. Audit the third-party tags on your pages, remove those that nobody uses and load the rest after the main content. Use the browser's developer tools to throttle the connection and the processor, and watch what a mid-range phone experiences. The gap between your laptop and that experience is the real size of your problem.

Content decisions, not only code

Responsive design also forces editorial choices. If a table, a long paragraph or a wall of icons cannot work on a small screen, it may not be working on a large one either. Shorten, prioritise and put the information people ask for first. Teams that treat the small screen as a discipline usually produce better desktop pages as a side effect.

Browser emulators help, but nothing replaces a mid-range handset on a mobile connection, held in one hand outdoors. Also try landscape orientation, a large text setting and dark mode. Write down every point of friction and fix them in order of how many people they affect. If you would like a structured review of your own site, we can walk through it with you.