Formulare ohne JavaScript: Auswahlfelder richtig bauen

Formulare ohne JavaScript heißt hier: Die Grundfunktion steht ohne Skript, Komfort kommt obendrauf. Ein Formular, das ohne Skript funktioniert und mit Skript bequemer wird, übersteht einen Ladefehler, einen Werbeblocker und jeden Tippfehler im Code. Auswahlfelder in Form kleiner Schaltflächen, oft Chips genannt, sind dafür ein gutes Beispiel. Gebaut werden sie meist aus einem Textelement mit Datenattribut, einer Formatvorlage für den ausgewählten Zustand und einem Skript, das beim Klick eine Klasse umschaltet und ein verstecktes Feld füllt.

Was passiert, wenn das Skript fehlt

Den folgenden Fall haben wir im öffentlichen Eintragsformular des SEO CMS selbst gefunden, behoben ist er seit Fassung 1.0.127. Das Skript für die Auswahlfelder existierte nicht, weder in der Vorlage noch in der ausgelieferten Skriptdatei. Die Folgen bauten aufeinander auf.

Zuerst ließ sich nichts auswählen. Sichtbar war nur der Zustand beim Überfahren mit der Maus, und der sah aus, als sei etwas ausgewählt. Dann blieb das versteckte Feld leer, das als Pflichtfeld ausgezeichnet war. Die HTML-Norm regelt diesen Fall so: Vor dem Absenden prüft der Browser alle Pflichtfelder, und scheitert die Prüfung, wird nicht abgeschickt. Ist das betroffene Feld gar nicht dargestellt, etwa wegen des Attributs hidden, darf der Browser den Fehler als Skriptfehler melden ^[1]. Der landet in der Entwicklerkonsole. Für Besucher tat der Absenden-Knopf einfach nichts, ohne Hinweis und ohne markiertes Feld.

Lange aufgefallen ist das nicht, weil im Backend dasselbe Muster mit Skript umgesetzt war und dort funktionierte. Wer das Formular dort testete, sah keinen Fehler.

Die Fassung ohne Skript

Die Lösung ist ein echtes Ankreuzfeld mit Beschriftung:

<input type="checkbox" class="chip-input" id="c3" name="leistungen[]" value="SEO">

<label class="chip-toggle" for="c3">SEO</label>

Das Aussehen entsteht über die Pseudoklasse :checked, die angekreuzte Ankreuzfelder trifft, kombiniert mit dem Nachbarselektor auf die folgende Beschriftung ^[2]. Ein Klick auf die Beschriftung kreuzt das Feld an, weil sie über das Attribut for verknüpft ist. Das Ergebnis sieht aus wie vorher. Es lässt sich mit der Tastatur bedienen, wird als Ankreuzfeld angesagt, funktioniert ohne Skript, und die Auswahl bleibt nach einem abgelehnten Absenden erhalten, wenn der Server die Werte zurückgibt.

Verstecken, aber richtig

Das Ankreuzfeld selbst soll unsichtbar sein, nur die Beschriftung zeigt den Zustand. Mit display: none geht das schief. MDN beschreibt, dass ein Element damit aus dem Barrierefreiheitsbaum fällt und von Screenreadern nicht mehr angesagt wird ^[3]. Üblich ist stattdessen eine Technik, die das Element nur optisch entfernt, etwa über absolute Positionierung und eine Größe von einem Pixel. WebAIM erklärt dazu, dass Screenreader solche Inhalte weiter vorlesen, weil sie Teil der Seite bleiben ^[4].

WebAIM warnt aber auch: Formularelemente bleiben bei dieser Technik per Tastatur erreichbar, ohne dass Sehende sie sehen ^[4]. Bei Chips heißt das, dass die Beschriftung den Fokus anzeigen muss. Eine Formatvorlage für das fokussierte Ankreuzfeld, die auf die folgende Beschriftung wirkt, gehört deshalb zwingend dazu. Fehlt sie, springt der Fokus beim Tabben unsichtbar durch die Auswahl.

Die allgemeine Regel

Ein nachgebautes Bedienelement muss alles nachbauen, was das echte mitbringt: Fokus, Tastaturbedienung, Rolle für Screenreader und Zustand. Nach unserer Erfahrung wird davon meist das Aussehen umgesetzt und der Rest vergessen. Der ARIA Authoring Practices Guide des W3C fasst das in den Satz "A role is a promise": Anders als native Eingabeelemente bringen ARIA-Rollen im Browser weder Tastaturbedienung noch Gestaltung mit, beides muss der Autor selbst bauen ^[5]. Ein natives HTML-Element ist deshalb die günstigere Wahl, weil es weniger Stellen gibt, an denen etwas fehlen kann. Wie das SEO CMS Barrierefreiheit und Suche umsetzt, steht unter Suche und Barrierefreiheit, was die Anforderungen dahinter sind, im Glossareintrag Barrierefreiheit.

So prüfst du ein Formular vor dem Livegang

Ein Formular ist erst geprüft, wenn es einmal vollständig abgeschickt wurde. Eine Sichtprüfung hätte den Fehler oben nie gefunden, die Seite sah in Ordnung aus. Drei Durchgänge reichen:

• einmal vollständig ausfüllen und abschicken, bis die Bestätigung kommt,
• einmal nur mit der Tastatur bedienen und dabei auf den sichtbaren Fokus achten,
• einmal mit abgeschaltetem JavaScript ausfüllen und dabei die Entwicklerkonsole offen halten.

Meldet die Konsole beim Absenden einen Fehler zu einem Formularfeld, das du auf der Seite gar nicht siehst, steckt nach unserer Erfahrung fast immer ein verstecktes Pflichtfeld dahinter. Was in Fassung 1.0.127 sonst noch korrigiert wurde, fasst der Beitrag SEO CMS 1.0.127 und 1.0.128 zusammen. Warum JavaScript auch für Suchmaschinen eine eigene Fehlerquelle ist, beschreibt der Glossareintrag JavaScript-SEO.

Wenn ein Formular auf deiner Website still versagt und du nicht weißt, woran es liegt, bring die Adresse in die gratis Sprechstunde mit. Dann sprechen wir darüber, woran es liegen kann.

1. Gesetz HTML Living Standard, Abschnitt 4.10.21.2 Constraint validation. WHATWG. Stand 31.10.2026. abgerufen am 31.10.2026
2. Organisation :checked. MDN Web Docs, Mozilla. Stand 31.10.2026. abgerufen am 31.10.2026
3. Organisation display (Abschnitt Accessibility). MDN Web Docs, Mozilla. Stand 21.09.2026. abgerufen am 31.10.2026
4. Organisation Invisible Content Just for Screen Reader Users. WebAIM. Stand 25.09.2020. abgerufen am 31.10.2026
5. Organisation ARIA Authoring Practices Guide: Read Me First. W3C Web Accessibility Initiative. Stand ohne Datum. abgerufen am 31.10.2026

Zuletzt geprüft am 03.11.2026, nächste Prüfung spätestens im November 2027. Fehler entdeckt? Schreib uns.