Keyboard Navigation and Focus

The problem

A lot of interfaces look finished and still fail the first honest test:

• navigate only with the keyboard
• clearly see where focus is
• open and close components without getting lost

When that breaks, the experience is not just “less accessible.”

It becomes confusing.

The user presses Tab and focus disappears. Opens a modal and keeps navigating the buttons behind it. Closes the overlay and lands in some random place on the screen. All of that makes the product feel disorganized even when the visual design is polished.

Mental model

Think about it like this:

Focus is the interface’s navigation cursor for people who are not using a mouse.

If that cursor is invisible, disordered, or trapped in the wrong place, the person loses orientation.

Keyboard and focus are not a side feature of navigation. In many flows, they are the navigation.

So the better question is not:

• “does this screen work with a keyboard?”

The better question is:

• “does this screen stay predictable when the keyboard becomes the main way to move through it?”

Breaking it down

Focus order needs to follow the logic of the screen

Focus should move in a way that feels natural.

In practice, that usually means:

• following the visual and structural order of the interface
• not jumping into unrelated areas
• not forcing the person to cross irrelevant elements just to reach what matters

When DOM order and experience order fight each other, keyboard navigation reveals it quickly.

Visible focus is not a cosmetic detail

Some teams remove outline because they think it looks ugly.

That is almost always a mistake.

If you do not want the browser’s default style, that is fine. But you still need to replace it with another strong, visible, and consistent indicator.

Without that, the user is navigating in the dark.

Overlay components need to govern focus

Modals, drawers, menus, and popovers all change the interaction context.

So they also need to manage focus:

• when they open, focus should enter the new context
• while they are open, navigation should stay inside that context when that makes sense
• when they close, focus should return to the element that started the action

If you ignore that cycle, the interface starts feeling broken underneath.

A native element solves half the problem before JavaScript

This connects directly to semantics.

A real button already accepts focus, responds to keyboard input, and joins the navigation flow the way users expect.

A styled div does not.

When the team starts from the wrong element, it usually ends up rebuilding basic behavior with patches.

Simple example

Imagine a “Delete” button that opens a confirmation modal.

Broken flow:

1. the user presses Enter on the button
2. the modal opens visually
3. focus stays on the background button or disappears
4. Tab starts walking through elements outside the modal
5. when the modal closes, focus returns to an unpredictable place

Healthy flow:

1. the user presses Enter on the button
2. the modal opens
3. focus moves to the first useful element inside the modal
4. Tab navigates inside the modal context
5. Esc or the close button ends the interaction
6. focus returns to the “Delete” button

That second flow is not polish.

It is what keeps the interface understandable during a context switch.

Common mistakes

• removing outline and putting nothing in its place
• testing interactive components only with the mouse
• opening a modal without moving focus inside it
• closing a modal without returning focus to the origin
• building a button with div and trying to fix it later with onKeyDown
• using tabIndex as a shortcut for bad structure instead of fixing the base

How a senior thinks

More experienced engineers treat keyboard and focus as part of the interface contract.

Not as late polishing.

The question changes from:

• “we will think about accessibility later”

to:

• “what is the navigation path of this screen when the user is not using a mouse?”

That changes how you build components, review PRs, and test flows.

A stronger engineer also knows that bad focus behavior can be hard to notice from the developer’s own context and immediately obvious for someone who depends on keyboard navigation. That is why they validate early, prefer native elements whenever possible, and treat context changes more carefully.

What the interviewer wants to see

When this topic shows up in interviews, the interviewer usually does not want a memorized list of attributes.

They want to see whether you understand:

• that keyboard navigation is a main flow
• that focus must be visible and predictable
• that overlay components need to control focus entry and exit
• that correct semantics removes a large part of the problem before any patching

A strong answer often sounds like this:

I think about focus as the current position of navigation. If it becomes invisible or moves to places without logic, the interface already lost predictability. In modals, menus, and drawers, I manage exactly where focus enters, how it moves, and where it returns when the context closes.

A good interface does not work only on click. It keeps making sense when the keyboard takes over.

When focus behaves well, the interface feels solid. When it behaves badly, it feels broken even without a visual bug.