VINASIGcomponents

02 Reusable interface

Components

Common controls with understandable behavior, accessible states, and reusable examples. These specifications are draft proposals.

Component guidance is still being shaped

Use these examples to review the format. A future component page should document purpose, variants, states, keyboard behavior, responsive behavior, and accessibility. Browse the full catalog of 81 interface entries.

Actions

Buttons

Use a button to perform an action. Use a link to navigate to another page.

Link action
  • PurposePerform an action in the current context.
  • LabelUse a concise verb that describes the outcome.
  • KeyboardPreserve native button and link keyboard behavior. Keep the focus outline visible.

Data entry

Text input

Keep the label visible and close to its control. Helper text should explain format or next steps.

Use a short, recognizable name.
  • LabelAssociate a persistent, visible label with each field.
  • Helper textConnect hints or errors with the field using aria-describedby.
  • ErrorExplain what needs correction and preserve the user's existing entry.

Selection

A custom dropdown needs a considered trigger and an equally considered open options panel.

Open the menu to inspect its options. Use arrow keys to move, Enter to select and Escape to keep the current value.

  • Both statesStyle the closed trigger and the open options panel with the same tokens and font. Operating-system popups do not meet the VINASIG control requirement.
  • KeyboardSupport opening, arrow-key navigation, Enter or Space to select, Escape to close, visible focus, and normal focus exit.
  • AccessibilityUse a visible label and an established accessible select or listbox pattern. Announce the current value and selected option.
  • ResponsiveKeep the popup attached to its trigger and inside the viewport on narrow screens.

The reusable control retains a hidden native select for form state. Read the component specification and test the consumer's real interactions before adoption.

Feedback

Status messages

Use a text label with the status color so meaning remains clear without color perception.

Changes saved

Your draft is up to date.

Could not save

Check your connection and try again.

Visual symbols

Use a shared icon set

Use pictographic icons only when they clarify a control or add useful recognition.

Information Success Open link
  • Icon setUse Lucide SVG icons through the shared Icon.astro component.
  • Brand logosUse Simple Icons for third-party company and product logos such as Google and Apple. Their default color follows the surrounding text. Choose an explicit brand color only when the context and official guidance call for it.
  • Sign-in marksFollow each provider's current sign-in guidance. Google sign-in buttons use the standard multicolor G, not a monochrome logo.
  • Icon styleUse Lucide for interface arrows and pictographic icons shown alongside each other so their visual style stays consistent.
  • Wrapped linksKeep action labels and their icons in the same text flow. At high zoom or narrow widths, the icon stays beside the final word rather than floating to the far edge.
  • CharactersSpace Grotesk symbols may be used as text or typographic notation. Do not substitute them for interface icons when they look different from the shared icon set.
  • Custom glyphsDo not type emoji, pictographic Unicode symbols, or private-use codepoints into page markup or CSS.
  • MeaningKeep visible text when an icon alone would make a label or action unclear.
  • AccessibilityDecorative icons stay hidden from assistive technology. Give icon-only controls an accessible name.
<Icon name="info" />

Icons render as inline vector graphics and inherit the interface color.

Content grouping

Cards

Cards group related content. Keep interactive targets explicit and avoid nested clickable regions.

Foundation color

Use semantic tokens

Semantic tokens connect a component to its role and make system-wide changes easier to apply.

Read color foundations