How Do You Build Keyboard-Accessible Web Interfaces?
Learn how to build keyboard-accessible interfaces: tabindex, focus indicators, focus trapping, and skip links explained.
Expected Interview Answer
Keyboard-accessible interfaces ensure every interactive element can be reached via Tab, activated via Enter or Space, and operated without a mouse at all, which is essential for users with motor impairments, screen reader users, and power users alike, and is achieved primarily by using native interactive elements and managing focus order and visibility deliberately.
The foundation is using native elements (<button>, <a>, <input>, <select>) that come with built-in keyboard support instead of clickable <div>s, because reimplementing focusability and key handling manually is error-prone. When a custom widget is unavoidable, tabindex controls whether and how an element joins the tab order — tabindex="0" adds it in natural document order, tabindex="-1" makes it programmatically focusable but skips it in Tab order (useful for moving focus into a modal), and positive tabindex values should be avoided because they create a confusing, hard-to-maintain custom order that overrides the natural document flow. Visible focus indicators (never disable outline: none without a replacement) are non-negotiable, since a keyboard user with no visible focus ring has no way to know where they are on the page. For complex interactions like modals, focus must be trapped inside the dialog while open and returned to the triggering element on close, and skip links ("Skip to main content") let keyboard users bypass repetitive navigation blocks instead of tabbing through dozens of links on every page load.
- Enables full site usage for users who cannot or do not use a mouse
- Native focus indicators and skip links reduce navigation friction for keyboard and screen reader users
- Correct focus trapping prevents users from getting lost outside a modal dialog
- Well-managed tab order improves usability for all users, not just those with disabilities
AI Mentor Explanation
Keyboard navigation is like a ground designed so a player using only a marked walking path, with no need to cut across the field, can still reach every area — the nets, the pavilion, the boundary rope — in a sensible order. If a gate is unmarked or hidden behind a wall with no path leading to it, that player simply cannot get there. A well-lit, clearly marked path with visible signage at every junction is what lets any visitor, regardless of mobility, reach every part of the ground in a predictable sequence. Removing the path markers entirely, the way disabling a focus outline does, leaves the visitor unable to tell where they currently stand.
Step-by-Step Explanation
Step 1
Use native interactive elements first
Prefer <button>, <a>, <input>, and <select> so keyboard support comes built in.
Step 2
Manage tabindex deliberately
Use tabindex="0" to include custom elements in natural tab order and tabindex="-1" for programmatic-only focus targets.
Step 3
Keep focus indicators visible
Never remove outline styling without providing an equally visible custom focus style.
Step 4
Trap and restore focus for modals
Keep focus inside an open dialog and return it to the trigger element when the dialog closes.
What Interviewer Expects
- Understanding of tabindex values (0, -1, and why positive values are discouraged)
- Ability to explain focus trapping and focus restoration for modals
- Awareness that focus indicators must remain visible, never silently removed
- Mention of skip links for bypassing repetitive navigation
Common Mistakes
- Setting outline: none in CSS without providing a replacement focus style
- Using positive tabindex values, creating a confusing custom tab order
- Building a custom modal that does not trap focus, letting Tab escape to the page behind it
- Making a clickable div without adding tabindex and Enter/Space key handlers
Best Answer (HR Friendly)
“Keyboard accessibility means someone can use an entire website using only the Tab, Enter, and arrow keys, with no mouse at all. This matters for people with motor impairments and for screen reader users. The key things are always keeping a visible focus outline so people know where they are, and making sure custom things like pop-ups trap focus properly instead of letting it escape to the background.”
Code Example
function openModal(modalEl, triggerEl) {
const focusable = modalEl.querySelectorAll(
'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
)
const first = focusable[0]
const last = focusable[focusable.length - 1]
first.focus()
function handleKeydown(e) {
if (e.key === 'Escape') return closeModal(modalEl, triggerEl)
if (e.key !== 'Tab') return
if (e.shiftKey && document.activeElement === first) {
e.preventDefault()
last.focus()
} else if (!e.shiftKey && document.activeElement === last) {
e.preventDefault()
first.focus()
}
}
modalEl.addEventListener('keydown', handleKeydown)
}
function closeModal(modalEl, triggerEl) {
modalEl.hidden = true
triggerEl.focus() // restore focus to trigger
}Follow-up Questions
- Why should positive tabindex values generally be avoided?
- How would you implement a "Skip to main content" link and why does it matter?
- What is the difference between tabindex="0" and tabindex="-1"?
- How do you test a page for keyboard accessibility without a screen reader?
MCQ Practice
1. What does tabindex="-1" do to an element?
tabindex="-1" allows JS-driven focus() calls but skips the element during Tab key navigation.
2. Why should CSS outline: none never be used without a replacement?
Without a visible focus style, keyboard users cannot tell which element is currently active.
3. What should happen when a modal dialog closes?
Restoring focus to the trigger element preserves context for keyboard and screen reader users.
Flash Cards
tabindex="0" does what? — Adds the element to natural Tab order.
tabindex="-1" does what? — Makes it focusable via JS only, skipped in Tab order.
Why keep focus indicators visible? — So keyboard users always know their current position on the page.
What must a modal do with focus? — Trap it while open and restore it to the trigger element on close.