Field

🧭 When to Use a Field

Use a Field whenever you place an input element inside your UI. Fields help communicate:

• Focus

• Errors or success

• Interaction state (e.g., loading, disabled)

• Additional UI elements (like icons or buttons)

Avoid using Fields for non-interactive content. They are meant to visually support interactive components.

🎯 Field Statuses

Empty – The resting state of the field when there is no input or user interaction.
Hover – Triggered when the user hovers over the field; shows that it is interactive.
Active – The focused state, usually with a visible outline or elevation.
Filled – The field has user input or pre-filled content.
Disabled – The field is not interactable and should appear visually muted.
Loader – Used when the field is performing an action (e.g., validating or fetching data). May include a spinner or progress indicator.

Each status is visually distinct and driven by tokenized styles for consistency across the system.

🧩 Field Types

Default – A standard field wrapper with no extras. Ideal for basic text inputs, selects, or textareas.

Pre-element – Displays an element (like an icon, avatar, or currency symbol) inside the field before the input. Often used for branding, units, or visual cues.

Post-element – Displays an element after the input, such as a status icon, copy button, or password toggle.

Pre-tab – For use cases where a button or tab-like control appears before the input. Helpful in search bars or scoped filters.

Post-tab – Similar to post-element, but with more prominent visual weight—used for embedded actions or quick controls after the field.

These types are built using Figma’s variants and modifiers. Each layer is clearly labeled and easily swappable.

🚥 Field States

Default – No validation errors or warnings. This is the typical state unless something is wrong.
Error – Indicates invalid input, missing data, or system validation issues. Often paired with an error message or icon.

The error state updates border color, focus ring, and icon appearance, and is designed to be WCAG-compliant.

♿ Accessibility Considerations

From a design perspective:

• Use consistent color contrast for all field statuses (especially error and disabled)

• Keep focus states visible and strong—keyboard users depend on them

• Don’t rely on color alone—combine visual cues (e.g. error icon + red border + error message)

From a code perspective (if implemented):

• Ensure the aria-invalid attribute is set when a field is in an error state

• Link error messages to the input using aria-describedby

• Preserve disabled fields in the accessibility tree only when necessary (e.g., readonly mode)

✅ Best Practices

• Always use a Field wrapper around interactive inputs—it ensures proper feedback and spacing

• Use spacing tokens to keep Fields consistent in vertical and horizontal layouts

• If you’re using icons or additional elements, keep their purpose clear (e.g., input hints, triggers, or indicators)

• Pair Field with Label and Helper Text for full accessibility and clarity