Barrierefreiheits-Quick-Wins: Kleine Code-Änderungen, große Wirkung

Konkret heißt das: die passende Tastatur beim Ausfüllen eines Formulars auf dem Smartphone, ein Formularfeld, das sich automatisch ausfüllt, eine Fehlermeldung, die direkt sagt, was fehlt — lauter kleine Umsetzungen der WCAG, die wir längst als selbstverständlichen Bedienkomfort erleben.

Genau das zeigen die folgenden sieben Beispiele: Oft reicht ein einziges Attribut oder eine einzige Codezeile, um spürbar mehr Barrierefreiheit zu schaffen, ganz ohne große Konzeptionsrunde oder Sonderlösung. Das lohnt sich auch ohne rechtliche Pflicht, wie ich an anderer Stelle bereits erklärt habe. Es zeigt vor allem eines: Barrierefreiheit ist kein Sonderfall, sondern ein Qualitätsmerkmal.

Besonders deutlich wird das bei Formularen: Genau dort, wo wir Angaben eintippen, auswählen und abschicken, entscheiden oft schon einzelne Attribute über Komfort oder Frust. Viele der folgenden Beispiele setzen deshalb hier an — einige gelten aber genauso außerhalb von Formularen.

Bedienflächen: Groß genug für alle Eingabegeräte

Eine Website muss sich heute nahtlos auf jedem Endgerät bedienen lassen, egal ob 34“-Ultrawide-Monitor oder 6“-Smartphone-Display. Wir erwarten, dass Schrift und Elemente sich anpassen und nichts kaputtgeht, egal wie wir zugreifen.

Besonders bei Geräten, die wir mit den Händen bedienen, sind ausreichend große Schaltflächen entscheidend. Nur so treffen wir direkt und ohne Umwege die richtige Einstellung, öffnen das richtige Menü oder bedienen die Anwendung ohne Frust.

Die WCAG verlangen mindestens 24×24 Pixel für interaktive Elemente. Apple empfiehlt in seinen Guidelines eher 44×44 Pixel, Google bei Material Design 48×48 Pixel. Diese Mindestgrößen definieren wir am besten direkt im CSS, mit logischen Eigenschaften statt physischer:

button,
.icon-button {
    min-inline-size: 44px;
    min-block-size: 44px;
    padding: 0.5em 1em;
}

/* Zusätzlicher Spielraum für Touch-Geräte */
@media (pointer: coarse) {
    button,
    .icon-button {
        min-inline-size: 48px;
        min-block-size: 48px;
    }
}

min-inline-size und min-block-size verhalten sich wie min-width und min-height, richten sich aber nach der Schreibrichtung statt fest nach horizontal/vertikal. Bei einer Seite mit vertikaler Schrift oder Rechts-nach-links-Layout bleibt die Mindestgröße dann trotzdem korrekt. Mit der Media Query pointer: coarse sprechen wir gezielt Touch-Geräte an, ohne die Größe auch am Desktop unnötig aufzublasen.

Tastaturbedienbarkeit: Nativ statt nachgebaut

Standard-HTML-Elemente wie <input>, <button>, <details>, <select> oder <a> bringen native Tastatur-Unterstützung von Haus aus mit, ohne dass wir dafür im Code irgendwas extra anpassen müssen. Ein Link lässt sich mit Tab erreichen und mit Enter aktivieren, ein Button zusätzlich auch mit der Leertaste, ein <select> öffnet sich mit Enter oder Pfeiltasten und lässt sich per Tastatur durchblättern. Das kriegen wir geschenkt, solange wir die richtigen Elemente verwenden statt sie mit <div> und JavaScript nachzubauen.

Besonders in Formularen und Suchfeldern nutzen wir alle gerne die Tastaturbedienung und gehen ganz selbstverständlich davon aus, dass sie funktioniert. Power-Nutzende tabben von einem Feld zum nächsten, weil die Maus parallel zu bedienen umständlich ist und Zeit kostet. Eine Suche schicken wir gerne direkt mit Enter ab, ohne extra auf eine Schaltfläche klicken zu müssen. Und wenn Formularfelder dazu noch korrekt benannt und verknüpft sind, profitieren auch Menschen, die einen Screenreader oder Sprachsteuerung nutzen.

Ein Suchfeld, bei dem Enter direkt absendet und das sich komplett per Tastatur bedienen lässt, ganz ohne zusätzliches JavaScript:

<form role="search">
    <label for="site-search">Suche</label>
    <input type="search" id="site-search" name="q" />
    <button type="submit">Suchen</button>
</form>

Kein Klick-Handler, kein keydown-Listener, nichts. type="search" sorgt auf vielen Tastaturen zusätzlich dafür, dass die Enter-Taste direkt als „Suchen“ beschriftet wird. Der <button type="submit"> reagiert nativ auf Enter und Leertaste, ganz ohne dass wir das selbst programmieren müssten.

Input-Type: Die richtige Tastatur zur richtigen Zeit

