Responsive design begins with content, not a device list

Put the essential content into a sensible reading order before arranging columns. A visitor should be able to understand the page's purpose, read the information needed for a decision and reach the next action. If a narrow layout requires hiding the information that makes the offer understandable, revisit the content and structure.

MDN describes responsive design as an approach using flexible layouts and media queries, rather than a separate technology. Its guidance on mobile-first design begins with a simple layout and adds complexity as room becomes available. Use that idea to review the page's priorities. Small screens expose unclear ordering, but the correction should improve the content structure for every viewport.

Resize the page slowly and watch for the point where the arrangement stops working. A navigation label may wrap, a comparison may become difficult to scan or a column may become too narrow for its paragraphs. Record the actual failure and change the layout where that failure occurs.

MDN's media-query guidance recommends choosing breakpoints around the content and notes that Grid and Flexbox can provide flexibility without a media query. Do not assume a particular phone or tablet width is the right dividing line for every component. A short card and a detailed pricing explanation can need different treatment within the same page.

Decide what each image explains before deciding how large to make it. An editorial photograph can establish context; a product detail may need a closer crop. Decorative repetition adds download weight without helping a reader. Check that the subject remains visible when the image is shown in a narrower slot.

MDN documents srcset and sizes as ways to offer image candidates and describe their layout width so the browser can choose an appropriate resource. Keep that size information aligned with the rendered layout. Use a picture element when different crops are needed for art direction. Check the actual downloaded resource in the browser rather than assuming a small-looking image is a small download.

A narrow viewport does not tell you how a person is operating the page. Review the same journey with a keyboard and touch input, and increase browser zoom to check that essential controls remain reachable. Avoid interactions that expose important information only while the pointer hovers.

MDN's keyboard guidance calls for keyboard-operable interactive controls and visible focus. web.dev also recommends matching the visual and document order and testing the tab sequence. Prefer the platform's native links and buttons where they fit the task. Styling a block to look clickable does not establish its keyboard behavior or accessible name.

Use the longest plausible heading, an image that fails to load and a form showing validation feedback. Try the navigation while zoomed, and follow links with the keyboard without a mouse rescue. Where animation is present, test a reduced-motion preference, which web.dev identifies as a user setting that designs should respect.

Write findings as observable failures: the submit button is covered, the focus indicator disappears or the menu cannot be closed from the keyboard. Include the viewport and interaction that produced each result. A clean screenshot is one piece of evidence, not an accessibility assessment. Finish the review by repeating the affected journey after each correction.