Next.js Label for Accessible Form Fields

Drivn installs through a small CLI that writes the component source directly into your repository — there is no runtime npm package to version-lock. From the root of your Next.js 16 project run npx drivn add label. The Label has no component dependencies and imports no icons, so the CLI writes a single label.tsx file and nothing else. The CLI reference documents every flag, including targeting a custom directory or installing several components at once. After install you own the file; future Drivn releases will not overwrite it. Commit the change for a clean baseline before you wire it into forms, and confirm the file landed under your UI directory in the editor.

Because the Label holds no state and runs no effect, its source has no 'use client' directive — you can import and render it inside a server component with zero client JavaScript shipped for the field. The component wraps your text in a native <label> styled to text-sm font-medium text-foreground, so it reads as a small, medium-weight caption above the control. The attribute that does the accessibility work is htmlFor: set it to the id of the input it describes and the browser links the two, so a screen reader announces the label when the field is focused and a click on the label word focuses the input. Because both the Label and Drivn's Input render on the server, an uncontrolled labeled field ships no client JavaScript at all. See the installation guide for project setup.

Because the Label renders on the server and forwards every native attribute, it drops straight into the App Router's Server Action form pattern with no client boundary. Give each input a name and an id, point each Label's htmlFor at the matching id, attach a server function to the form's action, and read the values off FormData on the server — no onChange, no useState, no client component. The label is doing accessibility work, not state work, so it never needs to hydrate: the browser posts the form natively and the action runs on the server. The htmlFor/id pairing keeps the form usable for keyboard and screen-reader users while shipping zero client JavaScript for the field. For copy-paste labeled-field patterns see the Label examples.

A label is not only for text inputs — the same htmlFor/id pairing associates it with a Checkbox, a radio, or a Select. Point the Label's htmlFor at the control's id and clicking the label toggles the checkbox or focuses the select, which enlarges the hit target and matches native form behavior. For a checkbox the convention is to place the Label beside the control in a horizontal row rather than above it, so the two read as a single line — a flex items-center gap-2 wrapper handles the layout. The Label's styling stays the same in either arrangement because it carries no positional classes of its own; the wrapper owns the layout and the Label owns only its text-sm font-medium typography. This composability is why the Label ships one className and no variants.

Every class the Label renders lives in a single cn() call inside the file you own after install — there are no size or variant maps, because a label is one consistent style across a form. It sets text-sm font-medium text-foreground: a small, medium-weight caption that reads its color from your Tailwind tokens. Edit that one string and every label in your app updates at once, and because text-foreground is a token, changing it in theming re-themes every label for dark and light mode automatically. The className prop merges through cn() for per-instance overrides — pass className="text-base" to enlarge one label or className="text-destructive" to flag an error field without touching the base. The Label source below is copied verbatim from label.ts.