Headings, Paragraphs, Lists and Tables

Most of any web page is text, and a wall of text is hard to use: nobody can skim it, and nobody can find the part they came for. HTML gives text a shape: headings that form an outline, paragraphs, lists, and tables for information that truly has rows and columns. Choosing the right element is a decision about what the text means, not how it looks. The look can always change later; the meaning is what stays.

A book's table of contents is the picture to hold on to. Chapters, then sections, then subsections, each level inside the one above. Anyone can scan it and jump to the part they need, but only if the levels are honest: a table of contents that goes from a chapter straight to a sub-subsection leaves the reader wondering what they missed.

Headings Are the Outline

HTML has six heading elements, h1 to h6, and the number is the level in the outline, not a size. The h1 is the title of the page. Each h2 starts a major section, an h3 is a part of the h2 above it, and so on down. Two rules keep the outline honest: one h1 per page, which is the convention most accessibility guides recommend and this book follows, and no skipped levels on the way down.

<h1>Making Bread at Home</h1>
<p>A loaf needs four ingredients and most of a morning.</p>

<h2>What You Need</h2>
<p>Flour, water, salt and yeast, plus a large bowl.</p>

<h2>The Method</h2>
<p>Mix, knead, leave it to rise, then bake.</p>
<h3>Shaping the Loaf</h3>
<p>Fold the dough under itself until the top is smooth.</p>

This goes between the body tags of a page built on the skeleton from topic 1. The browser shows the page title in very large bold type, the two section headings a size smaller, and "Shaping the Loaf" smaller again, each followed by a paragraph of ordinary text with a gap above and below it. Those sizes come from the browser's built-in styles, and Chapter 3 shows how to change them.

The outline matters most to people who cannot see the sizes at all. A screen reader, the software that reads a page aloud, can list every heading on the page and jump straight to any of them. For its users, the headings are how a page is skimmed, exactly as a sighted reader's eye skims the big bold lines.

h1

Making Bread at Home

h2

What You Need

h2

The Method

h3

Shaping the Loaf

Paragraphs, and Two Kinds of Emphasis

A p element is a paragraph. The browser puts space above and below it, and it ignores the line breaks inside your file: it wraps the text to fit the window, however you typed it.

Inside a paragraph, two elements mark words that matter. strong means the words are important, such as a warning, and the browser shows them in bold. em means the words are stressed, the way your voice leans on a word when you speak, and the browser shows them in italics. Stress can change what a sentence means: in "I asked for tea", stressing the word tea complains about the drink, while stressing the word I complains about who did the asking.

HTML also has b and i, which draw bold and italics too, but they carry no sense of importance or stress. The standard keeps them for narrower jobs, such as a phrase in another language. When the words matter, use the element that says why.

Lists: When Order Matters and When It Does Not

<ul>
  <li>500 g bread flour</li>
  <li>350 ml warm water</li>
  <li>10 g salt</li>
</ul>

<ol>
  <li>Mix everything into a rough dough.</li>
  <li>Knead for ten minutes.</li>
  <li>Leave to rise for an hour.</li>
</ol>

A ul, an unordered list, is for items whose order does not matter, like ingredients. An ol, an ordered list, is for items whose order is the point, like steps. Each item in either kind is an li, a list item. The browser shows the first list with a bullet before each item and the second numbered 1, 2 and 3, both indented from the left. You never type the numbers; the browser counts, so inserting a step renumbers the rest.

A screen reader announces a list and how many items it holds before reading them, which tells a listener how much is coming. Lists turn up in places you might not expect: a site's menu of links is a list of destinations, and the next topic builds one.

Tables Are for Data

A table is for information that genuinely has rows and columns, where each cell makes sense only when you know its row and its column. Opening hours, a timetable and a price comparison are tables. A table is built one row at a time: a tr is a table row, a th is a header cell that says what its column means, and a td is an ordinary data cell. A caption names the whole table.

<table>
  <caption>Bakery opening hours</caption>
  <tr>
    <th>Day</th>
    <th>Opens</th>
    <th>Closes</th>
  </tr>
  <tr>
    <td>Monday to Friday</td>
    <td>07:00</td>
    <td>18:00</td>
  </tr>
  <tr>
    <td>Saturday</td>
    <td>08:00</td>
    <td>16:00</td>
  </tr>
</table>

The browser shows the caption centred above three rows of three cells. The header cells in the first row are bold and centred; the others are plain. There are no lines between the cells, because the browser's default table has no borders; CSS adds them if you want them. The header cells are what make the table usable by ear: when a screen-reader user moves to the cell saying 16:00, they hear that it is in the Closes column.

Tables are never for arranging things side by side on the screen. Years ago that was the usual trick, and it still turns up in old pages and emails. A table says "this is data" to every program that reads the page. Browsers try to guess which tables are only layout, but when the guess fails, a screen reader announces rows and columns and reads the page cell by cell, which turns a layout into nonsense. Chapter 4 arranges things on screen the proper way.

Why Can a Broken Page Look Fine?

Browsers are built to be forgiving. When the HTML breaks a rule, the browser does not stop or show an error; it fixes the mistake as best it can and carries on. That keeps millions of imperfect pages readable. It also means a page can look right while its structure is quietly different from what you wrote.

<p>Before you start:
  <ul>
    <li>Wash your hands.</li>
    <li>Clear the table.</li>
  </ul>
</p>

<p>Before you start:</p>
<ul>
  <li>Wash your hands.</li>
  <li>Clear the table.</li>
</ul>
<p></p>

The first block puts a list inside a paragraph, which HTML does not allow: a paragraph can hold text and small inline elements, not a list. On screen, the result looks exactly as intended, a line of text followed by two bullet points. Underneath, the browser closed the paragraph the moment the list began, and when it reached your closing paragraph tag with no paragraph open, it made a new, empty paragraph to match it. That is the second block: three elements where you wrote one.

So "it looks right" is not proof that the HTML is right. Two tools show the truth. The W3C, one of the bodies that writes web standards, runs a free checker at validator.w3.org that lists every rule a page breaks. And the browser's DevTools, in topic 6, show the structure the browser actually built.