Formulare verständlich und zugänglich gestalten
Voraussetzungen und Lernziele
Du kennst die Grundstruktur eines HTML-Dokuments. Nach 120 Minuten kannst du ein semantisches Formular bauen, es mit der Tastatur prüfen, Browservalidierung von Serverprüfung unterscheiden und eine verständliche Fehlerdarstellung entwerfen. Vorgesehen sind 30 Minuten Theorie, 60 Minuten lokale Umsetzung und 30 Minuten Prüfung.
Das Formular ist eine Vereinbarung
Ein Formular verbindet Menschen, Browser und Server. Der Mensch braucht verständliche Beschriftungen, erwartbare Aktionen und konkrete Rückmeldungen. Der Browser braucht passende HTML-Elemente. Der Server braucht eindeutige Feldnamen und geprüfte Werte. Eine schöne Oberfläche kann diese drei Aufgaben unterstützen, aber nicht ersetzen.
Ein Beispiel für einen Themenantrag sieht vereinfacht so aus:
<form method="post" action="/themenantrag">
<label for="title">Arbeitstitel</label>
<input id="title" name="title" required maxlength="120"
aria-describedby="title-help">
<p id="title-help">Formuliere die technische Frage möglichst konkret.</p>
<label for="proposal">Fragestellung und eigene Untersuchung</label>
<textarea id="proposal" name="proposal" required rows="8"></textarea>
<button type="submit">Thema zur Prüfung einreichen</button>
</form>
Das ist nur die sichtbare Formularstruktur. Eine produktive Anwendung benötigt zusätzlich ihre serverseitige Anmeldung, Berechtigungsprüfung und einen CSRF-Schutz gemäss ihrem Framework. Die Verwendung von POST allein stellt diese Schutzfunktionen nicht her.
id verbindet das Feld mit seiner Beschriftung. name bestimmt den Schlüssel bei der Übermittlung. Die Beschriftung bleibt sichtbar, wenn bereits Text eingegeben wurde. Ein Platzhalter im leeren Feld wäre dafür kein gleichwertiger Ersatz: Er verschwindet beim Tippen und eignet sich höchstens für ein zusätzliches Beispiel.
HTML zuerst, JavaScript gezielt
Die Standardfunktionen eines Formulars arbeiten bereits ohne JavaScript. Ein echter Button besitzt ein erwartbares Tastaturverhalten und eine Rolle. Ein beliebiges DIV mit einem Klickhandler müsste dieses Verhalten mühsam nachbilden. Verwende deshalb die semantisch passende Grundlage und ergänze Interaktionen erst dort, wo sie den Ablauf verbessern.
Ein Feld mit required kann eine leere Eingabe im Browser abweisen. Ein E-Mail-Feld kann bei der Eingabe unterstützen. Diese Prüfungen helfen Menschen, Fehler früh zu bemerken. Sie sind keine vertrauenswürdige Grenze: Eine Anfrage kann mit einem anderen Werkzeug direkt an den Server gesendet werden. Dort werden Format, Länge, fachliche Gültigkeit und Rechte unabhängig erneut geprüft.
JavaScript sollte das Speichern nicht unbemerkt verändern. Wenn eine Antwort als Entwurf gespeichert wurde, muss diese Rückmeldung sichtbar sein. Wenn die Verbindung unterbrochen ist, darf kein Erfolg angezeigt werden, den der Server nicht bestätigt hat. Für folgenreiche Aktionen wie «verbindlich einreichen» muss die Bedeutung von der gewöhnlichen Entwurfsspeicherung unterscheidbar bleiben.
Fehler führen zum nächsten Schritt
«Ungültig» lässt offen, was zu tun ist. «Der Titel darf höchstens 120 Zeichen enthalten» benennt eine korrigierbare Bedingung. Eine hilfreiche Fehlerseite bietet eine Zusammenfassung und eine Zuordnung zum betreffenden Feld. Das Feld kann nach einer Serverantwort zusätzlich aria-invalid="true" und einen Verweis auf den Fehlertext erhalten.
Erhalte ungefährliche bereits eingegebene Inhalte, damit Menschen nicht alles neu tippen müssen. Passwörter und andere Geheimnisse werden dagegen nicht in den ausgelieferten HTML-Text zurückgeschrieben. Unterscheide fachliche Fehler von technischen Ausfällen: Ein vorübergehend nicht erreichbarer Server bedeutet nicht, dass der eingegebene Themenantrag fachlich schlecht ist.
Auch Warnungen dürfen nicht allein durch Farbe vermittelt werden. Ergänze verständlichen Text und eine klare Zuordnung. Ein roter Rahmen ist für sich allein weder eine Erklärung noch für alle Menschen wahrnehmbar.
Responsives Layout ohne veränderte Bedeutung
Ein einfaches Formular kann auf grossen und kleinen Geräten dieselbe logische Reihenfolge behalten. Eine begrenzte Textbreite erleichtert das Lesen. Eingaben benötigen ausreichend Platz. Bei langen Feldern ist eine einzelne Spalte häufig nachvollziehbarer als eine optisch dichte Anordnung.
Vermeide starre Breiten, die auf einem Smartphone über den Rand hinausragen. Ein Codebeispiel darf innerhalb seines Bereichs horizontal scrollen; die ganze Seite sollte dadurch nicht unbedienbar werden. Gestaltung und sichtbarer Tastaturfokus müssen zusammenpassen. Entferne den Fokusrahmen nicht ohne eine mindestens ebenso gut erkennbare Alternative.
Verständnisfragen mit Erklärung
Warum braucht ein Feld name und nicht nur id? Die Kennung kann für Beschriftung und Dokumentzugriff dienen. Bei der üblichen Formularübermittlung wird dagegen der Feldname als Schlüssel verwendet.
Kann required die Servervalidierung ersetzen? Nein. Browserprüfungen sind Unterstützung bei der Eingabe und können umgangen werden.
Warum ist ein echtes button-Element nützlich? Es bringt eine passende semantische Rolle und standardisiertes Verhalten mit. Ein selbstgebautes Klickelement müsste beides korrekt ergänzen.
Übung: Ein Formular überprüfen
Baue lokal ein Formular für einen Themenantrag mit Titel, Abschlussform, Fragestellung und Quellenbasis. Stelle als Formularempfänger nur eine eigene lokale Testseite ein. Verwende keine echten personenbezogenen oder vertraulichen Angaben.
Prüfe ausschliesslich mit der Tastatur: Kannst du jedes Feld erreichen, Beschriftungen zuordnen, die Abschlussform ändern und den Absendevorgang erkennen? Teste danach ein schmales Browserfenster sowie leere und sehr lange Eingaben. Halte Ergebnis und Verbesserung in einem kurzen Protokoll fest.
Hilfe 1
Beginne ohne JavaScript. Verwende label, input, select, textarea und button. Überprüfe, ob eine Beschriftung beim Anklicken den Fokus in das zugehörige Feld setzt.
Muster einer begründeten Prüfliste
- Alle Felder besitzen dauerhafte sichtbare Beschriftungen.
- Die Tab-Reihenfolge folgt der fachlichen Eingabereihenfolge.
- Der aktuelle Fokus ist gut erkennbar.
- Hinweise sind über aria-describedby zugeordnet, falls eine zusätzliche programmatische Verknüpfung erforderlich ist.
- Die Absendeaktion nennt ihren Zweck und unterscheidet sich von «Entwurf speichern».
- Leere Pflichtfelder werden im Browser erkannt; derselbe Fall wird unabhängig auf der lokalen Serverseite geprüft.
- Die schmale Ansicht erfordert kein horizontales Scrollen der gesamten Seite.
- Ein technischer Fehler führt nicht zu einer falschen Erfolgsmeldung.
Die Liste ist keine vollständige Barrierefreiheitszertifizierung. Sie beschreibt konkrete, selbst nachvollziehbare Beobachtungen.
Transfer und Zusammenfassung
Entwirf die Fehlerantwort für einen bereits eingereichten Antrag, der nicht mehr bearbeitet werden darf. Welche Erklärung braucht der Mensch? Welche Zustandsprüfung muss der Server vornehmen? Wie verhinderst du, dass ein versteckter oder deaktivierter Button fälschlich als ausreichende Berechtigungsprüfung angesehen wird?
Semantisches HTML schafft eine robuste Grundlage. Browserhilfen verbessern die Eingabe. Der Server bleibt für Vertrauen, Rechte und fachliche Zustände verantwortlich. Gute Rückmeldungen verbinden diese Ebenen zu einem verständlichen Lernablauf.
Quellen und Prüfung
Primärquellen zuletzt inhaltlich konsultiert am 8. November 2026. Versionsangaben beachten; eine Dokumentationsseite kann sich später ändern.
Konto erstellen, um deinen Bearbeitungsstand zu speichern.