Form fields

Labelled inputs, selects, textareas, radio and checkbox groups, hints and error states.

Form fields

Full name required

As it should appear on your certificate.

Email address required

Enter a complete email address, like name@example.com.

Role optional

Notes optional

Tell us about your accessibility goals.

Referral code optional

Preferred standard WCAG 2.2 AA The international baseline most laws reference. EN 301 549 The European harmonised standard. Section 508 (unavailable) Not part of this track yet.

Topics you care about Accessible forms ARIA patterns Color & contrast

Using the form field accessibly

Use these form fields whenever you collect input — from a single search box to a multi-step sign-up — so every control is announced, grouped and recoverable for keyboard and screen-reader users.

Do

Give every control a programmatic label with <label for> (or aria-label when no text fits).
Wrap related radios or checkboxes in a <fieldset> with a <legend>.
Tie hints and errors to the field with aria-describedby and add autocomplete tokens for personal data.

Don't

Don't use a placeholder as the only label — it vanishes on input and fails many screen readers.
Don't leave grouped choices without a shared <legend> for context.
Don't flag an error with colour alone or with no guidance on how to fix it.

Build it right

Mark failing fields with aria-invalid="true" and link the message via aria-describedby.
Announce new errors through a live region or role="alert", and say how to correct each one.
Keep the visible label and the accessible name in sync; never strip the label to save space.
Add autocomplete tokens (name, email, tel) so browsers can fill personal data.

The source CSS for this component lives in assets/css/components/form.css.