Keyboard Trap Form

Published at 15 Jun 2026

Description
Explains what the challenge is about and what you need to build.

keyboard trap

occurs when keyboard focus enters a UI region — such as a modal, dialog, or embedded widget — but cannot leave it using standard keyboard navigation (Tab, Shift+Tab, Esc). This is a critical

WCAG 2.1.2

violation because users who rely on keyboards (screen reader users, power users with mobility impairments) become stuck, unable to reach the rest of the page.

In this challenge, you are given a login form rendered inside a modal overlay. Currently, pressing Tab cycles through the form fields but the focus

escapes

behind the modal onto page elements your users cannot see or interact with. Your job is to trap the Tab cycle inside the modal and make sure the form is usable entirely by keyboard.

This is a common real-world pattern you will encounter in design systems, dialog components, slide-out drawers, and date picker overlays.

Requirements
Lists the specific elements, IDs, and behaviors your solution must include to pass the tests.

The form container must have ID #login-form.
Focus must be trapped inside the form elements: username input, Cancel button (#btn-cancel), and Save Changes button (#btn-save).
When Tab is pressed on the last focusable element (Save), focus must wrap back to the first element (username).
When Shift+Tab is pressed on the first element (username), focus must wrap to the last element (Save).
Pressing Enter on the input submits the form by triggering the save action.
The active element must show a visible focus indicator (e.g., outline or ring) for accessibility compliance.

Example Demo

User Flow

Step-by-step Flow Explanation:

User loads page: Focus is initialized on the first interactive form control (username input). The background page is dimmed by the overlay.
Tab forward: User presses Tab. Focus moves to the Cancel button, then to the Save Changes button. On the next Tab, focus must not leave the modal — it must jump back to the username input.
Shift+Tab backward: User presses Shift+Tab on the username input. Focus must move to the Save button (last element), not escape behind the modal.
Submit via Enter: While typing in the username field, user presses Enter. The form should invoke the save/confirm action.
Visual feedback: Every focused element shows a clear outline or ring so the user always knows where they are.
Verification: Test scripts programmatically dispatch Tab key events and assert that the active document.activeElement never points to elements outside #login-form.

Related UI Challenges

Component UI

Discussion (0)

Join the Discussion

index.html

style.css

script.js

Loading Monaco Workspace...

Live Preview Browser

Tests & Console Output

Click to expand

Test Assertion	Status	Details/Errors
Required DOM Elements exist (#login-form, #username, #btn-cancel, #btn-save)	Pending	Pending execution
Focus listeners are registered on the form element	Pending	Pending execution