WCAG 2.2 / Inclusive Design / 03
Keyboard and focus systems
Design logical order, visible focus, unobscured targets, skip paths, and robust modal behavior.
Before you begin
By the end, you can…
- Complete an interface by keyboard
- Manage focus during dynamic changes
- Keep focused controls visible
01 / Understand
Keyboard access is interaction architecture
Tab should move through interactive elements in a logical order. Arrow keys often move within composite widgets such as tabs or menus. Enter and Space activate according to native conventions. Avoid positive tabindex values, which create a second fragile reading order.
Visible focus is location information. It must remain distinguishable and not be hidden under sticky headers, cookie banners, or dialogs. WCAG 2.2 adds explicit focus-not-obscured requirements.
02 / Apply
Move focus only for a reason
When a modal opens, focus moves inside; when it closes, focus returns to the trigger. After deleting an item, focus moves to a sensible neighbor or status. Routine content updates should not steal focus.
Test forward and backward, at zoom, and after every dynamic action. A keyboard trap is any state a person cannot leave using the same input method.
03 / Make
Your studio task
Make — Complete the page’s primary task with only Tab, Shift+Tab, arrows, Enter, Space, and Escape.
- Put the mouse away and complete the primary task.
- Record missing, hidden, illogical, or trapped focus.
- Repair with native controls and deliberate focus movement.
- Repeat backward and at 200% zoom.
Focus never disappears, becomes trapped, or lands beneath sticky content.
04 / Check