Keyboard Traps: The Hidden Lawsuit Trigger

Keyboard traps: The hidden lawsuit trigger

Monique Reid filed suit against Colgate-Palmolive in New York Supreme Court, Kings County, on February 2, 2026. Her complaint alleged the company's website discriminated against visually impaired consumers by maintaining barriers that prevent screen reader access and keyboard navigation, making online shopping impossible without mouse-based interactions .

The case is one of thousands. But the specific allegation about keyboard navigation points to a particular technical failure that shows up repeatedly in accessibility lawsuits: keyboard traps.

According to WebAIM's annual survey, 68% of screen reader users encounter keyboard traps or inaccessible interfaces monthly . For the estimated 7 million Americans who cannot use a mouse due to motor disabilities, these traps don't just cause frustration. They make websites unusable .

What a keyboard trap actually is

WCAG 2.1 Success Criterion 2.1.2 is straightforward: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface .

That's the rule. In practice, a keyboard trap happens when you tab into a section of a website and can't tab out. Maybe focus gets stuck in a dropdown menu. Maybe a modal dialog opens and you can't escape. Maybe custom JavaScript keeps pulling focus back to a particular element no matter how many times you press Tab.

The W3C's understanding document puts it simply: keyboard users don't get stuck. Ensure users always know how to navigate away from components .

This matters because people who rely on the keyboard often have no other means to navigate. A mouse user who encounters a trap can just click somewhere else. A keyboard user can't .

Why keyboard traps trigger lawsuits

The ADA doesn't mention websites. But the Department of Justice has made clear that Title III applies to online spaces, and courts have largely agreed. When a plaintiff's lawyer tests a site and finds they can't navigate past a certain point, that's a concrete barrier.

Keyboard traps are especially damaging in litigation because they're demonstrable. A plaintiff can show the court exactly what happens. Press Tab. Focus disappears into a widget. Press Tab again. Nothing. Press Tab twenty times. Still stuck. There's no way to complete a purchase, submit a form, or access information.

The Colgate-Palmolive suit alleges exactly this: barriers that prevent keyboard navigation, making online shopping impossible without mouse-based interactions . That's the legal theory. If you require a mouse, you're excluding people who can't use one.

Where keyboard traps hide

Keyboard traps appear in predictable places. Modal dialogs are the most common offender. A modal opens, focus moves inside, and the developer forgets to manage what happens when the user reaches the last focusable element. The user tabs past the last button and focus disappears into the background, or worse, gets stuck entirely .

Custom widgets cause problems too. Developers build dropdown menus, tab panels, and carousels using divs and spans instead of semantic HTML. They add click handlers but forget keyboard handlers. A user tabs into the widget and can't get out because the arrow keys do nothing and Tab is trapped .

Third-party embeds are another source. The W3C's G21 technique document specifically calls out plug-ins as a common trap. If a plug-in doesn't provide a keyboard mechanism to return focus to the parent window, users can become trapped in that content . This was a bigger problem with Flash, but modern embeds like interactive maps or custom media players can still trap focus if they're not built correctly.

The W3C's ACT rule examples show a simple trap pattern:

html

<a href="#">Link 1</a> <button onblur="setTimeout(() => this.focus(), 10)">  Button1 </button> <a href="#">Link 2</a>

When focus leaves the button, the setTimeout immediately pulls it back. The user can never reach Link 2. That's a trap .

The modal dialog exception

There's one legitimate case where trapping focus is actually required. Modal dialogs must trap focus while they're open. If you tab past the last button in a modal and focus moves to the page behind it, users get confused and can lose context entirely .

The W3C's example explains it: When a dialog has been opened, focus is trapped within the dialog. Tabbing from the last control takes focus to the first control. The dialog is dismissed by activating the Cancel or OK button .

This is allowed because the trap is intentional and the user has a clear way out. The key is that the user knows how to leave. That's what the success criterion means when it says if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method .

In practice, that means modals should close with the Escape key, and buttons to dismiss the modal should be clearly available. The user should never be stuck with no way out.

