By the end of this lesson you can
- Ensure everything works with a keyboard alone.
- Design visible focus indicators and logical focus order.
- Handle focus in modals, menus and dynamic content.
The idea
Many people navigate without a mouse: keyboard users, switch users, screen reader users and people using voice control. Everything you can do with a mouse must be possible with a keyboard.
Basic keys
- Tab / Shift+Tab: move between interactive elements.
- Enter: activate links and buttons.
- Space: activate buttons, toggle checkboxes.
- Arrow keys: move within components such as radio groups, tabs and menus.
- Escape: close modals and menus.
Focus indicators
Focus must always be visible (WCAG 2.4.7) and, at AA in WCAG 2.2, not hidden by other content such as sticky headers (2.4.11). Design a strong indicator, such as a thick outline with offset, with at least 3:1 contrast.
Focus order
Focus should follow a logical reading order, usually the visual order. Annotate focus order for complex layouts.
Managing focus
- When a modal opens, move focus into it, keep it there until it closes, then return focus to the trigger.
- After deleting an item, move focus somewhere sensible.
- Provide a "Skip to main content" link.
- Avoid keyboard traps: people must always be able to move away.
Why it matters in real projects
Keyboard access is fundamental: if a control cannot be reached by keyboard, it is unusable for many disabled people. Invisible focus leaves keyboard users lost. Focus management in modals and dynamic content is a frequent failure that designers can prevent by specifying it clearly before development begins.
A realistic example
A ticketing site's seat map works only with a mouse. Keyboard users can tab to the map but not select seats, and the custom focus style was removed because it "looked ugly".
The designer specifies arrow key navigation between seats, Enter to select, a visible focus ring with 3:1 contrast, a list view alternative for screen reader users and focus returning to the "Selected seats" summary after each choice. Developers build it from the spec, and keyboard users can now book.
Step by step
Unplug the mouse
Try a key task using only the keyboard.
Check every control
Make sure each can be reached and used.
Check focus visibility
Is it always obvious where focus is?
Check order
Does focus move in a logical order?
Check modals and menus
Does focus move in, stay in and return correctly?
Annotate
Document focus order and behaviour in designs.
Common mistakes
Mistake Removing focus outlines for aesthetics.
Instead Design a better visible focus style.
Mistake Custom controls that ignore the keyboard.
Instead Specify keyboard behaviour for every custom control.
Mistake Focus lost after closing modals.
Instead Return focus to the trigger.
Check your understanding
Choose an answer, then check it. There is an explanation either way.
Practice exercise
Exercise · about 45 min
Keyboard test
Test a website using only the keyboard.
Steps
- Complete a key task with keyboard only.
- Record every problem.
- Annotate the correct focus order for one screen.
- Design a focus indicator that meets contrast requirements.
Deliverable
A problem log, a focus order annotation and a focus style.
Self-assessment
Tick each item when it is true of your exercise. Be honest; this is for you.
4 items
Summary
- All functions must work by keyboard.
- Design visible, high-contrast focus indicators.
- Keep focus order logical.
- Manage focus in modals and dynamic content.
Further reading
Third-party sources, chosen for reliability. They open in a new tab.
Your notes
Marking complete updates your course and roadmap progress.