Neither display: none nor visibility: hidden leaves a submenu available to a screen reader — both remove it from the accessibility tree — so accessibility is not the tiebreaker between them, and choosing on that basis is choosing on a false premise.
That is the correction this article exists to make, and Drupal core states it in its own stylesheet. core/modules/system/css/components/hidden.module.css defines three utilities and documents exactly what each one does to assistive technology:
/* Hide elements from all users. */
.hidden { display: none; }
/* Hide elements visually, but keep them available for screen readers. */
.visually-hidden {
position: absolute !important;
overflow: hidden;
clip: rect(1px, 1px, 1px, 1px);
width: 1px;
height: 1px;
word-wrap: normal;
}
/* Hide visually and from screen readers, but maintain layout. */
.invisible { visibility: hidden; }Read the third comment. Core's own class for visibility: hidden is documented as hiding content from screen readers; the only difference core draws between it and .hidden is layout. And note why .visually-hidden needs clip and a one-pixel box at all: if visibility: hidden kept content in the accessibility tree, that class would be one line long.
Three ways to hide, and what each one costs
| Behaviour | display: none | visibility: hidden | .visually-hidden |
|---|---|---|---|
| In the accessibility tree | No | No | Yes |
| Reachable by keyboard Tab | No | No | Yes |
| Occupies layout space | No | Yes, unless out of flow | No, it is absolutely positioned |
| Found by browser in-page search | No | No | Yes |
| Measurable by JavaScript | No, all dimensions read 0 | Yes | Yes, but 1×1 |
| Transitionable | Only with discrete transitions | Yes, paired with opacity | Not applicable |
| Right for a closed submenu | Usually | When you want the fade | Never |
The third row is the one most write-ups get wrong. "visibility: hidden still takes up space" holds only for an element in normal flow, and a dropdown submenu almost never is — it is absolutely positioned so it overlays the page instead of pushing it down. Out of flow, the layout objection disappears entirely.
What my own theme does, and why it does two different things
Solo, the Drupal theme I maintain, ships several menu styles, and they deliberately do not all answer this the same way.
The hover dropdown in css/components/solo-menu.css hides submenus with display: none and reveals them with display: flex on li:hover. Every tier below the first is position: absolute using logical properties — inset-inline-start, inset-block-start — so the same rules work right-to-left without a mirrored stylesheet. There is no transition here, so nothing is lost, and the panes stay out of the render tree until needed.
The off-canvas sidebar menu, in css/theme/solo-menu-side.css, does the opposite. It sits at visibility: hidden, parked out of view with inset-inline-start: 100%, and its transition names both properties:
.primary-sidebar-menu {
visibility: hidden;
transition:
transform var(--solo-sidebar-speed, 400ms) ease-in-out,
visibility var(--solo-sidebar-speed, 400ms) ease-in-out;
}
.primary-sidebar-menu.toggled {
visibility: visible;
transform: translateX(-100%);
}Listing visibility in the transition is not decoration. It animates discretely, and naming it is what keeps the panel visible for the whole slide-out, vanishing only once the slide-in finishes. Drop it and the panel disappears the instant the class is removed, leaving the transform animating something nobody can see.
Same theme, same question, two answers — and the deciding factor both times was whether there is an animation, not accessibility. To see these in a working install rather than a listing, installing and customising Solo walks through the settings that switch between them.
Animation is no longer the deciding factor either
The classic reason to prefer visibility: hidden was that display could not be animated. Modern CSS has closed that gap with two features that work together:
transition-behavior: allow-discrete, which lets discrete properties such asdisplayparticipate in a transition instead of snapping at the start.@starting-style, which supplies the "before" values an element should animate from when it first becomes rendered — the missing piece that made entry animations impossible fromdisplay: none.
Together they let a submenu fade in from display: none and fade back out to it, with nothing left occupying anything in between. Check current browser support before relying on it; the fallback is benign, because without support the menu still opens and closes, just instantly.
The Drupal-specific traps
Hidden content measures zero
Anything inside a display: none ancestor has no box, so every geometry read returns zero — and Drupal themes measure things constantly. Solo's responsive pass in js/components/solo-scripts.js reads getBoundingClientRect().width per region and assigns a width class from it, so a region measured under a display: none ancestor reads 0 and lands in the narrowest bucket. The same mechanism catches out sliders, charts and sticky-header offsets initialised inside a closed panel. visibility: hidden does not have this problem, which is a real reason to pick it that has nothing to do with animation.
Behaviours inside a pane that was hidden
When JavaScript reveals a pane containing Drupal-rendered content — a Views block, an exposed filter, a field group — that content's behaviours may never have run, or may have run against a zero-size box. Call Drupal.attachBehaviors(revealedElement, drupalSettings) on the newly visible element, passing the element rather than document so you re-process only what changed.
Hiding is not the same as not rendering
A menu link hidden in CSS is still in the HTML, still crawled, and still counted by an accessibility audit. If a menu item should not be there, unpublish it or remove it from the menu. The same confusion turns up with block titles, where "hidden" means several different things depending on which control you used — why hidden block titles in Drupal still affect SEO and accessibility works through that case in detail.
The choice that actually matters more than either property
A submenu revealed only by :hover cannot be opened by a keyboard, and on a touch screen the first tap on the parent either does nothing or follows the link. Whichever property hides it, a hover-only dropdown excludes people.
The accessible pattern is a real <button> carrying aria-expanded, toggled on click and on Enter or Space, with Escape closing the menu and returning focus to the button. Solo's menubar and mega-menu variants work this way; the state is managed in js/menu/solo-menu-state-manager.js. Hover can stay as an enhancement on top — it just cannot be the only way in. Getting that wiring right on top of Drupal's menu markup and an RTL layout takes longer than people expect; it is squarely Drupal theming work, and worth budgeting for rather than discovering during an audit.
Common questions
So which one should I use for a dropdown?
display: none by default. Reach for visibility: hidden plus opacity when you want a fade and cannot yet rely on discrete transitions, or when something inside the panel has to be measurable while closed.
Is opacity: 0 on its own a valid way to hide a menu?
No, and it is the worst option. A transparent element is still in the accessibility tree, still focusable and still intercepts clicks, so keyboard users tab into an invisible menu and mouse users hit an invisible wall. Always pair it with visibility: hidden.
What about the HTML hidden attribute?
The user-agent stylesheet applies it as display: none, so it behaves like the first column above, with the advantage that the state lives in the markup where both server-rendered code and JavaScript can see it. Any CSS display rule of equal or greater specificity overrides it silently.
Can I use these to hide things only on small screens?
You can, but hiding is usually the wrong answer to a narrow layout: the content is still downloaded and now unreachable for that visitor. Reflow it instead — small screen sizes in responsive web design covers how narrow layouts really behave in a Drupal theme.
My submenu will not open after an AJAX request. Is this the cause?
Probably not the CSS. More often the JavaScript that binds the toggle ran once on page load and never ran again for the replaced markup, or ran twice and cancelled itself out. Check the behaviour before you touch the stylesheet — troubleshooting CSS issues in a Drupal sub-theme covers how to tell a CSS problem from a JavaScript one.
Next step
Try one test on your own menu right now: load the page, press Tab repeatedly, and see whether you can open every submenu without a mouse. If you cannot, the property you used to hide it was never the real problem.
If that test fails and the menu is load-bearing for your site, describe what happens when you tab through it and I will tell you whether it is a stylesheet fix or a rebuild of the menu markup.
