Keyboard navigation: focus order, skip links, and widgets

By UX Patterns GuideWorked decision updated November 6, 2026Editorial method

Start with a logical page Tab sequence. Add a skip link for repeated navigation and a managed keyboard model only for the component that needs it. A shortcut accelerates a command; it does not repair a broken route to that command.

Focus traversal live example Skip link live example Data grid live example

Worked decision · constructed example

Which keyboard behavior belongs to the page, and which belongs inside a widget?

A reviewer opens a document workspace with repeated navigation, a formatting toolbar, an editable data grid, and a Rename dialog. The reviewer needs to reach the document, edit a value, rename the file, and continue where they left off.

Try Focus traversal →Try Skip link →Try Data grid →

One task crosses several keyboard scopes
Point in the task	Expected behavior	Decision it resolves
Arrive at the workspace	An early skip link reaches the main work area.	Bypass repeated blocks rather than adding many extra Tab presses.
Move between controls	Tab and Shift+Tab follow the meaningful page order.	Arrange the source order to support the task before considering shortcuts.
Enter the toolbar or grid	The component supplies its documented arrow-key behavior and a route back out.	Treat the widget as a keyboard scope rather than making every cell a page stop.
Rename the file	Focus enters the modal, remains inside while open, and returns to its opener after cancellation.	Contain focus for the modal task, then restore the page route.

Why this choice

Each behavior solves a different movement problem. Giving every grid cell a Tab stop makes the page route unnecessarily long. Making arrow keys move across the whole page instead creates a surprising global interaction. Define the boundaries first, then test the transitions between them.

Where the decision changes

A normal table of readable values does not acquire a grid keyboard model just because it contains rows and columns. Use a grid when the interaction requires managed cell navigation, and budget for that behavior explicitly.

Try these checks

Start at the address bar and reach the main task using the keyboard.
Enter and leave each composite widget without losing visible focus.
Open Rename, cycle forward and backward, press Escape, and check the return target.
Repeat after a responsive layout change; visual order and keyboard order should still make sense together.

What the sources support

APG distinguishes page Tab movement from managed movement inside composite widgets. W3C APG: Keyboard interface ↗
MDN explains sequential focus participation and advises against positive tabindex values for routine ordering. MDN: tabindex ↗

These source claims were checked on 2026-11-06. The scenario and decision analysis are illustrative; the checks are a test plan, not reported results from a user study.

Compare the full pattern contracts

