AHWD study materials
AHWD study resources

The Keyboard Trap

AHWD · Put your knowledge to work in context.

All case studies

The Keyboard Trap

A web application for managing employee schedules has a modal dialog that appears when users click a 'Filter' button. The dialog contains a form with several input fields and two buttons: 'Apply' and 'Cancel'. Testing reveals that keyboard users can open the dialog but cannot close it or navigate out of it using the keyboard alone. The focus gets trapped inside the dialog, and pressing Escape does nothing. The development team argues that the dialog is accessible because it has a visible close button and the form fields are properly labeled. They claim that keyboard users can simply use the mouse to close it. However, the company has a policy that all applications must be fully keyboard accessible. The team is unsure how to fix the issue without breaking the visual design.

1. Identify the specific WCAG 2.1 success criteria that this dialog violates and explain why.

Read the worked answer

The dialog violates WCAG 2.1 Success Criterion 2.1.2 No Keyboard Trap (Level A) because keyboard users cannot move focus out of the dialog using standard keyboard mechanisms (e.g., Tab, Shift+Tab, Escape). It also potentially violates 2.1.1 Keyboard (Level A) if the dialog cannot be operated entirely via keyboard. The visible close button is not sufficient if it cannot be reached or activated via keyboard. The team's argument that mouse use is an alternative does not excuse the keyboard trap.

2. Recommend a technical solution to fix the keyboard trap while preserving the visual design. Include considerations for focus management and user expectations.

Read the worked answer

Implement a focus trap that cycles focus within the dialog only while it is open, but allow Escape key to close the dialog. Ensure the close button is focusable and activates on Enter/Space. Upon opening, move focus to the first focusable element or the dialog itself. Upon closing, return focus to the triggering element. Use ARIA roles (e.g., role='dialog') and aria-modal='true' to inform assistive technology. These changes do not affect visual design and align with user expectations for modal dialogs.