The CSS-Only Spoiler: A Study in Web Accessibility Trade-offs

The quest for a JavaScript-free spoiler element exposes a fascinating gap between web standards and practical implementation. While the HTML <details> element provides nearly perfect behavior—native reveal functionality, screen reader support, and cross-platform compatibility—its structural limitations create a fundamental conflict with how modern content is authored, particularly in Markdown-based systems.

The core problem emerges from HTML's content model restrictions. The <details> element cannot be a direct child of a paragraph tag, yet most Markdown processors wrap text content in <p> elements by default. When a parser encounters <p>hello <details>secret</details> world</p>, it must restructure the document to maintain valid HTML, moving the <details> outside the paragraph and leaving orphaned text fragments. This isn't merely a technical quirk; it breaks the logical flow of content and creates unpredictable rendering outcomes that undermine the author's intent.

The proposed CSS-only solution leverages an interesting intersection of HTML attributes and CSS selectors. By adding tabindex="0" to a <span> element, any element becomes focusable through both keyboard navigation and touch interaction. The :focus pseudo-class then becomes the trigger mechanism for revealing hidden content. This approach requires no JavaScript, works across all modern browsers, and maintains the element's position within the document flow.

However, this clever workaround introduces significant accessibility concerns. When tested with VoiceOver on macOS, the screen reader announces the hidden text during navigation, then immediately removes it from the accessibility tree when focus leaves the element. More critically, there's no semantic indication that the content represents spoilers, no mechanism for users to skip potentially sensitive material, and no clear visual or auditory cue about the interactive nature of the element. To assistive technology, it's essentially just text—potentially revealing information before the user understands they've encountered a spoiler.

This limitation highlights a broader pattern in web development: many sophisticated UI interactions remain inaccessible without JavaScript. The <details> element succeeds precisely because it's a native, semantic construct with built-in accessibility affordances. Custom CSS solutions, while technically functional, often lack the comprehensive accessibility guarantees that come from using standardized HTML elements. The trade-off becomes particularly acute for content creators who prioritize both semantic correctness and practical authoring workflows.

The decision to proceed with a "good enough" CSS-only solution reflects a pragmatic acknowledgment of these constraints. For a personal blog where content control and authoring simplicity are paramount, and where the audience may be more tolerant of accessibility imperfections, this compromise might be acceptable. Yet it also serves as a reminder that the web's accessibility story remains incomplete—some patterns still require JavaScript to achieve full compliance, and the gap between what's possible with pure HTML/CSS and what's required for universal access continues to shape development decisions.

Ultimately, the spoiler element becomes a microcosm of web development's central tension: balancing ideal semantic structure with practical authoring needs, and recognizing that sometimes the most elegant technical solution isn't the most accessible one. The path forward likely involves either pushing for HTML standardization changes (allowing <details> within paragraphs) or developing better tooling that can intelligently restructure Markdown output to accommodate semantic HTML elements without breaking document flow.