FrontendHaltKeyboard and focus management
Create predictable keyboard interaction, visible focus, modal focus containment, and sensible restoration.
WHAT YOU WILL BE ABLE TO DO
Learning outcomes
- Explain keyboard and focus management in plain language.
- Connect the behavior to the underlying browser or framework model.
- Implement the core pattern and reason through edge cases.
- Answer common follow-ups without relying on memorized phrases.
01Explain it simply
Keyboard access means every interactive feature can be reached and operated without a pointer. Focus management controls where keyboard input goes when interfaces open, close, validate, or navigate.
One-line definition: Create predictable keyboard interaction, visible focus, modal focus containment, and sensible restoration.
02Mental model
Use native tab order for normal document flow. Programmatic focus is reserved for meaningful context changes such as opening a dialog, reporting an invalid form, or moving between composite-widget items.
03Step by step
- Use native interactive elements.
- Keep DOM order aligned with visual order.
- Provide a visible focus indicator.
- Move focus into modal UI and restore it on close.
- Use roving tabindex for composite widgets such as tabs or menus.
04Working example
const trigger = document.querySelector('#open');const dialog = document.querySelector('dialog');
trigger.addEventListener('click', () => dialog.showModal());dialog.addEventListener('close', () => trigger.focus());The native dialog handles modal focus containment in supporting browsers, while explicit restoration returns the user to the control that opened it.
05Where it is used
- Dialogs and drawers
- Form error recovery
- Menus, tabs, and listboxes
- Client-side route changes
06Common mistakes
- Positive tabindex values that create a second tab order
- Removing outlines without a replacement
- Moving focus on every rerender
- Closing a dialog without restoring context
07Interview answer
Describe initial focus, containment, Escape behavior, restoration, and how the interaction follows the relevant ARIA Authoring Practices pattern.
Should every div be made focusable so keyboard users can reach all content?
No. Static content is read through normal document navigation; only interactive controls or deliberate programmatic-focus targets should enter the tab order.
DDConcept deep dives
Deep dive 1
DOM order is the default navigation model
Tab normally follows focusable elements in document order. A logical DOM gives keyboard and assistive navigation the same reading sequence as the visual interface. Positive tabindex creates a competing order that becomes impossible to maintain as responsive layouts and conditional controls change.
- Use native controls so focusability and activation are built in.
- Static content does not need tabindex merely to be readable.
- Use :focus-visible for clear keyboard indicators without suppressing focus styles.
Deep dive 2
Composite widgets manage one Tab stop
Tabs, menus, listboxes, and toolbars commonly use roving tabindex: one item is in the Tab sequence and arrow keys move the active item. The exact keys, roles, selection behavior, and focus rules depend on the established widget pattern. Implementing only arrow keys without semantics produces an incomplete custom control.
- Home and End often move to first and last items where the pattern specifies.
- Selection may follow focus or require activation depending on cost and convention.
- Type-ahead behavior improves large option sets.
Deep dive 3
Modal UI owns focus from open through close
Opening a modal moves focus inside, makes background content unavailable, and keeps Tab navigation within the modal. Closing restores focus to the opener when it still exists or to another logical control. Visual transition timing must not leave focus inside content that has become invisible or inert.
- Choose initial focus based on task meaning, not always the first button.
- Support Escape unless the operation genuinely cannot be dismissed.
- Native dialog can supply important modal behavior but still needs labels and restoration logic.
QAInterview questions and model answers
Attempt each answer aloud before opening it. The model answer shows the depth and precision expected in an interview; it is not a script to memorize.
Intermediate · Conceptual · 1 min · Question 1What should be in the normal tab order?Open model answer
Model answer
Native interactive controls and deliberate widget focus stops should be reachable in logical DOM order. Static text does not need tabindex. Avoid positive tabindex because it creates a second, fragile navigation order.
Open question page →Intermediate · Conceptual · 1 min · Question 2How should a modal dialog manage focus?Open model answer
Model answer
Move focus to an appropriate element inside, contain Tab navigation while modal, support Escape where the interaction permits, hide or inert background interaction, and restore focus to the trigger or another logical destination on close.
Open question page →Intermediate · Conceptual · 1 min · Question 3What is roving tabindex?Open model answer
Model answer
A composite widget keeps one item at tabindex=0 and the rest at -1, moving the active stop with arrow keys. This gives the overall widget one Tab stop while supporting internal keyboard navigation according to its pattern.
Open question page →Intermediate · Conceptual · 1 min · Question 4When should code move focus?Open model answer
Model answer
Only for meaningful context changes or recovery, such as opening a dialog, focusing an invalid field after submission, or restoring the trigger. Moving focus on ordinary rerenders disorients users.
Open question page →Intermediate · Conceptual · 1 min · Question 5What makes a good focus indicator?Open model answer
Model answer
It must be clearly visible against adjacent colors, follow the actual focused control, survive high-contrast modes where possible, and not rely only on subtle color change. :focus-visible can avoid pointer-only rings without removing keyboard feedback.
Open question page →Intermediate · Conceptual · 1 min · Question 6How should focus work after client-side navigation?Open model answer
Model answer
Users need confirmation that page context changed. Depending on the router and product, move focus to the page heading or a route-announcement target and update the document title, while avoiding unexpected focus movement for in-page state changes.
Open question page →Beginner · Conceptual · 1 min · Question 7What does tabindex=-1 do?Open model answer
Model answer
It removes an element from sequential Tab navigation while still allowing programmatic focus, useful for headings, error summaries, and managed composite items.
Open question page →Advanced · Conceptual · 1 min · Question 8Should clicking a control always show focus-visible styling?Open model answer
Model answer
:focus-visible lets the browser infer when a strong focus indicator is needed, generally preserving it for keyboard navigation without forcing identical pointer styling.
Open question page →Advanced · Conceptual · 1 min · Question 9How should focus behave after deleting a row?Open model answer
Model answer
Move it to the next logical row action, the previous row when no next exists, or the containing region when the list becomes empty, and announce the result.
Open question page →Advanced · Conceptual · 1 min · Question 10What is inert?Open model answer
Model answer
The inert attribute makes a subtree unavailable for focus and user interaction and removes it from relevant accessibility exposure, useful for modal background management.
Open question page →SCScenario questions
Scenario 1
A side drawer visually closes, but keyboard focus remains on an invisible button inside it.
- Restore focus as part of the close transition lifecycle.
- Return it to the opener when it still exists.
- Choose a nearby logical destination if the opener was removed.
- Ensure hidden content is no longer tabbable before the transition completes.
Reveal worked answer
The drawer owns both initial focus and restoration. On close I would make its contents non-interactive immediately, then restore focus to the stable trigger. If closing also deletes the trigger, focus moves to the next meaningful control or region instead of falling to the document body.