Tables: real tabular data, done correctly

Tables have a real, narrow, correct use in HTML: genuinely tabular data, where rows and columns both carry real meaning. This part builds one — a real subscription plan comparison for Bright Leaf Coffee — the exact kind of content a table is actually meant for.

A real comparison table

<table>
  <caption>Compare Bright Leaf Coffee subscription plans</caption>
  <thead>
    <tr>
      <th scope="col">Plan</th>
      <th scope="col">Price</th>
      <th scope="col">Bags per month</th>
      <th scope="col">Free shipping</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Gift Subscription</th>
      <td>$18/mo</td>
      <td>1</td>
      <td>Yes</td>
    </tr>
    <tr>
      <th scope="row">Monthly Subscription</th>
      <td>$16/mo</td>
      <td>1</td>
      <td>Yes</td>
    </tr>
    <tr>
      <th scope="row">Double Bag</th>
      <td>$30/mo</td>
      <td>2</td>
      <td>Yes</td>
    </tr>
  </tbody>
</table>

What each piece is actually doing

• <table> wraps the entire table
• <caption> provides a real, accessible description of what the table contains — announced by screen readers before the table content itself, the equivalent of a sighted reader's first glance at a table title
• <thead> groups the header row(s); <tbody> groups the actual data rows — this separation lets a screen reader distinguish "this row defines what the columns mean" from "this row is actual data"
• <th> marks a header cell — for a column header, scope="col"; for a row header (like each plan name above), scope="row"
• <td> marks a regular data cell

Why scope is the detail almost everyone skips

Without scope: a screen reader announces each cell's value with no
  indication of which row or column header it belongs to — "$18/mo"
  alone, with no context
With scope: the same cell is announced with its real header context —
  "Gift Subscription, Price: $18/mo"

scope="col" and scope="row" are what let a screen reader correctly associate a data cell with its real header when read out of visual/sequential order — genuinely necessary for a table of any real complexity, and the single most commonly missing piece in tables built without accessibility in mind from the start.

When a table is the wrong choice

<!-- wrong: using a table purely to force a two-column visual layout -->
<table>
  <tr>
    <td><img src="/images/logo.svg" alt="Bright Leaf Coffee" /></td>
    <td><nav><a href="/">Home</a></nav></td>
  </tr>
</table>

Tables were commonly misused for page layout in older web design, before CSS layout tools were reliable — using a table purely to force a visual grid, with no real tabular data inside it, is a real, outdated anti-pattern. A screen reader announces that structure as an actual data table, misleadingly implying the header and nav are related tabular data when they're not. Layout is CSS's job (covered later in this series); tables are for real data with genuine rows-and-columns meaning, like the subscription comparison above.

Responsive tables: a real, honest limitation

Wide tables with many columns are a genuine, unsolved layout challenge on narrow phone screens — HTML alone doesn't have a built-in mechanism to reflow a table's columns into something narrower. The common real solutions (horizontal scroll on a wrapping container, or restructuring data into cards below a breakpoint) are CSS-layer decisions, covered when this series reaches styling — worth knowing as a real constraint now, even before the solution is covered.

Next: forms — the fundamentals of <form>, input types, and labels, building Bright Leaf Coffee's real newsletter signup.