Scrollable Region Keyboard

What this check is really testing

Lighthouse and the axe-core engine behind it flag "Scrollable region must have keyboard access" when they find an element whose content overflows and scrolls, but which cannot receive keyboard focus. In plain terms: a mouse user can scroll that box with a wheel or trackpad, but a keyboard-only user cannot Tab to it and cannot drive it with the arrow keys, Page Up, Page Down, Home, or End. The content inside is effectively unreachable for anyone who does not use a pointer.

This shows up constantly on code blocks with horizontal overflow, data tables wrapped in a scrolling <div>, chat panes, sidebars, and any container styled with overflow:auto or overflow:scroll that holds no natively focusable child. The rule is simple once you know it: if a region scrolls, either it must be focusable itself, or it must contain something focusable like a link, button, or input that a keyboard user can Tab into.

Why it matters

Keyboard operability is one of the load-bearing pillars of WCAG. Screen reader users, people with motor impairments who cannot use a mouse precisely, and plenty of power users navigate entirely by keyboard. When a scroll region is a keyboard dead zone, they physically cannot read the half of your table or code sample that sits below the fold of that box. It is not a cosmetic nit. It is content that exists on the page but is locked away from a real slice of your audience.

On the SEO and quality side, accessibility failures pull down your Lighthouse accessibility score, and that score is part of how teams judge page quality in audits and PageSpeed reports. It will not directly tank your rankings, but it is a signal of sloppy front-end work, and it is exactly the kind of thing that gets flagged in a procurement review or an accessibility complaint. I would rather fix a one-attribute problem now than answer a legal letter about it later.

How to detect it

• Lighthouse in Chrome DevTools: run the Accessibility audit and look for "Scrollable region must have keyboard access" under the failing items. It lists the exact offending elements.
• axe DevTools browser extension: the same rule fires here (scrollable-region-focusable) with the node highlighted on the page.
• The keyboard test, which costs nothing: unplug your mouse, load the page, and Tab through it. If you hit a box that scrolls with a wheel but you cannot reach or arrow through with the keyboard, you found it.
• WAVE by WebAIM for a visual overlay if you prefer that workflow.

How to fix it

The core fix is one line. On the scroll container, add tabindex="0". That makes it focusable in the Tab order, and browsers then let the arrow keys, Page Up, Page Down, Home, and End scroll it. Then give it a name and a role so assistive tech announces it as a scrollable region rather than an anonymous box:

<div class="table-scroll" tabindex="0" role="region" aria-label="Pricing table">
  <table> ... </table>
</div>

One trap to avoid: do not slap tabindex="0" on a region that already contains focusable elements. That creates a redundant, confusing extra stop in the Tab order. If a link or input already lives inside, the region is already reachable and you should leave it alone.

Do vs Don't

What "good" looks like

Every scrolling region on the page is either reachable through a focusable child or carries tabindex="0" with a clear role and label. You can Tab into each scroll box, drive it with arrow keys, and a visible focus ring tells you where you are. Run Lighthouse and the accessibility item is gone. That is the whole job, and it is one of the highest-value-per-minute fixes in the entire accessibility report.

FAQ