Keyboard Navigation and Focus Indicators

Mobile & Accessibility2 min readBy the Monopage team

Not everyone uses a mouse. People with motor disabilities, people who use screen readers, and many power users navigate with a keyboard or another device that behaves like one. If your site cannot be used this way, you are shutting those visitors out. Fortunately, most of this comes down to using standard HTML correctly.

The basics

Pressing Tab moves forward through interactive elements such as links, buttons, and form fields. Shift + Tab moves backward. Enter activates links and buttons, and Space activates buttons and checkboxes. Arrow keys often work within menus, tabs, and radio groups.

Try it on your own site: unplug your mouse and attempt to reach and use everything.

Use real HTML elements

Native links, buttons, and form controls already work with the keyboard and are announced properly by screen readers. A div styled to look like a button does not, unless you add the roles, keyboard handling, and focus behavior yourself. When possible, use the right element in the first place.

Show a clear focus indicator

When an element receives focus, there must be a visible sign, such as an outline. Never remove the default outline with outline: none unless you replace it with something equally visible. Choose a focus style with sufficient contrast, at least 3:1 against surrounding colors. WCAG 2.2 adds further expectations for focus appearance and for focused items not being hidden behind sticky headers. See color contrast.

The :focus-visible CSS selector helps show focus styles for keyboard users without distracting mouse users.

Keep the order logical

Tab order follows the order of elements in the HTML. Make sure the visual layout and the underlying order match, so focus does not jump around unpredictably. Avoid positive tabindex values, which disrupt natural order.

A "Skip to main content" link at the top of the page lets keyboard users bypass repeated navigation. It can be visually hidden until it receives focus.

Avoid keyboard traps

A user must always be able to move away from any component using the keyboard. Modal dialogs should move focus into the dialog when opened, keep focus inside while open, allow Escape to close it, and return focus to the trigger afterward.

Make menus keyboard friendly

Dropdowns that open only on hover are unusable without a mouse. Ensure menus open with Enter or Space, expose their state, and can be closed. See navigation best practices.

Handle forms and widgets

Forms need logical ordering and visible focus. See accessible forms. Custom widgets like carousels, accordions, and tabs need extra care, and simpler designs are often safer.

Test with real use

Navigate through each key page and task, such as contacting you or completing checkout, using only the keyboard. Also test with a screen reader if you can. See accessibility basics.

The bottom line

Use semantic HTML, keep focus visible, maintain a logical order, and avoid traps. Keyboard-friendly sites are better for everyone.