Beyond pointer-events: The Broader CSS Accessibility Misconception

Marcus's analysis of pointer-events: none lands on a real and persistent problem. But I want to push the argument further, because pointer-events is not an outlier — it's one entry in a much longer catalog of CSS properties that developers systematically misread as accessibility controls. The pattern matters more than any single property.

The Rendering-Accessibility Confusion Is Structural

Web development education has long treated visual output as the primary artifact. If something looks disabled, developers assume it is disabled — across all interaction modalities. This is not laziness or carelessness. It reflects how CSS is taught, how browsers present their DevTools, and how design systems communicate state.

The W3C's CSS specification (opens in new window) and the WCAG 2.1 guidelines (opens in new window) operate in largely separate conceptual spaces, and most developers encounter them separately. CSS is taught as a visual tool. Accessibility guidelines arrive later, often as compliance requirements, rarely as a parallel layer of the same rendering model. The result is a mental model where visual state and accessible state feel synonymous when they are frequently independent.

pointer-events: none is the clearest example of this gap. visibility: hidden is another: it removes an element from the visual layout and from the accessibility tree, but it still occupies space in the document flow. opacity: 0 removes visual presence entirely while leaving the element fully interactive and fully announced to screen readers — a combination that creates invisible, reachable controls that no sighted user can see. display: none is the one property that reliably removes an element from both rendering and the accessibility tree simultaneously, which is precisely why developers reach for it when they want something "gone" — and why they assume other properties do the same.

The disabled Attribute Problem

The pointer-events misconception has a close cousin in form controls: the disabled HTML attribute versus ARIA's aria-disabled. These are not interchangeable, and the distinction carries real consequences for keyboard users.

The native disabled attribute removes an element from the tab order entirely. Screen readers typically announce it as unavailable. aria-disabled="true", by contrast, keeps the element focusable and reachable by keyboard, while communicating its disabled state semantically. The ARIA Authoring Practices Guide (opens in new window) recommends aria-disabled specifically in cases where removing focus entirely would disorient users — for instance, in a toolbar where skipping disabled items breaks the expected navigation pattern.

Developers who understand pointer-events: none as "disabled for mouse" naturally reach for it alongside disabled or aria-disabled without recognizing that each operates on a different layer. As explored in the original article, the property has no relationship to the accessibility tree. But the deeper issue is that developers rarely have a clear map of which properties affect which layers.

What a Layered Mental Model Actually Looks Like

The Section 508 guidance from the U.S. Access Board (opens in new window) and the DOJ's web accessibility guidance (opens in new window) both require that interactive elements be operable by keyboard. Neither document teaches CSS. That gap — between legal requirement and implementation knowledge — falls on developers, and it falls on the tools and frameworks they use.

A more useful mental model treats the browser's output as three overlapping layers:

Visual layer: What pixels appear on screen. Controlled by CSS properties like opacity, visibility, display, color, pointer-events.

Interaction layer: What elements respond to input events — pointer, keyboard, touch. Controlled by pointer-events, tabindex, disabled, event listeners, and focus management.

Semantic layer: What the accessibility tree exposes to assistive technology. Controlled by HTML semantics, ARIA attributes, display: none, visibility: hidden, aria-hidden, and inert.

The inert attribute, now supported across all major browsers (opens in new window), is the closest thing to a unified control across the interaction and semantic layers. Setting inert on an element removes it from tab order, prevents pointer events, and hides it from the accessibility tree — without affecting visual rendering. It is, in many ways, what developers imagine pointer-events: none does.

The Pacific ADA Center (opens in new window) and similar regional technical assistance centers regularly field questions from developers who have implemented visual disabled states without corresponding accessible states. The frequency of those questions reflects how poorly the three-layer model is communicated in standard development training.

The Design System Amplification Effect

Individual developer misunderstanding scales when it enters a design system. A component library that uses pointer-events: none to implement a disabled button state ships that misunderstanding to every team that consumes it. The Great Lakes ADA Center's technical guidance (opens in new window) on digital accessibility consistently identifies inherited component patterns as a primary source of systemic barriers — not because individual developers made bad choices, but because those choices were abstracted into reusable code.

This is the implementation reality that the original article's framework points toward without fully addressing: the fix is not just correcting individual property usage. It requires design system audits, component-level accessibility testing, and explicit documentation of which CSS properties affect which browser layers.

Where the Fix Actually Lives

The approach I take in my own analysis tries to hold both the technical specificity and the systemic context simultaneously. pointer-events: none is a legitimate, useful property for its intended purpose — passing pointer events through overlay containers, creating non-interactive decorative elements, managing complex layered UI. The problem is not the property. The problem is a documentation and education ecosystem that does not clearly communicate the boundaries between rendering layers.

Fix the property misuse, yes. But also fix the mental model. Teach CSS in the context of the three layers it affects — visual, interaction, semantic — and the pointer-events confusion becomes obviously impossible. Developers who understand that pointer events and keyboard focus are separate browser mechanisms do not make this mistake. They need that understanding built in from the start, not corrected after the fact by a compliance audit.

The WCAG Understanding documents (opens in new window) provide the semantic layer requirements. The HTML specification's focus management section (opens in new window) covers the interaction layer. What the field still lacks is a unified resource that maps CSS properties explicitly to all three layers — which is, perhaps, the article that needs writing next.