pointer-events: none Is Not an Accessibility Feature

The CSS pointer-events property is one of the most misused tools in modern web development. Not because developers don't understand what it does — most do. Because they misunderstand what it doesn't do.

pointer-events: none removes an element from hit-testing. The browser skips it when determining what's under the cursor. That's the whole mechanism. And that mechanism has nothing to do with keyboard users, screen reader users, or anyone navigating outside of a pointer device. The element is still in the DOM. It's still focusable. It's still announced. It's still reachable. You've made something invisible to mice and touchscreens while leaving it fully present for assistive technology — which is almost always the opposite of what you intended.

What the Property Actually Does

The CSS-Tricks almanac entry on pointer-events (opens in new window) explains the mechanism precisely: before firing a pointer event, the browser runs hit-testing to determine which element is under the pointer. Setting pointer-events: none removes an element from that process. The browser "skips it and continues looking for the next eligible element underneath."

That's a rendering engine concept. Hit-testing is visual and pointer-specific. It has no relationship to the accessibility tree, tab order, or how a screen reader traverses the DOM.

The property is inherited, which compounds the problem. Set pointer-events: none on a parent and every child inherits it — unless explicitly overridden with pointer-events: auto. The almanac entry describes a common modal pattern where a full-page overlay container needs to pass pointer events through to background elements. The fix is pointer-events: none on the container, then pointer-events: auto restored on the modal itself. Clean solution for mouse users. Completely orthogonal to whether that overlay is trapping keyboard focus, which is the actual accessibility problem in modal implementations.

The Disabled State Problem

The most consequential misuse pattern is applying pointer-events: none to simulate a disabled interactive element — a button, a link, a form control — without using the actual HTML disabled attribute or aria-disabled.

Here's what that looks like in practice:

.button--disabled {
  pointer-events: none;
  opacity: 0.4;
}

To a mouse user, this button appears and behaves as disabled. Visually dimmed, non-clickable. The developer ships it and moves on.

To a keyboard user, this button is fully interactive. Tab stops on it. Enter activates it. Nothing in the HTML signals that the element is in a disabled state.

To a screen reader user, the element is announced as a button with no disabled state. No aria-disabled="true". No native disabled attribute. The assistive technology has no information to convey that the control is unavailable.

This fails WCAG 4.1.2 Name, Role, Value (opens in new window) — the success criterion requiring that the state of user interface components be programmatically determinable. It also fails WCAG 2.1.1 Keyboard (opens in new window) if the intent is that the element shouldn't be operable. A visually disabled button that activates on Enter is a broken experience for keyboard users regardless of what the designer intended.

The correct implementation is straightforward:

<!-- For native form controls -->
<button disabled>Submit</button>

<!-- For custom interactive elements -->
<div role="button" aria-disabled="true" tabindex="0">Submit</div>

Note the distinction: native disabled removes the element from tab order entirely (which may or may not be desirable), while aria-disabled="true" keeps it focusable but communicates the disabled state to assistive technology. Which you choose depends on the UX intent — but pointer-events: none communicates neither.

The Overlay and Inert Pattern

The modal/overlay case the almanac describes is worth examining more carefully, because it's where the pointer-events pattern is most operationally tempting and most accessibility-incomplete.

A full-viewport overlay container with pointer-events: none lets mouse clicks pass through to background content. But the actual accessibility requirement for modal dialogs is focus trapping — keyboard focus must be constrained within the modal while it's open. Background content should be inert to all users, not just pointer users.

The modern solution is the inert attribute (opens in new window), now broadly supported across browsers (opens in new window). Setting inert on background content when a modal opens removes it from tab order, prevents focus, and hides it from the accessibility tree. That's the complete solution. pointer-events: none on the overlay container is, at best, a partial complement to this — not a substitute.

<!-- When modal opens -->
<main inert>...background content...</main>
<dialog open>...modal content...</dialog>

This matters operationally because teams often reach for CSS solutions to what are fundamentally HTML and ARIA problems. CSS controls presentation. Accessibility state lives in the DOM. Our research on testing methodology gaps documents exactly this pattern: automated tools detect CSS properties but can't reliably assess whether the underlying semantic state matches the visual presentation.

SVG and the Legitimate Use Cases

To be clear: pointer-events is a genuinely useful property with legitimate applications. The SVG-specific values — visiblePainted, visibleFill, visibleStroke, bounding-box, and others — provide precise control over which parts of a graphic receive pointer events. For complex SVG interfaces, data visualizations, and interactive maps, this level of hit-testing control has no direct accessibility equivalent and doesn't pretend to.

The property also has valid uses in CSS-only UI patterns: allowing pointer events to pass through decorative overlay layers, managing z-index stacking without restructuring the DOM, and handling complex drag-and-drop interactions where temporary pointer-event suppression is part of the interaction model.

None of these use cases are accessibility problems on their own. The problem is when pointer-events: none is used as a proxy for semantic state — when it's doing the job that disabled, aria-disabled, aria-hidden, or inert should be doing instead.

What Development Teams Should Audit

If you're doing a codebase review, search for pointer-events: none applied to interactive elements. For each instance, ask three questions:

1. Is the element still in the tab order? If yes and the intent is to make it non-interactive, that's a keyboard accessibility failure.
2. Does the element have a corresponding semantic state? disabled, aria-disabled, or aria-hidden should reflect whatever the CSS is visually communicating.
3. Is this on an overlay or container? If so, is focus trapping handled separately? Is background content marked inert when appropriate?

Automated testing will catch some of this — a focusable element with pointer-events: none and no disabled state is a detectable pattern. But the intent behind the CSS choice requires human judgment. The distinction between automated detection and contextual evaluation is exactly why this class of issue persists in codebases that otherwise pass automated scans.

The underlying issue is a mental model problem. pointer-events: none feels like "making something inactive" because that's what it does for mouse users. But accessibility requires that the inactive state be communicated through the semantic layer — not just the rendering layer. CSS describes how things look. HTML and ARIA describe what they are and what state they're in.

Those are different jobs. Use the right tool for each.