Infos zur Barrierefreiheit für:

Der korrekte Aufbau eines barrierfreien Formulars

Auf fast jeder Webseite wird mindestens ein Formular genutzt um zum Beispiel eine Suche zu starten oder als Kontaktformular zu dienen. Trotz dieser großen Verbreitung, entsprechen die meisten Formulare nicht den HTML-Richtlinen, geschweige denn, dass sie barrierefrei wären. Dabei ist es gar nicht so schwer, ein barrierefreies Formular zu gestalten.

Eindeutige Zuordnung der Beschreibung zu den Kontrollfeldern

Eine der Grundvoraussetzungen für ein barrierefreies Formular ist die Zuordnungsmöglichkeit von Beschreibungen zu den jeweiligen Kontrollelementen (Eingabefelder, Auswahlfelder, Checkboxen und so weiter). Diese Zuordnung wird mit dem Element <label> und den Attributen for und id (im Kontrollfeld) erreicht. Eine korrekte Zuordnung am Beispiel eines Eingabefeldes sieht wie folgt aus:

<label for="geb_ort">Geburtsort: </label>
<input type="text" name="geb_ort " id="geb_ort" size="40">

Durch diese Zuordnung kann das zugehörige Eingabefeld direkt von der Beschreibung aus anvisiert werden. Dies ist vor allem für blinde Nutzer eine wichtige Hilfe, da sie so nicht irrtümlich Eingaben in falsche Felder machen, beziehungsweise raten müssen, welches Kontrollfeld zu welcher Beschreibung gehört.

Linearisierbarkeit und Klarheit der Hinweise

Denken Sie bei der Platzierung der Formularelemente immer daran, dass zusammengehörende Informationen nicht über das Formular verstreut werden dürfen. Es nützt einem Blinden zum Beispiel nichts, wenn Sie neben Feldbeschreibungen jeweils einen Stern schreiben, aber erst unter dem Formular erklärt wird, dass der Stern auf Pflichtfelder hinweist. Sein Vorlesegerät wird ihm diese Information erst mitteilen, wenn das gesamte Formular bereits vorgelesen wurde. Vermutlich hat der Nutzer dann schon auf die Absendefläche gedrückt und muss sich nun mit Warnhinweisen herumschlagen, weil er nicht alle Pflichtfelder ausgefüllt hat.

Achten Sie daher darauf, dass sich wichtige Informationen immer möglichst vor dem jeweiligen Kontrollfeld befinden. Aber das alleine nützt noch nicht viel, wenn diese Hinweise nicht leicht verständlich sind. Das gern genutzte Beispiel mit dem Stern als Zeichen für ein Pflichtfeld, ist im Sinne der Barrierefreiheit ein unklarer Hinweis. Es ist eindeutiger, wenn bei jeder Beschreibung für ein Pflichtfeld statt einem Stern direkt das Wort Pflichtfeld steht. Der Nutzer muss so nicht erst irgendwo nach einer Erklärung für den Stern suchen, sondern bekommt unmissverständlich mitgeteilt, dass er dieses Feld ausfüllen muss.

Ersparen Sie Ihren Nutzer Fehleingaben indem sie ihnen bei Feldern die eine ganz bestimmte Form der Eingabe voraussetzen, einfach verständliche Anweisungen geben. Für die Eingabe eines Datums wäre der Hinweis „Eingabe nach dem Schema TT.MM.JJJJ, zum Beispiel: 18.12.2006“ sehr hilfreich, da sonst ein Nutzer möglicherweise den Monat ausschreiben und somit eine Fehlermeldung provozieren würde.

Fokus-Hervorhebung bei Kontrollfeldern

Wenn sich ein Nutzer per Tastatur durch das Formular bewegt (mit der Tabulator-Taste), ist es optisch nicht immer sofort erkennbar in welchem Feld er sich soeben befindet. Diesen Umstand können Sie beheben, indem Sie per CSS das Aussehen von Kontrollfeldern ändern, sobald sich darauf der Fokus eines Nutzers befindet. Eine einfache Regel hierfür könnte wie folgt aussehen: 

input:hover, input:active, input:focus, 
select:hover, select:active, select:focus
textarea:hover, textarea:active, textarea:focus {
    background-color: #F3F1F4;
    border: 3px solid #ccc;
}

Durch diese Form der Kennzeichnung wird das entsprechende Feld mit einer anderen Hintergrundfarbe als im normalen Status angezeigt und erhält zusätzlich noch einen auffälligen Rand. Natürlich können Sie die Art der Hervorhebung mit weiteren CSS-Angaben noch detailierter steuern. Achten Sie dabei aber immer darauf, dass mindestens eine Angabe sich vom Normalstatus nicht nur durch Farbänderung darstellt (in diesem Fall das Hinzufügen eines breiten Randes der im Normalzustand nicht existiert).

Gruppierung per <fieldset>

Bei großen Formularen macht es Sinn, die einzelnen Kontrollelemente entsprechend ihrem Sinn nach Gruppen zu sortieren. So würde es zum Beispiel Sinn machen, wenn alle Pflichtfelder in einer Gruppe sind und alle optionalen Eingaben in einer anderen Gruppe. Oder Sie fragen bei einem Formular erst ab, für welche Themen der Nutzer die Zusendung von Informationsmaterial wünscht und gruppieren dann die Abfrage seiner Adressdaten in einem eigenen Feld.

Wenn Sie mit <fieldset> eine Gruppierung erstellt haben, müssen Sie dem Nutzer natürlich noch klar machen, welche Inhalte hier gruppiert wurden. Sie müssen der Gruppe daher mit dem Element <legend> eine Beschreibung zuweisen. Ein beispielhaftes Formular könnte dann in Kurzform so aussehen: 


