<form>

Stell dir ein Formular wie einen Briefumschlag vor: Du steckst Informationen hinein (<input>, <textarea>), schreibst eine Adresse drauf (action) und wählst, wie der Brief verschickt wird (method). Wenn der Nutzer auf den Absende-Button klickt, nimmt der Browser alle Felder mit einem name-Attribut, packt ihre Werte zusammen und schickt sie an die URL, die du in action angegeben hast.

• <form> ist ein Block-Element und der Container für alle Formularelemente
• Das action-Attribut definiert, wohin die Daten gesendet werden (eine URL auf deinem Server)
• Das method-Attribut definiert wie die Daten gesendet werden: per GET oder POST
• Formulare können nicht verschachtelt werden: ein <form> innerhalb eines anderen <form> ist ungültiges HTML

GET vs. POST

Der Unterschied ist wichtig und lässt sich gut mit einer Analogie merken:

• GET ist wie eine Postkarte: Die Daten stehen offen in der URL (z.B. /suche?q=html). Jeder kann sie lesen, und du kannst die URL als Lesezeichen speichern oder teilen. Verwende GET für Suchen, Filter und alles, was keine sensiblen Daten enthält.

• POST ist wie ein verschlossener Briefumschlag: Die Daten werden im Body des HTTP-Requests verschickt und sind nicht in der URL sichtbar. Verwende POST für Logins, Registrierungen, Kontaktformulare und alles mit persönlichen oder sensiblen Daten.

enctype-Werte

Das enctype-Attribut bestimmt, wie die Formulardaten beim Absenden verpackt werden. Du brauchst in den allermeisten Fällen nur die ersten zwei Optionen:

• application/x-www-form-urlencoded (Standard): Daten werden als URL-encoded String gesendet (z.B. name=Max&email=max@example.com). Für die meisten Formulare genau richtig
• multipart/form-data (Pflicht bei Datei-Uploads): Wenn dein Formular ein <input type="file"> enthält, musst du diesen Encoding-Typ setzen. Sonst bekommt der Server nur den Dateinamen, aber nicht die Datei selbst
• text/plain: Sendet die Daten als unformatierten Text. Nur zum Debuggen nützlich, nicht für den Produktiveinsatz

Formulare sind für viele Nutzer eine Herausforderung, besonders für Menschen, die auf Screenreader oder Tastaturnavigation angewiesen sind. Ein paar Grundregeln machen den Unterschied zwischen einem frustrierenden und einem nutzbaren Formular.

Labels sind Pflicht. Jedes Eingabefeld braucht ein sichtbares <label>, das über for mit der id des Feldes verknüpft ist. Placeholder-Text ist kein Ersatz für Labels: er verschwindet, sobald der Nutzer tippt, und wird von vielen Screenreadern nicht zuverlässig vorgelesen.

Gruppiere zusammengehörige Felder mit <fieldset> und <legend>. Bei Checkbox-Gruppen oder Radio-Buttons ist das besonders wichtig. Ohne <fieldset> hört ein Screenreader-Nutzer nur “Anfänger, Radio-Button”, aber nicht, dass es um die Frage “Erfahrungslevel” geht. Mit <legend> wird der Kontext klar.

Fehlermeldungen müssen zugänglich sein. Wenn ein Feld ungültig ist, reicht es nicht, den Rahmen rot zu färben. Verknüpfe die Fehlermeldung über aria-describedby mit dem jeweiligen Feld und setze aria-invalid="true". So liest der Screenreader beim Fokussieren des Feldes automatisch die Fehlermeldung vor.

Tastaturnavigation testen. Jedes Formular sollte komplett mit der Tastatur bedienbar sein: Tab zum nächsten Feld, Shift+Tab zurück, Enter zum Absenden. Achte darauf, dass die Tab-Reihenfolge logisch ist und kein Feld übersprungen wird. Benutzerdefinierte Widgets (Custom Dropdowns, Toggle-Switches) brauchen oft zusätzliche role- und aria-Attribute, um mit der Tastatur bedienbar zu sein.

aria-label für Formulare ohne sichtbare Überschrift. Wenn dein Formular keine sichtbare Überschrift hat (z.B. ein Suchfeld im Header), gib dem <form>-Element ein aria-label, damit Screenreader-Nutzer wissen, worum es geht: <form aria-label="Seitensuche">.

• enctype vergessen bei Datei-Uploads: Das ist einer der häufigsten Fehler. Ohne enctype="multipart/form-data" sendet der Browser bei einem Datei-Upload nur den Dateinamen als Text, nicht die eigentliche Datei. Der Server bekommt dann einen String wie "foto.jpg" statt der Bilddaten.

• Formulare verschachteln: <form> innerhalb von <form> ist ungültiges HTML. Der Browser ignoriert das innere Formular, und die Absende-Logik funktioniert nicht wie erwartet. Wenn du mehrere unabhängige Absende-Aktionen brauchst, verwende separate Formulare nebeneinander.

• Kein name-Attribut auf Eingabefeldern: Das name-Attribut ist entscheidend: es ist der Schlüssel, unter dem der Server die Daten empfängt. Ein <input> ohne name wird beim Absenden komplett ignoriert. Der Server bekommt die Eingabe dann einfach nicht.

• GET für sensible Daten: Wenn du method="get" für ein Login-Formular verwendest, steht das Passwort in der URL (z.B. /login?password=geheim). Das erscheint im Browser-Verlauf, in Server-Logs und kann von Dritten eingesehen werden. Verwende für sensible Daten immer method="post".

Das form-Element wird von allen Browsern vollständig unterstützt. Die HTML5-Validierungsattribute (wie required, pattern, novalidate) funktionieren ebenfalls in allen modernen Browsern zuverlässig.

• Chrome

  Komplett

• Firefox

  Komplett

• Safari

  Komplett

• Edge

  Komplett

• Opera

  Komplett

Formulare werden von den meisten Email-Clients aus Sicherheitsgründen nicht unterstützt. Interaktive Elemente werden in der Regel entfernt oder ignoriert.

• Apple Mail

  Teilweise

  Zeigt Formularelemente an, aber das Absenden funktioniert nicht zuverlässig.

• Gmail

  Keine

  Gmail entfernt form-Elemente und deren Inhalte komplett aus dem HTML.

• Outlook

  Keine

  Outlook entfernt Formulare aus Sicherheitsgründen vollständig.

• Thunderbird

  Teilweise

  Zeigt Formularelemente an, Funktionalität ist aber eingeschränkt.

• Yahoo Mail

  Keine

  Yahoo Mail entfernt Formular-Elemente aus dem HTML.