Detailed explanation
Keyboard accessibility means users can reach and operate interactive features without a mouse. It supports people who cannot use pointing devices, users of assistive technologies that generate keyboard input, and anyone navigating by keyboard. Links, buttons, form controls, menus, dialogs, and custom widgets must expose appropriate keyboard behaviour. Interviewers usually expect you to explain more than Tab navigation: a usable experience also requires visible focus, a meaningful focus order, correct activation keys, and predictable focus management.
Under the hood, the browser maintains a focused element, available through document.activeElement. Native controls such as buttons, links with href, and inputs participate in sequential keyboard navigation automatically. Tab moves forward and Shift+Tab moves backward, generally following document order rather than the visual layout created with CSS. Enter activates links; native buttons support Enter and Space. Composite widgets, such as tab lists and menus, typically use arrow keys internally rather than making every item a separate Tab stop. Prefer semantic HTML because ARIA roles alone do not add focusability or keyboard behaviour. Use tabindex="0" to include an element in the normal sequence and tabindex="-1" for programmatic focus; avoid positive values.
Test manually by putting the mouse aside and navigating the complete page, including error states and content revealed dynamically. Check that every available action is reachable, focus stays visible, and the sequence follows a sensible reading and interaction order. Activate controls with their expected keys, fill and submit forms, and test custom widgets against their established keyboard patterns. Open and close dialogs: focus should enter the dialog, remain inside while it is modal, and return to a suitable trigger when closed. Ensure users can leave other components without getting trapped.
For styling, use a clear indicator such as button:focus-visible { outline: 2px solid #2563eb; outline-offset: 2px; }, checking its contrast against surrounding colours. Never remove outlines without an adequate replacement. Verify that sticky headers, overlays, and scrolling do not hide focused controls. Automated accessibility tools can flag some problems, but manual testing is necessary to assess actual keyboard operation, focus movement, and usability.
Key points to remember
- Keyboard accessibility covers reaching, operating, and leaving interactive components.
- Prefer native HTML controls with built-in focus and activation behaviour.
- Keep focus visible and navigation order consistent with the page’s meaning.
- Test Tab, Shift+Tab, Enter, Space, and widget-specific arrow-key behaviour.
- Check dynamic states, dialogs, validation errors, and focus restoration manually.
Common mistakes candidates make
- Testing only whether controls receive focus, without checking whether they work.
- Removing focus outlines or using positive tabindex values to repair a poor document order.
- Assuming ARIA roles or automated accessibility checks provide complete keyboard support.
Likely follow-up questions
What is the difference between :focus and :focus-visible?
:focus matches an element whenever it has focus. :focus-visible matches when browser heuristics determine that a visible focus indicator is appropriate, commonly during keyboard navigation.
Why is a native button better than a clickable div?
A native button provides button semantics, keyboard focusability, and Enter/Space activation by default. A div with a click handler requires those behaviours to be implemented explicitly; adding role="button" alone is insufficient.
Is keeping focus inside a modal dialog a keyboard trap?
Containing focus in an open modal is expected because the background is unavailable for interaction. It becomes a problematic trap if users cannot dismiss or complete the dialog using the keyboard and return to the surrounding interface.
Interview tip: Explain reachability, operation, and focus management first, then describe a keyboard-only walkthrough with one concrete example.