form-labelling

Name: form-labelling
Author: Owl-Listener

82stars25forks

How to install form-labelling?

owl-listener/inclusive-design-skills/form-labelling

$npx -y skills add Owl-Listener/inclusive-design-skills --skill form-labelling

Installs into the current project.

Summary

Design form labels, instructions, and grouping that work for screen readers and cognitive accessibility. Use when designing or reviewing forms, input fields, checkboxes, radio buttons, select menus, or any data entry interface. Triggers on: form label, label, input label, fieldse

Files · 1

View on GitHub

SKILL.md

1	# Form Labelling
2
3	Every form field needs a visible, persistent label that is
4	programmatically associated with the input. This is the single most
5	common accessibility failure on the web — and the easiest to fix.
6
7	## Core Rules
8
9	### Every Input Has a Visible Label
10	- Use <label> element with for/id association
11	- The label must be visible at all times — not just as placeholder
12	text that disappears on focus
13	- Labels go above the input (most accessible and most scannable)
14	- Never use placeholder text as the only label — it disappears
15	when the user starts typing
16
17	### Labels Describe What to Enter
18	- Good: "Email address"
19	- Bad: "Enter your info here"
20	- Good: "Date of birth (DD/MM/YYYY)"
21	- Bad: "Date"
22	- Include format hints in the label or help text, not just in
23	placeholder
24
25	### Required Fields Are Clear
26	- Mark required fields with visible text: "required" or *
27	- If using , explain it at the top of the form: " = required"
28	- Use aria-required="true" for programmatic indication
29	- Better: make most fields required by design and mark the
30	optional ones instead — "Company name (optional)"
31
32	## Grouping Patterns
33
34	### Related Fields Need Fieldsets
35	- Group related fields with <fieldset> and <legend>
36	- Radio buttons: always group with fieldset
37	- Legend: "Preferred contact method"
38	- Options: Email, Phone, Text
39	- Checkboxes: group when they share a question
40	- Legend: "Which topics interest you?"
41	- Options: Design, Engineering, Product
42	- Address fields: group under "Delivery address" or "Billing address"
43
44	### When You Have Multiple Forms
45	- Each form section should have a heading or legend
46	- Sections should be visually and structurally separated
47	- Progress indicators help users understand where they are
48
49	## Instruction Patterns
50
51	### Help Text
52	- Place help text between the label and the input
53	- Associate with aria-describedby so screen readers announce it
54	- Good: "Must be at least 8 characters with one number"
55	- Keep instructions concise — one sentence
56
57	### Error Association
58	- Error messages must be programmatically linked to the field
59	(aria-describedby or aria-errormessage)
60	- Place error text directly below the field, not in a remote banner
61	- Include the field label in the error: "Email address: please
62	enter a valid email"
63
64	## Common Mistakes
65
66	- Placeholder as label — disappears on input, invisible to many
67	screen readers
68	- Icon-only labels — a magnifying glass without text "Search" label
69	- Labels far from inputs — spatial separation breaks the visual
70	association
71	- Labels that change — don't change label text based on input state
72	- Unlabelled buttons — every button needs visible text or aria-label
73
74	## Assessment Checklist
75
76	- [ ] Every input has a visible <label> associated with for/id
77	- [ ] No placeholder-only labels
78	- [ ] Required fields are indicated visually and programmatically
79	- [ ] Related fields are grouped with fieldset/legend
80	- [ ] Help text is associated with aria-describedby
81	- [ ] Error messages are linked to their field
82	- [ ] All buttons have visible text labels

People who liked this also viewed

6 picks

Type

form-labelling

82stars25forks

View on GitHub

How to install form-labelling?

owl-listener/inclusive-design-skills/form-labelling

$npx -y skills add Owl-Listener/inclusive-design-skills --skill form-labelling

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Form Labelling
2
3	Every form field needs a visible, persistent label that is
4	programmatically associated with the input. This is the single most
5	common accessibility failure on the web — and the easiest to fix.
6
7	## Core Rules
8
9	### Every Input Has a Visible Label
10	- Use <label> element with for/id association
11	- The label must be visible at all times — not just as placeholder
12	text that disappears on focus
13	- Labels go above the input (most accessible and most scannable)
14	- Never use placeholder text as the only label — it disappears
15	when the user starts typing
16
17	### Labels Describe What to Enter
18	- Good: "Email address"
19	- Bad: "Enter your info here"
20	- Good: "Date of birth (DD/MM/YYYY)"
21	- Bad: "Date"
22	- Include format hints in the label or help text, not just in
23	placeholder
24
25	### Required Fields Are Clear
26	- Mark required fields with visible text: "required" or *
27	- If using , explain it at the top of the form: " = required"
28	- Use aria-required="true" for programmatic indication
29	- Better: make most fields required by design and mark the
30	optional ones instead — "Company name (optional)"
31
32	## Grouping Patterns
33
34	### Related Fields Need Fieldsets
35	- Group related fields with <fieldset> and <legend>
36	- Radio buttons: always group with fieldset
37	- Legend: "Preferred contact method"
38	- Options: Email, Phone, Text
39	- Checkboxes: group when they share a question
40	- Legend: "Which topics interest you?"
41	- Options: Design, Engineering, Product
42	- Address fields: group under "Delivery address" or "Billing address"
43
44	### When You Have Multiple Forms
45	- Each form section should have a heading or legend
46	- Sections should be visually and structurally separated
47	- Progress indicators help users understand where they are
48
49	## Instruction Patterns
50
51	### Help Text
52	- Place help text between the label and the input
53	- Associate with aria-describedby so screen readers announce it
54	- Good: "Must be at least 8 characters with one number"
55	- Keep instructions concise — one sentence
56
57	### Error Association
58	- Error messages must be programmatically linked to the field
59	(aria-describedby or aria-errormessage)
60	- Place error text directly below the field, not in a remote banner
61	- Include the field label in the error: "Email address: please
62	enter a valid email"
63
64	## Common Mistakes
65
66	- Placeholder as label — disappears on input, invisible to many
67	screen readers
68	- Icon-only labels — a magnifying glass without text "Search" label
69	- Labels far from inputs — spatial separation breaks the visual
70	association
71	- Labels that change — don't change label text based on input state
72	- Unlabelled buttons — every button needs visible text or aria-label
73
74	## Assessment Checklist
75
76	- [ ] Every input has a visible <label> associated with for/id
77	- [ ] No placeholder-only labels
78	- [ ] Required fields are indicated visually and programmatically
79	- [ ] Related fields are grouped with fieldset/legend
80	- [ ] Help text is associated with aria-describedby
81	- [ ] Error messages are linked to their field
82	- [ ] All buttons have visible text labels

People who liked this also viewed

6 picks

Type