In Part 1, you learned what HTML is, how a page travels from server to browser, and wrote your first document with a heading and a paragraph. In this lesson we go much deeper into text itself: the full heading hierarchy, paragraphs, and the wide vocabulary of text-level elements HTML gives you for meaning, not just appearance. This is a longer, more detailed lesson than Part 1 — text is the foundation of almost every page you’ll ever build, so it’s worth understanding thoroughly rather than skimming.

The heading hierarchy: h1 through h6

HTML gives you six levels of heading, from <h1> (most important) to <h6> (least important):

<h1>Garlic Butter Pasta</h1>
<h2>Ingredients</h2>
<h3>For the sauce</h3>
<h3>For the pasta</h3>
<h2>Instructions</h2>
<h3>Step 1: Boil the pasta</h3>
<h3>Step 2: Make the sauce</h3>

Notice this isn’t arbitrary — it mirrors how you’d outline the same recipe on paper: one main title, two major sections, each broken into sub-points. This is the single most important idea in this lesson: headings describe document structure, not font size. A common beginner mistake is picking a heading level because it “looks right” visually (e.g. using <h4> because <h1> looks too big), when visual size is actually CSS’s job, which we cover later in this series. The heading level you choose should describe the content’s place in the document’s outline, full stop — you can always make an <h1> visually smaller with CSS without changing what it means structurally.

Why heading order matters for accessibility

Screen reader users (people who navigate the web by listening to a page read aloud, often due to visual impairment) frequently jump between headings the way a sighted user’s eye jumps down a page scanning for structure. Many screen readers let you press a key to skip straight to the “next heading” — but that only works usefully if headings are nested in a sane order. Skipping levels (going from an <h2> straight to an <h4> with nothing in between) breaks that mental model, forcing screen reader users to guess whether they missed a section. The rule of thumb: use exactly one <h1> per page (the page’s main title), then nest <h2>, <h3>, etc. without skipping levels, the same way you wouldn’t skip from “1.” to “1.1.1” in a numbered outline without a “1.1” first.

Why heading structure matters for SEO

Search engines parse your heading structure to understand what a page is about and how it’s organized, similarly to how a screen reader does. An <h1> that accurately states the page’s topic, followed by <h2>s that outline its major sections, gives search engines (and by extension, the people searching) a much clearer signal than a page where every piece of text is wrapped in a plain <div> or <p> with no heading structure at all. Good heading structure is one of the cheapest, highest-leverage SEO improvements you can make to any page.

Paragraphs: the workhorse of body text

The <p> element represents a paragraph of text — one self-contained thought or block of prose:

<p>
  Garlic butter pasta is a fast weeknight dinner that uses ingredients
  most kitchens already have on hand.
</p>
<p>
  The whole dish comes together in under twenty minutes, including the
  time it takes to boil the pasta.
</p>

A very common beginner mistake is using multiple <br> (line break) tags to fake paragraph spacing instead of using separate <p> elements:

<!-- Don't do this: -->
<p>First thought here.<br><br>Second, unrelated thought here.</p>

<!-- Do this instead: -->
<p>First thought here.</p>
<p>Second, unrelated thought here.</p>

<br> means “a forced line break within one continuous piece of text” (like the line breaks in a mailing address or a poem) — not “a new paragraph.” Using separate <p> elements correctly tells both browsers and assistive technology that these are two distinct, self-contained ideas, which also lets you style paragraph spacing consistently with CSS later, rather than depending on how many <br> tags you happened to type.

Text-level semantic elements: meaning, not just looks

Beyond headings and paragraphs, HTML provides many small elements for marking up specific kinds of text with meaning. This is the part of HTML that beginners most often shortcut by reaching for generic <span> tags and CSS — which works visually, but throws away meaning that browsers, screen readers, and search engines could otherwise use. Here’s a comparison of the most common ones:

Let’s look at real examples of several of these, since the differences matter more in practice than in a table.

<strong> vs. <em> — importance vs. emphasis

These are the two most confused elements in this whole lesson, because they both render as bold/italic by default and beginners assume they’re just “the bold tag” and “the italic tag.” They’re not — <b> and <i> exist for pure visual styling with no semantic weight, while <strong> and <em> change the actual meaning of the sentence:

<p><strong>Warning:</strong> unplugging the device while updating can damage it.</p>

<p>I <em>did</em> lock the door — I checked twice.</p>

Read that second sentence aloud without emphasizing “did,” and it sounds like a flat statement. Emphasizing “did” changes it into a defensive clarification. A screen reader that respects <em> will actually change its intonation on that word — something a purely visual <i> tag can never communicate to someone who can’t see italics.

