interaction-states

Design and verify interactive component states across input methods and themes.

1|Updated Sep 11, 2026
One-click install
npx skills add https://github.com/rebuildup/my-web-2026 --skill interaction-states-rebuildup
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: interaction-states
Source: https://github.com/rebuildup/my-web-2026/tree/main/skills/interaction-states
Command: npx skills add https://github.com/rebuildup/my-web-2026 --skill interaction-states-rebuildup

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Interactive components often end up with inconsistent or confusing state behavior: focus confused with selection, active-down reused as a toggle indicator, disabled and read-only treated identically, or status conveyed by color alone. This Skill provides a structured workflow to define, implement, and verify component states so hover, focus, pressed, selected, disabled, loading, and validation states remain coherent across pointer, keyboard, and touch. ## Core Features & Use Cases - State taxonomy and semantics: Distinguishes transient input feedback (hover, active/down), persistent choice (selected, checked, pressed, expanded, current), availability (disabled, read-only), and status (error, warning, success) with clear definitions for each. - Combination and priority rules: Provides a state matrix approach and a meaning-based priority order (operability, focus, persistent value, status, transient feedback) so overlapping states like selected + focus or error + focus remain distinguishable. - Verification checklist: Defines a completion gate covering pointer/keyboard/touch operation, light/dark/high-contrast themes, zoom, and real rendered UI inspection rather than build success alone. - Use Case: When building a toggle button group, use this Skill to separate the momentary pressed-down appearance from the persistent on/off state, then verify keyboard users can distinguish focus from selection. ## Quick Start Use the interaction-states skill to review my component's hover, focus, selected, disabled, and error states and verify them across keyboard and touch input.

Frequently Asked Questions about interaction-states

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design focus and selected states for a component?

Treat focus and selection as separate states: focus is the current keyboard navigation position and moves, while selection persists after focus leaves. Ensure both are visually distinguishable when a selected item loses focus to another item.

What is the difference between disabled and read-only states?

Disabled means the control is currently inoperable, while read-only means the value cannot be edited but remains relevant for viewing, selecting, or copying. Do not style read-only content like disabled content or remove it from navigation.

Should disabled items be focusable in toolbars and menus?

It depends on the component pattern. Native disabled controls leave the tab sequence, but in toolbars, menus, and listboxes a focusable disabled state can keep unavailable items discoverable. Follow the component pattern rather than a fixed rule.

How do I verify interaction states across input methods?

Operate the real rendered UI with mouse, keyboard only, and touch. Confirm default to hover to press sequences, keyboard focus paths, persistent toggle states, and that essential behavior never depends on hover alone.

Why should error and success states not rely on color alone?

Color-only cues fail for users who cannot distinguish colors and in high-contrast modes. Add redundant cues such as icons, text, or structure so error, warning, and success status remain perceivable in all visual environments.