A Readability Checklist for Every Page You Publish

Pilots don’t take off from memory. Before every flight they walk through a checklist, not because they don’t know how to fly but because knowing how isn’t the same as remembering to. Writing has the same property. Everyone who publishes web pages knows, in principle, that text should be legible and paragraphs short and headlines clear. And yet pages ship constantly that violate all of it, written by people who knew better. The problem isn’t knowledge. It’s that at the moment of publishing, your head is full of the content, and the content crowds out everything else.

So I want to argue for a readability checklist — a fixed sequence you run before any page goes live — and propose one. The value of a checklist isn’t in the sophistication of its items. It’s that it runs even when you’re tired, rushed, or in love with what you wrote, which describes most publishing moments.

The first check is the environment check: open the page on a real phone. Not the responsive preview in your browser, which you’ll view from two feet away on a large monitor — an actual phone, held in your hand. Most of your readers are here. The page was almost certainly written somewhere else. Everything that follows should be checked in this view first, because a page that reads well on mobile nearly always reads well on desktop, and the reverse is false.

The second is the five-second check. Look at the top of the page as if you’d never seen it and ask: would a stranger know what this page is about and whom it’s for? Not from the whole page — from what’s visible before any scrolling. If the answer lives below the fold, the people who needed it most will never scroll to find it. They give you a few seconds of ungenerous attention, and the top of the page is all of it.

The third is the skeleton check. Read only the headings, in order, skipping all body text. They should form a coherent outline of the page — a stranger reading just the headings should get the argument in miniature. While you’re there, confirm the structure is real in the HTML, not just visual: one h1 that states the topic, h2s beneath it, no levels skipped. This isn’t pedantry. Screen readers navigate by heading structure, and search engines infer your page’s organization from it. A page whose “headings” are just bolded paragraphs has no structure to either of them.

The fourth is the wall check. Scroll the full page on the phone and watch for any paragraph taller than five or six lines as rendered. On a narrow screen text reflows, and a paragraph that looked fine in your editor becomes a wall. Walls don’t get read; they get scrolled past, along with whatever was in them. The fix is almost always to split at a sentence boundary that was already a natural seam. If you can’t find a seam, the paragraph probably contains two ideas fighting for space, and splitting it improves the writing too.

The fifth is the comfort check, which is three numbers. Body text at least sixteen pixels on mobile. Line height around one and a half. Contrast between text and background of at least 4.5 to 1, which is the WCAG threshold for normal-size body text — and which, in practice, means checking your grays, because nearly every contrast failure I see is a designer’s tasteful light gray on white. These are the physical preconditions of reading. Get them wrong and nothing about the prose matters, the way nothing about a lecture matters if the microphone is off.

The sixth is the label check. Read every link and button on the page out of context, as bare phrases. “Learn more.” “Click here.” “Submit.” Each one should say where it goes or what it does: “See pricing,” “Read the security docs,” “Create your account.” People skim by jumping between links, and screen reader users can pull up a list of a page’s links detached from their surroundings. A label that only makes sense mid-sentence fails both readers.

The seventh is the read-aloud check, and it’s the only one that takes real minutes. Read the page out loud, quickly, once. Your ear catches what your eye forgives: the sentence you stumble over, the phrase you’d never say to a person, the jargon that felt normal on screen and feels absurd in your mouth. Fix whatever made you stumble. You don’t need to deliberate; the stumble is the diagnosis.

Seven checks, maybe ten minutes for a typical page. You could argue some are accessibility or SEO rather than readability, and you’d be right, which is sort of the point — these concerns converge, because they’re all downstream of one question: can an imperfect reader in imperfect conditions extract your meaning? I built GazeSite to run checks in this spirit automatically, and automation is genuinely useful for the mechanical items — it will catch the missing h1 and the failing contrast every time, without fatigue. But no scanner reads aloud in your voice or knows what your stranger doesn’t know. The checklist’s job is different from a tool’s job. The tool catches what you can’t see. The checklist makes you look at what you stopped seeing. Pages fail readability mostly through the second kind of blindness, and the cure is embarrassingly cheap: a fixed routine, run every time, especially when you’re sure you don’t need it.