Tab Bar

Also called bottom navigation, bottom bar, nav bar, tab strip

A fixed row of top-level destinations at the bottom of a small screen.

Example

Home

What is new since you last opened the app, in the order it arrived.

What the bar exposes

<nav aria-label="App"> → <ul> → <a aria-current="page">
no role="tablist", no role="tab", no aria-controls
current: home · 4 destinations · 56px targets

Four destinations, each with an icon and a word, because the second and third icons are never as obvious as they look in the design file. The targets are 56px tall — above the 44px floor — and the bar pads itself with env(safe-area-inset-bottom) so the last row does not sit under the home indicator.

When to use it

A phone-sized app has three to five top-level areas people switch between constantly.
The areas are equally important — none of them is a sub-section of another.
Switching should preserve where you were: coming back to a tab returns you to what you were doing in it.

When not to

There are more than five destinations. A “More” tab hiding six others is a menu that lost an argument.
The screen is wide. On desktop this is a sidebar or a header nav; a bottom bar there is 60px of wasted chrome.
The items are actions rather than places. A row of buttons at the bottom is a toolbar, not navigation.

Trade-offs

Always in reach of a thumb, which is the whole reason it lives at the bottom.
Top-level structure is visible at all times without opening anything.
Familiar from both platforms, so it needs no explanation.

Costs a permanent strip of a small screen, and gets in the way of the keyboard.
Caps you at about five destinations, which teams outgrow and then work around badly.
Icon-only bars are guessy: the second and third items are rarely as obvious as the designer thinks.

Accessibility

What this pattern needs in order to work for everyone.

Keyboard: These are links in a `<nav>`. Tab moves through them and Enter follows — no arrow-key model, because nothing here is a tablist.
Touch targets of at least 44×44px, including the space around the icon, not just the icon itself.
Hide the bar when the on-screen keyboard is open, or it sits on top of the field being typed into.
Roles and state: Never `role="tablist"`. That role promises `tabpanel`s controlled by each tab, and this bar navigates instead — a screen reader user is told to expect panels that do not exist.
Mark the current destination with `aria-current="page"`, and name the nav so it is distinguishable from any other on the page.
Keep the text label under the icon. Icon-only navigation loses its accessible name unless you add one anyway, so the label may as well be visible.
Respect the home indicator: pad the bar with `env(safe-area-inset-bottom)` or the last row of targets sits under the system gesture area.
Focus: Following an item moves focus to the new screen's heading, as any navigation would. Focus does not stay in the bar, because the page changed.

In the wild

iOS Music — Five destinations, icons with labels, and each tab remembering its own position.
Material Design bottom navigation — Explicitly documented as navigation, capped at five, with labels recommended for every item.

Compared with

Side-by-side breakdowns of patterns that solve a similar problem.

Tab Bar vs Tabs