Responsive Navigation Patterns

Why does aria-expanded matter on a hamburger button?

A sighted user can see whether the menu is open or shut. A screen-reader user cannot — all they hear is the button's name. aria-expanded="false" tells assistive tech the button controls something that is currently collapsed; flipping it to "true" when the menu opens announces "expanded". Without it the user has no idea the button did anything, or whether the menu is already open. You must update the attribute in JavaScript every time you toggle the menu — setting it once in the HTML is not enough.

Should I use display:none or visibility/opacity to hide the mobile menu?

Both fully remove the element from the accessibility tree and the tab order, which is what you want for a closed menu — a hidden link must not be focusable. display:none is the simplest and most reliable. The catch is that display cannot be animated, so if you want a slide or fade you animate transform/opacity for the motion and still toggle a state that removes it from focus when closed (for example a hidden attribute or display:none at the end of the transition). Never hide a menu with only opacity:0 or visibility:hidden left half-on, because the links stay clickable and tabbable while invisible.

What is a focus trap and do I need one?

A focus trap keeps keyboard focus inside an open overlay so Tab cycles through the menu's links instead of escaping to the page behind it. You need one for a full-screen or off-canvas drawer that visually covers the page — otherwise a keyboard user tabs into content they cannot see. For a simple dropdown that sits in the flow you usually do not trap focus; you just make sure Escape closes it and returns focus to the button. The minimum every toggle menu needs is: Escape closes it, and focus returns to the trigger button on close.

Can I build a mobile menu with no JavaScript at all?

Yes — the "checkbox hack" uses a hidden <input type="checkbox"> plus a <label> as the toggle, and the :checked pseudo-class reveals the menu in pure CSS. It works without JS, which is its appeal. The downside is accessibility: a checkbox is announced as a checkbox, not a menu button, and you cannot easily expose aria-expanded state or wire up Escape. For production, a real <button> with a few lines of JavaScript is the more accessible choice; reach for the checkbox hack only when JS is genuinely unavailable.

Why is my sticky header not sticking?

position: sticky only works if the element has a threshold to stick to (you set top: 0) and none of its ancestors clip or hide overflow. The most common cause is an ancestor with overflow: hidden, auto, or scroll — that creates a scroll container the sticky element sticks inside of, which usually is not the page. Also check the element is a direct, full-height-enough child of the scrolling area and that you actually gave it top: 0. Remove stray overflow rules on parents first.

Where should the hamburger menu break to mobile?

There is no magic number — the right breakpoint is wherever your horizontal links stop fitting comfortably, which you find by shrinking the window until they crowd or wrap. A common starting point is around 768px, but a nav with eight long items may need to switch sooner and a nav with three short items can stay horizontal longer. Design mobile-first: write the small-screen layout as the default, then add a min-width media query that lays the links out horizontally once there is room.