Scrollable region not keyboard accessible (scrollable-region-focusable)

The scrollable-region-focusable rule flags a box that scrolls – a wide table, a terms-and-conditions panel, a code block – when neither the box nor anything inside it can receive keyboard focus. Mouse and touch users can scroll it; keyboard users cannot reach the hidden part at all. The fix is to make the box focusable and name it: tabindex="0" with role="region" and a label.

What the rule means

WCAG 2.1.1 Keyboard requires that all functionality is available from a keyboard. Scrolling a box to read what is hidden is part of that. With the keyboard, a box scrolls with the arrow keys only once focus is on it or inside it.

axe-core reports an element when all of these are true:

• its content overflows, horizontally or vertically, by more than a few pixels, and the overflow is set to auto or scroll – overflow: hidden is not scrolling;
• some content actually lies outside the visible area;
• the element is not in the tab order and contains nothing that is – no link, button, form field or other element with tabindex="0".

A scrolling box with a link inside passes, because tabbing to the link scrolls the box. <select> and <textarea> are exempt, as are combobox popups.

What the rule does not check: whether scrolling by keyboard is comfortable, whether the focusable element inside actually brings the hidden content into view, and whether the box has a visible focus indicator once it is focusable. axe-core also tags the rule with 2.1.3 Keyboard (No Exception), a Level AAA criterion.

Who is affected

People who navigate by keyboard alone: people with motor disabilities using a keyboard, switch access or a mouth stick, and blind people using a screen reader together with the keyboard. For them, the columns of a table that do not fit, or the second half of a text in a fixed-height panel, simply do not exist. People who zoom in are affected more often, because content that fits on a wide screen starts scrolling in a narrow one.

Why the check fails

• Responsive tables wrapped in overflow-x: auto, the usual way to keep a wide table from breaking the layout on phones.
• Fixed-height text panels for terms, privacy notes or consent texts, with overflow-y: auto.
• Code blocks and pre-formatted text in documentation and blogs, which scroll sideways.
• Chat logs, activity feeds and comment lists in a scrolling container.
• Card rows and product sliders built as horizontal scroll areas with no links inside a card.
• Content that fits on desktop and overflows on mobile – which is why the problem often appears only at narrow widths.

How to fix it

1. Put tabindex="0" on the scrolling container, so it takes focus and the arrow keys scroll it.
2. Give it role="region" and a name – aria-labelledby pointing to a caption or heading, or aria-label – so screen readers announce what the focus stop is.
3. Give it a visible focus style, because it is now a keyboard stop like any control.
4. Better still, avoid the scroll where you can: let tables reflow into stacked rows on narrow screens, and let text panels grow.

<!-- Before: the fare table scrolls sideways, but nothing can take focus -->
<style>
  .table-scroll { overflow-x: auto; max-width: 20rem; }
  .table-scroll table { min-width: 40rem; }
</style>
<div class="table-scroll">
  <table>
    <caption>Fares by zone</caption>
    <tr><th scope="col">Zone</th><th scope="col">Single</th><th scope="col">Day ticket</th><th scope="col">Weekly pass</th></tr>
    <tr><td>A</td><td>£2.90</td><td>£8.10</td><td>£29.50</td></tr>
  </table>
</div>

<!-- After: a named, focusable region – Tab reaches it, arrow keys scroll it -->
<style>
  .table-scroll { overflow-x: auto; max-width: 20rem; }
  .table-scroll table { min-width: 40rem; }
</style>
<div class="table-scroll" tabindex="0" role="region" aria-labelledby="fares-caption">
  <table>
    <caption id="fares-caption">Fares by zone</caption>
    <tr><th scope="col">Zone</th><th scope="col">Single</th><th scope="col">Day ticket</th><th scope="col">Weekly pass</th></tr>
    <tr><td>A</td><td>£2.90</td><td>£8.10</td><td>£29.50</td></tr>
  </table>
</div>

And the focus style the new keyboard stop needs:

.table-scroll:focus-visible { outline: 2px solid #005fcc; outline-offset: 2px; }

How to test it manually

1. Resize the browser to phone width (or use the device toolbar in developer tools) – many scroll areas only appear there.
2. Press Tab through the page. Does focus reach every scrolling box, or something inside it?
3. When it does, press the arrow keys: does the box scroll, and can you reach all of its content?
4. Check that the focused box has a visible indicator, and with a screen reader, that it is announced with a meaningful name.
5. Some browsers now make scroll containers focusable on their own, so test in more than one, including Safari – a box that works in one browser may be unreachable in another.

Related WCAG criterion

2.1.1 Keyboard, Level A. Related: 1.4.10 Reflow, which allows two-dimensional scrolling only for content such as data tables that needs it, and 2.4.7 Focus Visible for the focus indicator on the container. 2.1.3 Keyboard (No Exception) is Level AAA and has no page here.

How Reviseberg reports it

Reviseberg runs scrollable-region-focusable on every crawled page at 1280px and again at 360px, because a table or panel that fits on a wide screen often starts scrolling on a narrow one. A region found at both widths is counted once. The issue list shows the rule with its severity, WCAG criterion 2.1.1 and level, the number of elements and pages, and the points you get back by fixing it. The detail view shows the selector and HTML snippet of the scrolling container and every affected page – a shared table wrapper or text-panel component usually explains all of them. You can mark a finding as "ignore", "can't fix" or "false positive" with a reason; every decision is logged.

No crawl settles 2.1.1 on its own. With no findings, the criterion shows as partly checked, not passed, until a person records a manual result.

Related rules

• undefined – the keyboard agent finds controls that Tab never reaches.
• undefined – focus with no visible indicator, which the new keyboard stop needs.
• undefined – the other rule that zoom and narrow screens bring into play.
• undefined – also checked again at 360px.

Check your tables and scroll areas at phone width – get a free scan