Keyboard Navigation in Custom Components: What I Learned

When building custom UI components like dropdowns, page navigators, or drag-and-drop interfaces, one thing I always ask myself is:

“Can I use this with only the keyboard?”

Keyboard navigation isn’t just about accessibility checkboxes. It’s about creating interfaces that feel predictable, usable, and polished. In this post, I’ll share what I learned while building keyboard support into a custom component — and how it reshaped the way I think about interaction design.

1. Start With Tab Order and Focus Management

Every interactive component needs to play well with the browser’s native tab order.

• I made sure each PageButton or DropdownItem was reachable with the Tab key.
• I used tabIndex={-1} strategically to support roving focus (more on that below).
• I preserved the focus when reordering items, opening popovers, or navigating between buttons.

Even something like restoring focus after closing a dropdown makes a huge difference in perceived polish.

2. Use Arrow Keys for Predictable Navigation

I implemented roving focus so that arrow keys (←, →, ↑, ↓) move between items without requiring a full tab press.

This pattern is especially useful for:

• Horizontal components like a page navigator
• Menus and dropdowns with multiple options
• List-based UIs where you want to preserve keyboard context

I used a shared context and index tracking to manage the currently „focused“ item, and updated tabIndex + aria-activedescendant to reflect the changes.

3. Don’t Forget Home, End, Escape, and Enter

Power users expect more than just arrows:

• Home and End keys jump to the first and last elements
• Escape closes overlays or cancels interactions
• Enter triggers the primary action for a focused element

These behaviors are small, but implementing them creates a feeling of completeness and care in your component API.

4. Announce Focus and State with ARIA

Using aria-* attributes helped make the keyboard navigation screen-reader friendly:

• aria-selected, aria-expanded, and aria-current clarified state
• aria-label and aria-describedby provided extra context
• aria-live was helpful in announcing changes like item insertion or reordering

I tested everything using VoiceOver and NVDA to make sure that actions had proper feedback.

5. Accessibility Isn’t Optional, It’s Foundational

The more I build accessible components, the more I realize it improves the experience for everyone — not just those relying on assistive technologies.

Keyboard-friendly components are:

• Easier to test
• Easier to use in complex flows
• More predictable for power users
• More respectful of user input methods

And if you build it right once, every reuse of the component carries those benefits forward.

Final Thoughts

Keyboard navigation might seem like a small detail, but it’s a signal of thoughtfulness, craft, and care. It pushes you to think in systems, consider state more carefully, and design for real-world use.

I’ll never build another component without asking:

“Can I use this with just a keyboard?”