accessibility
Focus management
What is focus management, and why does it matter?
Focus management is deliberately controlling where the keyboard focus goes when the interface changes - moving it into a dialog when it opens, returning it to the trigger when it closes, sending it to a new view or an error. Get it right and a keyboard or screen-reader user is always somewhere sensible; get it wrong and they're dumped back at the top of the page, lost.
Also known as: focus management, managing focus, focus on dialog
The demo
Use the keyboard. Open and close the dialog with focus managed, then with it broken, and watch the "focus is on" tracker - it's where your next keystroke would land.
What this demo shows (text version)
A "delete item" button opens a confirmation dialog. A tracker shows where keyboard focus currently is. With focus managed, opening the dialog moves focus onto its first button, and closing it (Cancel, Delete or Escape) returns focus to the "delete item" button you started from - so you never lose your place. With focus unmanaged, opening the dialog leaves focus stranded behind it, and closing drops focus back to the top of the page.
Focus is the keyboard user's cursor and often what a screen reader announces, so when the UI changes it must be sent somewhere sensible - into the dialog that opened, back to the trigger that closed, to a new view's heading or a form's first error. The most-missed step is returning focus to where it came from. Manage focus deliberately, but never yank it unbidden, and keep a visible focus indicator so people can see where they've landed.
When the UI changes, focus has to go somewhere deliberate: into a dialog when it opens, back to the control that opened it when it closes, to the heading of a new view, or to an error that needs fixing. Leave it to chance and keyboard and screen-reader users get stranded - acting on invisible elements or thrown back to the top after every action. Always send focus, and always send it back.
With focus managed, opening the dialog put you right inside it and closing it returned you to the exact button you came from - you never lost your place. Broken, the dialog opened but your focus was still stranded behind it, and closing dumped you at the top of the page. Same dialog; only where the focus went decided whether you stayed oriented.
Focus is the keyboard user's cursor - it's where their next keystroke lands and, for a screen-reader user, often what gets announced. So when content appears, moves or disappears, focus must be sent somewhere meaningful: into the dialog or menu that opened, to the first error on a failed submit, to the heading of a freshly-loaded view. Unmanaged, it stays on a now-hidden element or falls back to the page top.
The most important and most-missed move is returning focus. When a dialog, menu or panel closes, focus should go back to the control that opened it - not vanish to the body. Without that return, a keyboard user is silently teleported to the top of the page and has to tab all the way back to where they were, every single time.
Manage it, but don't steal it. Move focus in response to a user action or a change they'd expect, not at random or on a timer - yanking focus unbidden is as disorienting as losing it. And pair focus moves with a visible focus indicator (see interactive states) so sighted keyboard users can see where they've landed.