Keyboard navigation follows the page's focus: the element that is currently ready to receive keyboard input.
Focus moves: Pressing Tab moves focus to the next interactive element, such as a link, button, or form field. Shift+Tab moves it back.
Focus is shown: A visible outline or highlight, called a focus indicator, shows where the user is on the page.
The user acts: Enter follows a link or submits a form, Space presses a button or selects a checkbox, and the arrow keys move between options in menus, tabs, or lists.
For example, a visitor can tab to a newsletter form, type an email address, press Tab to reach the Subscribe button, and press Enter to sign up, without touching a mouse.
Most browsers and websites use the same core keys:
Key | What it typically does |
|---|---|
Tab | Moves to the next link, button, or form field |
Shift + Tab | Moves to the previous interactive element |
Enter | Follows a link, presses a button, or submits a form |
Space | Presses a button, selects a checkbox or scrolls the page down |
Arrow keys | Move between options in menus, tabs, radio buttons and sliders, or scroll the page |
Escape | Closes a dialog, pop-up or open menu |
Home, End, Page Up, Page Down | Jump to the top or bottom of the page, or scroll one screen at a time |
Many people browse without a mouse. This includes people with motor impairments who find precise mouse movements difficult, people who are blind and use a screen reader with the keyboard, and people using switch devices or other tools that work like a keyboard.
When a site isn't built for keyboard use, these visitors can get stuck. Common barriers include:
Menus, buttons, or pop-ups that respond only to a mouse click or hover.
Missing or hidden focus indicators, so users can't see where they are.
A focus order that jumps around instead of following the visual layout.
Keyboard traps, where focus gets stuck inside an element.
Read more about keyboard traps and other common accessibility pitfalls.
The Web Content Accessibility Guidelines (WCAG) include several keyboard requirements. In plain terms: functionality should work with a keyboard, users shouldn't get trapped, focus should move in a logical order, and the focused element should be visible. Many US and EU accessibility laws and policies reference WCAG or standards based on it.
The World Wide Web Consortium (W3C) explains the keyboard requirement in detail. For testing steps, see our guide to keyboard accessibility.
Focus indicator: The visible outline that shows which element currently has keyboard focus.
Screen reader: Assistive software that many people control with keyboard commands to navigate websites.
Motor impairment: A condition affecting movement that can make using a mouse difficult, which is why keyboard support matters.
WCAG: The guidelines that set keyboard, focus and other accessibility requirements for web content.
They are closely related. Keyboard navigation describes how a person moves through and uses a site with a keyboard. Keyboard accessibility describes whether the site supports that, meaning every interactive feature can be reached, used, and left with the keyboard alone.
Put the mouse aside and try to complete key tasks, such as opening the menu or submitting a form, using only the keyboard. Check that focus is always visible, follows a logical order, and never gets stuck. On a Mac, Safari may skip links on Tab until you turn on "Press Tab to highlight each item" in its settings. Automated scans can flag some keyboard issues, but you still need to manually check task completion. Learn more about automated vs. manual accessibility testing.
Yes. People with a temporary injury, people on a laptop without a mouse, and power users who move through forms with Tab benefit too. A site that works well with the keyboard is often easier to use overall.
A keyboard trap happens when focus moves into an element, such as a pop-up, chat widget or embedded player, and the user can't leave it with standard keys. The rest of the page then becomes unreachable without a mouse.
Compliance Content Manager | CIPP/E (IAPP) | CPACC (IAAP)
Alex is a Compliance Content Manager at Clym, where he researches and writes about everything related to data privacy and web accessibility compliance for businesses, helping them stay informed on their compliance needs and spreading awareness about making the web safer and more inclusive. When he's not writing about compliance, Alex has his nose in a book or is hiking in the great outdoors.