<form action="" method="post">
  <fieldset>
    <legend>Gewünschte Informationen</legend>
      Platz für die passenden Kontrollelemente zur Informationsabfrage
  </fieldset>

  <fieldset>
    <legend>Ihre Daten</legend>
      Platz für passende Kontrollelemente zur Abfrage der Adressdaten
  </fieldset>

  <input type="submit" value="Formular absenden" name="submit">
</form>

Wie sieht es mit tabindex, accesskeys und der Vorbelegung von Eingabefeldern aus?

Sie werden zwar in der Barrierefreien Informationstechnik Verordnung (BITV) und ähnlichen Regelwerken zur Umsetzung der Barrierefreiheit gefordert, aber ich lehne diese Techniken ab. Regelwerke sind gut, aber in diesem Fall handelt es sich um stark veraltete Vorgaben deren Sinn inzwischen durch viele bekannt gewordene Nachteile mehr als nur fraglich ist. Ich werde hier kurz zusammengefasst erläutern, wo ich einige der Probleme mit diesen Techniken sehe. Für Details finden Sie am Ende dieses Artikel Links zu Beiträgen auf anderen Webseiten die sich ausgiebig mit den einzelnen Punkten beschäftigen.

Sprungvorgaben durch das tabindex-Attribut

Diese Funktion legt fest, in welcher Reihenfolge der Nutzer durch das Formular navigiert. Das Problem damit ist jedoch, dass diese Festlegung gleichzeitig verhindert, dass ein Nutzer regulär mit der Tastatur durch die Webseite navigieren kann. Um diese Art der Navigation wieder zu ermöglichen, müsste dann die gesamte Webseite mit tabindex versehen werden. Zudem stellt sich die Frage, woher der Anbieter der Webseite so genau weiß in welcher Reihenfolge der Besucher die Seite navigieren möchte. Ich finde es daher sinnvoller die Webseite gut linearisiert aufzubauen und dem Besucher mit Sprunglinks die Möglichkeit zu geben bei Bedarf Abschnitte direkt anzuvisieren.

Nutzung des accesskey-Attributs

Die Idee bei Access Keys ist, dass Besucher die Möglichkeit erhalten wichtige Funktionen / Links durch bestimmte Tastaturkürzel direkt anzuvisieren. Wenn der Besucher zum Beispiel gerade einen längeren Text liest und dabei ein Wort entdeckt, das er nicht kennt, könnte er mit dem entsprechenden Tastaturkürzel direkt zum Link für das Glossar springen um auf diese Seite zu wechseln.

Ein Problem hierbei ist, dass vorausgesetzt wird, dass der Besucher diese Tastaturkürzel kennt. Da jeder Anbieter einer Webseite diese Kürzel beliebig definieren kann, muss der Nutzer erst herausfinden mit welchen Tastaturkürzeln er welche Funktionen / Links erreichen kann. Es reicht also definitiv nicht, dass auf der Webseite mehrere Access Keys eingebaut werden, ohne den Nutzer darauf hinzuweisen, dass es diese Funktion gibt und welches Kürzel zu welchem Ergebnis führt.

Bei weitem das größte Problem ist aber die Tatsache, dass diese Kürzel bereits existierende Funktionen in Vorlesegeräten oder Browsern überdecken können. So kann der Nutzer dann möglicherweise zwar mit einem bestimmten Kürzel das Glossar anvisieren, aber dafür wichtige Funktionen in seinem Vorlesegerät nicht mehr aktivieren.

Vorbelegung von Eingabefeldern

Diese Forderung entstammt der Annahme, dass dadurch für Benutzer von Hilfsprogrammen der Umgang mit einem Formular erleichtert wird. Der Benutzer würde ein Eingabefeld leichter erkennen, da sich darin bereits Text befindet, der nochmal eindeutig darauf hinweist, welche Art von Eingabe erwartet wird. Das Problem hierbei ist, dass sich diese Annahme nicht als richtig erwiesen hat. Viele Programme markieren den vorbelegten Text automatisch anstatt ihn vorzulesen, oder die Benutzer bemerken nicht, dass es in einem Feld eine Vorbelegung gibt und löschen sie nicht, bevor sie ihre eigene Eingabe machen. Daraus resultierend kann es auch zu Fehlermeldungen kommen, wenn die Plausibilität einer Eingabe überprüft wird.

Eine erste Lösung für dieses Problem erfanden findige Programmierer indem sie Regeln für die Vorbelegung per Javascript hinterlegten. So wurde sie automatisch ausgeblendet sobald der Fokus direkt im Eingabefeld lag. Das Problem dieser Technik ist, dass sie nur funktioniert wenn Javascript beim Nutzer aktiviert ist. Falls es deaktiviert ist, bleibt die Vorbelegung weiterhin wie beim ursprünglichen Problem bestehen. Zudem erreicht diese Technik Nutzer von Vorlesegeräten nicht, da die Vorbelegung gelöscht wird bevor das Programm sie vorlesen kann.

Ich vertrete daher die Meinung, dass die Vorbelegung von Eingabefeldern mehr Probleme bewirkt anstatt wirklich zu helfen. Es ist sinnvoller eine eindeutige Verbindung zwischen der Beschriftung und dem zugehörigen Kontrollfeld herzustellen. Falls es wirklich unklar sein sollte, welche Eingabe in ein Feld erwartet wird, bedeutet das nur, dass die Beschriftung noch eindeutiger verfasst werden muss.

zum Seitenanfang