Skip to main content
Accessibility Field Guide

Keyboard-Only Navigation

A practical Field Guide page about checking whether people can move through screens, controls, menus, dialogs, and forms without using a mouse.

Close-up of a laptop keyboard.
Photo: Close-up of Laptop Keyboard via Pexels — https://www.pexels.com/photo/close-up-of-laptop-keyboard-257879/
View full screen Download image

A screen should still make sense when the mouse is gone.

That is one of the quickest accessibility checks a team can do. Put the mouse aside, use the keyboard, and try to complete the task.

Can you reach the controls?

Can you tell where you are?

Can you open and close menus, dialogs, accordions, date pickers, and custom widgets?

Can you submit the form, fix errors, and keep going?

If the answer is no, the page may look complete but still be blocked for keyboard users, screen reader users, switch users, voice-control users, and anyone who cannot or does not use a mouse for that task.

Keyboard review is not the whole accessibility review. But it is a very good way to find broken paths early.

The common project moment

A team builds a screen with normal-looking controls:

  • buttons
  • links
  • form fields
  • dropdowns
  • menus
  • accordions
  • tabs
  • modals
  • tables
  • upload controls
  • date pickers

Everything works with a mouse. The design looks right. The click behavior has been tested.

Then someone tries the same screen with the keyboard.

The path breaks.

A card can be clicked but cannot be reached with Tab.

A menu opens but cannot be closed with Escape.

A modal traps focus or lets focus move behind it.

A custom dropdown looks like a select field but does not behave like one.

A button is actually a clickable div.

The issue is not always obvious from a screenshot. You have to use the screen.

What to notice earlier

The task should be possible without a mouse

Start with the task, not the component list.

Can someone complete the main thing this screen is for using only the keyboard?

Examples:

  • search for a record
  • fill out a form
  • select an option
  • upload a file
  • open a menu
  • close a dialog
  • move between tabs
  • review a table
  • submit a request
  • recover from an error

If the main task requires a mouse, the screen is not ready.

Interactive things should be reachable

Keyboard users move through interactive controls with Tab, Shift + Tab, arrow keys, Enter, Space, and sometimes other expected keys depending on the component.

If something can be clicked, ask whether it can also be reached and operated from the keyboard.

Common misses:

  • clickable cards
  • icons used as buttons
  • custom dropdowns
  • help tooltips
  • expandable sections
  • table row actions
  • drag-and-drop upload areas
  • calendar/date picker controls
  • links or buttons that appear only on hover

A good first pass is simple:

Press Tab through the page and see what you can reach.

Native controls usually give you a better starting point

Native HTML controls already have a lot of expected keyboard behavior.

A real button can be reached and activated. A real link behaves like a link. A real input receives focus. A real select has familiar keyboard behavior.

Custom controls can be accessible, but they require more care. If a team creates a custom dropdown, tab panel, dialog, or combobox, it needs keyboard behavior, focus handling, names, roles, states, and clear expectations.

A useful question:

Are we using a native control where one already fits?

If the answer is no, the team should know what keyboard behavior the custom control needs before it goes too far.

Keyboard traps block the path

A keyboard trap happens when the user can move focus into something but cannot move back out using the keyboard.

Common places to check:

  • modals
  • chat widgets
  • embedded maps
  • date pickers
  • custom dropdowns
  • third-party widgets
  • file upload controls
  • carousels or sliders

A modal should keep focus inside while it is open, but it should also provide a way to close it and return to the page. That is controlled focus, not a trap.

The practical test is:

If I tab into this area, can I get out without using a mouse?

Hover-only behavior often hides keyboard problems

If important actions appear only when someone hovers with a mouse, keyboard users may never find them.

Examples:

  • row actions that appear only on hover
  • edit/delete buttons hidden until the mouse enters a card
  • tooltips that contain necessary instructions
  • navigation menus that open only on hover
  • help text that is not available on focus

If the information or action is important, it needs a keyboard path too.

Focus order should match the visual and task order

Keyboard navigation should move in a logical path.

That usually means the focus order follows the visible order and the task flow. It should not jump unexpectedly from the header to the footer, skip the main content, move into hidden controls, or bounce around a form.

