Accessible forms and errors

Accessible Forms & Validation

Forms are where users create accounts, configure settings, enter payment details and complete core workflows. Every field must state clearly what input is expected, whether it is required, why validation failed and how to recover (WCAG 1.3.1, 1.3.5, 2.4.6, 3.3.1, 3.3.2, 3.3.3, 3.3.4, 3.3.7, 3.3.8).

1. Labels, Instructions & Grouping

• Persistent visible <label>: every <input>, <select> and <textarea> needs a permanently visible <label for="field-id"> (or explicit aria-labelledby when a visible heading acts as the label).
• Never use placeholder as the only label: placeholders disappear as soon as the user types, strain short-term memory, often fail 4.5:1 contrast, and are not treated as reliable accessible names across all assistive technologies.
• Format hints & helper text: place formatting rules (e.g., "Use YYYY-MM-DD", "Minimum 12 characters") in visible text above or adjacent to the input and link them via aria-describedby="hint-id" before the user submits.
• Group related controls (<fieldset> + <legend>):
  • Wrap radio button groups, checkbox groups, date parts (Day / Month / Year) and repeated address blocks (Shipping vs. Billing) in a <fieldset> with a concise <legend> (or role="group" / role="radiogroup" with aria-labelledby).
  • Without a group legend, a screen reader user hears "Yes, radio button 1 of 2" without knowing what question "Yes" answers.
• Input purpose & cognitive support:
  • Set appropriate type (email, tel, url, number, search, password) and inputmode (numeric, decimal) so mobile keyboards match the data.
  • Add standard autocomplete attributes (name, email, username, current-password, new-password, one-time-code, street-address, cc-number) on personal data fields (WCAG 1.3.5).
  • Never block paste (onpaste prevention) on password or verification fields (WCAG 3.3.8 Accessible Authentication).

2. Error Identification, Association & Focus Management

When client-side or server-side validation fails:

1. Mark invalid fields programmatically: set aria-invalid="true" on the offending input(s) (and remove aria-invalid or set "false" once corrected).
2. Associate the error message with the field:
   • Render a visible, specific error message next to the field (<p id="email-error">Enter a valid work email address, including '@'</p>).
   • Reference the error ID in aria-describedby="email-hint email-error" (or aria-errormessage where supported alongside aria-describedby), keeping both helper text and error text linked.
   • Do not rely on red border color alone — include text and an icon (aria-hidden="true") alongside the message (WCAG 1.4.1).
3. Move focus predictably on submit failure:
   • For short forms: move focus directly to the first invalid input so the user hears the field label, invalid entry, and its linked error message immediately.
   • For long or multi-section forms: render an Error Summary at the top of the form (role="alert" or focused container with tabindex="-1" and a heading like "There are 3 problems with your submission"), where each item is an anchor link (<a href="#field-id">) that jumps focus directly to the corresponding invalid field.

3. Disabled Submit Buttons vs. Helpful Validation

• Avoid disabling the primary Submit button silently while the user is still filling out a complex form — disabled buttons cannot receive keyboard focus by default and give no explanation of why submission is blocked.
• Prefer allowing submission and guiding the user directly to the missing or invalid field with a clear error message.
• During in-flight submission (pending state), prevent duplicate submits while keeping focus stable (aria-disabled="true" or aria-busy="true" with visible loading feedback).