Tabs

Peer views of one subject, only one visible at a time. Tabs are the only structural component whose entire purpose is to hide things — which is why their rules are about what may never be hidden.

Overview

Tabs solve a real problem — a subject with several equally valid views that will not fit on one screen. They solve it by concealment, and concealment in clinical software is the mechanism behind most of the failure modes elsewhere in this system: the filtered-out patient, the collapsed queue, the value below the fold.

So the component is permitted, narrowly, with one governing rule: nothing a clinician needs in order to notice something may live behind a tab.

Anatomy

What may never be behind a tab

• Never hide an alarm. As above.
• Never hide patient identity. The patient header sits above the tab strip, never inside a panel.
• Never hide the primary action of the screen behind a non-default tab.
• Never hide a required form field. A clinician cannot submit a form whose errors are in a panel they cannot see; if a form needs tabs, it needs to be a sequence instead.

Structure

• Two to five tabs. One tab is not a tab. Beyond five, the labels shrink or scroll and the set stops being scannable — that content wants navigation, not tabs.
• Never nest tabs. Tabs inside tabs cannot be held under interruption and cannot be described unambiguously by assistive technology.
• The default tab is the one the screen exists for, and it is stable — never "whichever was open last time", which produces a colleague's view on your screen.
• Overflow wraps. It does not scroll, and it never collapses into a menu. A tab inside an overflow menu is hidden twice, and a strip that scrolls sideways offers nothing a reader can see — the cropped-tab hint is a convention you have to already know, and on touch the sideways swipe competes with the page. Wrapping costs a second row and shows every label. This page asked for scrolling until the rule was read against the code, which wraps; the code was right.
• Selecting a tab never reorders the strip. Mainstream systems let a tab chosen from an overflow menu move to the end of the row, shifting every other tab to make room. The set a clinician learned the shape of is then rearranged by the act of using it, under a pointer already moving — the objection in Reprioritisation, applied to navigation.
• Panels keep their state when a clinician switches away and back — an annotation toggled on in the ECG view is still on when they return.

Content behind a tab is still content in the record

A clinician who wants to know whether a patient is on amiodarone presses Ctrl + F and types the word. If the answer is in a panel they have not opened, the browser reports no match — and no match is not the same answer as no amiodarone.

The platform has the mechanism. hidden="until-found" keeps a panel invisible and out of the accessibility tree while leaving its text reachable by the browser's own find; when a match is inside, the browser fires beforematch and reveals it. The component listens for that and selects the matching tab, so the strip and the panel agree — otherwise the reader ends up reading a panel whose tab still says it is not selected.

• This is the same argument that rebuilt the accordion. Accordion is a native <details> for exactly this reason. Tabs kept plain hidden for longer only because nobody checked.
• It does not weaken the concealment rules. A panel is still not read out, still not tabbed into, and an alarm still never waits in one — see What may never be behind a tab. Findable is not the same as present.
• Engines without support lose nothing. An unknown value on hidden is truthy, so the panel hides as it did before.
• Server-rendered markup still says hidden until the component mounts, because React types the attribute as a boolean. The behaviour is asserted in a real browser rather than in the render gate, which is the honest place for it.

Arrowing through a tab is not reading it

Arrow keys move focus only; Enter, Space or a click selects. ARIA’s authoring practices permit either, and this component selected on arrow for a long time while the accessibility notes below said it did not — the per-bullet audit of the safety notes was what caught it. Automatic activation walks a keyboard user through every panel between the first tab and the fourth, rendering, announcing and loading each in passing. Manual activation means a tab is selected because someone chose it. What follows is about that selection.

• onChange is a selection event, not a view. If it is wired to record that a clinician looked at a panel, a tab chosen and left in a second files a viewing that did not happen. That is the objection Editing the draft makes to dwell timers, arriving through a keyboard instead.
• Nothing else may hang off selection either — not marking a result acknowledged, not clearing a notification, not starting a billable action. Selecting a tab changes what is on screen and nothing in the record.
• Where a panel is expensive to populate, fetch on selection but debounce it, so traversal does not fire four requests. The component holds no such state; this is yours.

What the component enforces, and what it only asks for

The tab strip holds its keyboard and its concealment rules. What it cannot hold is the decision about what is safe to conceal at all, which is the subject of most of this page.

Do's and don'ts

Accessibility

• Full ARIA tabs pattern — role="tablist" with an accessible name, role="tab" with aria-selected, and role="tabpanel" associated back to its tab.
• Roving tabindex. One tab stop for the strip; arrow keys move between tabs, Home and End jump to the ends.
• Manual activation. Arrow keys move focus; Enter or Space selects. Auto-activation on arrow renders every panel in passing, which is noisy for screen-reader users and expensive when a panel loads data.
• Selected state is not colour alone — underline plus text weight plus aria-selected.
• Counts are in the tab's accessible name: "Troponin, 2 items" rather than a visual badge a screen reader announces as a bare number.
• Panels are labelled by their tab and are focusable so keyboard users land in the content after selecting.
• At 320 px and 200 % zoom the strip scrolls horizontally with visible affordance; labels never truncate.

Outcomes of use

What this contributes to, in the terms of Usability & context of use. These are attributes believed to contribute to an outcome; the outcome itself is settled by observing real use in a specified context, not by this page.

• Effectiveness — nothing needed goes unnoticed because it was in another panel. Counts and docked alarms are what buy the right to hide anything at all.
• Efficiency — one subject's views reachable without losing context or re-establishing identity, which is what tabs are genuinely good at.
• Satisfaction — confidence that the screen is not concealing something. A clinician who checks every tab before acting has been given a strip that does not tell them enough.

Clinical safety notes

• Alarms never behind a tab. (you) Mitigates: a Critical condition arising in a hidden panel and waiting there unseen.
• Counts on tabs with pending content. (the component names what it counts; supplying them is you) Mitigates: an unattended result being indistinguishable from an empty view.
• Patient identity above the strip. (you) Mitigates: acting inside a panel with the record's identity out of view.
• Stable default tab, never last-used. (you) Mitigates: inheriting a colleague's view and assuming it is the standard one.
• No nested tabs; five maximum. (you) Mitigates: structure that cannot be held under interruption.
• Panels retain state. (you) Mitigates: silently reverting a deliberate view setting such as annotation or calibration.
• Manual activation. (the component) Mitigates: loading and announcing panels a clinician only passed through.

Implementation

$ npx shadcn@latest add https://md.notjustany.tech/r/tabs.json

<Tabs
  label="Patient record"
  activeId={active}
  onChange={setActive}
  tabs={[
    { id: "ecg", label: "ECG", content: <p>12-lead, acquired 14:26</p> },
    { id: "troponin", label: "Troponin",
      count: { value: 2, of: { one: "result", other: "results" } },
      content: <p>47 ng/L, rising</p> },
  ]}
/>

// The count is a Badge, so a bare number with no unit cannot be shown.
// Arrow keys move focus; Enter or Space selects. onChange is a selection, not a view.

What the component takes. This table used to list defaultValue, syncToUrl, activationMode, count, keepMounted — props the component does not have, and never had. Found by the registry gate’s props-table rule.

Related

• Alert Banner — where hoisted alarms render.
• Card — the usual content of a panel.
• Patient header — sits above the strip.
• Data grid — the same disclosure logic for hidden rows.