Besonders auf dem Smartphone merken wir sofort, wenn ein Formularfeld das korrekte type-Attribut am <input> hat: die Telefontastatur bei der Telefonnummer, die Kalenderauswahl beim Geburtsdatum, das direkt verfügbare @-Zeichen bei der E-Mail-Adresse.

Mit dem richtigen Typ bekommen wir vor allem auf Smartphones eine angepasste Eingabemaske, die Zeit spart und die passenden Zeichen direkt anbietet. Weitere Beispiele sind der Farbwähler bei Farbwerten oder verdeckte Zeichen beim Passwort, was gleichzeitig für mehr Datenschutz sorgt. Außerdem übernimmt der Browser bei korrektem Typ schon ein erstes Parsing und zeigt bei falscher Eingabe direkt einen Hinweis oder Fehler an.

Die wichtigsten input-types im Überblick:

Ein Sonderfall verdient dabei Aufmerksamkeit: type="number" ist nur für echte Zahlen im mathematischen Sinn gedacht, also Menge, Anzahl oder Preis. Für Ziffernfolgen, die keine Rechengröße sind (Postleitzahl, Telefonnummer, Kreditkartennummer), ist es die falsche Wahl. Es blendet Stepper-Pfeile ein, ändert den Wert schon beim versehentlichen Scrollen über dem Feld und wirft führende Nullen weg, aus der PLZ 01067 würde 1067. Wer nur die Ziffern-Tastatur auf dem Smartphone möchte, kombiniert deshalb besser type="text" mit inputmode="numeric": Ziffernblock ja, aber ohne die Nebenwirkungen von number. Genau so lösen wir es gleich beim Postleitzahl-Feld.

Die komplette Liste finden Sie in der MDN-Referenz zu den input-types (öffnet in neuem Tab).

Autocomplete: Formulare schnell und richtig ausfüllen

Besonders bei Anmelde- oder Adressformularen geben wir häufig dieselben Angaben ein: Name, Adresse, E-Mail. Ein falsch getippter Wert kann dabei richtig ärgerlich werden, etwa wenn die verwechselte Postleitzahl bei der Geburtstagsbestellung die Expresszustellung verhindert.

Genau hier hilft das autocomplete-Attribut. Es sagt dem Browser oder Zugangsgerät, welche Art von Eingabe erwartet wird, zum Beispiel Name, Adresse oder Suche. In der Regel greift das Gerät dann auf bereits gespeicherte Angaben zurück und bietet das Ausfüllen direkt an. Der Gewinn für uns: Wir müssen nicht jedes Feld händisch ausfüllen, können eher davon ausgehen, dass die Eingabe korrekt ist, und sparen dabei auch noch Zeit.

Ein einfaches Adressformular mit den passenden type- und autocomplete-Attributen kombiniert:

<form autocomplete="on">
    <label for="vorname">Vorname</label>
    <input type="text" id="vorname" name="vorname" autocomplete="given-name" />

    <label for="nachname">Nachname</label>
    <input type="text" id="nachname" name="nachname" autocomplete="family-name" />

    <label for="email">E-Mail</label>
    <input type="email" id="email" name="email" autocomplete="email" />

    <label for="plz">Postleitzahl</label>
    <input type="text" id="plz" name="plz" autocomplete="postal-code" inputmode="numeric" />
</form>

type und autocomplete ergänzen sich hier: type="email" bringt die passende Tastatur, autocomplete="email" sorgt dafür, dass der Browser eine bereits gespeicherte Adresse vorschlägt. Bei der Postleitzahl bleibt type="text" — wie oben beschrieben würde type="number" führende Nullen verwerfen; inputmode="numeric" holt trotzdem den Ziffernblock auf mobilen Geräten.

Damit Sie nicht bei jedem Feld neu überlegen müssen, welcher Wert passt: eine Übersicht der wichtigsten autocomplete-Werte, gruppiert nach Bereich.

Name

name, given-name, family-name

Kontakt

email, tel

Adresse

street-address, postal-code, address-level2 (Ort), country

Konto

username, new-password, current-password, one-time-code

Sonstiges

bday, organization, off

Eine ausführliche Übersicht aller Werte bietet die MDN-Referenz zum autocomplete-Attribut (öffnet in neuem Tab).

Fehlermeldungen: Klar sagen, was fehlt

„Fehler: Bitte füllen Sie alle Felder korrekt aus.“ Eine Meldung, sonst nichts. Und schon beginnt das Raten: Welches Feld war falsch? Was genau fehlt? Was wird überhaupt erwartet? Hilfreiche, konkrete Fehlermeldungen sind deshalb für alle wichtig, nicht nur für Menschen mit Behinderung.

Eine gute Fehlermeldung steht direkt beim betroffenen Feld, zeigt den Fehler nicht nur über Farbe an und sagt eindeutig, was fehlt oder wo das Problem liegt: die falsche Adresse, das fehlende Pflichtfeld Geburtsdatum, die Mindestlänge im Freitext. Geben Sie dem Feld mit, was Sie bei der Eingabe erwarten, dann füllen Nutzende es auch beim ersten Versuch richtig aus.

