Headings, text and lists

Learning objectives

• Build a heading outline that reads as a table of contents, without skipped levels, and check it with a tool
• Explain what happened to the HTML5 outline algorithm, and why an h1 inside a section no longer looks smaller
• Choose among the paragraph-level elements, p, br, hr, blockquote, pre, figure and address, by what each one means
• Pick the right text-level element by meaning, tell strong from b and em from i, and say honestly what a screen reader does with each
• Mark up unordered, ordered and description lists correctly, nest them, and keep their semantics when CSS removes the markers

Headings are the page's outline

HTML has six heading elements, h1 to h6. The number is a rank, not a size: h1 heads the whole page or its main topic, h2 heads a major section, h3 a subsection within it, and so on down. Read in order, a page's headings form its outline, and a good outline reads like a table of contents. The course slides put it in newspaper terms: a heading is a headline, a logical element, and how big it looks is somebody else's decision.

That somebody is CSS. The browser's default style sheet makes an h1 large and bold and each level after it a little smaller, which is why so many headings get chosen by size. That is the mistake to unlearn. If a section needs a small heading, it is still an h2 when it is a major section, and a rule such as h2 { font-size: 1.1rem } makes it small. If some text needs to look big and bold but heads nothing, it is not a heading at all. CSS Basics explains the default style sheet and why a base layer resets it.

Who reads the outline

Sighted readers skim headings with their eyes. Screen reader users skim them with keys: in the common Windows screen readers, H moves to the next heading and 1 to 6 to the next heading of that level, and VoiceOver's rotor lists every heading on the page. WebAIM's Screen Reader User Survey #11, run in July and August 2026 with 1,780 valid responses, asked what respondents are most likely to do first when looking for information on a long page. 67.8% said they navigate through the headings, far ahead of the Find feature at 12.5% and landmarks at 3.4%. 88.3% called heading levels very or somewhat useful. Headings are not a detail of accessibility. For many users they are the page's main menu.

Search engines, reader modes and AI agents read the same outline, and so does this site: the "On this page" column is built from this lesson's h2 and h3 elements.

Never skip a level

A heading may go down only one level at a time. After an h2 can come another h2, an h3, or anything higher, such as a new h1; it cannot jump to an h4. This used to be advice. It is now a rule of the HTML standard: each heading that follows another "must have a heading level that is less than, equal to, or 1 greater than" the level of the one before. The Nu HTML Checker reports a skip as an error, in words worth knowing by sight:

Lesson 04 found the same rule on its practice page, where only Nu caught it. The reason behind the rule is the user's experience. A screen reader user who hears "heading level 2" and then "heading level 4" reasonably wonders what was missed, and a table of contents built from the outline shows a hole. Skips almost always come from choosing by size: the designer wanted a small heading, and h4 was the small one.

One h1: a convention, not a rule

The slides advise a single h1 that describes the whole page, and that remains the best practice. It is not a rule of the language. The standard says plainly that "a document can contain multiple top-level headings," and its own examples include one. What it does say is that at least one heading "should" be level 1. The Nu HTML Checker takes a middle position: an h1 inside a section or article earns a warning, not an error, suggesting "using the h1 element as a top-level heading only," because "all h1 elements are treated as top-level headings by many screen readers and other tools." One h1, matching the page's title in meaning, gives screen reader users a reliable target: pressing 1 lands on the start of the content.

The page's h1 need not be the first heading in the source; a site header may come first. And a heading starts a topic, so a subtitle is not a heading: it is a paragraph, grouped with the heading by hgroup.

The outline algorithm that never arrived

HTML5 once promised something different. Its document outline algorithm computed each heading's level from how deeply it was nested in sectioning elements, so every section could start with an h1. The slides of the time noted, accurately, that what the outline would look like was "speculative."

It stayed speculative. No browser ever exposed those computed levels to the accessibility tree, so a screen reader heard every one of those h1s as level 1, and pages written to the algorithm became flat lists of top-level headings. In July 2022 the WHATWG replaced the algorithm with the one this lesson has been describing: a heading's level is the number in its name. Sectioning elements still matter for landmarks, as lesson 05 showed. They no longer change heading levels.

The default styles catch up

One piece of the algorithm did ship: the browsers' default style sheets. They drew an h1 inside a sectioning element at h2 size, one level deeper at h3 size, and so on, so the page looked like the outline the accessibility tree never had. That leftover is now being removed. Firefox finished rolling the change out in Firefox 140, in June 2025; Chrome shows deprecation warnings for such headings from version 136, and in Chrome 156, tested for this lesson, an h1 at any depth renders at the same 2em; WebKit, Safari's engine, committed the same change in July 2025. Any page that relied on the shrinking now shows several same-sized giant headings. MDN's advice, which this course follows, is to use real levels and to set your own font-size and margin on h1.

