A complete page, end to end

Everything, in one page

A page worth linking to is rarely one clever element; it is a handful of ordinary decisions made in order. The document declares its language and its title, the regions are landmarks, the headings descend in order, the image can be read aloud, and the description in the head is the sentence a search result shows.

Nothing in this chapter is new. It is the whole course, applied to one page — which is how the elements stop being a list to remember and become a way of writing.

A plan in words first

Before typing, say what the page is for and who reads it, then name its regions out loud: a header with the site and its navigation, a main column with the content, a footer with the small print. Decide what each block of content is — a heading, a paragraph, a list, an image, a form — and the elements follow from the decisions.

That order is the difference between markup that survives a redesign and markup that has to be rewritten with it.

The page as a set of questions

Every decision on the checklist is really a question about the reader. Who is this page for, and what should they be able to do when it ends? Which part is the page itself, and which part is the same on every page? What is the one heading that names it? What does each image add that the words do not? Answer those four before you type, and the elements stop being a list to memorise: a header is the answer to "what is the same everywhere", a main is the answer to "what is this page for", and an alt is the answer to "what would be lost if this image vanished".

The order of decisions

Content first, structure second, metadata last. Decide what the page says before choosing elements, then decide which region each block belongs to, then write the title and description that summarise what you built. In that order, the metadata is a description rather than a guess.

The reverse order produces a page that looks finished and reads badly: a layout chosen first, content poured into boxes, and heading levels picked because they fit. The browser will render it, and a screen reader will still have nothing to navigate.

The checklist this page must pass

• The document declares a language, so screen readers pronounce it correctly.
• The head carries a title and a description, so the tab and the search result are right.
• One h1, and headings that descend without skipping a level.
• Landmarks: header, nav, main and footer rather than divs with classes.
• Every image either says something with its alt, or is marked decorative with alt="".
• Every link has a real destination, and every form control has a label.
• The finished page validates, and passes the keyboard and zoom test from the accessibility chapter.

Before you ship it

Run the page through a validator — the W3C keeps one at validator.w3.org — and fix what it names; a stray unclosed tag is the beginning of a layout that breaks in one browser. Then walk it with the keyboard, zoom to 200%, and read it aloud, in order. Those three passes find most of what a reader would stumble on. Do them in that order, and do them twice: the second pass is where a page that only looked finished turns into one that holds up. A page that passes the validator and the keyboard is not perfect, but every remaining problem is now a judgement call rather than an accident.

Finally, let it be simple. A small page that does five things properly beats a large one that does twenty approximately, and the next person to open the file will agree.

What a validator can and cannot tell you

A validator checks the grammar: unclosed tags, attributes that do not belong, elements in places they cannot go. It cannot tell you whether a heading says the right thing, whether the alt text is useful, or whether the form asks a question a person can answer. Those are judgement calls.

Use it in two passes. First the validator, until it is quiet; then the keyboard, the zoom and the read-aloud test. A page can be perfectly valid and still unusable — validity is the floor, not the finish line.

Try these next

• Take a page you already have and write its regions in a sentence before changing any markup.
• Run it through the validator, fix only the errors, then do the keyboard pass.
• Remove the alt from one meaningful image and see what a screen reader says instead.