Radio

2nd lightest of the eight, by js weight

A single <input type="radio">, themed through CSS custom properties, meant to be used inside a RadioGroup rather than standalone.

Example (a11y tier)

Delivery methodStandard (5-7 days)Express (2 days)PickupReady in 1 hour at the downtown location.

Import

import Radio from 'abaabil/radio'         // structure only

import Radio from 'abaabil/radio/styled'  // + CSS

import Radio, { RadioGroup } from 'abaabil/radio/a11y'  // + label/description/shared name

Why `RadioGroup` matters: the shared `name`

Radio buttons only behave as one group, mutually exclusive selection and arrow-key navigation between them, when they share the same native name attribute. Radios with different (or missing) names each act as their own independent group of one, and nothing visible tells you this went wrong: they still render, still look identical, and each one still toggles on click. The bug only shows up as "I can select two of these at once" or "arrow keys don't move between them", usually reported by a keyboard or screen reader user long after the markup shipped.

RadioGroup removes the chance to get this wrong: it generates a shared name with useId and provides it through context, so every Radio rendered inside automatically picks it up. Passing an explicit name to RadioGroup (as in the example above) is optional and only useful for reading the group's value from native form submission.

Props

Prop	Type	Default	Tier	Description
`className`	string	—	all	Merged with the base class.
`label`	string	—	a11y	Accessible name, rendered as a real `<label>`. The platform does not supply one.
`description`	string	—	a11y	Rendered text, wired via `aria-describedby`.
`name`	string	inherited from `RadioGroup`	a11y	Overrides the name inherited from an enclosing `RadioGroup`.
`id`	string	—	a11y	Overrides the generated input id.
...props	—	—	all	Everything else (`value`, `checked`, `defaultChecked`, `onChange`, `aria-describedby`, ...) lands on the `<input>`.