axe-core scrollable-region-focusable error region not keyboard accessible

axe-core scrollable-region-focusable error region not keyboard accessible - how to fix it

TL;DR

A [div] with overflow scroll that is not focusable traps its content away from keyboard users: they can never scroll it. Add tabindex="0" plus role="region" and an aria-label describing the content, for example [div tabindex="0" role="region" aria-label="Terms and conditions"]. Keep the visible focus style so keyboard users can see where they are.

Scroll-gated consent ('scroll to the bottom to enable the agree button') is the highest-stakes version of this bug: if the terms box is not keyboard-focusable, keyboard users literally cannot consent. When you fix the region, also verify the gating logic works with keyboard scrolling, not just mouse wheel events.

The verbatim error looks like this:

axe-core 4.x
Rule: scrollable-region-focusable (serious)
"Elements that have scrollable content should be accessible by keyboard"

Element: [div class="terms-box" style="overflow-y: scroll; height: 200px"]
  Scrollable region is not focusable; keyboard users cannot scroll it.

Steps

1. Reproduce with the single rule:

npx @axe-core/cli https://example.com/signup --rules scrollable-region-focusable

Expected: each non-focusable scrollable region is listed.

2. Confirm the flagged element genuinely scrolls (overflow auto/scroll with constrained height) and contains content a keyboard user would need to read, like terms text or a log view.
3. Make it focusable and named:

[div class="terms-box" tabindex="0" role="region" aria-label="Terms and conditions"]
  ...scrollable content...
[/div]

Ensure your CSS does not suppress the focus outline on this element.

4. Re-run the focused scan. Expected output: 0 violations for scrollable-region-focusable.
5. Keyboard-test: tab to the region, confirm a visible focus indicator, and scroll with arrow keys. Then confirm a screen reader announces the region name on entry.
6. Test the scroll-gating logic with keyboard only. Some implementations listen for mouse wheel or touch scroll events and never fire on keyboard scrolling. The scroll event fires for keyboard scrolling too, but only if the region is focusable first.
7. Consider whether the region should scroll independently at all. Long terms text that scrolls with the page needs no tabindex and no fix. Independent scroll regions should be the exception, used for chat logs, code viewers, and genuinely constrained panels.

When to use

• Axe flags scrollable-region-focusable on overflow containers.
• A terms-and-conditions box, chat log, or code viewer scrolls with a mouse but not a keyboard.
• A dashboard panel with internal scroll is unreachable by keyboard.

When not to use

• The scrollable thing is the whole page (page scroll is always keyboard-accessible).
• The region is a carousel or tab panel (build the full widget pattern with arrow-key semantics, not just tabindex).
• The content is decorative or duplicated elsewhere (consider removing the scroll region).

Why it happens

Mouse and touch users scroll any overflow region directly, but keyboard users can only scroll what they can focus. An unfocusable scroll region is effectively read-only for keyboard users, which breaks forms (unread terms), dashboards (unseen data), and any scroll-gated consent flow. The tabindex="0" puts it in the tab order where keyboard users expect it.

Independent scroll regions proliferated with dashboard and chat UI patterns. Developers build them with overflow CSS, test with a mouse, and never discover the keyboard gap because tab order skips the region entirely. The bug is invisible in the most common testing setups, which is why it needs an automated rule.

Edge cases

• tabindex="0" adds a tab stop. On pages with many scroll regions this gets tedious; consider whether the content should scroll with the page instead.
• role="region" without an accessible name is itself a violation in some configurations. Always pair it with aria-label or aria-labelledby.
• Overflow regions created by virtualized lists (react-window style) need the focus target on the scroll container, not on rows that get recycled.
• Do not use tabindex greater than 0 to 'prioritize' the region; that triggers the separate tabindex rule.
• A scroll region that contains no focusable content and only text still needs tabindex="0" for keyboard scrollers. The rule applies to content access, not just widget access.
• role="region" makes the landmark appear in screen reader landmark navigation. For minor scroll boxes, tabindex="0" with an aria-label and no role can be less noisy.
• Sticky headers inside scroll regions can trap keyboard focus visually. Test arrow-key scrolling end to end.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstBlOWSDbtyN0ZcwXB9YGkA