Responsive & sortable tables

On a narrow screen a wide table is wider than the viewport. Reflow (1.4.10) allows two-dimensional data like a table to scroll in one direction, so horizontal scrolling is fine — but only if the user can actually do it. A bare overflow:auto wrapper scrolls with a mouse or a touch swipe, yet a keyboard user can’t reach it: a plain <div> isn’t focusable, so the arrow keys never get the chance to scroll it and the off-screen columns are stranded (2.1.1). The fix is to make the scroll container focusable and give it a name, so it lands in the Tab order and a screen reader announces it as a region.

<div style="overflow-x: auto">
  <table>
    <!-- many wide columns -->
  </table>
</div>

<div class="table-wrap" role="region"
     aria-label="Quarterly revenue by region" tabindex="0">
  <table>
    <caption>Quarterly revenue by region</caption>
    <!-- many wide columns -->
  </table>
</div>

function syncScrollFocus(region) {
  const overflows = region.scrollWidth > region.clientWidth;
  if (overflows) {
    region.setAttribute('tabindex', '0');
  } else {
    region.removeAttribute('tabindex');
  }
}

const region = document.querySelector('.table-wrap');
syncScrollFocus(region);
new ResizeObserver(() => syncScrollFocus(region)).observe(region);

A clickable column header that re-orders the table is a control, so Name, Role, Value (4.1.2) applies: it must expose its name, its role, and — crucially — its current state. The usual implementation shows the sort direction with a little up or down arrow drawn in CSS and nothing else. A sighted mouse user sees it; a screen reader user hears only “Date, column header” with no hint that the table is sorted by date, ascending. The state lives entirely in the pixels. aria-sort puts it back in the markup: set it to ascending, descending, or none on the one header that is currently controlling the order.

<th scope="col" class="is-sorted-asc" onclick="sortByDate()">
  Date
</th>
<!-- the ▲ is a CSS ::after arrow; nothing is in the a11y tree -->

<th scope="col" aria-sort="ascending">
  <button type="button">
    Date
    <span class="sort-icon" aria-hidden="true"></span>
  </button>
</th>
<th scope="col" aria-sort="none">
  <button type="button">Amount</button>
</th>

function setSort(table, activeTh, direction) {
  // direction is 'ascending' or 'descending'
  table.querySelectorAll('th[aria-sort]').forEach((th) => {
    th.setAttribute('aria-sort', 'none');
  });
  activeTh.setAttribute('aria-sort', direction);
  // ...reorder the <tbody> rows accordingly...
}

A popular mobile pattern turns each row into a stacked “card” by setting the table elements to display: block. Visually it’s tidy, but it’s also destructive: once a <tr> and its cells stop being table rows and cells, the browser no longer maps each value to its column header. A user then meets a column of bare values — £1,240, Paid, 2026-03-14 — with nothing saying which is the amount, the status, or the date. The header-to-value relationship that 1.3.1 requires has been thrown away by the very CSS that made it look neat. Keep the association by printing each cell’s header next to its value.

@media (max-width: 30rem) {
  table, thead, tbody, tr, th, td { display: block; }
  thead { display: none; }   /* headers gone — values now unlabelled */
}

<tr>
  <th scope="row">Invoice 042</th>
  <td data-label="Amount">£1,240</td>
  <td data-label="Status">Paid</td>
  <td data-label="Date">2026-03-14</td>
</tr>

@media (max-width: 30rem) {
  table, tbody, tr, td, th { display: block; }
  thead { display: none; }
  tr { margin-block-end: 1rem; }
  td::before {
    content: attr(data-label) ": ";
    font-weight: 600;
  }
}