Navigation Patterns Covering Tabs, Drawers, Bottom Navigation, and Their Interactive States

Choosing a navigation pattern is not a visual choice. It is a structural decision that determines whether a user can find a feature in two taps or twenty. The wrong pattern adds 39% to task completion time and reduces content discovery by 21%, according to a 2016 Nielsen Norman Group study of 240 mobile users. The right pattern, assessed for every interactive state, keeps focus order intact, announces the current location to screen readers, and handles empty or loading sections without breaking the flow. Compare four patterns by the interaction problem each solves, not by how they look.

Mobile navigation is constrained by viewport width, thumb reach zones, and WCAG 2.2 focus-order requirements. Each pattern exists because the others fail in a specific context.

Bottom Navigation Bar: Three To Five Top-Level Items

The bottom navigation bar solves the problem of persistent top-level access. Material Design 3 specifies 3-5 items. Apple Human Interface Guidelines specify 3-5 tabs on iPhone and up to 7 on iPad. The bar remains visible across all top-level sections within its scope. The failure case is a sixth item: it forces an overflow menu that hides a section, contradicting the pattern's reason for existing. Minimum touch target size is 48×48 dp for Material Design and 44×44 pt for Apple. WCAG 2.2 Level AA requires 24×24 CSS pixels; Level AAA requires 44×44 CSS pixels. Design to the platform maximum, not the WCAG minimum, to pass a usability test.

Tab Panel Pattern: Same-Context Switching

The tab panel pattern solves same-context switching, moving between views that share a parent section. Apple HIG calls this a tab bar. The ARIA role is tablist with tab and tabpanel children. The current tab must carry aria-selected="true" and the panel must carry aria-labelledby pointing to the tab. Focus order must preserve meaning and operability: pressing Tab moves into the tablist, arrow keys move between tabs, Tab moves into the active panel. A keyboard focus trap here, where Tab from the last tab moves to the browser chrome instead of the panel, is a WCAG 2.2 Level A failure.

Drawer Component: Progressive Disclosure For Many Sections

The drawer component solves progressive disclosure for apps with more than five top-level sections. Material Design 3 sets maximum width at 360 dp, or 85% of screen width. The hamburger menu that triggers it carries a discoverability penalty: hidden navigation reduces content discovery by 21% and increases task time by 39% compared to visible navigation, per the same Nielsen Norman Group study. Use a drawer only when the count of sections exceeds what a bottom bar or tab bar can hold. The drawer must trap keyboard focus while open and release it on close, using a focus-trap pattern with a skip link as escape.

Navigation Rail: The Tablet And Foldable Compromise

The navigation rail, specified in Material Design 3 at 80 dp wide, solves the problem of persistent but space-efficient navigation on tablets and foldables. It sits on the left edge, shows icons by default, and expands labels on hover. It suits screens wider than a phone but narrower than a desktop sidebar. The rail must expose its current location indicator to the aria-current="page" attribute and announce state changes via a screen reader announcement.

An accessible navigation menu is not about colour contrast alone. It is about state coverage: what does each item look like and announce when it is active, inactive, focused, disabled, loading, or the parent of an empty section?

Current Location Indicator

Every navigation pattern must indicate the current location. Material Design 3 requires a 3:1 contrast ratio between the active and inactive state. The ARIA attribute is aria-current="page" on the active link. Apple HIG tab bar uses a selected state with a filled icon and bold label. A pattern with no current-location indicator forces a user to remember where they are, which fails WCAG 2.2 consistent navigation and link purpose criteria.

Focus Order And Keyboard Focus Trap

WCAG 2.2 requires that focus order preserves meaning and operability. In a drawer, focus must cycle within the drawer while it is open. A broken focus trap, where Tab from the last drawer item moves to the background page, is a failure. In a bottom navigation bar, focus order must be left-to-right (or right-to-left for RTL languages) and the active tab must receive focus before inactive tabs when the user returns to that screen.

Empty State Navigation And Loading State Skeleton