What proper focus trapping looks like

TestParty's guide shows correct modal implementation:

javascript

modal.addEventListener('keydown', (e) => {  if (e.key === 'Escape') {    closeModal();    triggerButton.focus(); // Return focus to trigger  }  if (e.key === 'Tab') {    // Trap focus within modal, but allow cycling    const focusable = modal.querySelectorAll(      'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'    );    const firstFocusable = focusable[0];    const lastFocusable = focusable[focusable.length - 1];    if (e.shiftKey && document.activeElement === firstFocusable) {      e.preventDefault();      lastFocusable.focus();    } else if (!e.shiftKey && document.activeElement === lastFocusable) {      e.preventDefault();      firstFocusable.focus();    }  } });

This keeps focus inside the modal while it's open but cycles through the available elements. When the modal closes, focus returns to whatever opened it. That's the pattern .

The Mozilla example

Even major organizations get this wrong. Mozilla's bedrock project, which powers the Mozilla.org website, had an issue filed in March 2025 about their mobile navigation menu .

The problem: When opening the mobile navigation menu on a device with an external keyboard or assistive technology, focus wasn't confined to the menu. Users could tab out and land on page elements hidden behind the open menu.

The issue report describes the expected behavior: When the mobile navigation menu is open, the keyboard focus should remain within the menu. Users should only be able to navigate through the menu items until the menu is closed .

This is the inverse of the usual trap problem. Here the menu wasn't trapping focus when it should have been. Both failures cause confusion. Users expect focus to stay in an open menu until they intentionally close it. When it doesn't, navigation becomes unpredictable.

The issue remains open. Mozilla hasn't fixed it yet.

Testing for keyboard traps

Testing for traps is simple but tedious. You need to go through every page with nothing but a keyboard.

The UXPin guide recommends starting at the browser's address bar. Press Tab repeatedly until you return to the address bar. Note any skipped elements, illogical order, or invisible focus states. Then do it again with Shift+Tab to test reverse navigation .

For widgets specifically, you need to test that all interactive elements respond to appropriate keys. Links activate with Enter. Buttons activate with Enter and Space. Checkboxes toggle with Space. Radio buttons navigate with arrow keys and select with Space .

For custom widgets like tabs, accordions, and menus, you need to test the full interaction pattern. Can you open the menu with Enter or Space? Can you navigate items with arrow keys? Can you close it with Escape? Does focus return to where it started?

The W3C's ACT rule provides a more formal testing approach. The rule checks for keyboard traps by testing whether focus can move away from a component in any direction. If you can escape in one direction but not the other, that's still considered passing under the technical rule, but it's recognized as a poor practice .

The instructions requirement

Sometimes traps are unavoidable. A complex widget might need to handle its own keyboard interactions. In those cases, the success criterion requires that users be advised of the method for moving focus away .

The W3C's examples show how this works. In one example, two buttons create a trap but instructions are provided before the buttons: "Press Ctrl+M to Exit." The Escape key is programmed to work, and the instructions are accessible via keyboard. That passes .

Another example places the instructions within the trap itself. A paragraph inside the trapped region says "Press Ctrl+M to Exit." That also passes .

What fails is having instructions that don't work, or having no instructions at all. The W3C shows a failed example where the instructions say "Press Ctrl+M to Exit" but the script doesn't actually implement that key combination. The user reads the help text, follows the instructions, and nothing happens. That's a failure .

The business case beyond lawsuits

The legal risk is real. But keyboard accessibility matters for reasons beyond avoiding litigation.

About 20% of users worldwide live with disabilities that influence how they interact with the web. That includes people with motor disabilities, blind users who rely on screen readers, and people with low vision who find mouse pointers hard to track .

There are also temporary circumstances. Users with broken arms, carpal tunnel flare-ups, or those working in cramped spaces may temporarily rely on keyboard navigation .

And there are power users. Many developers and technical users prefer keyboard navigation for efficiency. Poor keyboard support frustrates these users and increases task completion time .

A staggering 25% of all digital accessibility issues are tied to poor keyboard support . Fixing keyboard traps addresses a significant portion of accessibility barriers.

Common fixes for common traps

Most keyboard traps have straightforward fixes once you know where to look.

Modal dialogs: Implement the focus trapping pattern shown above. Ensure Escape closes the dialog. Return focus to the trigger element when the dialog closes .

Custom dropdowns: Don't build them with divs. Use semantic HTML with proper ARIA attributes if needed. Ensure arrow keys navigate options. Ensure Tab exits the dropdown when closed .

Third-party embeds: Test them thoroughly. If an embed traps focus, look for documented keyboard commands. If none exist, consider replacing the embed or adding visible instructions before users enter it .

Event handlers that steal focus: Check for any JavaScript that calls .focus() on a blur event. The W3C examples show this pattern:

javascript

<button onblur="setTimeout(() => this.focus(), 10)">

Any code that refocuses an element when it loses focus creates a trap. Remove it .

Positive tabindex values: Positive tabindex values create unpredictable focus order. Use semantic HTML elements which are naturally focusable and follow the DOM order. For custom elements, use tabindex="0" to include them in the natural order .

The overlay problem

Some companies sell accessibility overlays that claim to fix keyboard traps automatically. They don't.

Overlays work by injecting JavaScript that attempts to modify behavior after the page loads. They can't fix structural problems like missing keyboard handlers. They often conflict with users' own assistive technology. And they create the illusion of accessibility without actually achieving it.

If you're relying on an overlay to fix keyboard traps, test your site with a keyboard. Remove your mouse. Try to navigate. You'll likely find the traps are still there.

What the Colgate-Palmolive case means

The Monique Reid suit against Colgate-Palmolive is typical. It alleges the website discriminates against visually impaired consumers by maintaining barriers that prevent screen reader access and keyboard navigation .

The case is in Kings County, New York, which is a busy jurisdiction for ADA lawsuits. The plaintiff is represented by Shaked Law Group, which files many such suits .

The outcome will depend on whether Colgate-Palmolive can show their site doesn't trap keyboard users. If a plaintiff's expert can demonstrate that focus gets stuck in widgets, modals, or custom components, the company faces liability.

The ADA itself allows injunctive relief, meaning Colgate-Palmolive could be ordered to fix their site. But New York state law allows damages. The suit includes disability discrimination claims under state law .

What you should do now

Test your site with a keyboard today. Unplug your mouse. Start at the address bar. Press Tab through every page.

Watch for these specific problems:

Skipped elements. If you can't reach something with Tab, it's inaccessible.

Invisible focus. If you can't see where you are, you're lost.

Trapped focus. If you enter a section and can't leave, you have a trap.

Missing escape routes. If a modal opens and Escape doesn't close it, users are stuck.

Improper focus management. If focus doesn't return to the trigger after a modal closes, users lose context.

Document what you find. Fix the traps first. They're Level A violations, which means failing them means failing basic accessibility.

The W3C's technique G21 provides a simple test procedure. Tab through content from start to finish. Check that keyboard focus is not trapped in any content. If focus appears trapped, check that help information explains how to exit and can be accessed via keyboard .

That's it. No complex tools required. Just a keyboard and attention.

The bottom line

Monique Reid sued Colgate-Palmolive on February 2, 2026, alleging keyboard navigation barriers. She's not the first and won't be the last.

Keyboard traps are a hidden lawsuit trigger because they're easy to find and impossible to defend. When a plaintiff's lawyer tabs through your site and gets stuck, they have evidence. When a screen reader user encounters a widget they can't escape, they have a story.

The fix is straightforward. Test with a keyboard. Find the traps. Fix the code. Document your work. It's not expensive. It's not complicated. It's just necessary.

Sixty-eight percent of screen reader users encounter these problems monthly . Twenty-five percent of all accessibility issues are keyboard-related . Seven million Americans can't use a mouse .

Your site should work for them. If it doesn't, a lawsuit might be the least of your problems. The real cost is the users you're excluding every day.