Tab Menu
A tab menu is the set of destinations an app is made of, drawn as one repeated item: a glyph, a label, and a chosen state that is the only thing on screen saying where you are. This family draws that item four ways, a fixed sidebar rail, a header row underlined in brand ink, a row of labels with no glyphs at all, and the same row with its icons kept.
The name describes the shape, not the semantics. Where each item has an address of its own, these are links inside a navigation landmark, and the real work is marking the current one with something other than colour, since a filled pill or a bar survives a grayscale screenshot and a coloured word does not. Width is the other constraint. Destinations that do not fit are usually handled by letting the row scroll, which hides the tail of the nav behind a gesture nobody mentions; wrapping keeps every destination visible, and an underline then has to stay attached to the label it belongs to.
Dashboard nav
Best for
App sidebars: a fixed 240px rail of destinations
Anatomy
Icon and label on every row · the chosen row on a grey pill · rows fill the rail's width · a hairline all round the set
Underline nav
Best for
Section switching in a page header: the chosen one named in brand
Anatomy
Brand ink on the chosen tab · an 8px bar sitting on the bottom rule · the bar scales between tabs rather than cutting · the row wraps before it clips
Subtle nav
Best for
Quiet switching: labels only, where an icon would be noise
Anatomy
No glyphs · the chosen label on a grey pill · 8px of padding round each label · the row wraps before it clips
Icon nav
Best for
Switching where the glyph carries as much as the word
Anatomy
A 20px glyph beside every label · the chosen tab on a grey pill · a hairline round the whole set rather than above and below · the row wraps before it clips
Pill nav
Best for
Four or five sections of one page, switched from a header
Anatomy
Icon and label pills · count on the items that carry one · grey pill on the current item · wraps to a rounded card
Sidebar with groups, and the icon rail
Best for
App navigation that has to fold away for room
Anatomy
Workspace switcher · items with counts · Projects group · seats card · settings · account card with an inline collapse button · folds to a 64px rail with dots for counts
Using Tab Menu
Reach for it when
- An app with a small, stable set of destinations that does not change as the reader moves between them.
- A fixed sidebar rail where every row wants a glyph and a label and the whole row should be the target.
- A header row under a page title, where the chosen section should be named in brand ink rather than a weight change.
- Switching where the labels are short and an icon would only add noise.
Reach for something else when
- Destinations that nest three levels deep: collapsible sidebar groups or a tree view show a hierarchy that a flat row has to pretend is not there.
- Facets of one record that stay on the same page. Those are tabs, and the difference is whether the address changes, not what the control looks like.
- A destination list long enough to wrap twice: a command menu or a grouped dropdown handles the tail better than a nav that has become a paragraph.
Where it shows up
Dashboard sidebar
A fixed rail of destinations down the side of an application. Rows fill the rail's full width so the whole row is the target, and the glyph does the recognising while the label does the confirming.
Page section headers
A row sitting under a page title, moving between the areas of one section. The chosen item is named in brand ink with a bar beneath it, which is legible from further away than a weight change would be.
Workspace settings nav
Account, billing, members, integrations. Labels only, because glyphs for abstract areas are guesses the reader has to decode twice, and the words are short enough that the row still fits.
Icon-led switching
Places where the glyph carries as much as the word: media kinds, view modes, tool categories. The two together travel across languages better than an icon on its own, which has to be learned first.
Questions
Should tab menu items be links or buttons?
If each item is a destination with an address of its own, use links. Real anchors can be opened in a new tab, middle-clicked and copied, and a screen reader announces them as navigation. Reach for buttons with tab semantics only when the address does not change and content swaps in place. The visual treatment is identical either way; the underlying element is not.
How should the current destination be marked?
With two signals rather than one. Set aria-current on the item so assistive technology announces it, and give that item a change of shape as well: a filled pill, or a bar under the label. Colour alone fails for anyone who cannot distinguish the hue, and fails again in a printout, a screenshot or bright sunlight where contrast collapses.
Premium components,
free in your inbox.
Join the Orvain Dispatch and get production-ready components, free to keep: React and Vue code plus the Figma frame, yours to ship.
Orvain MCPTab Menu
A tab menu is the set of destinations an app is made of, drawn as one repeated item: a glyph, a label, and a chosen state that is the only thing on screen saying where you are. This family draws that item four ways, a fixed sidebar rail, a header row underlined in brand ink, a row of labels with no glyphs at all, and the same row with its icons kept.
The name describes the shape, not the semantics. Where each item has an address of its own, these are links inside a navigation landmark, and the real work is marking the current one with something other than colour, since a filled pill or a bar survives a grayscale screenshot and a coloured word does not. Width is the other constraint. Destinations that do not fit are usually handled by letting the row scroll, which hides the tail of the nav behind a gesture nobody mentions; wrapping keeps every destination visible, and an underline then has to stay attached to the label it belongs to.
Dashboard nav
Best for
App sidebars: a fixed 240px rail of destinations
Anatomy
Icon and label on every row · the chosen row on a grey pill · rows fill the rail's width · a hairline all round the set
Underline nav
Best for
Section switching in a page header: the chosen one named in brand
Anatomy
Brand ink on the chosen tab · an 8px bar sitting on the bottom rule · the bar scales between tabs rather than cutting · the row wraps before it clips
Subtle nav
Best for
Quiet switching: labels only, where an icon would be noise
Anatomy
No glyphs · the chosen label on a grey pill · 8px of padding round each label · the row wraps before it clips
Icon nav
Best for
Switching where the glyph carries as much as the word
Anatomy
A 20px glyph beside every label · the chosen tab on a grey pill · a hairline round the whole set rather than above and below · the row wraps before it clips
Pill nav
Best for
Four or five sections of one page, switched from a header
Anatomy
Icon and label pills · count on the items that carry one · grey pill on the current item · wraps to a rounded card
Sidebar with groups, and the icon rail
Best for
App navigation that has to fold away for room
Anatomy
Workspace switcher · items with counts · Projects group · seats card · settings · account card with an inline collapse button · folds to a 64px rail with dots for counts
Using Tab Menu
Reach for it when
- An app with a small, stable set of destinations that does not change as the reader moves between them.
- A fixed sidebar rail where every row wants a glyph and a label and the whole row should be the target.
- A header row under a page title, where the chosen section should be named in brand ink rather than a weight change.
- Switching where the labels are short and an icon would only add noise.
Reach for something else when
- Destinations that nest three levels deep: collapsible sidebar groups or a tree view show a hierarchy that a flat row has to pretend is not there.
- Facets of one record that stay on the same page. Those are tabs, and the difference is whether the address changes, not what the control looks like.
- A destination list long enough to wrap twice: a command menu or a grouped dropdown handles the tail better than a nav that has become a paragraph.
Where it shows up
Dashboard sidebar
A fixed rail of destinations down the side of an application. Rows fill the rail's full width so the whole row is the target, and the glyph does the recognising while the label does the confirming.
Page section headers
A row sitting under a page title, moving between the areas of one section. The chosen item is named in brand ink with a bar beneath it, which is legible from further away than a weight change would be.
Workspace settings nav
Account, billing, members, integrations. Labels only, because glyphs for abstract areas are guesses the reader has to decode twice, and the words are short enough that the row still fits.
Icon-led switching
Places where the glyph carries as much as the word: media kinds, view modes, tool categories. The two together travel across languages better than an icon on its own, which has to be learned first.
Questions
Should tab menu items be links or buttons?
If each item is a destination with an address of its own, use links. Real anchors can be opened in a new tab, middle-clicked and copied, and a screen reader announces them as navigation. Reach for buttons with tab semantics only when the address does not change and content swaps in place. The visual treatment is identical either way; the underlying element is not.
How should the current destination be marked?
With two signals rather than one. Set aria-current on the item so assistive technology announces it, and give that item a change of shape as well: a filled pill, or a bar under the label. Colour alone fails for anyone who cannot distinguish the hue, and fails again in a printout, a screenshot or bright sunlight where contrast collapses.
Related blocks
All blocksPremium components, free in your inbox.
Join the Orvain Dispatch and get production-ready components, free to keep: React and Vue code plus the Figma frame, yours to ship.
