Don't steal focus from the layout picker during arrow-key layout stepping [#1026]#1340
Open
milosde111 wants to merge 1 commit into
Open
Don't steal focus from the layout picker during arrow-key layout stepping [#1026]#1340milosde111 wants to merge 1 commit into
milosde111 wants to merge 1 commit into
Conversation
Updated the applyLayout function to accept an options parameter, allowing control over focus behavior during layout changes. Added logic to maintain focus on the picker during arrow-key navigation, preventing unwanted focus shifts to newly visible slots. Updated tests to verify that focus remains on the picker and that nested elements do not trigger layout changes. This improves accessibility and user experience when navigating layouts.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes two keyboard correctness bugs in the layout-first picker that remain after #1295 (arrow-key operation) and #1300 (roving tabindex). Without these fixes, arrow-key layout browsing is broken: focus leaves the picker mid-step and navigation keys bubbling from nested label content can change the selection unintentionally.
Problem
After #1295 and #1300, a keyboard user can step through interview / solo / panel with arrow keys and Home/End while the picker acts as a single tab stop. Two issues remain:
Focus is stolen mid-step.
applyLayout()always auto-focuses a newly visible or blocking slot (e.g. Guest 2 when stepping to panel). That runs before the picker handler refocuses the next layout option, briefly routing focus into the canvas and announcing slot state while the creator is still browsing layouts.Bubbled navigation keys can step layouts. The picker keydown handler does not check
event.target, so an arrow key bubbling from nested label content inside a layout button can trigger layout stepping — the same failure mode fixed for placed-video move in Don't let the placed-video keyboard handler hijack its child controls… #1285.Solution
keepPickerFocusflag toapplyLayout(). The arrow-key picker path passes{ keepPickerFocus: true }; all other callers (click, reset, programmatic) keep the existing auto-focus behavior.event.target === button, matching the placed-video keyboard pattern from Don't let the placed-video keyboard handler hijack its child controls… #1285.No new UI, dependencies, or live-region copy. Pointer-driven layout selection and placement-focus behavior are unchanged.
Test plan
node preview/layout-first.test.js— arrow-key stepping to panel keeps focus on the picker; bubbled keys from nested labels are ignorednode preview/layout-first-placement-focus.test.js— click/programmatic layout switch still auto-focuses the correct slotnpm testRelated
event.targetguard