Form foundations
Native forms with visible context
A close look at labels, descriptions, validation, read-only behavior, counts, groups, and form participation in Gummy UI’s public form foundations.
By Gummy UI · Published
Keep the control native
Gummy UI’s form foundations use native labels, inputs, textareas, checkboxes, radio inputs, fieldsets, and selects where those elements already provide the required behavior. The Gel Pop shell is layered around the control rather than replacing it with a generic element. Names, values, required state, disabled state, and browser form participation remain available to the consuming application.
This architecture reduces the amount of custom keyboard behavior the design system must own. It also makes the source easier to inspect: a contributor can find the actual input and see how visual adornments, status marks, and support text are connected around it.
Give every message an address
Descriptions, errors, success messages, and character counts receive stable IDs derived from the control ID. The input’s accessible description joins the relevant IDs instead of relying on visual proximity. Invalid state and error-message relationships are exposed on the control, while visible status marks remain decorative.
A message should still make sense without colour. Error text explains the problem, success text confirms the outcome, and required or optional cues appear in the label. The material can reinforce those states, but it does not become their only carrier.
Distinguish disabled from read-only
Disabled controls are unavailable and follow native disabled behavior. Read-only controls remain part of the reading flow but prevent editing through the component’s documented path. Gummy UI gives those conditions distinct data attributes and support copy so a consumer does not need to infer behavior from opacity alone.
The distinction becomes especially important for checkbox, radio, and select-like interactions, where HTML support differs. Tests exercise protected values and keyboard behavior for the implemented foundations. A form composition should still explain why a value cannot change, because component state cannot provide the application’s business reason.
Review the form as a composition
Individual controls can be correct while a form remains difficult to use. Labels need a consistent scan path, descriptions should not crowd error messages, action order must survive narrow reflow, and long values need room to wrap. Field groups and radio legends should explain the relationship between choices.
The Component Lab includes a realistic form composition alongside state matrices so these interactions can be reviewed together. It is still sample content, not evidence of a customer workflow. Its purpose is to expose density, focus, validation, and responsive behavior using the same canonical sources delivered by the registry.