Referenzierte Normen
Benötigen Sie ein fundiertes technisches Audit Ihrer digitalen Produkte anhand dieser Standards?
Audit anfordern1. 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:
<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:
<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>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.