scrollable-region-focusable
Web validation
When an element scrolls because overflow, overflow-x, or overflow-y is set to auto or scroll, keyboard users need a way to enter that region so they can reveal and explore content that sits outside the visible frame. The easiest method is to add tabindex="0" to the container, but that is not required if the region already contains a naturally focusable child (for example, a <button> or link). While any focusable element inside the scrolling box holds focus, standard keys such as Arrow Up/Down, Page Up/Down, and Space/Shift + Space scroll the region. Providing one or the other keeps the page fully operable for everyone.
Note: Some desktop browsers (such as Chrome, Edge, and Firefox) make scrollable regions keyboard-focusable by default, but others, including Safari and most mobile and tablet browsers, do not, so this rule is still important.
Pass Patterns
Making a container focusable
Adding tabindex="0" makes the region itself a keyboard stop and guarantees that users can scroll it.
<div style="max-height: 400px; overflow-y: auto;" tabindex="0">
<p>Lots of text …</p>
</div>Interactive child provides focus
Because the button is naturally focusable, no additional tabindex is required on the container. The small viewport (60 px × 200 px) plus long prose ensures hidden content that must be revealed by scrolling.
<div style="height: 60px; width: 200px; overflow: auto; border: 1px solid #ccc;">
<button type="button">Scroll Inside</button>
<p>
This content will overflow the container dimensions and will result in parts of
this content being hidden below the fold of its scrollable container.
</p>
</div>Fail Patterns
No focus target
The region scrolls visually, but neither the container nor any child is focusable, so keyboard users cannot enter it.
<div style="height: 250px; overflow: auto;">
<p>Scrollable prose …</p>
</div>The container is not focusable, and all children are removed from the tab order
Every interactive child has tabindex="-1" and the container is not focusable, eliminating all keyboard access.
<div style="height: 200px; overflow: auto;">
<button tabindex="-1">Hidden From Keyboard</button>
</div>ACT Rules
Try It Yourself
Because some browsers make scrollable regions focusable by default, routine testing with the keyboard can be misleading, so the testing here focuses on locating the relevant attribute or element.
Inspecting the browser dev-tools
- Open the browser dev tools.
- Move to the Elements panel, and locate the scrollable container in the DOM tree.
Expected result: The container has a tabindex="0" attribute or it has a focusable descendant (e.g., <button>, <a>, <input>, etc.).
Actual result: The container does not have a tabindex="0" attribute, and none of its descendants is included in the page focus sequence (i.e., can receive the focus when tabbing to it).
FAQ
How does this issue relate to 2.1.1 Keyboard?
Success Criterion 2.1.1 requires that every part of a page work with a keyboard alone. If a scrollable region cannot take focus, its content is unreachable without a pointing device, so the page fails this criterion.
Why is this issue marked as Serious?
When users cannot enter a scrollable region with the keyboard, essential information or controls may be hidden. This blocks people who rely on keyboards, switch devices, or voice input that emulates keystrokes.
Standards and Regulations
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 2.1.1 Keyboard (A) | All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. |
| EN 301 549 | 9.2.1.1 Keyboard | Same as the WCAG text. |
| 508 Trusted Tester | 2.1.1-keyboard-access, 4.A | All functionality can be accessed and executed using only the keyboard. |