The CSS Disability Illusion: Why Visual Hiding Creates Legal Risk

Marcus's analysis of pointer-events: none as a non-feature correctly identifies the technical failure mode. But there's a compliance dimension worth examining separately: when development teams reach for CSS to solve accessibility problems, they're not just making a technical mistake. They're creating a documented gap between what a site appears to support and what it actually delivers — and that gap has become increasingly relevant in ADA Title III litigation.

This isn't a hypothetical concern. The DOJ's updated guidance on web accessibility (opens in new window) issued in March 2022 was explicit that WCAG 2.1 Level AA represents the standard against which digital properties are evaluated. WCAG Success Criterion 2.1.1 requires that all functionality be operable via keyboard. No CSS property changes that requirement. A button styled to appear disabled — but remaining in the tab order and announced by screen readers — fails that criterion regardless of how it looks to a mouse user.

The pattern Marcus describes is more common than most accessibility auditors would like to admit. Teams apply pointer-events: none to a "disabled" state, ship the feature, and mark the ticket closed. The visual QA passes. The mouse-based usability test passes. What doesn't get tested is the keyboard path, and what doesn't get documented is whether the element was actually removed from the accessibility tree or simply hidden from pointer hit-testing.

The Conformance Claim Problem

Here's where strategic risk enters the picture. Many organizations publish accessibility conformance reports — Voluntary Product Accessibility Templates (VPATs) or WCAG conformance statements — as part of procurement compliance or general transparency. These documents make claims about which success criteria are met.

When pointer-events: none is used to simulate a disabled or hidden interactive element, the conformance claim for SC 2.1.1 is almost certainly incorrect. The element is reachable by keyboard. It may be activatable. It's announced by screen readers. None of that aligns with a "supported" conformance claim for keyboard accessibility.

The Section508.gov guidance on conformance reporting (opens in new window) notes that VPATs are legal documents in federal procurement contexts. Inaccurate conformance claims in that context carry consequences that go beyond user experience. For private-sector organizations, inaccurate public accessibility statements have appeared as evidence in ADA complaints filed with the DOJ and in private litigation.

As explored in the original technical breakdown, the mechanism is simple: hit-testing is a rendering concept, orthogonal to the accessibility tree. But the organizational consequence of misunderstanding that mechanism is a conformance posture that doesn't reflect reality.

What Auditors Actually Find

Accessibility audits that rely primarily on automated testing will frequently miss this class of error. Tools like axe-core or Lighthouse test the accessibility tree and ARIA semantics — they don't always catch the mismatch between visual presentation and keyboard behavior that pointer-events: none creates. Manual keyboard testing is required.

The Great Lakes ADA Center's training resources (opens in new window) on digital accessibility consistently emphasize that automated tools catch roughly 30–40% of accessibility barriers. The remainder require human evaluation. CSS-based visual hiding that doesn't correspond to DOM or ARIA state changes falls squarely into that manual-testing gap.

For organizations relying on automated scans to maintain their conformance claims, this creates a structural blind spot. The scan passes. The VPAT gets updated. The keyboard user still encounters a focusable element that appears to do nothing — or worse, activates an action the visual design suggested was unavailable. That's not a minor UX inconsistency. For a keyboard-dependent user, it's a barrier that the organization's own documentation claims doesn't exist.

The Correct Technical Path Has Compliance Implications Too

Marcus's article recommends the appropriate alternatives: the disabled attribute for form controls, aria-disabled="true" for custom components, display: none or visibility: hidden for genuine removal from both visual and assistive technology presentation. These aren't just better code — they're the implementations that produce accurate conformance claims.

The disabled attribute on a button does several things simultaneously: removes it from the tab order, prevents activation, triggers the :disabled CSS pseudo-class for visual styling, and updates the accessible state in the accessibility tree. One attribute, coherent behavior across all interaction modalities. That coherence is what a conformance claim for SC 2.1.1 actually requires.

aria-disabled="true" is more nuanced — it communicates disabled state to assistive technology while leaving the element in the tab order, which is sometimes the correct UX choice when you want keyboard users to encounter the element and understand why it's unavailable. The WCAG Authoring Practices Guide (opens in new window) covers this distinction in detail, particularly in the context of toolbar and menu patterns where focus management expectations differ from standard form controls.

Closing the Gap Between Testing and Documentation

Organizations that treat accessibility as a compliance checkbox — rather than a continuous practice — are most vulnerable to this class of error. The gap between "our site passed the scan" and "our site is actually accessible" is where litigation risk lives, where user harm occurs, and where conformance claims become legally problematic. Those three things are not equivalent in weight, but they tend to arrive together.

Building on the technical framework established in Marcus's analysis, the question for accessibility leads and legal teams isn't just "did we use the right CSS property." It's "does our testing methodology catch the difference between visual hiding and genuine removal from the interaction model, and does our conformance documentation reflect what we actually tested."

Teams that can answer yes to both questions are in a defensible position. Teams relying on pointer-events to do accessibility work they don't understand are carrying undocumented risk — technical, legal, and reputational.

For organizations looking to close that gap, the Pacific ADA Center's technical assistance resources (opens in new window) and ADA.gov's digital accessibility materials (opens in new window) provide grounding in both the legal framework and the practical testing expectations that underpin it. The technical fix is straightforward. The organizational fix — building testing practices that catch what automated scans miss — takes more deliberate investment. The place to start is a manual keyboard audit of any element your codebase marks as "disabled" through CSS alone.