Component Docs Workflow

Use this when the user asks for a component documentation standard or docs for specific components.

Required Standard

Every component page must include:

• Purpose and when not to use, with named alternatives.
• Anatomy: named parts, roles, and conditional vs. always-present parts.
• Variants and states: default, hover, focus, active, disabled, loading, error, empty, and read-only where applicable.
• Content rules: labels, placeholder text, helper text, error messages, formatting constraints, and character limits when relevant.
• Accessibility behavior: keyboard interaction, focus management, screen-reader announcements, contrast, reduced motion, and known gaps.
• Code API: props/attributes, slots or children patterns, events, controlled vs. uncontrolled behavior, complex types, and deprecated prop migration.
• Testing requirements: unit, interaction, accessibility automation, manual assistive-technology testing, and visual regression.
• Lifecycle status: experimental, stable, deprecated, plus migration notes.

Accessibility Rules

Use native HTML semantics first. ARIA supplements native behavior only where native semantics are insufficient. Automated tools such as axe or Lighthouse do not prove full accessibility; include manual keyboard and assistive-technology checks.

Application

When documenting examples such as DatePicker or DataTable, apply the full standard to each component rather than only listing props. Complex components must include anatomy, all visible states, keyboard paths, screen-reader behavior, code API, tests, and lifecycle status.