Keyboard-Scrollable Table Containers

A keyboard-scrollable table container is an element with overflow-x: auto wrapping a wide table, made focusable with tabindex="0" so a keyboard user can move focus to it and scroll it with the arrow keys. Without the tabindex, a table with no interactive content inside it cannot be scrolled by keyboard at all: the columns beyond the right edge are visible to mouse and touch users and unreachable to everyone else. axe-core reports this as scrollable-region-focusable, and it is one of the most common findings on data-heavy pages.

This page covers the container’s markup, name, focus style and scroll affordance. It belongs to responsive data tables.

Spec reference

Browsers scroll a focused scrollable element with arrow keys, Page Up/Page Down and Home/End. Chromium has made some scroll containers keyboard-focusable by default since version 130 when they contain no focusable children, but other engines do not, and the behaviour differs when the table contains links or buttons. Setting tabindex="0" explicitly makes it consistent.

Once the container is focusable, it needs an accessible name, because screen readers announce focused elements. role="region" with aria-labelledby pointing at the table caption gives it a name and makes it a landmark; a focusable <div> with no role or name is announced as “clickable” or not at all.

Criteria in play: SC 2.1.1 Keyboard (the hidden columns must be reachable), SC 2.4.7 Focus Visible (the container needs a focus indicator), SC 4.1.2 Name, Role, Value (a focusable element needs a name and role), and SC 1.4.10 Reflow, which exempts data tables from the no-horizontal-scroll rule but not from being operable.

The scroll container, from outside in Layers of a keyboard-scrollable table: the region wrapper with tabindex, role and name; its focus ring and edge shadows; and the table with its caption inside. The scroll container, from outside indiv role="region"tabindex="0", aria-labelledby pointing at the caption, overflow-x: autoFocus and affordancea visible focus ring on the wrapper; edge shadows when content overflowstablecaption with an id; headers and cells unchanged
The wrapper is the only new element — everything it needs is attributes and CSS.

When to use a scroll container — and when not to

Use it for tables whose meaning depends on columns: comparisons across periods, financial statements, pivots, anything a user reads across a row and down a column. Two-dimensional scrolling is the explicit exception WCAG makes for data tables, because reflowing them into a single column destroys the information.

Do not add tabindex="0" when the table already contains focusable elements in every column that needs to be reached — for example, a grid with a roving tabindex that scrolls cells into view. Adding a second tab stop for the container then adds noise. Keep it where the table is static.

The misapplication to name is overflow: hidden on the wrapper with a custom drag-to-scroll gesture. It looks sleek and removes the columns from keyboard and screen reader reach entirely.

Annotated code example

<!-- SC 2.1.1 + 4.1.2: focusable, named, scrollable -->
<div class="table-scroll" role="region" aria-labelledby="orders-cap" tabindex="0">
  <table>
    <caption id="orders-cap">Orders by month, 2026</caption>
    <!-- 14 columns: Jan … Dec, Total, Change -->
  </table>
</div>
.table-scroll {
  overflow-x: auto;
  max-inline-size: 100%;
  /* scroll shadows: visible cue that more columns exist */
  background:
    linear-gradient(to right, var(--surface) 30%, transparent) left / 2rem 100% no-repeat local,
    linear-gradient(to left,  var(--surface) 30%, transparent) right / 2rem 100% no-repeat local,
    radial-gradient(farthest-side at 0 50%, var(--shadow), transparent) left / 0.75rem 100% no-repeat scroll,
    radial-gradient(farthest-side at 100% 50%, var(--shadow), transparent) right / 0.75rem 100% no-repeat scroll;
}
/* SC 2.4.7: the container itself shows focus */
.table-scroll:focus-visible {
  outline: 3px solid var(--color-focus);
  outline-offset: 2px;
}
// Optional: only make the wrapper focusable when it actually overflows
const ro = new ResizeObserver(([entry]) => {
  const el = entry.target;
  const overflows = el.scrollWidth > el.clientWidth;
  el.toggleAttribute('tabindex', overflows);
  if (overflows) el.setAttribute('tabindex', '0');
});
document.querySelectorAll('.table-scroll').forEach((el) => ro.observe(el));

