Semantic HTML as the Foundation

The plain-language idea

Semantic HTML means using the element whose meaning matches what the content actually is, not just an element that can be styled to look right. A <button> isn't just a clickable box — it carries meaning: "this is a control that performs an action." A <div> styled identically carries none. The browser turns that meaning into real, working behavior for assistive technology at zero extra cost: focusability, keyboard handling, and an announced role. Skip the right element and you inherit the job of rebuilding all of that yourself.

Three categories of markup carry an outsized share of this for free:

• Landmark elements — <header>, <nav>, <main>, <aside>, <footer> mark out the major regions of a page. A screen reader user can pull up a "landmarks" list and jump straight to <main>, skipping the header and nav entirely, instead of tabbing through every link on the page first. A page built entirely out of <div>s has no such list — every visit starts from the top, every time.
• Heading hierarchy — one <h1> per page, and no skipped levels (an <h2> followed directly by an <h4>, with no <h3> in between). Screen readers let a user pull up a heading outline of the whole page and jump between sections by level, the same way a sighted user visually scans a page for its biggest text. A broken hierarchy doesn't just look wrong in dev tools — it makes that outline lie about the page's actual structure.
• List and table markup — <ul>, <ol>, and <table> for content that is genuinely a list or a grid of data, instead of <div>s styled with CSS to merely look like one. A screen reader announces real markup as "list, 5 items" or "table, 3 columns, 4 rows" — information that lets a user know how much content is coming and navigate it row by row or item by item. A div-based lookalike gives none of that; visually it's identical, structurally it's just anonymous boxes.

See it in a real thing: a settings page, two ways

<!-- Div soup: looks right, says nothing -->
<div class="page">
  <div class="topbar">Settings</div>
  <div class="sidebar">
    <div class="link">Profile</div>
    <div class="link">Notifications</div>
  </div>
  <div class="content">
    <div class="title">Notification preferences</div>
    <div class="row">Email alerts</div>
    <div class="row">Push alerts</div>
  </div>
</div>

<!-- Semantic: same visual result, real structure -->
<header>Settings</header>
<nav aria-label="Settings sections">
  <ul>
    <li><a href="/settings/profile">Profile</a></li>
    <li><a href="/settings/notifications">Notifications</a></li>
  </ul>
</nav>
<main>
  <h1>Notification preferences</h1>
  <ul>
    <li>Email alerts</li>
    <li>Push alerts</li>
  </ul>
</main>

Both can be styled to be pixel-identical. Only the second one gives a screen reader user a landmarks list to jump <nav> → <main> directly, a real <h1> to confirm they've landed on the right page, and a "list, 2 items" announcement instead of two unrelated lines of text. None of that required a single line of JavaScript — it's what the elements already do.

What people usually miss

Watch out

• Landmarks aren't decorative — they're a navigation shortcut screen reader users rely on daily. Wrapping page regions in generic <div>s means every single visit starts with a linear read-through from the top, with no way to skip ahead.
• Heading level is structural, not a font-size shortcut. Choosing <h3> because "it's the font size I want" rather than because it's the third level of the actual outline breaks the very outline screen reader users navigate by — heading level and visual size should be styled independently in CSS, not conflated.
• A CSS grid or flex layout that visually resembles a table doesn't behave like one to assistive technology. Without real <table> markup (or an equivalent ARIA grid role, which is more work and more error-prone), a screen reader has no way to announce column count, row count, or which header a given cell belongs to.
• "It looks fine to me" is not evidence it works. Semantic correctness is invisible in a visual review — the only way to know a landmark or heading structure is actually right is to inspect it directly (DevTools' accessibility tree, a screen reader, or an automated check), not to eyeball the rendered page.

Why this matters in interviews

"Why not just build everything out of divs with the right CSS?" is a real interview question, and the strong answer names the specific, concrete behaviors a div-based rebuild has to reimplement by hand — landmark navigation, heading outlines, list/table announcements — rather than a vague appeal to "best practice."