Dimension	Focus traversal	Keyboard shortcut	Skip link	Modal dialog	Toolbar	Data grid
UI or UX	UI + UX - Sequential keyboard focus path through interactive controls and state changes	UI + UX - Direct key combination that activates a known command, focus target, or mode	UI + UX - Keyboard-visible bypass link to primary page content	UI + UX - Focused modal task layer	UI + UX - View-scoped command strip for related controls	UI + UX - Interactive row-and-column data workspace
UI guidance	Render a visible focus path that follows source order and task meaning: skip link, global controls, page heading or first task control, local controls, form fields, inline help, error links, overlays, and next task actions.	Render keyboard shortcuts as discoverable command hints near the visible command, in shortcut help, in menus or toolbars when space allows, and in platform-specific form such as Command+S on macOS and Control+S on Windows.	Render a real link before repeated page chrome, usually as the first focusable control after required cookie or service banners, with destination-oriented text such as Skip to main content.	Render a titled layer above a dimmed or otherwise unavailable page, with clear task content, named actions, visible close or cancel affordance, and stable scroll boundaries.	Render a toolbar as a labelled command region attached to the view, editor, canvas, table, or selected object it controls, with grouped buttons, toggle buttons, menu buttons, separators, compact inputs, overflow, and current state visible where relevant.	Render the grid as a named work surface with visible headers, row identifiers, focus location, selection state, dirty and invalid cell markers, column controls, and status text for row count, sort, filter, and save state.
UX guidance	Use focus traversal design when users must move through a page or workflow with Tab and Shift+Tab and understand where focus will go next, where it came from, and how to recover after state changes.	Use keyboard shortcuts as accelerators for frequent, reversible, well-understood commands that already have visible controls or reachable command surfaces.	Use skip links to let keyboard, switch, screen-reader, and magnifier users bypass repeated navigation, headers, breadcrumbs, filter panels, or other repeated blocks before reaching the primary task or content.	Use the modal interruption only for compact tasks that genuinely need temporary focus before the user returns to the page.	Help the person reach a clear task outcome.	Use a data grid when cell-level interaction makes users faster and more accurate than opening each record separately.
Good UI	A checkout form focuses the page heading after route change, tabs through Contact, Delivery, Payment, Review, and Submit in the same order users read the page, then returns focus to the changed section after editing.	A document editor Save button shows Command+S on macOS and Control+S on Windows, disables the shortcut while a blocking validation dialog is open, and announces Saved draft.	The first Tab on a service page reveals a high-contrast Skip to main content link above the header.	Account settings opens in a titled dialog with one display-name field, Save, Cancel, close control, and dimmed inactive page context.	A document editor toolbar labels the current document, groups Undo and Redo, formatting toggles, alignment controls, Insert link, and More, with Bold shown pressed for the selected text.	An invoice-review grid shows frozen invoice IDs, column headers for Vendor, Amount, Due, Owner, and Status, one highlighted focused cell, two selected rows, a dirty edited amount, and a status line naming the current cell.
Bad UI	A two-column form tabs from first name to ZIP code to back link because CSS grid order and DOM order disagree.	A global D key deletes records while users type in comments or dictate with speech input.	The skip link appears after the full header, search box, account menu, and navigation list.	A vague popup titled Popup floats over active page controls and offers only OK.	Overflow hides essential commands or changes command order unpredictably.	A static report uses role grid even though users only read values and ordinary table semantics would be clearer.
Good UX	A keyboard user presses Tab from the skip link to the H1, through visible form controls in reading order, into an opened help popover, then back to the invoker after Escape.	A user presses Command+S in an editor, sees Saving then Saved, focus remains in the editor, and the same Save command remains available in the toolbar and menu.	A keyboard user presses Tab once, activates Skip to main content, and reaches the page heading instead of tabbing through 18 header links.	Opening moves focus to the display-name field, Tab remains inside the layer, Escape cancels, and closing returns focus to Open dialog.	A keyboard user tabs once into the editor toolbar, uses Right Arrow to move from Bold to Italic, presses Space to toggle Italic, and focus remains in the toolbar while selected text stays selected.	A user presses Arrow Right to move from Amount to Due, presses Enter to edit the due date, presses Escape to cancel, and focus returns to the same cell in navigation mode.
Bad UX	A screen reader user follows an error link, but focus stays on the summary while the visual page scrolls to the field.	A speech input user says a sentence containing g and d, triggering global shortcuts that navigate away and delete a draft.	Users must tab through global navigation, service navigation, breadcrumbs, and account links on every page before content.	Users can click background Delete or Navigate controls while the modal is still open.	A keyboard user must tab through twenty toolbar buttons before reaching the editor body.	The grid reports selection but the visual highlight is focus, or focus highlight is mistaken for selected data.
Best fit	A workflow has multiple focusable elements, dynamic content, or overlays that users traverse with keyboard or assistive technology.	Users repeat a known command often enough that memorized keyboard acceleration saves meaningful time.	Pages include repeated navigation, headers, breadcrumbs, filters, or other content before the main content.	A short task must interrupt normal page interaction but should return users to the same context afterward.	A view, editor, canvas, media surface, table, or selection needs repeated related commands close to the work area.	Users repeatedly inspect or update many records in shared columns.
Avoid when	The concern is a single command accelerator rather than focus movement.	The command is rare, novice-oriented, high-risk, or hard to explain before execution.	The desired behavior is browsing visible sections within the current page.	The workflow is long, multi-step, shareable, or needs browser navigation.	There are only one or two actions that should be ordinary buttons.	The data is read-only and ordinary table navigation is enough.
Required state	Initial page focus state after route change or page load.	Visible command with shortcut hint.	Default hidden-but-focusable state before keyboard focus.	Closed page state with an obvious invoking control.	Default toolbar with label, visible scope, grouped controls, and focusable entry point.	Default navigation state with labelled grid, column headers, row headers or row identifiers, focused cell, and row count context.
Accessibility burden	Ensure focus order preserves meaning and operability when users navigate sequentially.	Make all shortcut outcomes available through visible controls or reachable command surfaces.	Use a real link and a real fragment target so browser and assistive-technology behavior is predictable.	Use dialog semantics with an accessible name from the visible title.	Use role toolbar only for a cohesive group of controls whose grouping helps users, and give each toolbar a clear accessible name.	Use grid semantics only for an interactive composite widget with managed focus.
Common misuse	Using positive tabindex values to force a visual order instead of fixing DOM order.	Making a shortcut the only path to a primary command.	Placing the skip link inside the header or after the navigation it should bypass.	Using a modal as a generic container for routine information that could stay inline.	Using a toolbar for primary app navigation or unrelated destinations.	Using role grid on a static table only to make it sound richer.

Focus traversal

