Skip to main content
Accessibility Field Guide

Focus Visible and Focus Order

A practical Field Guide page about making keyboard focus visible, predictable, and ordered so people do not lose their place on the page.

Colorful sticky notes arranged on a whiteboard schedule.
Photo: Colorful Sticky Notes Taped to Schedule on Whiteboard via Pexels — https://www.pexels.com/photo/colorful-sticky-notes-taped-to-schedule-on-whiteboard-15505432/
View full screen Download image

Keyboard access is not just whether someone can reach a control.

They also need to know where they are.

A visible focus indicator shows the user’s current place on the page. Focus order controls the path they move through as they press Tab, Shift + Tab, or use other keyboard commands.

When focus is visible and the order makes sense, the page has a trail.

When focus disappears, jumps around, moves behind a dialog, or lands on hidden controls, the user has to guess where the page took them.

That is when keyboard access starts to feel like wandering in the dark.

The common project moment

A team tests whether a page can be used without a mouse.

At first, the result looks okay. The user can press Tab. Some controls receive focus. Buttons can be activated.

But the path does not feel right.

Focus jumps from the header to the footer before the main content.

A modal opens, but focus stays behind it.

A user closes a menu and focus disappears.

A custom card receives focus, but there is no visible outline.

The focus indicator is so faint that it blends into the design.

A hidden item receives focus even though no one can see it.

Technically, some keyboard movement exists. Practically, the user cannot confidently follow the page.

What to notice earlier

Focus should be visible

When an interactive element receives keyboard focus, the user should be able to see it.

That visible cue might be an outline, border, underline, background change, or another clear treatment. The exact design can vary, but the purpose should not.

The user needs to answer one simple question:

Where am I right now?

If the focus indicator is removed, hidden, too subtle, or only visible in some parts of the page, the keyboard path becomes unreliable.

A common problem is removing the browser’s default outline without replacing it with an equally clear custom style. That may make the design look cleaner in a screenshot, but it removes the trail for keyboard users.

Focus order should follow the task

Focus order should usually follow the visual order and the task flow.

That means a user moving through the page should encounter things in an order that makes sense:

  • navigation before main content, when appropriate
  • fields in the order they appear in the form
  • help text before the control it explains, or closely connected to it
  • buttons after the information or fields they act on
  • dialog content before dialog actions
  • error summaries before the fields that need attention, when that pattern is used

The goal is not to force every page into one sequence. The goal is to avoid surprises.

If focus jumps around, users can lose the relationship between what they see, what they hear, and what they are trying to do.

Hidden content should not receive focus

If content is visually hidden because it is collapsed, inactive, behind a closed menu, or outside the current step, it usually should not be in the keyboard path.

Common issues:

  • closed accordion content still receives focus
  • hidden navigation menu links are still reachable
  • inactive tab panels receive focus
  • background page controls receive focus while a modal is open
  • off-screen controls receive focus with no visual context

A user should not tab into a place they cannot see or use.

If the page sends focus to hidden content, the trail breaks.

Dialogs and menus need intentional focus handling

Opening and closing layered UI is where many focus problems show up.

When a dialog opens, focus should move into the dialog or to a useful place inside it. While the dialog is open, focus should not wander into the page behind it. When the dialog closes, focus should return to a logical place, usually the control that opened it or the next sensible step.

Menus, popovers, help panels, and drawers need similar care.

A useful test question:

When this thing opens or closes, where does focus go next?

If no one has decided, the browser or component library may decide in a way that does not match the task.

Focus should not disappear after an action

Some actions change the page:

  • submitting a form
  • opening a modal
  • closing a modal
  • adding a row
  • deleting an item
  • filtering results
  • moving to the next step
  • showing an error summary
  • expanding a section

After the change, the user still needs a place to be.

If focus disappears, resets to the top, moves to the browser address bar, or lands somewhere unrelated, the user has to rebuild their context.

