mcpField
F
form-labelling

form-labelling

github.com/owl-listenerDesign & UI10876 installsUpdated 20w ago
Repository

About form-labelling

A form accessibility design skill for interface designers and developers. It covers persistent labels, instructions, errors, and grouping patterns, with a checklist for assessing forms.

Key features

  1. 01Visible, associated field labels
  2. 02Clear required and optional fields
  3. 03Group controls with fieldset and legend
  4. 04Associate help text and errors
  5. 05Form accessibility checklist

Use cases

  1. 01Find placeholder-only field labels
  2. 02Design forms with radio or checkbox groups
  3. 03Improve accessibility of instructions and errors

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/owl-listener/inclusive-design-skills --skill form-labelling

After installing, type/form-labellingin Claude Code to confirm it loaded.

Details

From the project README

Form Labelling

Every form field needs a visible, persistent label that is programmatically associated with the input. This is the single most common accessibility failure on the web — and the easiest to fix.

Core Rules

Every Input Has a Visible Label
  • Use element with for/id association
  • The label must be visible at all times — not just as placeholder text that disappears on focus
  • Labels go above the input (most accessible and most scannable)
  • Never use placeholder text as the only label — it disappears when the user starts typing
Labels Describe What to Enter
  • Good: "Email address"
  • Bad: "Enter your info here"
  • Good: "Date of birth (DD/MM/YYYY)"
  • Bad: "Date"
  • Include format hints in the label or help text, not just in placeholder
Required Fields Are Clear
  • Mark required fields with visible text: "required" or *
  • If using , explain it at the top of the form: " = required"
  • Use aria-required="true" for programmatic indication
  • Better: make most fields required by design and mark the optional ones instead — "Company name (optional)"

Grouping Patterns

Related Fields Need Fieldsets
  • Group related fields with and
  • Radio buttons: always group with fieldset
    • Legend: "Preferred contact method"
    • Options: Email, Phone, Text
  • Checkboxes: group when they share a question
    • Legend: "Which topics interest you?"
    • Options: Design, Engineering, Product
  • Address fields: group under "Delivery address" or "Billing address"
When You Have Multiple Forms
  • Each form section should have a heading or legend
  • Sections should be visually and structurally separated
  • Progress indicators help users understand where they are

Instruction Patterns

Help Text
  • Place help text between the label and the input
  • Associate with aria-describedby so screen readers announce it
  • Good: "Must be at least 8 characters with one number"
  • Keep instructions concise — one sentence
Error Association
  • Error messages must be programmatically linked to the field (aria-describedby or aria-errormessage)
  • Place error text directly below the field, not in a remote banner
  • Include the field label in the error: "Email address: please enter a valid email"

Common Mistakes

  • Placeholder as label — disappears on input, invisible to many screen readers
  • Icon-only labels — a magnifying glass without text "Search" label
  • Labels far from inputs — spatial separation breaks the visual association
  • Labels that change — don't change label text based on input state
  • Unlabelled buttons — every button needs visible text or aria-label

Assessment Checklist

  • Every input has a visible associated with for/id
  • No placeholder-only labels
  • Required fields are indicated visually and programmatically
  • Related fields are grouped with fieldset/legend
  • Help text is associated with aria-describedby
  • Error messages are linked to their field
  • All buttons have visible text labels

Comments

Markdown supported