What Is a Slide Menu?
Anything that stays off-screen until a trigger slides it in from one edge, then slides back out when dismissed, counts as a slide menu. While it’s closed, the page content keeps the full viewport, which is the whole appeal on small screens.
Bootstrap calls its version an off-canvas component (Bootstrap 5.3 documentation). Mobile app design gave us navigation drawer. Slide-out menu and side menu are the plain-English names for the same panel.
People often call the whole thing a hamburger menu, but the hamburger is only the three-bar button. The panel it opens is the slide menu.
App designers call that panel a drawer, and the drawer pattern in UI design sets visitor expectations. It hugs one edge and scrolls on its own, and visitors can dismiss it whenever they want.
Typical contents are secondary links and grouped sections. Justinmind’s slide menu design guide uses account links (profile, settings, logout) and mail folders (inbox, sent, drafts) as grouping examples.
It isn’t a dropdown, since a dropdown opens in place under its trigger. It isn’t a fixed sidebar either, because a sidebar never hides.
Slide Menu Types
The edge a slide menu enters from, and whether it covers the page or pushes it aside, shape most of how it behaves. Link depth is the other variable, and it matters more on bigger sites.
Origin Edge
Bootstrap 5.3 documents a placement for each edge of the screen, and none is applied by default.
offcanvas-start is the left edgeoffcanvas-end sits on the rightoffcanvas-top drops in from the topoffcanvas-bottom rises from the bottom
Each placement anchors to one edge of the viewport and slides along that edge’s axis. Left and right panels suit long link lists because they scroll vertically, while top and bottom panels fit short lists.
Justinmind adds a consistency rule. Pick left or right and keep that side across the whole product.
Overlay or Push
Overlay panels sit on top of the page while a backdrop dims whatever is underneath. The page stays where it is. Bootstrap’s offcanvas works this way, with a clickable backdrop on by default.
A push menu does something different. The page content slides sideways by the panel width as the panel enters, so two things are moving at once and the transition reads as a layout change instead of a layer opening.
Overlay is the safer default. It leaves the page layout untouched, so nothing reflows or loses its scroll position while the menu is open.
Full-Screen and Multi-Level Menus
A full-screen slide menu covers the entire viewport, which gives large touch targets and no backdrop to manage.
Multi-level menus swap the current list for the submenu instead of expanding it downward, and a back button returns to the previous level. Documentation for the Extras for Elementor and PowerPack slide menu widgets describes this drill-down. The reasoning is practical, since submenus that expand inside a panel create a scroll area inside a scroll area.
Every level adds a tap and a back step, so keep the hierarchy shallow.
When to Use a Slide Menu (and When Visible Navigation Wins)
Use a slide menu for secondary links on narrow screens, and keep primary navigation visible on every screen size.
The evidence behind that rule is Nielsen Norman Group’s 2016 quantitative study of hidden navigation. It tested hamburger-style menus against visible navigation and against combo navigation, where some links are visible and some are hidden.
179 participants completed tasks on 6 live websites, on both phones and desktops. Content discoverability dropped by more than 20% with hidden navigation. Desktop users were at least 39% slower to finish tasks when navigation was hidden than with visible or combo navigation, and mobile users were 15% slower than with combo navigation.
Design roundups often present a slide menu as a space-saving main menu for desktop sites. The NN/g data points the other way, because hiding navigation hurt the desktop experience more than the phone experience.
One limit on that evidence. The study hid the main navigation under an icon, and secondary links moved into a slide menu sit outside what it measured. That’s why the rule here keeps primary links visible.
Following NN/g’s recommendations, a desktop site should show its top-level links across the top or down the left side, with nothing hidden. On mobile with 4 or fewer top-level links, show all of them as visible links. With more than 4, hide some in a slide menu and keep the rest visible.
On wide screens, a visible sidebar navigation saves the same horizontal space as a slide menu without the extra click.
Justinmind’s guide points the same way. Its hybrid pattern pairs a bottom navigation bar for the everyday essentials with a slide menu for less frequently used options. The usability penalty falls hardest on content with no in-page link, so link to key pages from the content itself.
How Visitors Open and Close a Slide Menu
Most visitors open the panel with the hamburger button. An edge swipe works too, and on desktop a hover can do it, but neither is reliable enough to stand alone.
The button is the trigger that always works. Swipe gestures are invisible, so a visible button has to sit next to them (NN/g lists low salience as the first reason hidden navigation underperforms).
Hover fails on touch screens, and keyboard users cannot hover at all. A hover trigger needs a click or focus equivalent.
Most builds draw the three bars with CSS instead of loading an icon file, and collections of CSS hamburger menus show common ways to draw and animate the icon. Whatever the drawing looks like, the trigger should be a real button element.
Closing has more routes. Bootstrap 5.3 recommends a header with a dismiss action whenever possible, so a close button comes first. Clicking the backdrop closes the panel by default in Bootstrap, and you can switch to a static backdrop that ignores outside clicks.
Tapping a link inside the panel is a case people forget. Single-page apps and in-page anchors must close the panel in code, because no page load does it for them.
Then there are the platform gestures. MDN’s dialog documentation lists Esc on desktop and a back or dismiss gesture on mobile as platform-specific close actions.
Every slide menu needs at least one visible close control. A backdrop click alone cannot be operated from a keyboard.
How to Build a Slide Menu with HTML, CSS and JavaScript
The first four steps below are plain HTML and CSS. The toggle and the backdrop need JavaScript.
- Write the markup. That’s a button with
aria-controls pointing at the panel id and aria-expanded set to false, followed by a nav element holding the link list. - Position the panel with fixed positioning, anchored to the left edge from top to bottom, with a set width.
- Move it off-screen by applying
transform: translateX(-100%) in the closed state, and add a transform transition for the slide. - Add the open state. An
.open class resets the transform to translateX(0). - Wire up one click handler that adds or removes
.open on the panel and updates aria-expanded on the button. - Add the backdrop, a fixed layer behind the panel that closes it on click, and lock body scrolling while the panel is open.
The native dialog element is another route. Opened with showModal(), it makes the rest of the page inert, closes on Esc, exposes a ::backdrop pseudo-element for the dimmed layer, and moves focus to the first focusable element inside (MDN). That replaces the backdrop layer and the Escape and inert handling you would otherwise write by hand.
Browsers have supported the element across the board since March 2022. Animating it takes extra CSS, since MDN’s transition recipe needs @starting-style plus transition-behavior: allow-discrete on display and overlay. Firefox and Safari don’t support overlay yet, so the close animation can be cut short there.
CSS-Only Version and Its Limits
A slide menu works without JavaScript. The usual CSS-only mechanisms are a hidden checkbox paired with a label, or the :target selector, and SitePoint’s pure-CSS off-screen menu tutorial builds one with the checkbox approach.
CSS alone can’t update aria-expanded on the toggle. It can’t move focus into the panel or return it on close, and it can’t close on Escape. The :target variant also writes a fragment into the URL, which some people will find annoying.
CSS-only suits a prototype or a small brochure site. Anything that keyboard and screen reader users must operate reliably needs the JavaScript version.
Which CSS Property Should Animate a Slide Menu?
Animate transform. A translateX transition can run off the main thread, while changes to left, margin or width force layout work on the main thread.
MDN’s animation performance guide names transform as the most common property that avoids reflow and repaint. When the panel sits on its own layer, the GPU handles the motion, which helps most on mobile.
| Property | Browser cost | Verdict for a slide menu |
|---|
| transform: translateX | No reflow or repaint, GPU-eligible | Default choice |
| left, right or margin | Triggers reflow on the main thread | Avoid |
| width (jQuery animate style) | Reflows the panel and its content each frame | Legacy only |
The width approach is the 2010 pattern. Smashing Magazine’s jQuery sliding menu tutorial from that year animates a container from 0px to a set width with jQuery’s animate method, which leaves the browser re-laying out the panel on every step.
Sources also disagree on CSS versus JavaScript. MDN reports near-identical frame rates in Firefox when both run on the main thread, while GSAP and Velocity.js claim an edge over native CSS.
MDN’s own resolution is that CSS wins once the property is compositor-friendly, because the sampling leaves the main thread. So the property choice matters more than the animation tool.
Bootstrap 5.3 ships its offcanvas with a 0.3-second ease-in-out transform transition, with the duration set by a Sass variable. Its docs also say margin and translate cannot be applied to the .offcanvas element itself, because of how CSS handles the animation. Apply them to an inner element and keep .offcanvas as the independent wrapper.
MDN finds no performance difference between CSS transitions and keyframe animations, so open and close fit a plain transition. CSS keyframes earn their place only when the motion needs intermediate steps, such as a staggered reveal of the menu links.
How to Make a Slide Menu Accessible
An overlay slide menu with a backdrop should follow the modal dialog pattern from the W3C’s ARIA Authoring Practices Guide (APG). Applied to a slide menu, the pattern asks for the following.
- The panel gets role
dialog and aria-modal set to true - A visible title referenced by
aria-labelledby, or an aria-label that names the panel - Focus moves into the panel on open and goes back to the toggle on close
- Tab and Shift+Tab loop inside the panel
- A visible close button sits in the tab sequence
Bootstrap 5.3 adds role dialog through JavaScript and expects aria-labelledby to point at the offcanvas title. Its keyboard option closes the panel on Esc by default.
Marking the panel modal with ARIA is a commitment. The APG warns that users of some assistive technologies lose access to everything outside a dialog marked modal, so the flag belongs only where code blocks all interaction outside the panel and the styling visibly obscures the page.
A push menu that leaves the page visible and clickable fails both tests, so it should not carry aria-modal.
From a web accessibility audit’s point of view, a focus loop looks a lot like a trap. WCAG 2.2 criterion 2.1.2 (No Keyboard Trap, Level A) accepts constrained focus inside a modal as long as the user knows how to leave, and the W3C names Esc as a common standard exit method.
A custom panel also has to silence the page behind it. Set inert on the page wrapper while the menu is open, never on the panel itself.
MDN documents inert as removing content from the tab order and the accessibility tree, with cross-browser availability since April 2023. It adds no visual cue, so the dimmed backdrop does that job.
Motion is the last piece. A panel sliding in counts as motion animation under WCAG 2.3.3 (Animation from Interactions, Level AAA), because the criterion treats an element that moves into place as animated.
MDN adds that panning large objects can trigger vestibular reactions, and prefers-reduced-motion has worked across browsers since January 2020.
The fix is a reduce branch that swaps the slide for a fade. WCAG’s definition does not count opacity changes as motion animation, and Bootstrap’s offcanvas already keys its animation to the prefers-reduced-motion media query.
How a Slide Menu Should Behave Across Screen Sizes
Show the slide menu below a breakpoint and visible navigation above it. Bootstrap and Material UI both build that split into their panel components.
In Bootstrap 5.3, replace .offcanvas with .offcanvas-lg (or sm, md, xl, xxl) and the panel turns into inline content above that breakpoint. Responsive offcanvas classes arrived in Bootstrap 5.2.0. The toggle button needs a matching display utility so it disappears at the same breakpoint, and the close button needs an explicit data-bs-target.
Material UI takes the other approach, with the temporary Drawer variant on small screens and the permanent variant on wider ones. Its docs call the permanent drawer the recommended default for desktop. The persistent variant is acceptable for every size larger than mobile, though it isn’t recommended for apps with a multi-level hierarchy, and when it sits outside the page grid, it forces the page content to resize as it opens.
Custom builds do the same with media queries. At the breakpoint, reset the panel to static positioning, hide the toggle and drop the backdrop.
Crossing the breakpoint with the panel open is a common bug. Close the panel and clear the backdrop, the scroll lock and any inert state before the desktop layout takes over.
Pick the breakpoint from the link count, not from a device list. It’s the width where the visible bar starts wrapping or truncating labels.
A mobile-first design workflow starts with the slide menu and adds the visible bar at that width. NN/g’s warning applies here, since mobile-first should not turn into mobile-only.
Which Slide Menu Library or Component to Use
Use the component your stack already ships. That means Bootstrap’s offcanvas on Bootstrap sites, Material UI’s Drawer in React apps, and mmenu.js only when the menu needs sliding submenus.
Sites already built on Bootstrap get placement options, a backdrop, Esc handling and body scroll control without another dependency.
| Option | Best fit | Pro | Con |
|---|
| Bootstrap Offcanvas | Bootstrap 5 sites | Four placements, backdrop and Esc handling included | No built-in drill-down |
| Material UI Drawer | React apps | Temporary, persistent and permanent variants | Swipeable version adds 2 kB gzipped |
| mmenu.js | Multi-level mobile menus | Sliding submenus, back button and searchfield add-ons | Commercial use costs $15 or $150 |
| Slinky | Legacy jQuery sites | Light drill-down navigation | Needs jQuery, last release 4.2.1 in 2019 |
| Slidebars | Legacy jQuery sites | Panels on any side, unlimited instances (v2) | v2 breaks compatibility with 0.x |
The mmenu.js license has a split. Personal and non-profit sites use it free, a single commercial website costs $15, and unlimited commercial sites cost $150. The same author offers Mmenu Light as a lighter alternative.
Accessibility-first options exist too. js-offcanvas v2 is a dependency-free vanilla JavaScript class with focus trapping and focus restore, and react-aria-offcanvas ships with body lock, focus trap and focus return switched on by default.
For a single-level menu I’d skip the library entirely. A custom build or the native dialog element beats loading jQuery for a slide effect, and Slinky’s last npm release, 4.2.1, dates to July 2019.
What Breaks in Slide Menus and How to Fix It
Most slide menu bugs come from the same few places.
Focusable links in a closed panel
A panel moved off-screen with transform stays in the tab order and the accessibility tree, so keyboard users tab into links they cannot see.
Set inert on the closed panel, or switch it to visibility: hidden once the close transition ends. MDN notes that inert also works on elements meant to stay offscreen, not only on background content.
Page scrolling behind the panel
Bootstrap disables body scrolling while an offcanvas and its backdrop are visible, and exposes data-bs-scroll to allow body scrolling instead. A custom build sets overflow: hidden on the body when the panel opens and removes it on close.
Stacking collisions
A sticky navigation bar often paints over the panel because the panel sits inside a different stacking context.
Mount the panel directly under the body, outside any ancestor that sets transform. A transformed ancestor becomes the containing block for fixed descendants, which is also why push menus that transform the page wrapper break fixed headers.
A panel taller than the visible screen
A height of 100vh sizes the panel to the large viewport, so on mobile browsers with a retractable address bar the bottom links sit behind the toolbar.
MDN’s <length> reference for CSS viewport units (last updated July 2026) states that vh currently equals lvh. It lists svh as the safe size and dvh as the live size.
Anchoring the panel with top and bottom insets instead of a height sidesteps the whole problem. If you do need a fixed size, use svh. Avoid dvh for long panels, since MDN flags resizing during scroll as a performance hit.
Swipe gestures against the browser
Material UI’s documentation says the iOS swipe-to-go-back gesture interferes with the drawer’s edge discovery, so its own docs site turns discovery off on iOS.
The same docs warn that some low-end phones cannot follow the finger at 60 FPS and offer a disableBackdropTransition prop. Keep the hamburger button as the primary trigger and treat edge swipe as a bonus.
Slide Menu FAQ
How wide should a slide menu be?
Bootstrap’s offcanvas defaults to 400px wide for left and right panels and 30vh tall for top and bottom ones. That suits tablets and desktops.
On narrow phones, cap the width at 100% of the viewport so the panel never overflows the screen.
Does a slide menu hurt SEO?
No. Links inside a closed panel stay in the page’s HTML, and Google’s Gary Illyes said in 2016 that content hidden for user experience should get full weight under mobile-first indexing, as Search Engine Journal reported.
Keep the links as real anchor elements in the initial markup, not injected after a click.
Can a slide menu hold more than links?
It can. Bootstrap’s docs say an offcanvas panel can hold just about any component or custom element, and mmenu.js adds navbars for logos, breadcrumbs and tabs plus a searchfield add-on.
Keep the panel scannable, because everything inside it competes with the navigation links.
Can one page carry two slide menus, one on each side?
Mostly, though some components limit it. Bootstrap allows several offcanvas elements but shows one at a time, while Slidebars 2.0 supports an unlimited number of off-canvas instances on any side.
Give each panel its own toggle and its own aria-labelledby title.
How does a slide menu handle right-to-left languages?
mmenu.js lists right-to-left support and translations as built-in features.
In a custom build, anchor the panel with inset-inline-start instead of left, and mirror the translateX direction under dir="rtl" so the panel enters from the reading-start edge.
How to Test a Slide Menu Before Launch
Run the checks in order of how badly each failure blocks visitors. Keyboard goes first, then reduced motion, then a physical phone.
- Keyboard only, covering Tab, Shift+Tab, Esc and focus return
- Reduced-motion emulation in browser developer tools
- One real phone, to check the address bar, edge swipe and scroll lock
The order follows conformance level. A keyboard trap fails WCAG 2.1.2 at Level A, while motion triggered by interaction sits at Level AAA under 2.3.3, so a broken Esc key outranks an unreduced animation.
The phone pass costs an extra device, but it exposes the toolbar overlap and the iOS back-swipe conflict that desktop browsers hide.
Recheck the viewport step if browsers change what vh resolves to, since MDN currently lists it as equal to lvh.
Once the panel passes, the same keyboard and focus checks apply to the site’s other components, and a web accessibility checklist covers the rest.
