ux-component-states_skill

This skill helps you implement interactive component states with accessible hover, focus, loading, and error feedback for buttons, inputs, and cards.

JavaScript

1

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill matthewharwood/fantasy-phonics --skill ux-component-states

SKILL.md9.8 KB

Overview

This skill documents interactive component state patterns for web components and vanilla JavaScript UI: hover, focus, active/pressed, disabled, loading, error, success, locked, and undefined (not :defined). It focuses on clear visual feedback, accessibility (ARIA), and avoiding layout shifts for a polished user experience. Practical examples cover buttons, inputs, cards, progress indicators, and toggleable items. Patterns are framework-agnostic and suit small games or playful, fantasy-themed apps.

How this skill works

The skill defines CSS state selectors and attribute patterns (data-* and ARIA) to express semantic state without mixing presentation and logic. It shows how to toggle attributes in component JavaScript, keep direct element references, and update ARIA attributes to expose state to assistive tech. It also includes transition rules, reduced-motion support, and FOUC prevention for custom elements using :not(:defined) and reserved layout space. Examples include loading spinners via aria-busy, focus-visible rings, and pressed/selected toggles.

When to use it

Building interactive controls: buttons, inputs, toggles, and cards
Creating accessible custom elements or web components
Avoiding cumulative layout shift when hydrating JS components
Showing loading, error, success, locked, or selected states to users
Implementing keyboard and pointer feedback consistently across UI

Best practices

Use ARIA and data attributes for semantic, machine-readable states (aria-busy, aria-invalid, data-status)
Store element references in component constructors and avoid querying the DOM repeatedly
Prefer :focus-visible for keyboard focus and add visible focus rings for accessibility
Use opacity instead of display:none for undefined custom elements to prevent CLS
Respect prefers-reduced-motion and disable non-essential transitions for those users
Animate only transforms, opacity, and color for smoother, performant transitions

Example use cases

Button with hover, focus-visible, active, disabled, and aria-busy loading spinner
Input fields that show validation error via aria-invalid and an error message with accessible focus styles
Card list where selected, locked, and completed states use data attributes for styling and icons
Navigation items that use [aria-current] to indicate the current page and update on route changes
Web components that hide until defined (:not(:defined)) and reserve space to avoid layout shift

FAQ

aria-busy marks the element as processing while a visual spinner (via ::after) preserves layout and prevents shifting. Screen readers can announce busy status while you keep structure stable.

When should I use data- attributes vs ARIA?

Use ARIA for semantic state that affects accessibility (pressed, busy, invalid). Use data- attributes for internal styling states or complex status values that don’t need to be exposed to assistive tech.