TaggedWorks - Digital Accessibility Firm
Checklisten[ ENGINEERING-ARTIKEL ]

The Comprehensive Accessible Forms Checklist

A production-grade checklist for designing and developing accessible web forms with labels, instructions, error summaries, and autocomplete support.

TaggedWorks Design & Engineering
Veröffentlicht: 2024-03-05
8 Min. Lesezeit

Referenzierte Normen

WCAG 2.2 SC 1.3.1SC 3.3.1SC 3.3.2SC 3.3.3SC 3.3.7
[ ENGINEERING-AUDIT ]

Benötigen Sie ein fundiertes technisches Audit Ihrer digitalen Produkte anhand dieser Standards?

Audit anfordern

1. Structure & Visible Labels

Every interactive form input must have a programmatically associated, visible label. Placeholder text is never an acceptable substitute for a label because it disappears upon typing and typically lacks sufficient contrast.

  • Explicitly associate labels using label htmlFor matching the input id.
  • Never hide visible labels unless the visual context is unmistakable (and even then, provide sr-only text).
  • Clearly indicate required fields in text (e.g., '(required)'), not solely via a red asterisk or color alone.

2. Logical Grouping & Fieldsets

When multiple checkboxes or radio buttons represent a single concept, wrap them in a fieldset element with a clear legend:

CODE_REFERENZ :: IMPLEMENTIERUNG
<fieldset>
  <legend className="font-semibold">Select your notification preferences</legend>
  <label><input type="checkbox" name="pref" value="email" /> Email notifications</label>
  <label><input type="checkbox" name="pref" value="sms" /> SMS alerts</label>
</fieldset>

3. Error Summaries & Inline Errors

When validation errors occur upon form submission, follow this two-tiered pattern:

  • Display a top-level Error Summary box at the top of the form, move keyboard focus to it, and list links to each failing field.
  • Display an inline error message next to the field, and link it via aria-describedby on the input.
  • Mark invalid inputs with aria-invalid='true'.

4. Autocomplete & Input Purpose

Comply with WCAG 2.1 SC 1.3.5 (Identify Input Purpose) by providing standard HTML autocomplete attributes (e.g., name, email, street-address, postal-code, tel). This enables assistive browser technologies to auto-populate fields and display recognizable icons.

5. Production-Ready Form Pattern

Here is a complete accessible input field pattern:

CODE_REFERENZ :: IMPLEMENTIERUNG
<div>
  <label htmlFor="user-email" className="block font-medium">
    Work Email <span aria-hidden="true">*</span>
    <span className="sr-only">(required)</span>
  </label>
  <input
    id="user-email"
    name="email"
    type="email"
    autoComplete="email"
    required
    aria-invalid={hasError ? "true" : "false"}
    aria-describedby={hasError ? "user-email-error user-email-hint" : "user-email-hint"}
    className="border rounded p-2"
  />
  <p id="user-email-hint" className="text-sm text-slate-500">We will never share your email.</p>
  {hasError && (
    <p id="user-email-error" className="text-sm text-red-600 font-medium" role="alert">
      Please enter a valid work email address (e.g. name@company.com).
    </p>
  )}
</div>
TW

TaggedWorks Design & Engineering

Praxisgruppe für digitales Barrierefreiheits-Engineering & Forschung

TaggedWorks-Forschungspublikationen werden von praktizierenden Barrierefreiheits-Ingenieuren und Fachspezialisten verfasst. Unsere Empfehlungen basieren auf aktuellen WCAG 2.2-Interpretationen, Browser-Verhalten und Kompatibilitätstabellen assistiver Technologien.