WCAG 3.3.2 Labels or Instructions: Creating More Accessible Online Forms

WCAG 3.3.2: what this means for online forms

WCAG 3.3.2 appears in the WCAG success criteria as the requirement for clear labels or instructions where a page needs user input. For forms this means every field that requires a user action must provide a label or instruction that a user can perceive and use to complete the task.

When 3.3.2 applies

Apply 3.3.2 whenever a user must enter information, choose an option, or perform a gesture to complete a task. That covers:

• Text inputs, selects, checkboxes and radio buttons
• Custom controls that mimic native widgets
• Steps that rely on specific formatting (for example a date or phone number)

Core requirement in plain language

Provide a perceivable label or clear instruction so a user knows what to enter and how to enter it. If the input needs a specific format, give the format in the instruction.

Why this matters

Users who rely on screen readers, cognitive support, or keyboard navigation depend on labels and instructions to understand form fields. Missing or ambiguous labels cause incorrect entries, form abandonment, and barriers for assistive technology.

Good and bad examples

Good

• Visible label: <label for=“email”>Email address</label> with a matching input id.
• Short instruction for format: <span id=“dob-help”>Enter as DD/MM/YYYY</span> with aria-describedby on the input.
• Required indicator explained once at the top: “Fields marked * are required” plus visible star on each required label.

Bad

• Placeholder used as the only label. Placeholders disappear and are not reliable for assistive tech.
• Icon-only controls with no accessible name or tooltip.
• Instructions shown only by hover or focus states.

Accessible HTML patterns

Use native HTML labeling first. When you need additional instructions, use aria-describedby to connect help text or error text to the input.

Examples shown as text with entities so they can be copied safely:

• Basic label: <label for=“email”>Email address</label> <input id=“email” name=“email” type=“email” required>
• Label with help: <label for=“dob”>Date of birth</label> <span id=“dob-help”>Enter as DD/MM/YYYY</span> <input id=“dob” aria-describedby=“dob-help” name=“dob”>
• Custom control name: role and aria-label or aria-labelledby for non-native widgets (for example aria-labelledby=“label-id”).

When to use aria-describedby

Use aria-describedby to attach complex instructions, examples, or error text to a field. Do not use it as a substitute for a visible label. Screen readers announce aria-describedby after the label, which helps with context.

Placeholders versus labels

Placeholders are hint text, not labels. They disappear once the user types. Screen reader support for placeholders is inconsistent. Use a visible label for identification and a placeholder only for short hints that do not replace the label.

Instructions and error messaging

Provide concise instructions at the point of use. If a field requires a specific format, show the example before input and repeat it in any error message. Make error text programmatically connected to the field using aria-describedby or aria-invalid with a corresponding message.

Step-by-step: make a simple sign-up form meet 3.3.2

1. List which fields are required and define any format rules. Write short instructions for each rule.
2. Add a visible label element for every input and match the label to the input id.
3. For format rules, include a small help text element and reference it with aria-describedby.
4. When validation fails, show an inline error and ensure the error is referenced by aria-describedby. Set focus or an alert so keyboard users notice the failure.
5. Test with a screen reader and keyboard only to confirm labels and instructions are announced in the right order.

Practical checklist for developers and designers

• Every input has a visible label or accessible name.
• Instructions for format are clear and placed before the input.
• Placeholders never used as the sole label.
• Help text and errors are referenced with aria-describedby when needed.
• Required fields are explained once and marked consistently.
• Custom widgets expose accessible names via aria-labelledby or aria-label.
• Test with at least one screen reader and with keyboard only.

Common mistakes and how to avoid them

• Relying on visual cues alone. Provide programmatic labels for assistive tech.
• Hiding instructions behind hover or focus. Put essential instructions in persistent text or accessible description.
• Leaving error messages off-screen or outside the DOM flow. Ensure they are reachable and referenced by the field.

Testing tips

• Turn off CSS and confirm labels remain readable and instructions make sense.
• Try the form with a screen reader. Check that label, instruction, and error read in a logical sequence.
• Run an automated checker for basic label coverage, then follow up with manual tests for edge cases.

Where to learn more

See the WCAG success criteria for authoritative text and refer to WAI-ARIA practices when building custom widgets. Use platform accessibility docs for browser and assistive technology behaviour.