Skip to content
ui

Design and build an accessible, reusable UI component

Gets an AI to design a UI component's full set of states and variants up front, then implement it accessibly, instead of building only the happy-path visual state.

Who should use this

Is this prompt for you?

  • Developers building a new component for a shared component library
  • Anyone who has shipped a component missing a loading/error/empty state
  • Teams that care about keyboard and screen-reader accessibility, not just visual polish
The prompt

Copy this prompt

Prompt
Design and implement a reusable [component name, e.g. "multi-select dropdown", "data table", "toast notification"] component.

Tech context: [React/Vue/etc.], TypeScript, styling with [Tailwind/CSS modules/styled-components], any existing design tokens: [describe, e.g. "colors defined as CSS variables --brand-600 etc." or "none yet"].

Functional requirements: [describe what it needs to do, e.g. "select multiple options from a searchable list, show selected items as removable chips, support a max selection count"]

Before implementing, list all the states and variants this component needs, including ones I didn't mention if they're implied — for example: default, hover, focus, disabled, loading, empty/no-results, error, and any size or visual variants.

Then implement it with:
1. A clear, typed props interface with sensible defaults
2. Full keyboard support (tab order, arrow keys where relevant, Escape to close/cancel, Enter/Space to activate)
3. Correct ARIA roles and attributes for its interaction pattern (look up the correct pattern rather than guessing — e.g. combobox, listbox, dialog)
4. Visible focus states that meet contrast requirements, not just default browser outline removed with nothing replacing it
5. Responsive behavior at small viewport widths
6. A composable API (children/slots or render props) if the component is likely to need content customization later

Finally, give me 2-3 usage examples showing different variants, and a short list of what I should manually test with a keyboard and a screen reader before shipping this.

Works well with Cursor, Claude Code and Gemini.

How to use it

Getting the best result

  1. 1Name a specific, real component rather than something generic — specificity produces a much more complete state list
  2. 2Review the proposed states/variants list before implementation and add anything missing from your product's actual needs
  3. 3Actually test the keyboard interaction yourself (tab through it, try Escape/Enter/arrows) — don't just trust the description
  4. 4If you have an existing design system, paste its token names so the component matches instead of introducing new ad hoc values
Expected result

What you should get back

  • A complete list of the component's states and variants before any code is written
  • A typed, accessible component implementation with correct ARIA roles and keyboard support
  • Visible, sufficiently contrasted focus states
  • Usage examples and a manual accessibility testing checklist
Tips

Get more out of this prompt

  • Ask for the ARIA pattern by name (e.g. "the combobox pattern") so the AI implements a known-correct interaction model instead of improvising
  • Always test focus states and tab order yourself — this is the area AI-generated UI most often gets subtly wrong
  • For components used in forms, explicitly ask how it integrates with your form library's validation and error display
Common mistakes

What to watch out for

  • Only asking for the default visual state and discovering missing loading/empty/error states in production
  • Accepting removed focus outlines without a replacement, breaking keyboard accessibility
  • Not specifying existing design tokens, resulting in a component with colors/spacing that don't match the rest of the app

Ready to put this prompt to work?

Pair it with an AI coding tool and a real project, then ship something this week.