How do you design keyboard use and focus?
Show keyboard users their current position and let them complete tasks in a sensible order.
Keyboard access lets someone complete a web task without a mouse. Focus is the current keyboard position: users need to see it and reach actions in a sensible order.
Keep these basics in mind
- Semantic HTML uses page structure to describe roles such as headings, links, and buttons. HTML is the language that organises page content.
- Tab usually moves to the next interactive item. Different components have different keyboard rules; do not apply one rule everywhere.
- A focus indicator is a visible outline or other clear treatment showing the current position. Do not remove it merely for appearance.
- Opening a menu or dialog requires entry, exit, and return behaviour so users are not trapped.
See W3C’s keyboard guidance for operation and its visible-focus guidance for position indicators.
Check with a keyboard
Illustrative focus handling
This is a hypothetical form.
| Stage | Previous problem | Adjustment |
|---|---|---|
| Reach email field | Current position is invisible | Clear focus indicator |
| Reach Save | Mouse works but keyboard skips it | A keyboard-operable button |
| Close edit dialog | Position is lost | Usually return to the opening control |
Walk through an example
A user reaches Edit profile with Tab, opens the dialog, fills an email address, and saves. Closing returns focus to the original control. The team also checks the failure path so the user can find invalid fields or cancel and leave.
Limits and common misunderstandings
Focus and mouse hover are different states. Reaching an element with Tab does not prove its action works correctly. Drawing an outline is insufficient: structure, key behaviour, and browser operation need to work together.