How can I keep a focused control visible in a scrollable panel?
Quick answer
Move through the panel using only the keyboard and check that each focused control remains visible, including near the panel edges and beneath any fixed header or footer. Make sure the panel itself, or a keyboard-accessible scrolling method, lets users scroll its contents. Then continue tabbing to confirm the surrounding page is reachable. Test in the browsers your audience uses: scrollable-region focus behavior can vary. [S1] [S2] [S3]
The question, the details, the next step.
I have a page with a scrollable panel containing several controls. What should I test first?
Start with a keyboard-only pass. Use Tab and Shift+Tab to move focus through the page and panel; do not use a mouse to bring controls into view. At each step, pause and check whether the focused control can actually be seen. A focused item should not be entirely hidden by content added by the page, such as an overlay. [S1]
Test controls near the top, middle, and bottom of the panel. Repeat with the panel at different scroll positions, and check whether a fixed header or footer overlaps the focused control. The practical question is not simply whether a focus outline exists: can the user locate the focused item in the current viewport? W3C describes scrolling the focused item into view and CSS scroll-padding as possible approaches to overlap, not as the only required implementation. [S1] [S2]
How do I check whether keyboard users can scroll the panel itself?
Put focus inside the panel, then try the keyboard scrolling method supported by your page and browser. Observe whether the panel’s contents can move while focus remains usable. Also test what happens when focus first enters the panel and when it reaches its last control; a visually scrollable area is not enough if keyboard users cannot reach a way to scroll it.
Scrollable elements and their descendants need to be reachable by sequential keyboard focus navigation, unless another keyboard-accessible scrolling method is available. Browser behavior varies, so do not assume every browser treats a scrollable panel the same way. Test the actual page in the browsers you support. [S3]
Once the panel works, how can I make sure it does not trap keyboard users away from the rest of the page?
Continue the same keyboard pass beyond the panel. Tab forward from its last control and check that focus reaches the next page control; use Shift+Tab from the panel’s first control to check the reverse direction. Keep watching the focus indicator and the visible page as you move. A panel can scroll correctly while a separate problem still prevents access to surrounding content, so check those behaviors independently. The W3C focus-visibility criterion does not, by itself, establish keyboard access to every surrounding page region. [S1]
For example, suppose a panel contains a search field followed by several filter controls, and a fixed footer covers part of the viewport. Record whether each filter can be focused, whether the panel can scroll to reveal it, whether the footer still covers it, and whether tabbing onward reaches the next control outside the panel. If the footer overlap is the problem, a developer might test CSS scroll-padding on the relevant scroll container. Treat that as one candidate technique, then repeat the checks at each relevant viewport and in each target browser. [S2]
Can you give me a compact test record I can reuse for each panel?
Use this copyable record, filling in the bracketed details for your page. Mark each check as pass, fail, or not tested; a pass in one browser or viewport does not establish the result in another.
Panel: [name or page area] Browser and viewport: [browser/version] / [viewport] Keyboard-only test: [yes/no] Focused controls visible at top, middle, bottom: [notes] Fixed header/footer overlap: [notes] Can keyboard users scroll panel contents: [notes] Can keyboard users continue to surrounding page: [notes] Follow-up to retest: [change and test conditions]
If a check fails, note the exact control, panel position, and overlay involved. Retest after changes rather than relying only on a code inspection. scroll-padding is a W3C-documented technique for helping focused components avoid fixed-content overlap in supporting technologies; the cited technique does not establish that it solves every nested-scroll issue or works identically across browsers. [S2] [S3]
A practical checklist
Use Tab and Shift+Tab without a mouse, and record the browser and viewport.
Check focus visibility for controls near the panel’s top, middle, and bottom.
Look for overlap from fixed headers, footers, or other page-created content.
Verify keyboard users can scroll the panel, or use another keyboard-accessible scrolling method.
Continue tabbing in both directions to check access to the surrounding page.
Retest each relevant browser and viewport after making changes.
A few more useful answers
Does adding a visible focus outline guarantee the focused control is visible?
No. Check whether the focused control itself is visible in the viewport; an outline does not help if the control is entirely covered. [S1]
Is CSS `scroll-padding` required for every scrollable panel?
No. W3C presents it as one technique for helping focused content avoid fixed-position overlap, not as a mandatory solution. Test the relevant container and viewport. [S2]
Can I assume a scrollable panel is keyboard-focusable in every browser?
No. Browser behavior varies. Test the actual page and confirm keyboard users can reach the panel or another keyboard-accessible way to scroll it. [S3]
Sources
References used for this guide.