That is especially frustrating after errors or multi-step actions. The page should help the user continue, not make them find the path again.

Do not rely only on hover states

Design systems often spend time on hover states because they are easy to see in mouse testing.

Keyboard focus needs the same level of attention.

A control may have a hover style, active style, selected style, and disabled style, but no visible focus style. Or the focus style may be technically present but much harder to see than the hover state.

A practical design check:

If the mouse hover state is clear, is the keyboard focus state at least as easy to notice?

If not, keyboard users get a weaker version of the interface.

Questions teams can ask

During intake or requirements

  • Does the screen include dialogs, menus, accordions, tabs, drawers, or multi-step flows?
  • Does the screen show, hide, add, remove, or reorder content after user actions?
  • Are there error summaries, status messages, or dynamic updates?
  • Are any controls only visible after hover, selection, or expansion?
  • Are there embedded widgets or third-party components that manage focus themselves?

During design

  • Is there a visible focus style for every interactive component?
  • Is the focus style strong enough to see against the surrounding colors?
  • Does the design show focus states, not only hover states?
  • Is the expected tab order clear from the layout?
  • Are modal, menu, drawer, and popover focus behaviors accounted for?
  • Does the design avoid hiding important actions until mouse hover?

During development

  • Does the DOM order support the intended focus order?
  • Are hidden or inactive elements removed from the focus path when appropriate?
  • Does focus move to a useful place when dialogs, menus, or error summaries appear?
  • Does focus return to a logical place when those elements close?
  • Are custom focus styles visible and not clipped by overflow or layout rules?
  • Are scripts avoiding unexpected focus jumps?

During QA

  • Can you see focus on every interactive element?
  • Does focus move in a logical order through the page?
  • Does focus skip hidden, inactive, or unavailable content?
  • When a dialog opens, does focus move into it?
  • While a dialog is open, does focus stay inside it?
  • When a dialog closes, does focus return somewhere useful?
  • After submitting a form with errors, can you tell where focus went?
  • After dynamic updates, can you keep your place?

Common trail hazards

  • The default focus outline is removed and not replaced.
  • The focus indicator is too faint to see.
  • Focus order does not match the visible layout or task flow.
  • Hidden or collapsed content still receives focus.
  • Background page controls receive focus while a modal is open.
  • Focus disappears after opening, closing, submitting, filtering, or deleting.
  • Focus jumps to the top of the page after every update.
  • Hover states are clear, but focus states are missing or weak.
  • Custom controls have inconsistent focus behavior.
  • Error messages appear, but focus does not help the user find them.

Small habit

Do a slow Tab pass through the screen.

Do not only check whether focus moves. Watch where it moves.

Ask:

Can I see where I am, does the order make sense, and does the page keep my place when something changes?

If you lose the trail, the user probably will too.

Use these as trail markers, not as the whole conversation:

  • Keyboard-Only Navigation — for checking whether the same workflow is usable without a mouse.
  • Combobox — for focus behavior between an input, suggestion popup, active option, clear button, selected value, and error recovery.
  • Tabs — for focus behavior between the tab list, selected tab, active panel, and hidden panel content.
  • Modals and Dialogs — for focus movement when a dialog opens, traps focus, and returns focus after closing.
  • Status Messages and Alerts — for dynamic updates that need to be noticed without stealing focus unnecessarily.
  • QA Keyboard Check — for a quick keyboard and focus smoke test.
  • Accessibility Glossary — for plain-language definitions of common accessibility terms used across this guide.

What to do next

  • If the focus change happens because a dialog opened or closed, check Modals and Dialogs.
  • If the focus change follows a save, warning, loading state, or validation message, check Status Messages and Alerts.
  • If focus appears to move between an autocomplete input, suggestions, clear button, or selected values, check Combobox.
  • If focus moves between a row of tabs and the active panel, check Tabs.
  • If you need a quick hands-on test, use the QA Keyboard Check.