import type { ControlSize } from "@charcuterie/tokens";
import type { ReactNode } from "react";
export type CheckboxProps = {
    className?: string;
    /**
     * Standing help under the box — units, a consequence, a warning
     * about what ticking it does. Same slot, same words and same
     * announcement order as `Field`'s: bound with `aria-describedby`,
     * so a screen reader reads it **with** the control rather than
     * announcing it from nowhere.
     *
     * It renders **outside** the `<label>` on purpose. A `<label>`'s
     * text content *is* the control's accessible name, so a hint put
     * inside it would be read twice — once as part of the name, once as
     * the description — and a pointer press anywhere on the hint would
     * toggle the box.
     */
    description?: ReactNode;
    /**
     * The caller's own id, when it has one — a stable target for an
     * autofill hint or a deep link. Left to React's `useId` on the
     * `<input>` otherwise, which is enough for the wrapping `<label>`.
     */
    id?: string;
    /**
     * **Initial** only. The `<input>` is the store from then on — the
     * DOM owns a checkbox's checkedness, and a controlled `checked`
     * prop is the thing this library refuses to have
     * (`SegmentedControl` says the same about `selectedValue`).
     */
    isChecked?: boolean;
    isDisabled?: boolean;
    /**
     * Shows the value at full contrast but refuses to change it — a
     * setting you may read here and edit elsewhere. Distinct from
     * `isDisabled`, which dims: a read-only box is not turned down,
     * because the whole point is that you can still read it. Announced
     * as `aria-readonly`, and the toggle is blocked on both pointer and
     * `Space`.
     */
    isReadOnly?: boolean;
    /**
     * The visible text beside the box, and the checkbox's accessible
     * name — the `<label>` wraps the control, so there is no `for` to
     * get wrong. A box with no label is a control a screen reader
     * cannot announce, which is why this is required.
     */
    label: ReactNode;
    onChange?: (isChecked: boolean) => void;
    size?: ControlSize;
    /**
     * The `<input>`'s `value` attribute — which member of a group this
     * box IS, as opposed to whether it is ticked.
     *
     * A lone boolean does not need this. A GROUP does: the browser
     * submits `name=value` for each ticked box in a form, and, more
     * relevantly here, a group is normally read back with one query —
     * `[...root.querySelectorAll("input")].filter(i => i.checked)
     * .map(i => i.value)`. Without a `value` every box in the group
     * reports the string `"on"` and the read is useless, which is why
     * queuepilot's library and ratings pickers were still hand-rolling
     * a raw `<input type="checkbox">` rather than adopting this
     * component.
     *
     * Passed straight through and otherwise inert. It is NOT the
     * checked state and does not become one: `isChecked` still seeds
     * the box, and `onChange` still reports a boolean.
     */
    value?: string;
};
/**
 * A single boolean, on or off, that owns nothing but itself.
 *
 * This is the primitive mux-magic's `BooleanField` hand-rolled in
 * `bg-slate-700 accent-blue-500` because the library had no checkbox
 * to reach for — palette colours with no light mode, the exact M6
 * defect the token layer exists to delete. Here the box is
 * `bg-surface-sunken` and the fill is `bg-intent-accent-solid`, so
 * one control reads correctly in `daylight`, `midnight`, and on the
 * kiosk with no per-app override.
 *
 * ### The `<label>` wraps the control
 *
 * A checkbox reads to the *left* of its text, which is why it is not
 * a `Field` — `Field` stacks label above control in a `flex-col`,
 * right for a text input and wrong for a boolean, and stacking every
 * checkbox in a step card would double the card's height. Wrapping is
 * also the one label association that needs no `for` at all, so there
 * is no minted-then-dropped id to get wrong.
 *
 * ### A description is the one thing that cannot go in the `<label>`
 *
 * `Field` has had a `description` since it shipped and this component
 * had none, so a hint could not follow its checkbox. Downstream that
 * meant one hint out of three in a group stayed an app-styled
 * paragraph and the box carried two hint typographies.
 *
 * The slot is here now, and it renders **outside** the `<label>`.
 * A `<label>`'s text content is the control's accessible name, so a
 * hint inside it is announced twice — once inside the name, once
 * again as the description — and a pointer press on the hint toggles
 * the box, which is not what a sentence of explanation should do. So
 * the `<label>` is no longer the outermost element: a `<div>` holds
 * the row and the hint, `className` moves out to it (`className` is
 * the outermost box a component renders, and that rule does not bend
 * for this one), and `aria-describedby` binds the two back together.
 *
 * There is no `error` here to go with it. `Field` derives
 * `aria-invalid` from its error, and a lone boolean is almost never
 * the invalid thing — a **group** of them is, and a group's error
 * belongs on the `FieldGroup` around it, described rather than
 * asserted. Adding one per box would put `aria-invalid` on a control
 * that is not itself wrong.
 *
 * ### The `<input>` is the store
 *
 * `defaultChecked`, not `checked`. The DOM owns a checkbox's state
 * natively, so there is no second copy to keep in step and no
 * controlled-prop round-trip — `onChange` reports the new state to a
 * consumer that wants to persist it, and reading it back is the
 * `<input>`'s job. `isChecked` seeds the first paint and nothing
 * after.
 */
export declare const Checkbox: ({ className, description, id, isChecked, isDisabled, isReadOnly, label, onChange, size, value, }: CheckboxProps) => ReactNode;
//# sourceMappingURL=Checkbox.d.ts.map