The original goal, headings that adapt to where a component sits, has returned in a smaller form: in 2025 the standard gained the headingoffset and headingreset attributes. They are experimental and not yet supported across browsers, so a component should still take its heading level as a parameter.

hgroup: a heading and its subtitle

The slides show hgroup wrapping an h1 and an h2, to make a two-line heading: a title and a subtitle. That markup is now invalid. The hgroup element was redefined in the same 2022 change, and today it "represents a heading and related content": exactly one heading, h1 to h6, with p elements before or after it holding a subtitle, an alternative title or a tagline.

The slides' complaint about the old form was fair: the second heading entered the outline as a topic that did not exist. Now only the heading enters the outline, and Chrome gives the hgroup the role group. Every lesson on this site opens with this pattern.

Paragraphs, breaks and rules

p

A p is a paragraph: one unit of prose. It is flow content whose content model is phrasing content, which is why no list, heading or div can go inside it (lesson 04 reads its entry). Browsers put a margin between paragraphs, and that margin is the only spacing a paragraph should be asked to provide. The slides warn against the old trick of an empty paragraph, <p>&nbsp;</p>, to push content down. It adds an empty paragraph to the document and the accessibility tree, content that says nothing, to do a job that belongs to margin-block.

br

A br is a line break, and the standard limits it to "line breaks that are actually part of the content." The two classic cases are a poem, where the line is the unit of meaning, and a postal address, where each line is a field. Two paragraphs joined by <br><br> are still two paragraphs, and should be two p elements.

The slides add a less familiar use: a br placed as a fallback for a page with no CSS, then hidden by the style sheet with br { display: none } where it is not wanted. This course uses exactly that in its form-field pattern. With no CSS, the br after each label puts the input on its own line, so the form stays readable; when the style sheet loads, the field becomes a grid and the br does nothing. The break is part of the content's structure in the one case where nothing else provides it.

hr

An hr was the "horizontal rule," and browsers still draw it as a line. Its meaning now is a "paragraph-level thematic break": a scene change in a story, a shift of topic within a section. Chrome gives it the role separator. If the break is in the content, use hr and style the line as you like; if you only want a line, use a border. The slides ask how many a document should have. As many as it has thematic breaks that no heading already marks, which in most pages is none.

Quotations and citations

Three things in HTML are called "cite," and they are easy to mix up. A long quotation is a blockquote; a short one, within a sentence, is a q. The cite attribute on either holds the URL of the source, for machines; browsers do not display it. The cite element marks "the title of a work," such as a book, a film, a paper or a web page, for people.

Two rules shape that markup. Attribution "must be placed outside the blockquote," since everything inside it is the quotation; a figure with a figcaption keeps the two together. And a q gets its quotation marks from CSS, in the right style for its language, so do not type your own.

pre, figure and address

pre

A pre holds preformatted text: whitespace and line breaks shown exactly as written, in monospace by default. The standard's examples are an e-mail, computer code and ASCII art. Lines do not reflow, so add overflow-x: auto for small screens, and put a code inside when the content is code.

The parser drops a single newline right after the <pre> start tag (lesson 03), but the indentation of your source is content: a pre nested eight spaces deep shows eight extra spaces on every line.

figure and figcaption

A figure is "self-contained" content that the main text refers to as a unit, and that could be moved, to an appendix or the side of the page, "without affecting the flow of the document." It is not an image container. The standard lists "illustrations, diagrams, photos, code listings," and quotations and poems fit too; every diagram and summary table in this series sits in one. The optional figcaption, first or last child, captions it. Chrome gives a figure the role figure. Images inside figures, and what their alt text should say when a caption is present, are covered in Images.

address

The slides describe address as the address of the document's maintainer, rendered in italics. The current definition is narrower and clearer: it "represents the contact information for its nearest article or body element ancestor." It "must not contain information other than contact information," and it is not for any postal address in the text: a restaurant's address in a review is just a paragraph.

Text-level semantics: meaning over appearance

The slides divide the inline elements into physical ones, named for how they look (b, i, u, s, small), and logical ones, named for what they are (strong, em, code). That is HTML 4. HTML5 kept the physical names but gave each a meaning, and made obsolete the ones it could not rescue: tt, big, strike and acronym. So the slides' table needs a correction: u, s and small are conforming today. Every text-level element now has a meaning, and the question is which one fits.

strong and b, em and i

These four cause the most confusion, because two are bold and two are italic by default. The standard's definitions separate them:

• strong: "strong importance, seriousness, or urgency." A warning, the one sentence a reader must not miss.
• b: text to which "attention is being drawn for utilitarian purposes," with no extra importance. Keywords in a summary, product names in a review, the lead-in words of an article. The standard adds that b "should be used as a last resort when no other element is more appropriate."
• em: "stress emphasis." The stress you would put on a word when speaking, which changes what the sentence means.
• i: "an alternate voice or mood." A ship's name, a technical term, a thought, a phrase in another language, which should also carry lang, as <i lang="fr">bonjour</i>.