UI or UX: UI + UX - Sequential keyboard focus path through interactive controls and state changes
UI guidance: Render a visible focus path that follows source order and task meaning: skip link, global controls, page heading or first task control, local controls, form fields, inline help, error links, overlays, and next task actions.
UX guidance: Use focus traversal design when users must move through a page or workflow with Tab and Shift+Tab and understand where focus will go next, where it came from, and how to recover after state changes.
Good UI: A checkout form focuses the page heading after route change, tabs through Contact, Delivery, Payment, Review, and Submit in the same order users read the page, then returns focus to the changed section after editing.
Bad UI: A two-column form tabs from first name to ZIP code to back link because CSS grid order and DOM order disagree.
Good UX: A keyboard user presses Tab from the skip link to the H1, through visible form controls in reading order, into an opened help popover, then back to the invoker after Escape.
Bad UX: A screen reader user follows an error link, but focus stays on the summary while the visual page scrolls to the field.
Best fit: A workflow has multiple focusable elements, dynamic content, or overlays that users traverse with keyboard or assistive technology.
Avoid when: The concern is a single command accelerator rather than focus movement.
Required state: Initial page focus state after route change or page load.
Accessibility burden: Ensure focus order preserves meaning and operability when users navigate sequentially.
Common misuse: Using positive tabindex values to force a visual order instead of fixing DOM order.

Keyboard shortcut

UI or UX: UI + UX - Direct key combination that activates a known command, focus target, or mode
UI guidance: Render keyboard shortcuts as discoverable command hints near the visible command, in shortcut help, in menus or toolbars when space allows, and in platform-specific form such as Command+S on macOS and Control+S on Windows.
UX guidance: Use keyboard shortcuts as accelerators for frequent, reversible, well-understood commands that already have visible controls or reachable command surfaces.
Good UI: A document editor Save button shows Command+S on macOS and Control+S on Windows, disables the shortcut while a blocking validation dialog is open, and announces Saved draft.
Bad UI: A global D key deletes records while users type in comments or dictate with speech input.
Good UX: A user presses Command+S in an editor, sees Saving then Saved, focus remains in the editor, and the same Save command remains available in the toolbar and menu.
Bad UX: A speech input user says a sentence containing g and d, triggering global shortcuts that navigate away and delete a draft.
Best fit: Users repeat a known command often enough that memorized keyboard acceleration saves meaningful time.
Avoid when: The command is rare, novice-oriented, high-risk, or hard to explain before execution.
Required state: Visible command with shortcut hint.
Accessibility burden: Make all shortcut outcomes available through visible controls or reachable command surfaces.
Common misuse: Making a shortcut the only path to a primary command.

Skip link

UI or UX: UI + UX - Keyboard-visible bypass link to primary page content
UI guidance: Render a real link before repeated page chrome, usually as the first focusable control after required cookie or service banners, with destination-oriented text such as Skip to main content.
UX guidance: Use skip links to let keyboard, switch, screen-reader, and magnifier users bypass repeated navigation, headers, breadcrumbs, filter panels, or other repeated blocks before reaching the primary task or content.
Good UI: The first Tab on a service page reveals a high-contrast Skip to main content link above the header.
Bad UI: The skip link appears after the full header, search box, account menu, and navigation list.
Good UX: A keyboard user presses Tab once, activates Skip to main content, and reaches the page heading instead of tabbing through 18 header links.
Bad UX: Users must tab through global navigation, service navigation, breadcrumbs, and account links on every page before content.
Best fit: Pages include repeated navigation, headers, breadcrumbs, filters, or other content before the main content.
Avoid when: The desired behavior is browsing visible sections within the current page.
Required state: Default hidden-but-focusable state before keyboard focus.
Accessibility burden: Use a real link and a real fragment target so browser and assistive-technology behavior is predictable.
Common misuse: Placing the skip link inside the header or after the navigation it should bypass.

Modal dialog

UI or UX: UI + UX - Focused modal task layer
UI guidance: Render a titled layer above a dimmed or otherwise unavailable page, with clear task content, named actions, visible close or cancel affordance, and stable scroll boundaries.
UX guidance: Use the modal interruption only for compact tasks that genuinely need temporary focus before the user returns to the page.
Good UI: Account settings opens in a titled dialog with one display-name field, Save, Cancel, close control, and dimmed inactive page context.
Bad UI: A vague popup titled Popup floats over active page controls and offers only OK.
Good UX: Opening moves focus to the display-name field, Tab remains inside the layer, Escape cancels, and closing returns focus to Open dialog.
Bad UX: Users can click background Delete or Navigate controls while the modal is still open.
Best fit: A short task must interrupt normal page interaction but should return users to the same context afterward.
Avoid when: The workflow is long, multi-step, shareable, or needs browser navigation.
Required state: Closed page state with an obvious invoking control.
Accessibility burden: Use dialog semantics with an accessible name from the visible title.
Common misuse: Using a modal as a generic container for routine information that could stay inline.

Toolbar