The optional observer removes the extra tab stop on wide screens where nothing scrolls, and adds it back when the viewport narrows or the user zooms. It is a refinement; the static tabindex="0" alone is correct.

Keyboard & AT behaviour

Key / event Expected result Announcement
Tab to container Focus ring on the wrapper “Orders by month, 2026, region”
Right Arrow Scrolls ~40px right None (scrolling is silent)
End Scrolls to the last column None
NVDA T then Ctrl+Alt+Right Moves by cell; browser scrolls cell into view Cell with headers
VoiceOver iOS three-finger swipe Scrolls the region “Page 2 of 3” style scroll position

Screen reader users navigating by table commands do not need the container to be focused — the browser scrolls cells into view as the virtual cursor reaches them. The tabindex is primarily for sighted keyboard users, and the name is there because once something is focusable, it will be announced.

Default keyboard reach of a scrolling table Matrix of browsers and whether a static table inside an overflow container can be scrolled by keyboard without tabindex, and with it. Default keyboard reach of a scrolling tableBrowserWithout tabindexWith tabindex="0"Chrome 130+Focusable by default if no focusable childrenFocusable, namedFirefoxFocusable, but unnamedFocusable, namedSafariNot focusableFocusable, namedAny, with links insideOnly reachable via the linksContainer and links
Explicit tabindex makes every browser behave the same way.

Integration context

Scrolling tables lose their row context when the first column scrolls out of view. Making the first column and header row sticky, as in sticky headers and first columns, keeps sighted users oriented; screen reader users get the headers announced regardless.

axe-core’s scrollable-region-focusable rule catches the missing tabindex; it does not check the name. Add a custom assertion that every focusable [role="region"] has an accessible name — see configuring axe-core rules and handling false positives.

Checking one container by hand Four manual checks for a scroll container: tab to it, see the focus ring, scroll with arrows to the last column, and hear its name with a screen reader. Checking one container by handTab to itfocus lands on the wrapper, not past itSC 2.1.1See focusa visible ring on the wrapperSC 2.4.7Arrow to the endthe last column becomes visibleSC 2.1.1Hear its name"Orders by month, 2026, region"SC 4.1.2
Four checks, one minute — and they catch every failure on this page.

Gotchas

Many scroll regions on one page. Each becomes a landmark. On a dashboard with twelve small tables, twelve regions clutter the landmark list. Use role="group" with a name instead of region when there are more than a few.

Vertical and horizontal scrolling together. A container with a fixed height that scrolls both ways can trap mouse-wheel users and confuse keyboard users. Prefer page-level vertical scrolling and container-level horizontal scrolling.

Focus hidden by sticky headers. When a page has a sticky header, the focused container may scroll under it; add scroll-margin-top to satisfy SC 2.4.11 Focus Not Obscured.

Testing checklist

FAQ

Why does a scrolling table need tabindex="0"?

Because keyboard users can only scroll an element that has focus. A table with no links or buttons inside gives them nothing to focus, so the columns off-screen are unreachable. tabindex=“0” makes the container itself focusable and scrollable with arrow keys.

Does the scroll container need an accessible name?

Yes, once it is focusable. Screen readers announce focused elements, and an unnamed focusable div is confusing. role=“region” with aria-labelledby pointing at the table caption gives it a clear name.

Does horizontal scrolling of a table fail SC 1.4.10 Reflow?

No. Data tables are an explicit exception because their meaning depends on two-dimensional layout. The table must still be operable, which is what the focusable container provides.

Is Chrome's default focusable scroller enough?

Not on its own. Other browsers do not do the same, and even in Chrome the element has no name. Setting tabindex, role and a name explicitly gives consistent behaviour everywhere.

← Back to Responsive Data Tables