Keyboard Operability

Keyboard operability means every interactive function can be completed using a keyboard alone, without requiring a mouse, touch, or other pointing device. For frontend engineers, this includes reaching controls, moving focus predictably, and operating widgets with appropriate keys.

Keyboard users typically navigate with `Tab` and `Shift+Tab`, activate controls with keys such as `Enter` or `Space`, and use additional keys when a widget pattern requires them. A usable interface must expose all interactive functionality through these keyboard interactions.

Focus is central to keyboard accessibility. The currently focused element should be visually identifiable, and focus should move in a logical order that matches the interface. Developers should avoid removing the browser's focus indicator unless they provide an equally clear replacement.

Native HTML controls such as `<button>`, `<a>`, `<input>`, and `<select>` generally provide much of this behavior automatically. Custom controls built with generic elements such as `<div>` often require extra keyboard handling and accessibility semantics, so using the appropriate native element is usually simpler and more robust.

Interactive widgets may need behavior beyond basic tab navigation. For example, a menu, dialog, tab interface, or composite widget can have specific keyboard expectations. When implementing one, follow an established accessibility pattern rather than inventing key behavior.

Keyboard operability also means avoiding keyboard traps. Users must be able to move focus into and out of an interactive component without becoming stuck, except in carefully designed modal interactions where focus is intentionally contained until the dialog is closed.

Key points

• Every interactive function must work without a mouse or touch device.
• Keyboard focus must be visible and follow a logical order.
• Prefer native interactive HTML elements over generic elements with custom handlers.
• Custom widgets need appropriate keyboard behavior and accessibility semantics.
• Avoid keyboard traps and ensure users can move focus away from components.

Interview questions

How would you test keyboard accessibility manually?

I would use the interface without touching a mouse or trackpad. I would press `Tab` and `Shift+Tab` to verify that every interactive element is reachable and that focus is visible. I would activate controls with their expected keyboard keys and check dialogs, menus, forms, and other widgets for traps or unexpected focus movement. I would also verify that the sequence is logical.

What does keyboard accessibility mean for a web application?

It means users can perform all interactive tasks using only a keyboard. They must be able to reach controls, operate them, and move through the interface without depending on a mouse or touch input. Focus should be visible and the interaction order should be sensible. Native HTML controls are usually the easiest foundation for this behavior.

Why should you prefer a native `<button>` over a clickable `<div>`?

A native button already has the expected interactive semantics and keyboard behavior supplied by the browser. A clickable `<div>` is not inherently an interactive control, so reproducing button behavior requires additional focusability, keyboard handling, semantics, and state management. Using the native element also makes the implementation easier for assistive technologies and reduces the amount of accessibility code to maintain.

What is a keyboard trap, and how can you prevent one?

A keyboard trap occurs when focus enters a component and the keyboard user cannot move focus out through normal interaction. This can make an interface unusable without a pointing device. Components such as dialogs may intentionally constrain focus while open, but they need a reliable closing mechanism and correct focus restoration. Developers should test both entering and leaving every interactive component.

How would you design keyboard behavior for a custom tab component?

I would first consider whether native elements or an existing component pattern can meet the requirement. If a custom tab interface is necessary, I would implement the expected tab semantics, expose the selected state programmatically, and define a consistent keyboard model for moving between tabs and entering the associated panel. Focus behavior should be intentional rather than based on arbitrary DOM manipulation. I would then test the complete interaction with keyboard-only navigation and assistive technology.