The test for em is to move it. "We never said she took the money" denies saying it; "We never said she took the money" suggests someone else did. If moving the markup does not change the meaning, it is not stress.

Did HTML5 introduce presentation?

The slides end their tour of inline elements with a challenge: mark renders with a yellow background in Chrome and every other browser. Had HTML5, after all the talk of separating structure from style, introduced a presentational element?

The observation is right; the conclusion is not quite. Every element has a default rendering, em italic and h1 big, and the standard's rendering section suggests yellow for mark in the same way: it is how a browser shows the meaning when the author has said nothing else. The meaning of mark is "highlighted for reference purposes," such as search terms in results. In the standard's words, strong denotes importance and mark denotes relevance. Restyle it in any color; it still means "highlighted." The slide's real lesson stands: never pick an element for its default look.

small, s, del and u

small is no longer "one size smaller." It marks "side comments such as small print": legal terms, a copyright line, a caveat. It does not de-emphasize; the small print still says what it says.

s and del both draw a line through text, and mean different things. s marks contents "no longer accurate or no longer relevant," like the old price on a sale tag. del marks an edit: text removed from the document. The standard is explicit that s "is not appropriate when indicating document edits." The obsolete strike maps to whichever of the two you meant.

u is the awkward one: "an unarticulated, though explicitly rendered, non-textual annotation," such as a wavy line under a misspelling. Its underline looks exactly like a link, and the standard itself encourages avoiding it where it could be mistaken for one. In practice, avoid it.

code, kbd, samp and var

code is "a fragment of computer code," kbd "user input," usually keys (nested for combinations), samp "sample or quoted output" from a program, and var a variable. The obsolete tt meant only "monospace" and said nothing about which of these a text was. sub and sup are for conventions that need them, such as H₂O, not for text that wants to look smaller.

abbr, dfn and cite

abbr marks an abbreviation, "optionally with its expansion" in title. Do not rely on that tooltip: touch and keyboard users never see it, and screen readers do not reliably read it (lesson 03). Spell the term out on first use, "the World Wide Web Consortium (W3C)."

dfn marks "the defining instance of a term," the place the text says what a word means; Chrome gives it the role term. cite is the title of a work.

time and data: text for people and for machines

Some text has a second reader: a program that needs a precise value behind a human phrase. time carries one in its datetime attribute, and data in its value attribute.

The datetime value must use one of the standard's formats: a month (2026-09), a date (2026-10-26), a yearless date (10-26), a time (14:30), a local date and time (2026-10-26T14:30), a time-zone offset, a global date and time with a Z or an offset, a week (2026-W44), a year, or a duration (PT1H30M). Anything else is an error, and the Nu checker says so: datetime="Oct 26" gets "Bad value … The literal did not satisfy the time-datetime format." Calendar tools and search engines read these values; nothing reads "Tuesday at midnight" reliably.

ins and del: a document's history

HTML 4 introduced ins and del for change tracking. Both take a datetime for when and a cite URL for why. Both are transparent, so an edit may cover a few words or several paragraphs.

bdi and bdo: text direction

Mixed-direction text, such as an Arabic or Hebrew user name in an English sentence, can reorder the punctuation around it. bdi isolates text whose direction is unknown, which makes it the right wrapper for user-generated names and values inserted by a template. bdo, with a required dir, forces a direction and is rarely needed. Both build on the lang and dir attributes of lesson 03 and lesson 02.

How a font draws right-to-left and mixed-direction text, and what CSS adds, is in the Fonts section's Type for people.

ruby, rt and rp

Ruby annotations are small text set above or beside base text, most often a pronunciation guide for Chinese characters or Japanese kanji. The slide's example is still a good one:

rt holds the annotation. rp holds parentheses that only a browser without ruby support shows. Every current browser engine renders ruby, so rp is optional insurance now, something the standard says "can be used."

wbr, and span as the last resort

wbr marks "a line break opportunity" in a long word or URL. And span "represents its children," nothing more: like div in lesson 05, it is the last resort when no element means what you mean.

What screen readers actually do with them

It is tempting to justify these elements by what a screen reader does with them, and much teaching material does: em "changes the voice," strong "is read louder." The evidence says otherwise. In a test of default settings published by TPGi in January 2023, covering JAWS, NVDA, Narrator and VoiceOver on macOS and iOS, none of them announced strong or em at all. Several could report bold and italic if the user turned on formatting announcements, which most users leave off because hearing every style change is tiring. Results for other elements were mixed: JAWS and NVDA announced mark, del and ins; VoiceOver on macOS announced none of them; only NVDA announced s.

