The same content does not deserve the same container.

Patterns that lean on a cursor, on hover, and on a wide screen (a centered modal, a hover menu, a tooltip, a right click, a persistent sidebar) are ergonomically hostile to a thumb. Steven Hoober's field study of 1,333 observations found that 49% of people use a phone one-handed, with the thumb as the dominant actuator, and that grip changes "very often, sometimes every few seconds." The comfortable arc of the thumb covers the lower half of the screen; the top edge forces a regrip. That single fact drives the whole map: primary actions and navigation move down, anchored to the bottom edge, inside the safe area.

Material draws two variants. A standard bottom sheet "co-exists with the screen's main UI region and allows for simultaneously viewing and interacting with both regions," so it carries no scrim, good for secondary content that stays on screen while the main area scrolls. A modal bottom sheet "present[s] a set of choices while blocking interaction with the rest of the screen," sits above a scrim, and is the direct replacement for a centered modal and for inline menus. iOS expresses the same idea as a sheet with resizable detents (medium and large snap points) and an optional grabber, treated here as an iOS convention rather than a verbatim rule (see Sources).

A bottom sheet is still a dialog. It is not a decorated <div>. Build the modal variant on the native <dialog> element and let the platform hand you most of the accessibility for free.

Bottom sheet or centered modal? Same component, one media query.

Hoober's field data is the anchor here. One-handed use: 49% (67% right thumb, 33% left). Cradling: 36%. Two-handed: 15%, and 90% of that in portrait. When cradling, the thumb is on the screen 72% of the time. And, verbatim: users "change the way they're holding their phone very often, sometimes every few seconds." The thumb owns the lower band; the top edge is the stretch zone. So the primary action lives at the bottom, pinned (sticky), full width or aligned to the dominant thumb.

Target size: the legal floor is not the goal. WCAG 2.5.8 (AA) sets the minimum at "24 by 24 CSS pixels," but that is a floor with exceptions, not a target. NN/g recommends far more: interactive elements "at least 1cm by 1cm," because "the impact area of the typical thumb is an average of 2.5cm wide," and targets must be big enough and then also spaced well enough. Our rule for anything in the thumb zone: at least 44 to 48px tall, in line with Material's 48dp and NN/g's 1cm. Never the bare 24px for a primary action.

Material: a navigation bar "lets people switch between UI views on smaller devices" and holds three to five destinations (the component "does not support more than 5"). Each destination is a link or button with an accessible name, and the active one carries aria-current="page". Use a bottom bar for three to five top-level destinations of equal weight that stay visible; use a drawer when there are more than five or the navigation is secondary or hierarchical. On desktop that same set becomes the persistent sidebar.

A FAB "represents the primary action of a screen," a single, unambiguous action like create or compose. Use it only when there is exactly one such action. Do not pair a FAB with a sticky bottom CTA: they compete for the same thumb band, so on any one screen they are usually mutually exclusive.

Material: snackbars "provide brief messages about app processes at the bottom of the screen" and "shouldn't interrupt the user experience." Only one shows at a time (a new one dismisses any previous), it may carry a single optional action such as undo or retry, and it is "the preferred mechanism for displaying feedback messages," with toast reserved for when a snackbar cannot be used. It replaces the desktop toast that lived in the top-right corner. On web: a region with role="status" (or aria-live="polite") anchored to the bottom with env(safe-area-inset-bottom); if it has an action, that action is a real <button> reachable by keyboard, and never dependent on a swipe (Section 6).

Swipe to delete, long press for a context menu, pull to refresh, drag on a sheet's snap points: all useful, all mobile-native. The non-negotiable rule: a gesture can never be the only path. There must always be an alternative that works with a single pointer and with a keyboard.

MDN defines env(safe-area-inset-*) as "the safe distance from the top, right, bottom, or left inset edge of the viewport, defining where it is safe to place content without risking it being cut off by the shape of a non-rectangular display." The four variables are safe-area-inset-top, -right, -bottom, and -left. They are 0 on a plain rectangular viewport and larger than zero around a notch or the home indicator, but only when the page opts in with <meta name="viewport" content="viewport-fit=cover">.

Do not read navigator.userAgent. Detect the capability of the input and the size of the viewport, because that is what actually decides whether these patterns fit. MDN's pointer media feature tests the primary pointer's accuracy: coarse is "a pointing device of limited accuracy, such as a finger on a touchscreen," fine is "an accurate pointing device, such as a mouse," and none is no pointer at all. Use pointer for the primary device and any-pointer for any device present.

Why These compact chips are the whole detection surface: primary pointer accuracy, viewport width, and hover availability. No user-agent string appears anywhere in it.

Sources

• Steven Hoober, How Do Users Really Hold Mobile Devices? (UXmatters, 2013). Field study of 1,333 observations: 49% one-handed (67% right thumb), 36% cradling, 15% two-handed; thumb on screen 72% while cradling; grip changes very often, sometimes every few seconds. The basis for anchoring actions at the bottom. uxmatters.com/mt/archives/2013/02
• Aurora Harley, Touch Targets on Touchscreens (Nielsen Norman Group, 2019). Interactive elements at least 1cm by 1cm; the typical thumb impact area averages 2.5cm; targets must be big enough and then spaced well enough. nngroup.com/articles/touch-target-size
• W3C, Understanding WCAG. SC 2.5.1 Pointer Gestures (A), single-pointer alternative for path-based and multipoint gestures. SC 2.5.7 Dragging Movements (2.2, AA), no-drag alternative with the user-agent exception. SC 2.5.8 Target Size Minimum (2.2, AA), 24 by 24 CSS px floor with exceptions. w3.org/WAI/WCAG22/Understanding
• MDN Web Docs. The <dialog> element (showModal() makes the rest inert, Escape closes, focus behavior, aria-modal, ::backdrop, explicit close button). CSS env() and safe-area insets with the sticky footer pattern (Baseline 2020). The pointer media feature, coarse and fine and none (Baseline 2018). developer.mozilla.org
• Adam Argyle, Building a dialog component (web.dev). An accessible native dialog, focus placed on the cancel action so confirmation is deliberate, and the mega dialog transforming into a bottom-anchored action sheet at small viewports. web.dev/building-a-dialog-component
• Material Components (official docs, GitHub material-components-android). Bottom Sheet (standard vs modal, scrim, the 48dp accessible drag handle that handles expand and collapse commands). Snackbar (bottom, one at a time, one optional action, preferred over toast, readable by screen readers). Floating Action Button (single primary action, sizes, content description). Bottom Navigation (three to five destinations, a title per item). github.com/material-components/material-components-android
• Apple Human Interface Guidelines, Sheets and Action Sheets. Sheets for a scoped task tied to context; resizable detents (medium and large); the grabber as a resize hint; nonmodal sheets; action sheets anchored at the bottom on iPhone. Referenced as iOS conventions. iOS convention, cited via snippet, not verified verbatim developer.apple.com/design/human-interface-guidelines
• House rules layered on the cited guidance, not verbatim claims: the desktop-to-mobile mapping table and the "same component, one media query" position (design judgment anchored in the sources above), the 44 to 48px thumb-zone floor (reconciling Material 48dp, NN/g 1cm, and the WCAG 24px minimum), the FAB and sticky-CTA mutual-exclusion guidance, and the capability-OR-width activation rule. The virtual keyboard subsection is explicitly marked out of scope and not yet verified against a primary source.