Ungruppierte Formularsteuerelemente: Warum zusammengehörige Radiobuttons und Kontrollkästchen ein fieldset brauchen
Wenn ein Formular eine Gruppe zusammengehöriger Auswahlmöglichkeiten präsentiert – eine Reihe von Radiobuttons für "Bevorzugte Kontaktmethode", eine Reihe von Kontrollkästchen für "Welche Funktionen nutzen Sie?" –, hat jede einzelne Option typischerweise ihre eigene <label>. Aber ohne ein <fieldset>, das die gesamte Gruppe umschließt, und ein <legend>, das benennt, wofür die Gruppe als Ganzes steht, hat ein Screenreader-Nutzer, der Option für Option navigiert, keine Möglichkeit zu wissen, dass diese Auswahlmöglichkeiten zusammengehören oder welche Gesamtfrage sie beantworten.
Das Problem, das dies löst
Ein sehender Nutzer sieht den Überschriftentext der Gruppe visuell über den Optionen positioniert und schließt auf den Zusammenhang. Ein Screenreader-Nutzer, der ohne Kontext beim dritten Radiobutton einer Gruppe landet, hört nur die eigene Beschriftung dieser einzelnen Option ("E-Mail") – nicht die Tatsache, dass es eine von mehreren sich gegenseitig ausschließenden Möglichkeiten für "Bevorzugte Kontaktmethode" ist. Die Gruppe in <fieldset>/<legend> einzuschließen gibt assistiver Technologie diesen Gruppierungskontext automatisch, angekündigt zusammen mit jeder Option.
Die Lösung
<!-- Vorher: einzeln beschriftet, aber kein Kontext auf Gruppenebene -->
<p>Bevorzugte Kontaktmethode</p>
<input type="radio" id="email" name="kontakt"><label for="email">E-Mail</label>
<input type="radio" id="telefon" name="kontakt"><label for="telefon">Telefon</label>
<!-- Nachher: fieldset + legend geben der Gruppe echte semantische Bedeutung -->
<fieldset>
<legend>Bevorzugte Kontaktmethode</legend>
<input type="radio" id="email" name="kontakt"><label for="email">E-Mail</label>
<input type="radio" id="telefon" name="kontakt"><label for="telefon">Telefon</label>
</fieldset>
Das <legend> wird Teil des angekündigten Kontexts jeder Option – ein Screenreader liest beim Landen auf der ersten Option typischerweise so etwas wie "Bevorzugte Kontaktmethode, E-Mail, Radiobutton" vor und gibt damit das vollständige Bild in einer Ansage.
Wann dies gilt
Dies ist am wichtigsten für Gruppen zusammengehöriger Radiobuttons oder Kontrollkästchen – ein einzelnes eigenständiges Kontrollkästchen oder ein einzelnes, in keinem Zusammenhang stehendes Textfeld benötigt keine fieldset-Umschließung. Das Muster adressiert speziell Fälle, in denen mehrere einzeln beschriftete Steuerelemente nur zusammen Sinn ergeben, als Satz, der eine Gesamtfrage beantwortet.
Wo dies leicht übersehen wird
Mehrstufige Formulare und Einstellungsseiten mit vielen Umschalt-Gruppen sind der häufigste Ort, an dem dies übersprungen wird – jeder einzelne Umschalter erhält oft seine eigene Beschriftung, wodurch das Formular in einer schnellen visuellen oder sogar halbautomatisierten Prüfung VOLLSTÄNDIG aussieht, während der Kontext auf Gruppenebene, der sie verbindet, still und leise fehlt.
Offizielle Referenzen
Häufige Fragen
- Wann brauchen Formularelemente ein fieldset mit legend?
- Immer wenn mehrere Eingaben eine logische Auswahl bilden – etwa eine Gruppe von Radiobuttons oder zusammengehörige Checkboxen. Das `<fieldset>` gruppiert sie, die `<legend>` gibt der Gruppe ihre übergreifende Frage oder Bezeichnung.
- Warum genügt eine Überschrift über der Gruppe nicht?
- Eine visuelle Überschrift ist nicht programmatisch mit den Eingaben verknüpft. Eine `<legend>` innerhalb eines `<fieldset>` wird von Screenreadern zusammen mit der Beschriftung jeder Option als Gruppenname angesagt – eine benachbarte Überschrift nicht.
- Welche WCAG-Regeln gelten für gruppierte Bedienelemente?
- SC 1.3.1 (Info und Beziehungen) und 3.3.2 (Beschriftungen oder Anweisungen), Stufe A. Die Lösung ist ein `<fieldset>` mit aussagekräftiger `<legend>`.
Verwandte Artikel
Möchten Sie sehen, wie Ihre eigene Website abschneidet?
Kostenlosen Barrierefreiheitsscan durchführen