Screen readers differ and change between versions, so treat any table as a snapshot. The layer below is stable: Chrome 156, checked for this lesson, exposes roles for strong, em, mark, del, ins, code, time and dfn, gives s the same deletion role as del, and gives b, i, u, small, cite, q and kbd none. Whether a screen reader speaks a role is its own decision.

Two conclusions follow. Never let meaning depend on emphasis alone: if a warning would be dangerous to mishear, the words must carry it. And the case for semantic text does not rest on screen readers. The role is there for any tool that asks, search engines and AI agents read the elements, CSS can target kbd without a class, and the next developer can read the source. The Accessibility page follows that thread.

Lists

HTML has three lists, and they are three data structures, not three looks. A screen reader announces a list on entry, usually with its item count, and lets the user jump between lists and items. Lines separated by br are not a list to anything but the eye.

ul: a set

A ul is a list "where the order of the items is not important": ingredients, tags, menu links. Its only children are li elements, and its bullets belong to CSS; the type and compact attributes the slides mention are obsolete.

ol: a sequence

An ol is "intentionally ordered, such that changing the order would change the meaning": steps, rankings, a procedure. Use it whenever order matters, even if the design shows no numbers; hide the numbers with CSS, not by switching to ul. Three attributes adjust the numbering:

• start sets the first number, for a list that continues after an interruption: <ol start="4">.
• reversed counts down, for a countdown or a "top ten."
• type picks the marker, 1, a, A, i or I, and unlike its ul cousin it is conforming, because the standard keeps it for cases where the marker "matters": a legal document or a rubric whose text refers to "item (b)." Where it is only decoration, use CSS.

A single li may also carry value, and numbering continues from it. As the slides warn, nested ordered lists do not number themselves 1.1, 1.2, 1.2.1; that takes CSS counters.

dl: names and values

A dl, a description list, holds groups of names, dt, and values, dd: a glossary, metadata such as author and date, an FAQ. As the slides note, terms and descriptions need not pair one to one. A name may have several values, which the standard calls "alternatives," and several names may share one. The standard rules out one use: dialogue.

That last option arrived in 2016: each group may be wrapped in a div, so CSS can lay it out as a card. Either every group is wrapped or none is. Chrome exposes dt and dd as term and definition either way.

Nesting lists

A list item may contain flow content, including a whole list, so sublists go inside an li. The common mistake is to put the inner list between two items, as a direct child of the outer list. That is invalid, and lesson 04's content-model check shows why: a ul accepts only li.

The slides also mention using a ul or a blockquote just to indent. Both announce structure that is not there; indentation is padding-inline-start.

Menus are lists, and the Safari caveat

A navigation menu is a set of links, so the usual markup is a ul inside a nav, with CSS removing the bullets. Screen reader users then hear how many links the menu has before they start.

One browser complicates this. WebKit, Safari's engine, treats a list styled list-style: none as possibly presentational, so VoiceOver may not announce it as a list. The WebKit team has called this deliberate, a reaction to pages that wrap everything in lists, and the behavior has varied between macOS, iOS and versions; a 2025 report about iOS was closed in 2026 as a duplicate of the long-standing heuristic. Chrome keeps the list role. The accepted workaround restores the role:

The Nu checker warns that "the list role is unnecessary for element ul," and restating a role is usually noise. This is the accepted exception: add it where you remove the markers from a list whose list nature matters, and test in Safari with VoiceOver. Making the menu's links usable is the subject of Usable links.

Try it: mark up a real page

Take a page of plain text, such as a course announcement, a recipe or a product page copied as text from a site you use, and mark it up with only the elements in this lesson.

1. Write the headings first, and paste them into the heading outline viewer. Does the outline read as a table of contents? Fix every skip by changing the level, never by changing the text.
2. Mark up the paragraphs and lists. For each list, decide whether order matters (ol), whether it is a set (ul), or whether it pairs names with values (dl). Find at least one candidate for a dl; metadata such as dates, sizes and prices usually is one.
3. Go through the text sentence by sentence and mark up whatever has a meaning of its own: a date (time with a valid datetime), a warning (strong), a stressed word (em), a key (kbd), an abbreviation (spelled out the first time), a title of a work (cite), an old price (s). For each b or i you use, write down why no other element fits.
4. Run the page through the Nu HTML Checker and fix everything it reports. Try a bad datetime on purpose to see the error.
5. Turn CSS off, or view the page with none, and read it top to bottom. Then open the Accessibility pane in DevTools, or a screen reader, and step through the headings and lists. Compare what you meant with what each reader received.

Summary

Next steps

When content has two dimensions, rows of records with named columns, a list is no longer enough. Lesson 07, Tables, covers tables for data, never layout, with the headers and captions that make them readable. Lesson 08 turns to elements that open, close and respond without a script. For styling list markers, see Selectors and ::marker.