Interactions

Every interactive element should communicate clearly whether it can be used, what will happen if it is used, and whether the system has responded. Getting this right reduces hesitation and builds trust in the interface.

Input methods

Design and test with all four input methods in mind.

• Mouse: Hover states must appear immediately. Hit areas should be comfortably large. Use cursor: pointer to signal interactivity.
• Keyboard: Every element must be reachable by Tab and operable with Enter or Space. Focus order should follow reading order. Never suppress the focus ring.
• Touch: Targets must be at least 40x40px. Hover states do not exist; never gate actions or labels behind hover.
• Voice: Every control needs a meaningful visible label. Icon-only buttons must have an aria-label matching what a user would say to activate it.

Communicating affordance

Before a user commits to an action, they need enough information to feel confident doing so. Labels, icons, and placement do most of this work. Interaction states reinforce it.

An element at rest should look clickable if it is clickable. Rely on shape, labeling, and context (not just color) to establish this. Hover and focus states then confirm the expectation once the user moves toward the element.

Unavailable actions should remain visible but clearly inactive. A disabled state that is invisible or easy to overlook leaves users stuck without knowing why. Where possible, accompany a disabled element with an explanation nearby: a tooltip, helper text, or contextual message.

Responding to input

Once a user acts, the interface should respond immediately. Even if the operation takes time, the system should acknowledge the input right away.

• For operations that take time, show a Loader or Progress Bar so the user knows work is in progress.
• For completed actions that do not require a new page or view, use a Snackbar to confirm the outcome without interrupting the flow.
• For failures, explain what went wrong and what the user can do to resolve it. Surface errors close to where the problem occurred rather than in a generic top-level message.

Critical actions

Actions that are destructive or irreversible must be marked clearly so users can make an informed decision before confirming.

Use the critical variant on components and the corresponding critical color tokens for any action that deletes, removes, or permanently changes data. This applies to the trigger element as well as any confirmation dialog that follows.

• Use --color-interaction-critical-default and its state variants for interactive controls.
• Use --color-text-critical-* and --color-icon-critical-* tokens for supporting text, icons, and inline warnings.
• Always pair a critical action with a confirmation step. Never trigger a destructive operation on a single click.

Focus ring

The focus ring is the primary visual signal for keyboard navigation. It must always be visible.

Meteor's standard focus ring:

outline: 2px solid var(--color-border-brand-default);
outline-offset: 2px;

The 2px outline is heavy enough to read against both light and dark surfaces. The 2px offset keeps it visually separate from the element's own border.

Adjusting the offset

The offset is the only thing that should change between contexts. The thickness and color stay the same.

If the default 2px offset looks broken or visually wrong in a specific component, adjust it. Higher values give the ring more breathing room; lower values pull it in. Zero offset is acceptable when the element is inside an overflow: hidden container and there is no other way to show the ring.

Tokens

For interaction-specific color tokens, see the Tokens page.