Accessibility

What every component guarantees

• Semantic elements first — buttons are buttons, tabs use the tab pattern, dialogs are labelled modal dialogs.
• Everything interactive is keyboard operable, with a visible focus ring.
• Purely decorative layers (glows, particles, duplicated marquee content) are hidden from assistive technology.
• Animated text exposes its final text once, not character by character.
• Reduced-motion preferences produce a designed static state.
• Pointer-only effects have touch and keyboard equivalents, or degrade to a static component.

Per-component notes

Each component page has an Accessibility section describing exactly what that implementation does, and a Limitations section where an experimental component has known gaps (for example, canvas-based visuals that are decorative by design).

Your part

• Give icon-only controls an accessible name (the components accept aria-label).
• Keep sufficient contrast if you change accent colours — accents on text should meet WCAG AA (4.5:1).
• Do not remove the reduced-motion branches when editing a component.

How Wancraft is tested

The metadata schema, code generation and filtering logic are covered by Vitest unit tests, every generated usage example is type-checked, and Playwright end-to-end tests exercise keyboard navigation, the search dialog, tabs, the playground and horizontal overflow at widths from 320px to 1024px in a real browser. Component behaviour (keyboard paths, ARIA state, live regions) was checked in jsdom and in the browser during development. Dedicated screen-reader audits with NVDA, JAWS and VoiceOver have not been completed yet — if you find an issue, please report it.