Back to compare picker

Focus traversal vs Keyboard shortcut vs Skip link vs Modal dialog vs Toolbar vs Data grid

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.

Decision dimensions

Dimension Focus traversalKeyboard shortcutSkip linkModal dialogToolbarData grid
UI or UX UI + UX - Sequential keyboard focus path through interactive controls and state changesUI + UX - Direct key combination that activates a known command, focus target, or modeUI + UX - Keyboard-visible bypass link to primary page contentUI + UX - Focused modal task layerUI + UX - View-scoped command strip for related controlsUI + 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.Use a toolbar when users repeatedly apply related commands to the same view or selection and need fast visible access without opening a modal command surface.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 product hides Submit behind Control+Enter with no visible button, hint, focus rule, or mobile equivalent.The skip link is hidden with display none and never receives keyboard focus.A vague popup titled Popup floats over active page controls and offers only OK.A toolbar contains Back, Save, Delete, Pricing, Account, Filter, and Help with no shared scope or grouping.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 keyboard user tabs into an offscreen drawer and cannot see or escape the focused control.A screen reader user cannot discover the shortcut because it is not exposed in help, command labels, or aria-keyshortcuts.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.A user edits an amount, sorts by status, and the row disappears with no saved or unsaved indication.
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.There is no repeated block before the main content and the first focusable control is already the content task.The content is only informational and does not require blocking the page.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.Labelling any horizontal button row as a toolbar without shared scope or keyboard behavior.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 keyboard user tabs into an offscreen drawer and cannot see or escape the focused control.
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 product hides Submit behind Control+Enter with no visible button, hint, focus rule, or mobile equivalent.
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 screen reader user cannot discover the shortcut because it is not exposed in help, command labels, or aria-keyshortcuts.
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 is hidden with display none and never receives keyboard focus.
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
There is no repeated block before the main content and the first focusable control is already the content task.
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 content is only informational and does not require blocking the page.
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
Use a toolbar when users repeatedly apply related commands to the same view or selection and need fast visible access without opening a modal command surface.
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
A toolbar contains Back, Save, Delete, Pricing, Account, Filter, and Help with no shared scope or grouping.
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
Labelling any horizontal button row as a toolbar without shared scope or keyboard behavior.

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
A user edits an amount, sorts by status, and the row disappears with no saved or unsaved indication.
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
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.