focus-lock vs focus-trap: Choosing the Right Tool for Keyboard Accessibility

Both focus-lock and focus-trap solve the same core problem: keeping keyboard focus trapped inside a modal or overlay so users can’t accidentally navigate into obscured background content. This is essential for WCAG compliance and a good experience for keyboard and screen reader users. But they take different approaches — one leans declarative and React-friendly, the other stays lightweight and framework-neutral.

🧱 Core Architecture: Declarative vs Imperative

focus-lock is built primarily for React and uses a declarative component model. You wrap your modal content in <FocusLock>, and the library handles setup and cleanup automatically when the component mounts or unmounts.

import { FocusLock } from 'focus-lock';

function MyModal() {
  return (
    <FocusLock returnFocus>
      <div role="dialog" aria-modal="true">
        <h2>Confirm Action</h2>
        <button>Yes</button>
        <button>No</button>
      </div>
    </FocusLock>
  );
}

focus-trap provides an imperative API that works anywhere. You create a trap instance and explicitly call .activate() and .deactivate().

import { createFocusTrap } from 'focus-trap';

const modal = document.getElementById('my-modal');
const focusTrap = createFocusTrap(modal);

// Activate when modal opens
focusTrap.activate();

// Deactivate when modal closes
focusTrap.deactivate();

⚙️ Configuration and Control

Both libraries support common options like returning focus to the triggering element and handling click outside events, but their configuration styles differ.

focus-lock passes options as props:

<FocusLock
  returnFocus={true}
  autoFocus={true}
  allowOutsideClick={true}
  noFocusGuards={false}
>
  {/* modal content */}
</FocusLock>

focus-trap accepts an options object during creation:

const focusTrap = createFocusTrap(modal, {
  returnFocusOnDeactivate: true,
  clickOutsideDeactivates: true,
  escapeDeactivates: true,
  initialFocus: false
});

Note: focus-lock’s noFocusGuards adds invisible sentinel elements before and after the lock to catch focus — a technique also used internally by focus-trap, though not directly configurable as a boolean flag.

🔄 Activation Lifecycle Management

focus-lock ties activation directly to React rendering. When the <FocusLock> component appears in the tree, trapping begins; when it’s removed, trapping ends and focus optionally returns. This reduces boilerplate but assumes you’re using React’s render cycle to manage modal visibility.

focus-trap requires you to manually call .activate() and .deactivate(). This gives you precise control — useful if your modal’s open/closed state isn’t tied to component mount/unmount (e.g., toggling display: none instead of unmounting).

// Example: Toggling without unmounting
function toggleModal() {
  if (modal.style.display === 'none') {
    modal.style.display = 'block';
    focusTrap.activate();
  } else {
    modal.style.display = 'none';
    focusTrap.deactivate();
  }
}

🌐 Framework Compatibility

focus-lock is optimized for React. While it can be used outside React via its lower-level createFocusLock utility, its primary API assumes React context. It also ships with React-specific features like automatic cleanup on unmount.

focus-trap is completely framework-agnostic. It works in plain JavaScript, Vue, Angular, Svelte, or any environment with a DOM. There’s even a separate focus-trap-react package if you want a React wrapper around focus-trap.

🔁 Focus Return Behavior

Both support returning focus to the element that opened the modal.

In focus-lock, set returnFocus={true}:

<button onClick={() => setIsOpen(true)}>Open Modal</button>
{isOpen && (
  <FocusLock returnFocus>
    <Modal />
  </FocusLock>
)}

In focus-trap, use returnFocusOnDeactivate: true:

const focusTrap = createFocusTrap(modal, {
  returnFocusOnDeactivate: true
});

// The element that had focus when activate() was called gets focus back
focusTrap.activate();

🛑 Handling Edge Cases: Empty Modals and Dynamic Content

Both libraries handle edge cases like modals with no focusable elements.

focus-lock will focus the container itself if no focusable children exist (unless autoFocus={false}).

focus-trap behaves similarly by default but allows overriding fallbackFocus to specify a fallback element:

createFocusTrap(modal, {
  fallbackFocus: () => modal // or a specific element
});

For dynamically added content (e.g., loading states), both rely on the browser’s natural focus behavior once new focusable elements appear. Neither auto-re-focuses unless reactivated.

📦 Bundle Impact and Dependencies

Both are lightweight and dependency-free. Neither pulls in large external libraries. However, focus-lock includes React-specific logic in its main entry point, so if you’re not using React, focus-trap will have a smaller effective footprint.

🆚 Summary: Key Differences

💡 When to Pick Which

• Use focus-lock if you’re building a React app and want minimal boilerplate. Its component API aligns naturally with how modals are typically implemented in React (conditional rendering), and it handles cleanup reliably.

• Use focus-trap if you’re not using React, need fine-grained control over when trapping starts/stops, or are integrating into a legacy codebase where modals aren’t managed by component lifecycles.

Both libraries are actively maintained, well-tested, and meet accessibility standards. Your choice should come down to your app’s architecture — not feature gaps. In fact, many teams use focus-trap inside a custom React hook to get the best of both worlds.

✅ Pro Tip: If you’re using React but still want focus-trap’s flexibility, consider wrapping it in a useEffect:

useEffect(() => {
  if (isOpen) {
    const trap = createFocusTrap(modalRef.current);
    trap.activate();
    return () => trap.deactivate();
  }
}, [isOpen]);