Places It's Tempting To Use Display: None, But Don't

Every web developer has been there. You need something hidden from view--perhaps a modal that's not yet open, a success message to appear after submission, or decorative elements that add no meaning. The solution seems obvious: display: none. It's clean, it's standard, and it works. But this seemingly innocent CSS property can silently break accessibility for users who rely on assistive technologies.

This guide explores why display: none is often the wrong choice and what to use instead to create truly inclusive interfaces that work for everyone. Building accessible interfaces requires thoughtful decisions at every layer of your web development process.

The Accessibility Tree Problem

When you use display: none, you're not just hiding something visually--you're removing it entirely from the accessibility tree. This is the internal structure that screen readers use to understand and navigate your page.

The accessibility tree differs from the DOM in a crucial way: it's a filtered, optimized version of the document that assistive technologies actually interact with. According to MDN's accessibility documentation, when an element has display: none, it's stripped from this tree completely, meaning screen reader users cannot access its content, its ARIA attributes, or even know it exists.

For users who rely on screen readers, this can mean missing critical information--form labels, navigation instructions, or expanded descriptions that help them understand the interface. Accessible design principles should be foundational to every UI/UX design service you deliver.

Understanding Your Options

When it comes to hiding content on the web, you have three main approaches, each serving a different purpose:

The key question to ask: Who needs access to this content? Your answer determines which technique to use.

According to Nomensa's accessibility guidance, choosing the right hiding method is essential for maintaining an inclusive user experience while keeping visual design clean. These accessibility decisions impact both user experience and SEO performance since search engines also interact with your page's accessibility tree.

The Screen Reader Only Technique

The visually hidden pattern is essential for accessible interfaces. It keeps content available to assistive technologies while remaining invisible to sighted users.

The Modern Clip-Path Approach

The recommended modern technique uses clip-path to hide content while keeping it accessible:

.visually-hidden {
 border: 0;
 clip-path: inset(50%);
 height: 1px;
 margin: 0;
 overflow: hidden;
 position: absolute;
 white-space: nowrap;
 width: 1px;
}

Why this works: The element exists in the page, maintaining its place in the accessibility tree, but the clipping makes it visually invisible. Screen readers can still access and announce the content.

Common use cases: Form labels for visually obvious fields, "Read more" link context, skip links, and hidden headings that provide structure.

As WebAIM explains, this technique is fundamental for providing screen reader users with context that would otherwise be obvious from visual design.

Making Hidden Content Keyboard Accessible

Here's where many developers stumble: hidden interactive elements need special handling. A skip link that's invisible to sighted users must become visible when focused, or keyboard users will lose track of where they are.

The Skip Link Pattern

.visually-hidden {
 /* The basic visually hidden properties */
 position: absolute;
 width: 1px;
 height: 1px;
 overflow: hidden;
 clip-path: inset(50%);
 white-space: nowrap;
}

/* Make visible when focused */
.visually-hidden:focus {
 position: static;
 width: auto;
 height: auto;
 overflow: visible;
 clip-path: none;
 white-space: normal;
}

This pattern ensures that skip links and hidden interactive elements appear when keyboard users tab to them, providing essential navigation assistance without cluttering the visual design. Accessible keyboard navigation is a cornerstone of inclusive AI automation solutions that work for diverse users.

According to The A11Y Collective, this focus visibility is critical for users with motor disabilities who rely on keyboard navigation.

When to Hide from Screen Readers

The aria-hidden="true" attribute does the opposite of visually hidden techniques--it keeps content visible on screen but removes it from the accessibility tree.

Appropriate Use Cases

• Decorative icons: Font icons or SVGs that are purely decorative and add no meaning
• Repeated content: Information that appears multiple times visually but only needs to be read once
• Visual structure: Layout elements that convey meaning visually but are redundant in audio form

Use with Caution

Be very selective with aria-hidden. Removing meaningful content from the accessibility tree can leave screen reader users with an incomplete understanding of the interface. When in doubt, keep content accessible.

Note: aria-hidden does not affect keyboard accessibility. If an element is focusable, it will remain focusable even with aria-hidden="true".

Sources

1. MDN Web Docs - CSS and JavaScript accessibility best practices - Comprehensive coverage of CSS properties and their accessibility implications
2. WebAIM - CSS in Action: Invisible Content Just for Screen Reader Users - Authoritative source on techniques for hiding content for screen readers
3. The A11Y Collective - Essential Visually Hidden CSS Techniques - Modern approaches to visually hidden content with clip-path technique
4. Nomensa - How to improve web accessibility by hiding elements - Practical guidance on different hiding methods and aria-hidden attribute