Form Labels and Error Messages: WCAG Audit Checklist

Quick answer: what should a WCAG form audit check?

Why labels and errors matter

• Screen reader users need programmatic names and relationships.
• Keyboard users need predictable focus movement after errors.
• Low-vision users need visible labels, visible errors, and enough contrast.
• Users with cognitive or language disabilities need clear instructions and helpful correction text.
• All users benefit when forms explain requirements before and after validation.

Key WCAG criteria involved

• 1.3.1 Info and Relationships: labels, groups, instructions, and relationships should be programmatically determinable where needed.
• 2.4.6 Headings and Labels: headings and labels should describe topic or purpose.
• 3.3.1 Error Identification: automatically detected input errors should identify the item in error and describe the error in text.
• 3.3.2 Labels or Instructions: labels or instructions should be provided when content requires user input.
• 3.3.3 Error Suggestion: suggestions should be provided when an input error is detected and suggestions are known, unless doing so would compromise security or purpose.
• 3.3.4 Error Prevention: for legal, financial, data, or test responses, users may need review, confirmation, or reversibility.
• 4.1.2 Name, Role, Value: custom controls and inputs should expose programmatic names, roles, states, and values.

Labels and instructions

• Every text input, select, checkbox, radio button, switch, slider, upload field, and custom input should have a clear label.
• Do not rely only on placeholder text as the label.
• Required fields should be identified in text, not only by color or icon.
• Expected formats should be provided before submission, such as date, phone, password, file type, or ID number.
• Radio buttons and checkboxes should be grouped with a descriptive legend or equivalent relationship.

Programmatic label relationships

• Use label elements with correct for and id relationships for standard inputs.
• Use fieldset and legend for related radio buttons and checkboxes where appropriate.
• Use aria-labelledby or aria-describedby only when the relationship is intentionally managed and tested.
• Ensure visible labels and accessible names are consistent.
• Check that required, invalid, disabled, expanded, selected, and checked states are exposed where relevant.

Error identification

• Identify the field that has the error.
• Describe the error in text.
• Do not rely only on red borders, icons, vibration, or color.
• Keep error messages visible until the user can act on them.
• Ensure screen readers can discover or hear the error.
• Avoid generic messages such as invalid input when more detail is available.

Error suggestions

• Explain the expected format, such as use DD/MM/YYYY.
• Explain missing requirements, such as include at least one number.
• Suggest correction when the allowed value or range is known.
• Avoid blaming language.
• Do not reveal sensitive security information in a way that creates risk.
• Do not force users to guess which field caused the problem.

Focus handling after validation

• After failed submission, move focus to an error summary or first invalid field where appropriate.
• If an error summary is used, provide links to the affected fields.
• Ensure focus does not move unexpectedly while users are typing.
• Ensure dynamic validation messages are announced or discoverable.
• Do not trap focus in the form or error message.
• Retain user-entered data unless there is a valid security reason not to.

How auditors test form labels and errors

• Check every input's visible label and accessible name.
• Check instructions, required-field indicators, and input format guidance.
• Use Tab, Shift+Tab, Enter, Space, and arrow keys where relevant.
• Submit empty and invalid forms to trigger errors.
• Check whether errors are shown in text and associated with affected fields.
• Check whether screen readers announce or can discover the error.
• Check mobile and responsive layouts, because labels and error placement may change.

What evidence should appear in the report

• Affected URL, screen, form, field, state, or workflow.
• Field label, accessible name, and visible instruction issue.
• Validation scenario used to trigger the error.
• Expected behavior and actual behavior.
• WCAG criterion and level.
• Screenshot, keyboard path, screen reader note, DOM or accessibility-tree evidence where useful.
• User impact, severity, remediation guidance, and retest method.

Common failures

• Placeholder text used as the only label.
• Label visible but not associated with the input.
• Required field indicated only by color or asterisk without explanation.
• Error identified only by red border.
• Error summary not linked to fields.
• Screen reader does not announce the invalid field or error.
• Format requirements appear only after failed submission.
• Custom select, combobox, date picker, or upload component has missing name, role, state, or value.

Remediation guidance

• Use visible labels for inputs wherever possible.
• Associate labels programmatically with fields.
• Group related fields with fieldset and legend or equivalent semantics.
• Provide format instructions before users submit.
• Use clear, text-based error messages.
• Associate errors with affected fields.
• Provide helpful error suggestions where possible.
• Retest with keyboard and screen reader after remediation.

Retesting form fixes

• Original finding ID and form state.
• Field label and accessible name after remediation.
• Required-field and instruction visibility.
• Validation scenario retested.
• Error message text and field association.
• Keyboard path and focus behavior.
• Screen reader observation where relevant.
• Retest status and remaining risk.

Practical recommendation

Official references used