HTML Document Structure and Semantic Elements Explained

Imagine the Harbour Street Library asks you to build a page for its late-night study week. A colleague has already sketched it: fourteen <div> elements, each with a class like top, menu-box or side-thing. It looks fine in a browser. Yet a screen reader announces nothing but "group, group, group", a search engine cannot tell the event details from the footer small print, and you cannot tell which div is which when you return in three months. This lesson is about replacing those anonymous boxes with elements that say what they are.

The skeleton every document needs

An HTML document is a tree of elements. The browser reads your text, builds that tree (the DOM), then paints it. Four parts of the skeleton are not optional in practice: the doctype, the html element with a language, a head for information about the page, and a body for what people see.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Late-Night Study Week | Harbour Street Library</title>
</head>
<body>
  <h1>Late-Night Study Week</h1>
  <p>The reading room stays open until 10 pm, Monday to Thursday.</p>
</body>
</html>

Open this file and you see a bold, large heading with a single paragraph below it, both pushed in from the edges by the browser's default body margin. The words "Late-Night Study Week | Harbour Street Library" appear in the browser tab, not on the page. That is the job of <title>: it also becomes the bookmark name and the headline in search results.

• <!DOCTYPE html> switches the browser into standards mode. Without it, browsers fall back to quirks mode and apply decades-old rendering behaviour.
• lang="en" tells screen readers which pronunciation rules to use and lets browsers offer correct translation and hyphenation.
• <meta charset="utf-8"> declares the text encoding so characters such as the pound sign or an accented name do not turn into question marks. Keep it within the first 1024 bytes of the file.
• The viewport meta tag stops phones from pretending to be a 980-pixel-wide desktop. You will need it as soon as you write responsive CSS.

Say what the content is: semantic elements

A semantic element carries meaning in its name. <nav> is a set of navigation links, <main> is the unique central content of the page, <footer> is the closing information for its nearest section or page. Browsers give these meaning through the accessibility tree, which is why a screen reader user can press a single key to jump to the navigation or skip straight to the main content.

Here is the library page rebuilt with those elements. Read it and try to sketch what it will look like before the description below.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Late-Night Study Week | Harbour Street Library</title>
</head>
<body>
  <header>
    <h1>Harbour Street Library</h1>
    <nav aria-label="Main">
      <a href="/">Home</a>
      <a href="/events">Events</a>
      <a href="/visit">Visit us</a>
    </nav>
  </header>

  <main>
    <article>
      <h2>Late-Night Study Week</h2>
      <p>The reading room stays open until 10 pm, Monday to Thursday.</p>

      <section>
        <h3>What is available</h3>
        <ul>
          <li>Silent desks on the second floor</li>
          <li>Free tea at 8 pm</li>
        </ul>
      </section>

      <section>
        <h3>Who to ask</h3>
        <p>Staff wear green lanyards and can book a group room for you.</p>
      </section>
    </article>

    <aside>
      <h2>Good to know</h2>
      <p>The side entrance is step-free.</p>
    </aside>
  </main>

  <footer>
    <p>12 Harbour Street. Open Monday to Saturday.</p>
  </footer>
</body>
</html>

With no CSS, the browser stacks everything in source order. You see the large site name, then three links sitting on one line with spaces between them (links are inline elements), then the article heading, its paragraph, two sub-headings with a bulleted list under the first, the aside heading and note, and finally the address line. It looks plain, but the structure is rich: a screen reader can list the landmarks (banner, navigation, main, complementary, contentinfo) and jump between them.

What the browser does with invalid nesting

HTML parsers never throw errors the way a compiler does. They quietly repair what you wrote, which can surprise you. Some elements, such as p, can only contain phrasing content (text and inline elements). Put a block inside and the parser closes the paragraph early.

You write:
<p>Doors open <div>at 9</div> sharp.</p>

The parser builds:
<p>Doors open </p>
<div>at 9</div>
 sharp.
<p></p>        <- the stray </p> creates an empty paragraph

Your CSS selectors, spacing and tests will then be working against a tree you never wrote. An HTML validator catches these problems before they cost you an afternoon.

Block, inline and why order in the source matters

Block elements such as p, h1, ul and article start on a new line and fill the available width. Inline elements such as a, strong and span flow within a line of text. Keep your source order logical, because keyboard users tab through links in source order and screen readers read in source order, however you later rearrange things visually with CSS.

Common mistakes

• Forgetting the doctype. The page renders in quirks mode, so box sizes and table fonts behave oddly, and the validator reports Start tag seen without seeing a doctype first.
• Using `<br>` or empty paragraphs for spacing. Screen readers announce the empty paragraphs and the gaps break the moment someone changes font size. Spacing is CSS work.
• More than one visible `<main>`. The validator complains that a document must not have more than one visible main element, and landmark navigation becomes ambiguous.
• Skipping `lang`. A screen reader may read English text with the wrong voice, and Lighthouse reports <html> element does not have a [lang] attribute.
• Picking elements for their default look. Using blockquote to indent a paragraph or h3 because it is the right size misleads assistive technology. Choose by meaning, restyle with CSS.

How this shows up in real projects and interviews

In a React or Next.js codebase you will still write header, nav, main and footer, only inside JSX, and accessibility audits run against the final HTML. Interviewers for front-end roles often ask "what is semantic HTML and why does it matter?" The strong answer names three beneficiaries (assistive technology, search engines, future maintainers) and gives a concrete example such as replacing a clickable div with a real button. If you later build components, see React Components and Props and keep the same discipline: a component's root element should be the most meaningful one available.