<abbr> — abbreviations with their full meaning available

<p>
  This page follows the <abbr title="World Wide Web Consortium">W3C</abbr>
  specification.
</p>

Sighted users can hover over “W3C” to see a tooltip with the full term; screen readers can be configured to read out the expanded title value instead of the abbreviated letters. This one small attribute makes your content clearer for both audiences at once.

<code> and <pre> — for code, together or apart

You’ve been looking at <pre><code> combinations throughout this series already. <code> alone marks a short inline code fragment within a sentence:

<p>Use the <code>fetch()</code> function to make a network request.</p>

<pre> (“preformatted text”) preserves whitespace and line breaks exactly as typed, which is why multi-line code blocks combine both: <pre> keeps your indentation and line breaks intact, and the inner <code> marks the content as code specifically (as opposed to, say, preformatted poetry, which would just use <pre> alone).

Block quotations vs. inline quotations

For a quotation that stands on its own as a block (several sentences, a passage from another source), use <blockquote>. For a short quotation inside a sentence, use <q>, which browsers automatically wrap in quotation marks:

<blockquote cite="https://example.com/source">
  <p>The web does not just connect machines, it connects people.</p>
</blockquote>

<p>She called it <q>the best pasta I've had all year</q>.</p>

The cite attribute on <blockquote> is optional but valuable — it lets you record the source URL of a quotation without displaying a raw link inline, which search engines and citation-aware tools can still read from the markup.

A worked example: turning plain text into properly semantic HTML

Let’s take a paragraph of plain, unstructured text and progressively add the right elements, since seeing the “before” state makes the payoff of each element concrete:

<!-- Before: everything is one flat paragraph, no structure -->
<p>
  Recipe Notes. Warning do not leave the pan unattended. Preheat the
  oven to 200C 392F. As the chef said this is the one step people
  always skip. See the W3C flavor pairing guide for more ideas.
</p>

<!-- After: headings and text-level semantics added -->
<h3>Recipe Notes</h3>
<p><strong>Warning:</strong> do not leave the pan unattended.</p>
<p>Preheat the oven to 200<sup>o</sup>C (392<sup>o</sup>F).</p>
<p>As the chef said, <q>this is the one step people always skip</q>.</p>
<p>
  See the <abbr title="World Wide Web Consortium">W3C</abbr>
  flavor pairing guide for more ideas.
</p>

Nothing about the visible words changed much — but the document now carries real, machine-readable meaning: a distinct heading, an urgent warning a screen reader can announce differently, a properly marked temperature superscript, an inline quotation, and an abbreviation with its expansion available on demand.

Visualizing where text semantics sit in the bigger picture

It helps to see how this lesson’s elements relate to the DOM tree concept from Part 1. Headings and paragraphs are typically direct children of larger structural containers, while text-level elements like <strong> or <code> nest one level deeper, inside the text they modify:

Notice that <strong> is a child of <p>, not a sibling — it modifies part of that paragraph’s text, it doesn’t stand apart from it. This nesting relationship is exactly what CSS selectors and JavaScript DOM queries will later target, so building an accurate mental model of it now pays off continually later in this series.

Common mistakes with headings and text semantics

• Skipping heading levels for visual reasons. Choose heading level by document outline, not by how big or small you want the text to look — that’s CSS’s job.
• Using more than one <h1> per page. Reserve it for the single main title of the page.
• Reaching for <b>/<i> by habit. They still exist and are valid HTML, but they carry no semantic meaning — prefer <strong>/<em> whenever the text genuinely is important or emphasized, and reserve <b>/<i> for cases that are truly just stylistic (e.g. a product name that’s conventionally italicized, with no added emphasis).
• Faking paragraphs with <br>. Use separate <p> elements for separate ideas.
• Forgetting the title attribute on <abbr>. Without it, you get the dotted-underline styling with none of the accessibility benefit.

Recap

This lesson covered: the full h1–h6 heading hierarchy and why it must reflect document outline rather than visual size; why correct heading order matters for both screen reader navigation and search engine understanding; the <p> element and why <br> is not a paragraph substitute; a full tour of text-level semantic elements (<strong>, <em>, <mark>, <small>, <abbr>, <code>, <sub>/<sup>, <q>, <blockquote>) with the reasoning behind each; a worked before/after example converting flat text into properly semantic markup; and how text semantics fit into the DOM tree structure from Part 1.

Coming up next: Part 3 will cover links and navigation in full depth — the anchor element, absolute vs. relative URLs, linking within a page, opening links in new tabs safely, and the accessibility considerations around link text.