Button

🧭 When to Use a Button

Use a button when you want the user to take action. Buttons should be reserved for:

• Primary actions like “Submit,” “Save,” or “Next”

• Secondary actions such as “Cancel,” “Go Back,” or “View More”

• Destructive actions like “Delete,” “Remove,” or “Sign Out”

Avoid using buttons when a simple link is more appropriate—for example, when the action takes the user to another page without submitting data or triggering a function.

🎨 Button Variants

💡 Types (Visual Style)

TypeDescriptionDefaultSolid background, used for primary actionsSubtleLow-contrast background, secondary or low-emphasis actionsOutlineTransparent background with border; used when you want a neutral lookTransparentNo border or fill; best for icon-only actions or utility buttons

📏 Sizes

• Small (S) – Use for compact UI, toolbars, or mobile layouts

• Medium (M) – Default size, good for general use

• Large (L) – For high-emphasis areas like modals or feature banners

Each size adjusts padding and font size for consistency across breakpoints.

🌈 States (Purposeful Intent)

Use different color tokens to signal intent:

StateUse CaseDefaultNeutral/standard actionsSuccessFor confirmed, positive actions (e.g. "Approve", "Confirm")SecondaryVisual secondary hierarchy (not color-based like 'subtle')InformationFor actions that lead to informative processes (e.g. “Learn More”)ErrorFor destructive or negative actions (e.g. “Delete”)WarningCautionary actions (e.g. “Proceed Anyway”)

These states are token-driven, so you can rebrand or change themes without breaking consistency.

🎯 Interaction States

All buttons support these interactive states by default:

StateDescriptionDefaultThe resting state of the buttonHoverVisual feedback on mouse hover (e.g. slight shade or border highlight)FocusKeyboard navigation focus ring (WCAG-compliant for accessibility)DisabledMuted color and interaction blocked. Used to indicate unavailability.

⚠️ Important: Disabled buttons should still be visually perceivable. Use contrast-compliant colors even in disabled states.

♿ Accessibility Considerations

🔍 From a Design Perspective:

• Use sufficient color contrast between the text and background (minimum 4.5:1 for normal text).

• Never rely on color alone to communicate intent. Pair color with icons or text (e.g. ✅ Confirm, ⚠️ Warning).

• Ensure focus rings are visible and meet WCAG contrast guidelines.

• Use clear labeling inside buttons—avoid vague terms like "Click Here".

🧑‍💻 From a Code Perspective (if implemented):

• Use semantic button HTML elements (not div or span).

• Add aria-label if the button contains only an icon (e.g. hamburger menu).

• Ensure focusable states with keyboard (Tab, Enter, Space) work as expected.

• Avoid using disabled if you want screen readers to announce the button. Use aria-disabled="true" if visibility is needed but interaction is blocked.

🧰 Best Practices

• Don’t stack too many buttons together—use a primary + secondary structure.

• Use consistent sizing within a view to avoid UI noise.

• Always include a hover and focus state, even for subtle/transparent variants.