building-forms

Name: building-forms
Author: ancoleman

64installs59forks

How to install building-forms?

ancoleman/ai-design-components/building-forms

$npx -y skills add ancoleman/ai-design-components --skill building-forms

Installs into the current project.

Summary

Builds form components and data collection interfaces including contact forms, registration flows, checkout processes, surveys, and settings pages. Includes 50+ input types, validation strategies, accessibility patterns (WCAG 2.1), multi-step wizards, and UX best practices. Provi

Files · 1

View on GitHub

SKILL.md

1	# Form Systems & Input Patterns
2
3	Build accessible, user-friendly forms with systematic component selection, validation strategies, and UX best practices.
4
5	## Purpose
6
7	Forms are the primary mechanism for user data input in web applications. This skill provides systematic guidance for:
8	- Selecting appropriate input types based on data requirements
9	- Implementing validation strategies that enhance user experience
10	- Ensuring WCAG 2.1 AA accessibility compliance
11	- Creating complex patterns (multi-step wizards, conditional fields, dynamic forms)
12
13	## When to Use This Skill
14
15	Triggers:
16	- Building contact forms, login/registration flows, checkout processes
17	- Implementing surveys, questionnaires, or settings pages
18	- Adding validation to user inputs
19	- Creating multi-step workflows or wizards
20	- Ensuring form accessibility
21	- Collecting structured data (addresses, credit cards, dates)
22
23	Common Requests:
24	- "Create a registration form with validation"
25	- "Build a multi-step checkout flow"
26	- "Add inline validation to email input"
27	- "Make this form accessible for screen readers"
28	- "Implement a survey with conditional questions"
29
30	## Universal Form Concepts
31
32	### Component Selection Framework
33
34	The Golden Rule: Data Type → Input Component → Validation Pattern
35
36	Start by identifying the data type to collect, then select the appropriate component:
37
38	Quick Reference:
39	- Short text (<100 chars) → Text input, Email input, Password input
40	- Long text (>100 chars) → Textarea, Rich text editor, Code editor
41	- Numeric → Number input, Currency input, Slider
42	- Date/Time → Date picker, Time picker, Date range picker
43	- Boolean → Checkbox, Toggle switch
44	- Single choice → Radio group (2-7 options), Select dropdown (>7 options), Autocomplete (>15 options)
45	- Multiple choice → Checkbox group, Multi-select, Tag input
46	- File/Media → File upload, Image upload
47	- Structured → Address input, Credit card input, Phone number input
48
49	For detailed decision tree: See `references/decision-tree.md`
50
51	### Validation Timing Strategies
52
53	Recommended Default: On Blur with Progressive Enhancement
54
55	```
56	Field pristine (never touched): No validation
57	User typing: No errors shown
58	On blur (field loses focus): Validate and show errors
59	After first error: Switch to onChange for that field
60	On fix: Show success immediately
61	```
62
63	Validation Modes:
64	1. On Submit - Validate when form submitted (simple forms)
65	2. On Blur - Validate when field loses focus (RECOMMENDED for most forms)
66	3. On Change - Validate as user types (password strength, availability checks)
67	4. Debounced - Validate after user stops typing (API-based validation)
68	5. Progressive - Start with on-blur, switch to on-change after first error
69
70	For complete validation guide: See `references/validation-concepts.md`
71
72	### Accessibility Requirements (WCAG 2.1 AA)
73
74	Critical Accessibility Patterns:
75
76	Labels and Instructions:
77	- Every input must have an associated `<label>` or `aria-label`
78	- Labels must be visible and descriptive
79	- Required fields clearly indicated (not by color alone)
80	- Never use placeholder text as label replacement
81	- Provide help text for complex inputs
82
83	Keyboard Navigation:
84	- Logical, sequential tab order
85	- All inputs keyboard accessible
86	- Custom components support arrow keys
87	- Escape key dismisses modals/popovers
88	- Focus visible (outline or custom indicator)
89
90	Error Handling:
91	- Errors programmatically associated with inputs (`aria-describedby`)
92	- Error messages clear and actionable
93	- Errors announced by screen readers (`aria-live`)
94	- Focus moves to first error on submit
95	- Errors not conveyed by color alone
96
97	ARIA Attributes:
98	- `aria-required="true"` for required fields
99	- `aria-invalid="true"` when validation fails
100	- `aria-describedby` linking to help/error text
101	- `role="group"` for related inputs
102	- `aria-live="polite"` for validation messages
103
104	For complete accessibility checklist: See `references/accessibility-forms.md`
105
106	### UX Best Practices
107
108	Modern Form UX Principles (2024-2025):
109
110	1. Progressive Disclosure - Show only essential fields initially, reveal advanced options on demand
111	2. Smart Defaults - Pre-fill known information, suggest values based on context
112	3. Inline Validation with Positive Feedback - Show green checkmark on valid input, provide helpful error messages
113	4. Mobile-First - Large touch targets (4

People who liked this also viewed

6 picks

Type

building-forms

64installs59forks

View on GitHub

How to install building-forms?

ancoleman/ai-design-components/building-forms

$npx -y skills add ancoleman/ai-design-components --skill building-forms

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Form Systems & Input Patterns
2
3	Build accessible, user-friendly forms with systematic component selection, validation strategies, and UX best practices.
4
5	## Purpose
6
7	Forms are the primary mechanism for user data input in web applications. This skill provides systematic guidance for:
8	- Selecting appropriate input types based on data requirements
9	- Implementing validation strategies that enhance user experience
10	- Ensuring WCAG 2.1 AA accessibility compliance
11	- Creating complex patterns (multi-step wizards, conditional fields, dynamic forms)
12
13	## When to Use This Skill
14
15	Triggers:
16	- Building contact forms, login/registration flows, checkout processes
17	- Implementing surveys, questionnaires, or settings pages
18	- Adding validation to user inputs
19	- Creating multi-step workflows or wizards
20	- Ensuring form accessibility
21	- Collecting structured data (addresses, credit cards, dates)
22
23	Common Requests:
24	- "Create a registration form with validation"
25	- "Build a multi-step checkout flow"
26	- "Add inline validation to email input"
27	- "Make this form accessible for screen readers"
28	- "Implement a survey with conditional questions"
29
30	## Universal Form Concepts
31
32	### Component Selection Framework
33
34	The Golden Rule: Data Type → Input Component → Validation Pattern
35
36	Start by identifying the data type to collect, then select the appropriate component:
37
38	Quick Reference:
39	- Short text (<100 chars) → Text input, Email input, Password input
40	- Long text (>100 chars) → Textarea, Rich text editor, Code editor
41	- Numeric → Number input, Currency input, Slider
42	- Date/Time → Date picker, Time picker, Date range picker
43	- Boolean → Checkbox, Toggle switch
44	- Single choice → Radio group (2-7 options), Select dropdown (>7 options), Autocomplete (>15 options)
45	- Multiple choice → Checkbox group, Multi-select, Tag input
46	- File/Media → File upload, Image upload
47	- Structured → Address input, Credit card input, Phone number input
48
49	For detailed decision tree: See `references/decision-tree.md`
50
51	### Validation Timing Strategies
52
53	Recommended Default: On Blur with Progressive Enhancement
54
55	```
56	Field pristine (never touched): No validation
57	User typing: No errors shown
58	On blur (field loses focus): Validate and show errors
59	After first error: Switch to onChange for that field
60	On fix: Show success immediately
61	```
62
63	Validation Modes:
64	1. On Submit - Validate when form submitted (simple forms)
65	2. On Blur - Validate when field loses focus (RECOMMENDED for most forms)
66	3. On Change - Validate as user types (password strength, availability checks)
67	4. Debounced - Validate after user stops typing (API-based validation)
68	5. Progressive - Start with on-blur, switch to on-change after first error
69
70	For complete validation guide: See `references/validation-concepts.md`
71
72	### Accessibility Requirements (WCAG 2.1 AA)
73
74	Critical Accessibility Patterns:
75
76	Labels and Instructions:
77	- Every input must have an associated `<label>` or `aria-label`
78	- Labels must be visible and descriptive
79	- Required fields clearly indicated (not by color alone)
80	- Never use placeholder text as label replacement
81	- Provide help text for complex inputs
82
83	Keyboard Navigation:
84	- Logical, sequential tab order
85	- All inputs keyboard accessible
86	- Custom components support arrow keys
87	- Escape key dismisses modals/popovers
88	- Focus visible (outline or custom indicator)
89
90	Error Handling:
91	- Errors programmatically associated with inputs (`aria-describedby`)
92	- Error messages clear and actionable
93	- Errors announced by screen readers (`aria-live`)
94	- Focus moves to first error on submit
95	- Errors not conveyed by color alone
96
97	ARIA Attributes:
98	- `aria-required="true"` for required fields
99	- `aria-invalid="true"` when validation fails
100	- `aria-describedby` linking to help/error text
101	- `role="group"` for related inputs
102	- `aria-live="polite"` for validation messages
103
104	For complete accessibility checklist: See `references/accessibility-forms.md`
105
106	### UX Best Practices
107
108	Modern Form UX Principles (2024-2025):
109
110	1. Progressive Disclosure - Show only essential fields initially, reveal advanced options on demand
111	2. Smart Defaults - Pre-fill known information, suggest values based on context
112	3. Inline Validation with Positive Feedback - Show green checkmark on valid input, provide helpful error messages
113	4. Mobile-First - Large touch targets (4

People who liked this also viewed

6 picks

Type