UI or UX: UI + UX - View-scoped command strip for related controls
UI guidance: Render a toolbar as a labelled command region attached to the view, editor, canvas, table, or selected object it controls, with grouped buttons, toggle buttons, menu buttons, separators, compact inputs, overflow, and current state visible where relevant.
UX guidance: Help the person reach a clear task outcome.
Good UI: A document editor toolbar labels the current document, groups Undo and Redo, formatting toggles, alignment controls, Insert link, and More, with Bold shown pressed for the selected text.
Bad UI: Overflow hides essential commands or changes command order unpredictably.
Good UX: A keyboard user tabs once into the editor toolbar, uses Right Arrow to move from Bold to Italic, presses Space to toggle Italic, and focus remains in the toolbar while selected text stays selected.
Bad UX: A keyboard user must tab through twenty toolbar buttons before reaching the editor body.
Best fit: A view, editor, canvas, media surface, table, or selection needs repeated related commands close to the work area.
Avoid when: There are only one or two actions that should be ordinary buttons.
Required state: Default toolbar with label, visible scope, grouped controls, and focusable entry point.
Accessibility burden: Use role toolbar only for a cohesive group of controls whose grouping helps users, and give each toolbar a clear accessible name.
Common misuse: Using a toolbar for primary app navigation or unrelated destinations.

Data grid

UI or UX: UI + UX - Interactive row-and-column data workspace
UI guidance: Render the grid as a named work surface with visible headers, row identifiers, focus location, selection state, dirty and invalid cell markers, column controls, and status text for row count, sort, filter, and save state.
UX guidance: Use a data grid when cell-level interaction makes users faster and more accurate than opening each record separately.
Good UI: An invoice-review grid shows frozen invoice IDs, column headers for Vendor, Amount, Due, Owner, and Status, one highlighted focused cell, two selected rows, a dirty edited amount, and a status line naming the current cell.
Bad UI: A static report uses role grid even though users only read values and ordinary table semantics would be clearer.
Good UX: A user presses Arrow Right to move from Amount to Due, presses Enter to edit the due date, presses Escape to cancel, and focus returns to the same cell in navigation mode.
Bad UX: The grid reports selection but the visual highlight is focus, or focus highlight is mistaken for selected data.
Best fit: Users repeatedly inspect or update many records in shared columns.
Avoid when: The data is read-only and ordinary table navigation is enough.
Required state: Default navigation state with labelled grid, column headers, row headers or row identifiers, focused cell, and row count context.
Accessibility burden: Use grid semantics only for an interactive composite widget with managed focus.
Common misuse: Using role grid on a static table only to make it sound richer.

Decision rules

Choose focus traversal when users need a logical sequential focus order through links, buttons, fields, panels, validation messages, overlays, and return points using Tab and Shift+Tab.
Choose keyboard shortcut when one key combination directly invokes a known command instead of moving through the page focus sequence.
Choose skip link when the issue is bypassing repeated header, navigation, filter, or advertising blocks before reaching main content.
Choose modal dialog when focus must be intentionally contained inside a modal surface while background content is inert and focus returns to the invoker.
Choose toolbar when a labelled group of view-scoped controls benefits from one entry point, optional roving focus, arrow-key movement, and stable command grouping.
Choose data grid when two-dimensional cell focus for row-and-column interaction needs managed cell focus, arrow navigation, edit-mode boundaries, and one page tab stop.
Focus traversal must define source order, visible focus indicator, first focus target, next and previous Tab destinations, Shift+Tab behavior, focus return after close or submit, hidden-content removal, disabled-control policy, and recovery when target content changes.
Do not repair broken focus order with positive tabindex values, invisible focus targets, shortcut-only jumps, or CSS visual reordering that disagrees with DOM and reading order.
Focus traversal is incomplete if opening drawers, popovers, accordions, validation summaries, route changes, filters, virtualized lists, keyboard trap regions, or responsive layouts leaves focus on hidden, removed, offscreen, or unrelated controls.
Resolve traversal conflicts against skip links, landmarks, headings, modal focus containment, composite widget roving focus, keyboard shortcuts, browser focus behavior, and screen-reader browse modes.

Inspect live examples

Focus traversal Keyboard shortcut Skip link Modal dialog Toolbar Data grid

Failure modes

Tab order follows CSS columns visually in one mode and DOM order in another, causing focus to jump between unrelated sections.
A hidden drawer, collapsed panel, or disabled decorative element remains in the tab sequence.
A modal closes and focus returns to the top of the page instead of the opener or the next logical task.
Validation scrolls to an error but keyboard focus stays on the submit button.
Positive tabindex values make maintenance brittle and put focus before browser chrome, skip links, or main controls.
A virtualized list removes the focused row and leaves keyboard focus nowhere.
Focus rings are suppressed, so users cannot tell which item owns keyboard focus.