When a navigation section has no content, the navigation item must remain visible but the section must show an empty state, not a broken page. The empty state must include a clear message and a call to action. The loading state must use a skeleton screen that respects the layout dimensions of the section, so the navigation bar does not shift position when content loads.

A navigation state indicator that fails is worse than no navigation at all. Here is a before-and-after example.

Before: Broken Pattern

A bottom navigation bar with four items. The active item uses a lighter icon tint that fails the 3:1 contrast ratio against the inactive state. There is no aria-current attribute. The focus indicator is a browser-default dotted outline that disappears on a dark background. Tab order jumps from the third item to the page body because the fourth item has tabindex="-1". A screen reader announces each item as 'button' with no state. Result: a user who is blind cannot tell which section they are in. A user with motor impairment cannot reach the fourth item by keyboard alone.

After: Corrected Pattern

The active item uses a filled icon and bold label with a 4.5:1 contrast ratio against the inactive state. aria-current="page" is set on the active link. The focus indicator is a 2-pixel-thick perimeter with a 3:1 contrast ratio against adjacent colors, meeting WCAG 2.2 Level AA. Tab order is left-to-right, with tabindex="0" on all items. A screen reader announces 'Home, current page' for the active item and 'Settings, 3 of 4' for each inactive item. The empty state of a section shows a skeleton screen with the same dimensions as the loaded content, so the navigation bar does not shift.

Pattern	Current Location Indicator	Focus Order Risk	Empty State Handling	Screen Reader Announcement	Touch Target Minimum
Bottom Navigation Bar	aria-current="page", 3:1 active/inactive contrast	Left-to-right tab order; no trap needed	Skeleton screen in section	aria-selected or aria-current	48×48 dp (Material), 44×44 pt (Apple)
Tab Panel	aria-selected="true" on tab, aria-labelledby on panel	Arrow keys within tablist; Tab into panel	Empty tabpanel with message	tab role, selected state	Same as platform default
Drawer	aria-current="page" on link	Focus trap required while open	Hide empty sections from navigation	navigation landmark role	44×44 CSS px (WCAG AAA)
Navigation Rail	aria-current="page", icon fill change	Left-to-right vertical order	Skeleton or hide	navigation landmark role	48×48 dp (Material)

Choosing a UI navigation pattern comes down to three numbers: the count of top-level sections, the depth of the hierarchy, and the device class.

• 3-5 sections, same hierarchy: Use a bottom navigation bar. It is persistent, thumb-friendly, and the most-used pattern in mobile apps (57% of the top 100 apps, per Baymard Institute's mobile usability benchmark).
• 3-5 sections, same parent: Use a tab panel. It keeps the user in the same context without navigating away.
• 6+ sections, or a hierarchy deeper than 3 levels: Use a drawer. Accept the discoverability penalty because no visible pattern can fit that many items on a phone screen.
• Tablet or foldable with lateral space: Use a navigation rail. It combines persistence with a small footprint.

Each pattern must be evaluated for its failure mode. A bottom navigation bar with six items forces an overflow menu that hides a section. A tab panel with more than seven tabs on iPad exceeds Apple's maximum. A drawer that does not trap focus fails WCAG 2.2 Level A. A navigation rail without a label on hover fails the link purpose criterion.

Navigation pattern selection suits the designer or developer who needs a repeatable method for choosing between tabs, drawers, bottom navigation, and rails based on interaction constraints rather than visual preference. It suits the accessibility specialist who must defend a pattern choice against a stakeholder who wants a hamburger menu because it looks clean. It suits the product manager who needs to audit an existing app's navigation for state coverage gaps.

Skip this if you are seeking design inspiration or aesthetic trend analysis. Skip it if you want colour psychology as a primary decision-making framework. Skip it if you are shopping for design software or comparing subscription plans. The most common failure: picking a drawer because it hides clutter, then discovering that hidden navigation reduces content discovery by 21% and adds 39% to task completion time. If the data says visible navigation works better, use visible navigation.