Bei einer direkten Live-Validierung gilt dasselbe: Teilen Sie sofort mit, was genau fehlt und was zu tun ist, um das Feld korrekt auszufüllen. Besonders hilfreich wird es, wenn Sie das erwartete Format schon im Beschreibungstext oder als Hilfetext angeben, bevor der Fehler überhaupt auftritt.

Ein Datumsfeld mit Hilfetext und Fehlermeldung, über aria-describedby verknüpft — hier bewusst als type="text", damit der Format-Hinweis eine Funktion hat (ein nativer type="date"-Picker gibt das Format selbst vor und bräuchte ihn nicht):

<label for="geburtsdatum">Geburtsdatum</label>
<input
    type="text"
    id="geburtsdatum"
    name="geburtsdatum"
    aria-describedby="geburtsdatum-hinweis geburtsdatum-fehler"
    aria-invalid="true"
    required
/>
<p id="geburtsdatum-hinweis">Format: TT.MM.JJJJ</p>
<!-- Meldungstext erst per JavaScript einfügen, sobald der Fehler auftritt -->
<p id="geburtsdatum-fehler" role="alert">Bitte geben Sie ein gültiges Geburtsdatum ein.</p>

aria-describedby verknüpft Hilfetext und Fehlermeldung fest mit dem Feld, Screenreader lesen beides beim Fokussieren automatisch mit vor, nicht nur das Label. aria-invalid="true" setzen wir dynamisch per JavaScript, sobald ein Fehler vorliegt, nicht schon beim ersten Laden der Seite.

Beim role="alert" kommt es auf das Timing an: Es liest nur vor, was nach dem Laden neu in das Element eingefügt oder dort geändert wird. Steht die Meldung von Anfang an im HTML (wie oben zur Veranschaulichung), bleibt sie stumm — im echten Formular fügen wir den Meldungstext also erst per JavaScript ein, wenn der Fehler auftritt. Und weil dieselbe Meldung zusätzlich über aria-describedby verknüpft ist, geben manche Screenreader sie doppelt aus: einmal als Alarm beim Einfügen, einmal als Beschreibung beim Fokussieren. In der Praxis ist das meist vertretbar; wer es ganz sauber möchte, entscheidet sich pro Meldung für einen der beiden Wege.

Kontraste: Lesbar für alle

Ob Sonnenreflexion auf dem Smartphone-Display, ein geblendeter Monitor oder eine Sehschwäche: Von ausreichendem Kontrast profitieren wir alle. Oft kommt das Argument, es seien nun mal die Markenfarben, dabei lohnt sich fast immer die Prüfung, ob nicht doch eine barrierefreie Kombination möglich ist.

Fließtext steht dabei meist in einem eigenen, oft helleren Farbton als Überschriften. Ein einfacher Tipp: Öffnen Sie die Entwicklungswerkzeuge im Browser, klicken Sie auf den Farbwert eines Elements, es öffnet sich ein Colorpicker, der in der Regel direkt den Kontrast zum Hintergrund anzeigt. So sehen Sie sofort, wie sich schon eine kleine Anpassung auf die Lesbarkeit auswirkt.

Label: Sichtbar und korrekt verknüpft

Formularfelder sollten grundsätzlich ein sichtbares <label> haben. Die programmatisch korrekte Zuordnung hilft vor allem bei Screenreadern und Sprachsteuerung, aber eigentlich profitieren alle: Ein Label, das dauerhaft sichtbar bleibt, zeigt jederzeit, was in ein Feld gehört, auch nach dem Klick hinein. Das erleichtert die Fehlersuche und macht Formularfelder eindeutig identifizierbar.

Ein placeholder sollte deshalb nur Beispiele oder Formatierungshinweise transportieren, niemals das Label ersetzen. Für zusätzliche Hinweise eignet sich ein separater Hilfetext ohnehin besser, weil er nicht verschwindet, sobald man zu tippen beginnt.

Ein Label, korrekt per for/id verknüpft, mit Formatierungshinweis als Placeholder statt als Ersatz fürs Label:

<label for="telefon">Telefonnummer</label>
<input type="tel" id="telefon" name="telefon" placeholder="z. B. 0441 12345678" />

Die for/id-Verknüpfung sorgt dafür, dass ein Klick auf das Label den Fokus ins Feld setzt und Screenreader beim Fokussieren automatisch „Telefonnummer“ ansagen. Der placeholder zeigt hier nur ein Beispielformat, ersetzt aber nicht das sichtbare Label und verschwindet auch nicht, sobald man zu tippen beginnt.

Kleine Änderungen, große Wirkung

Die Beispiele zeigen: Eine barrierefreiere Umsetzung braucht nicht zwingend großen Umbau, lange Konzeptionsrunden oder Sonderlösungen. Oft reicht ein einzelnes Attribut oder eine einzige Codezeile. Am Ende profitieren wir alle davon, meistens sogar, ohne es als „barrierefrei“ wahrzunehmen, einfach weil es uns beim Nutzen hilft.