Keyboard Trap Form

Published at 15 Jun 2026

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

Fix a login form inside a modal so that the Tab key cycles only within the modal and does not escape behind the overlay.

Currently, pressing Tab lets focus leave the modal and move to page elements behind it, which is a WCAG accessibility violation. Trap the focus so it stays within the modal.

Implement a focus trap: on Tab from the last focusable element, wrap to the first; on Shift+Tab from the first, wrap to the last. Also focus the modal on open.

Ensure all interactive elements in the modal are reachable by keyboard and that focus does not escape.

Test Tab and Shift+Tab cycling within the modal without escaping.

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

Community Discussion

Ask questions, share solutions & tips

0 Comments

Join the Discussion

No comments yet

Be the first to share your approach or ask a question!

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