Visual review: columns, text and photos across screen sizes
A page can avoid overflow and still be hard to read. Use this procedure to review proportions, long content and interactions before publishing a change.
Six repeatable checks
Select representative pages
Test the home page, category, article, service, form and data table. Include a long heading, a right-to-left language and a page with several photos.
Compare columns
Inspect widths of 320, 390, 768, 1280, 1440 and 1920 px. Check alignment, reading order and gaps between blocks. Do not conceal layout defects with hidden overflow.
Enlarge text
Check text at 200%, then reflow at a width of 320 CSS pixels. Information and controls should remain accessible; data tables may have their own scrolling container.
Review photographs
Check crop, subject, dimensions and credit. A photo should not stretch to match long adjacent text. Describe visible content and identify stock photography.
Exercise interactions
Use the keyboard for menus, filters, FAQs and forms. Check visible focus, error messages and retained input after an error without submitting a real enquiry.
Keep evidence
Record URL, language, width, browser, defect and outcome after repair. Supplement laboratory measurements with real-user data when there is enough traffic for reliable analysis.
Review record to retain
- URL and language
- Screen and zoom level
- Observed defect and screenshot
- Repair and result of the repeat check
This is a working method, not a statement of compliance. Adapt the scope and document exceptions.
Before publishing: six functional checks
- Follow menus, links, downloads and language switches; check the actual destination.
- Use fictional inputs: empty fields, invalid addresses, accents and long text.
- Check that errors identify the field, work with a keyboard and preserve useful input.
- Test server-side validation too: browser checks can be bypassed.
- Distinguish acknowledgement from actual delivery; use an authorised test destination.
- Check behaviour without JavaScript, rejection and recovery; keep secrets out of evidence.
Situations and suitable checks
On a small screen, scroll the table horizontally. With a keyboard, focus the table and use the arrow keys.
| Situation | What it indicates | Useful verification |
|---|---|---|
| A control disappears with text enlarged to 200%. | The task is no longer accessible after enlargement. | Adapt the layout and retest with a keyboard. |
| A photo stretches or leaves a large desktop gap. | Its proportions unbalance nearby content. | Check size constraints and reading order. |
| A table is clipped by overflow: hidden. | Data is concealed. | Give the table its own keyboard-accessible scroller and wrapping cells. |
| A translated heading is clipped in another language. | Testing one language is insufficient. | Test long strings, RTL languages and actual language switching. |
Fictional example
A fictional service page looks correct at 1,440 pixels. At 320 pixels, its long translated heading is clipped; with text enlarged to 200%, a FAQ control becomes inaccessible.
Limit the photo size, allow columns to shrink and let text wrap. Repeat the task at 320, 390, 768 and 1,440 pixels, with text enlargement and keyboard navigation. Record remaining defects and retest after fixing them.
Acceptance criteria
- Information and controls are readable at representative widths and in representative languages.
- Text enlargement and keyboard navigation still allow the task to be completed.
- The version, browser, language and retest results are recorded.
Practical questions
Is a screenshot enough?
No. It validates one state. Also test long content, keyboard navigation and expanded, filtered or error states.
Should every page use one universal font size?
No. Review readability, line length, zoom and contrast. Font size alone guarantees neither accessibility nor visual balance.
How should Core Web Vitals be interpreted?
Good-experience thresholds are LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1 at the 75th percentile. They assess loading, interaction and stability; they do not replace visual review.
Is a screenshot needed for every possible device?
Choose major page families, useful tasks and browsers where differences have been observed. Record coverage limits: a few screenshots do not prove that every device works.
How should layout fixes be prioritized?
Address blocked tasks, hidden information and readability first. Then improve proportions, alignment and spacing, checking that each fix preserves functionality on other pages.