Sidebar
A sidebar is an app's main navigation, pinned to one edge of every screen. It stays visible, and that is what you are buying with the space.
<nav aria-label="Main">Also called Side navigation, Left nav, Nav rail.
invoices
Four invoices are waiting to be sent.
Pick a section: the panel changes and the sidebar keeps its place. Collapse it to the icon rail and the current section is still marked. Tab moves down the list one item at a time.
For designers
A sidebar is the cheapest way to answer two questions at once: where am I, and where else can I go. Nothing has to be opened for either answer, which is why apps people live in all day, from Figma to Linear to a bank's admin panel, put their navigation down the side and leave it there.
The cost is a column of screen, every screen, forever. That is a fair trade at six destinations and a bad one at three. Count the places people actually move between in a week, not the pages that exist in the app.
When to use a sidebar
Use a sidebar when
- The product has more than about five destinations people move between all day
- Someone needs to see where they are without opening anything first
- The screen is wide enough to give up 240 to 280px and still leave a working content column
Reach for something else when
- The items make something happen rather than going somewhere. Use a menu instead.
- There are three or four destinations and they fit across the top. Use tabs instead.
- The navigation only needs to be there for one task, then get out of the way. Use a drawer instead.
- People already know the name of the thing they want and would rather type it. Use a command palette instead.
Variants
Full
- Overview
- Invoices
- Customers
Icon rail
- Overview
- Invoices
- Customers
Drawer
Three widths of the same navigation. The rail keeps the icons and drops the words; the drawer is the phone version, opened from a button in the header.
Full. Icons and labels. The default, and the only version that needs no learning.
Icon rail. Icons alone, around 48 to 64px wide. Reads well once someone knows the app and badly on their first day, so it works best as the collapsed state of a full sidebar rather than as the only state on offer.
Drawer. The phone version. It opens over the page from a button in the header and closes on Escape or a tap outside.
How to build a sidebar
Mark it up as navigation and let the structure do the work: one nav with an accessible name, a list inside it, and a link per destination. The current page is marked in the markup with aria-current="page", so the orange fill in the demo above is decoration on top of something a screen reader can already read.
<nav aria-label="Main">
<ul>
<li><a href="/overview/">Overview</a></li>
<li><a href="/invoices/" aria-current="page">Invoices</a></li>
<li><a href="/customers/">Customers</a></li>
</ul>
</nav>
Tab moves through the links one at a time, which is correct here. A sidebar is a list of links rather than a menu widget, so it needs no arrow key handling, no roving focus and no role="navigation" on top of the nav element. Give the header a skip link that jumps past it, because a keyboard user on their tenth page of the day should not tab through fifteen destinations to reach the content again.
Two details that decide whether it survives real data. Long labels need a decision before launch: truncate with the full text in a title, or let them wrap to two lines. And when the sidebar collapses to icons, keep the label in the accessibility tree with a visually hidden span, so the link is still announced by name.
Edge cases
Sections that outgrow the screen. Scroll the nav on its own, and keep the account row pinned to the bottom rather than floating away below the fold.
A second level. Nest at most one, and open it in place. Two levels of nesting inside a sidebar is a tree, and a tree wants different keyboard behaviour.
Reduced motion. The collapse animation is a width change. Under prefers-reduced-motion: reduce, snap between the two widths instead of easing.
Common questions
- How wide should a sidebar be?
- Most desktop apps land between 240 and 280px expanded and between 48 and 64px as an icon rail. That is a convention rather than a rule. Pick the width that fits your longest label without truncation, then keep it for every screen.
- Should the sidebar collapse?
- Add a collapse toggle when the content next to it needs the room, like a canvas, a table with many columns, or a code editor. If the content is a normal page of text and forms, a sidebar that never changes width is one less thing for people to manage.
- Where does the sidebar go on a phone?
- Behind a button in the header, opening as a drawer over the page. Below about 768px there is no room for a permanent column, and a rail of unlabelled icons at that size is a guessing game.
- How do I show which section someone is in?
- Mark the current item with aria-current="page" and paint it differently from hover: a fill, a bar down one edge, or a weight change. Colour alone fails WCAG 1.4.1, so pair it with the fill or the weight.
- Can a sidebar hold actions as well as links?
- One, at the top, if it is the action the whole app is for. Slack keeps New message there and Gmail keeps Compose. Everything past the first belongs in the page it acts on.
- Should sidebar sections be collapsible?
- Only when the list runs past the fold. A group of four items that collapses adds a click and saves nothing. Once a workspace has 20 projects, collapsible groups are what keeps the whole list reachable without scrolling.
Last reviewed 26 AUG 2026