This topic overlaps with focus order, but it matters here because keyboard users experience the page as a sequence.

If the sequence does not make sense, the page becomes harder to use even when every control is technically reachable.

Keyboard testing should include error recovery

Do not stop after the happy path.

A form may be keyboard-accessible until something goes wrong. Then the user submits, errors appear, focus moves somewhere unhelpful, and the recovery path breaks.

Test the broken path too:

  • leave required fields blank
  • enter the wrong format
  • trigger a validation message
  • open the error summary
  • move to the problem field
  • fix the value
  • submit again

A keyboard path that only works when the user makes no mistakes is not enough.

Questions teams can ask

During intake or requirements

  • Does the screen include custom controls or third-party widgets?
  • Does the task involve menus, dialogs, tabs, accordions, uploads, or date pickers?
  • Are there actions that appear only after hover, selection, or row focus?
  • Does the user need to complete a form, fix errors, or move through several steps?
  • Are there embedded tools that may have their own keyboard behavior?

During design

  • Is every interactive element visible or discoverable without hover?
  • Is there a clear focus path through the screen?
  • Are dialogs, menus, and popovers designed with opening, closing, and return focus in mind?
  • Are custom controls designed with expected keyboard behavior?
  • Is there a visible state for focus, not only hover or active states?

During development

  • Are clickable elements built with the correct native element where possible?
  • Are custom controls reachable with the keyboard?
  • Do controls respond to expected keys such as Enter, Space, Escape, arrows, or Tab depending on the pattern?
  • Are hidden elements removed from the focus order when they are not available?
  • Does focus return to a logical place after closing dialogs or menus?
  • Are third-party widgets tested instead of assumed to work?

During QA

  • Can you complete the main task without a mouse?
  • Can you tab through the page in a logical order?
  • Can you activate every button, link, menu, and form control?
  • Can you open and close dialogs, menus, accordions, and custom widgets?
  • Can you recover from form errors using only the keyboard?
  • Can you get out of every embedded widget or modal without a mouse?
  • Does anything appear only on hover with no keyboard equivalent?

Common trail hazards

  • Clickable cards or icons are not keyboard reachable.
  • Buttons are built as clickable div or span elements.
  • Menus open with a mouse but not with the keyboard.
  • Dialogs do not manage focus when opened or closed.
  • Focus moves behind a modal while the modal is open.
  • A custom dropdown cannot be opened, navigated, or closed from the keyboard.
  • Important help text appears only on hover.
  • Hidden controls still receive focus.
  • Keyboard focus gets trapped in a widget.
  • The happy path works, but error recovery does not.

Small habit

Before a screen moves to review, do one no-mouse pass.

Put the mouse aside and try to complete the task with the keyboard.

Use:

  • Tab to move forward
  • Shift + Tab to move backward
  • Enter or Space to activate controls
  • Escape to close dialogs or menus when expected
  • arrow keys for controls that commonly use them, such as radio groups, menus, tabs, sliders, or custom selects

Then ask:

Where did I get stuck, where did I lose my place, and what could only be done with a mouse?

Those are the issues to fix before review.

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

  • Focus Visible and Focus Order — for checking whether the current keyboard location is visible and logical.
  • Modals and Dialogs — for keyboard behavior inside dialogs, overlays, and interruption flows.
  • Combobox — for keyboard behavior in autocomplete inputs, suggestion popups, active options, clearing, and selected values.
  • Tabs — for keyboard behavior when moving between tabs, selected panels, and hidden panel content.
  • Status Messages and Alerts — for updates keyboard users trigger, wait for, or need to notice before continuing.
  • QA Keyboard Check — for a repeatable hands-on check.
  • Accessibility Glossary — for plain-language definitions of common accessibility terms used across this guide.

What to do next

  • If a keyboard user opens a modal, overlay, drawer, or confirmation step, check Modals and Dialogs.
  • If a keyboard user types into an autocomplete field or moves through suggestions, check Combobox.
  • If a keyboard user switches between peer content panels, check Tabs.
  • If a keyboard action triggers a save message, warning, loading update, or validation feedback, check Status Messages and Alerts.
  • If you are testing a workflow by hand, use the QA Keyboard Check.