Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Barrierefreiheit: Mehrfachkennzeichnung in der Praxis – Teil 3

Barrierefreiheit: Mehrfachkennzeichnung in der Praxis – Teil 3

Dritter Teil unseres Auszugs aus dem Buch »Barrierefreiheit verstehen und umsetzen« von Kerstin Probiesch und Jan Eric Hellbusch. Siehe auch Teil 1 über Mehrfachauszeichnungen für Links und die Navigation und Teil 2 über Inhalte.

3 Formulare

Bei Formularen gibt es über die bereits aufgeführten Techniken hinaus zwei Besonderheiten: Zum einen wird oft zwischen Pflichtfeldern und optionalen Feldern unterschieden, zum anderen muss die Fehlerbehandlung besonders beachtet werden.

3.1 Pflichtfelder

Pflichtfelder werden gerne über Farbe hervorgehoben. Wie für andere Seitenelemente ist auch hier die Verwendung von Farbe empfehlenswert. Die farbige Kennzeichnung von Pflichtfeldern sollte jedoch durch zusätzliche, sichtbare Merkmale ergänzt werden. Die notwendigen Textangaben im LABEL-Element wurden bereits im Abschnitt »Kennzeichnung von Pflichtfeldern« [im Buch] vorgestellt. Einige Möglichkeiten sind das Asterisk, ein Text oder ein grafisches Symbol.

Wenn Pflichtfelder über Farbe gekennzeichnet sind, dann muss eine dieser Möglichkeiten genutzt werden. Dabei geht es nicht um die Zugänglichkeit für Screenreader-Nutzer, sondern ausdrücklich um Sehende bzw. Sehbehinderte.

Wenn beispielsweise ein Asterisk zusätzlich zur Farbe eingesetzt wird, dann sollte bei den (ebenfalls empfehlenswerten) Ausfüllhilfen ein Hinweis der Art »Bitte füllen Sie alle gelben und mit einem Asterisk (*) gekennzeichneten Felder aus« stehen. Das Asterisk ist zwar Konvention, aber wegen der geringen Größe des Zeichens ist es möglicherweise für Menschen mit einer Sehbehinderung nicht erkennbar.

Statt oder in Ergänzung eines solchen Zeichens empfiehlt sich zusätzlicher Text. Pflichtfelder können im zugehörigen LABEL-Element durch »Pflichtfeld« bzw. optionale Felder durch »optional« gekennzeichnet werden:

  1. <p><label for="wert">Mobiltelefon (optional)</label>
  2. <input name="handy" id="wert" type="text" /></p>

Listing 5: Mehrfachkennzeichnung für Pflichtfelder durch Textergänzung

Eine weitere Technik der Mehrfachkennzeichnung besteht in der Verwendung strukturierender HTML-Elemente. Wenn die Beschriftung eines Pflichtfelds über STRONG ausgezeichnet wird, dann wird sie fett dargestellt. Formal genügt das den Anforderungen. In der Praxis kommt es darauf an, ob ein Nutzer mit einer Seheinschränkung dies gut erkennt oder nicht.

Die Vermittlung von Informationen über Farbe allein ist besonders dann kritisch, wenn Inhaltstypen voneinander unterschieden werden sollen. Das folgende Beispiel zeigt die Vermittlung einer wichtigen Information allein über Farbe im Administrationsbereich von DokuWiki (vgl. auch Abb. 8 bzw. 9): »Einstellungen mit einem hellroten Hintergrund sind gesichert und können nicht mit diesem Plug-in verändert werden, Einstellungen mit hellblauem Hintergrund sind Voreinstellungen, weiß hinterlegte Felder zeigen lokal veränderte Werte an. Sowohl die blauen als auch die weißen Felder können verändert werden.«

Abb. 8: Administrationsbereich in einem DokuWiki mit farblicher Kennzeichnung verschiedener Typen von Steuerelementen
Abb. 8: Administrationsbereich in einem DokuWiki mit farblicher Kennzeichnung verschiedener Typen von Steuerelementen

Bei benutzerdefinierten Bildschirmfarben ist dieses Formular nicht mehr bedienbar:

Abb. 9: Bei benutzerdefinierten Farben ist der Administrationsbereich des DokuWiki nicht mehr bedienbar.
Abb. 9: Bei benutzerdefinierten Farben ist der Administrationsbereich des DokuWiki nicht mehr bedienbar.

3.2 Fehlermeldungen

Fehlermeldungen müssen unter dem Gesichtspunkt der Mehrfachkennzeichnung sorgfältig gestaltet werden. Fehlerbeschreibungen und Hilfen müssen nicht nur vorhanden, sondern auch wahrnehmbar sein. Es sind die Hinweise, Fehlermeldungen und Ausfüllhilfen, die es Nutzern ermöglichen, Logins, Bestellungen oder auch Online-Banking erfolgreich vornehmen bzw. abschließen zu können.

Eine über Farbe vermittelte Fehlermeldung wird deswegen durch zusätzliche Formatierungen (Schriftschnitt), Symbole oder Rahmen ergänzt. Hinweise wie »Fehlermeldungen in roter Farbe« sind nicht barrierefrei. Eine bessere Fehlermeldung ist: »Falsche Eingaben sind in Rot und fetter Schrift gekennzeichnet«.

Symbole für Fehlermeldungen sind ebenfalls positiv zu bewerten. Allerdings müssen allein stehende Symbole (ohne ergänzenden Text) im HTML stehen und dürfen nicht mittels CSS generiert werden, da sie wichtige Informationen transportieren. Außerdem müssen sie allgemein verständlich sein, wie z.B. ein Dreieck mit einem Ausrufezeichen.

Eine interessante Technik zur Mehrfachkennzeichnung fehlerhafter Eingaben wird beim Webangebot von »Sozialnetz Hessen« verwendet. Hier wird bei Fehleingaben das auch bei benutzerdefinierten Farbeinstellungen sichtbare FIELDSET-Element in Kombination mit LEGEND eingesetzt. Die Rahmen des FIELDSET-Elements werden dabei nicht unterdrückt und die Fehlermeldung hebt sich somit vom umgebenden Inhalt ab:

Abb. 10: In drei von vier Feldern werden fehlende Eingaben mithilfe von FIELDSET und LEGEND hervorgehoben.
Abb. 10: In drei von vier Feldern werden fehlende Eingaben mithilfe von FIELDSET und LEGEND hervorgehoben.

Mit dieser Form der Mehrfachkennzeichnung ist die Sichtbarkeit der fehlerhaft ausgefüllten Eingabefelder für alle Nutzer gleichermaßen gewährleistet. Sie sind bei benutzerdefinierten Farben erkennbar und zudem mit Screenreadern aufgrund der verwendeten HTML-Technik eindeutig identifizierbar.

Das Buch

Cover: Barrierefreiheit verstehen und umsetzen

Der Text ist ein Auszug aus »Barrierefreiheit verstehen und umsetzen – Webstandards für ein zugängliches und nutzbares Internet« von Kerstin Probiesch und Jan Eric Hellbusch. Das Buch ist im dpunkt.verlag erschienen. Wir veröffentlichen daraus das Kapitel »Mehrfachkennzeichnung in der Praxis«. Außerdem verlosen wir drei Exemplare.

Kommentare

Florian
am 29.03.2011 - 09:50

Hallo!
Da fällt mir noch ein guter Artikel ein, oder eher einer Artikelserie, die auf praegnanz.de mal verlinkt wurde.
Reine Formsache
Es geht um Formulargestaltung und Usability.

Grüße,
Florian

Permanenter Link

Gunnar Bittersmann
am 29.03.2011 - 12:17

Die Beschriftung als „Pflichtfeld“ bzw. „optional“ könnte auch im Eingabefeld selbst stehen (und verschwinden, wenn der Nutzer etwas eingibt). In HTML5 per @placeholder, in älteren Browsern per label.

Heutige Linktips: The Accessibility of WAI-ARIA, ARIA and Progressive Enhancement

Permanenter Link

Rosi
am 29.03.2011 - 13:35

Hallo,

über barrierefreie Formulare habe ich nun etwas gelernt! :-)

Gruß, Rosi

Permanenter Link
Jan Hellbusch

Jan Hellbusch (Autor)
am 29.03.2011 - 13:42

@Gunnar

Deine beschriebene Methode wäre dann nur für sehende zugänglich. Bei onfocus="entferne_text();" würden Screenreader nicht mitkriegen, was Du denen sagen willst.

Permanenter Link

Gunnar Bittersmann
am 29.03.2011 - 14:26

@Jan: "entferne_text();"?? Bei meiner Methode wird doch eben gerade kein Text entfernt. Du hast sie dir angesehen?
Die Beschriftung steht in einem label-Element, das bei visueller Darstellung hinter (in z-Richtung) dem Eingabefeld liegt, was die Beschriftung durch das Eingabefeld durchscheinen lässt. Beim focus-Event wird das label auf display: none gesetzt. Hm, dadurch lesen Screenreader es nicht mehr?

Permanenter Link

Dominik Strauß
am 29.03.2011 - 14:27

Das klingt ja schonmal sehr interessant. War es allerdings Absicht, dass hier kein Bezug zu ARIA-Attributen wie aria-required genommen wurde? Wenn ja, aus welchem Grund?

Mein empfehlenswerter Link geht in die Schweiz, zu den Leuten von http://www.access-for-all.ch/

Permanenter Link
Jan Hellbusch

Jan Hellbusch (Autor)
am 29.03.2011 - 15:24

@Gunnar

Technik nicht getestet? display:none führt dazu, dass die webfähigen Screenreader was nicht lesen. Nach der Anzahl Deiner Kommentare hätte ich angenommen, dass Dir das bekannt ist?

Permanenter Link

Type-Style
am 29.03.2011 - 15:49

http://video.yahoo.com/watch/4073211/10996186
Mit ein bisschen Aria und ein bisschen Common Sense ist dieses Pflichfeld Problem, kein Problem mehr.

Permanenter Link

Gunnar Bittersmann
am 29.03.2011 - 16:21

@Jan:
Technik nicht getestet?
Nein *schäm*, Barriefreiheit ist für die Plattform, für die ich das entwickelt habe, kein Thema.
Die Technik sollte sich aber auch barrierefrei umsetzen lassen, wenn man die Beschriftung bei visueller Darstellung nicht per display: none (worauf jQuerys hide() hinausläuft) verschwinden lässt, sondern mittels anderer Methoden.

display:none führt dazu, dass die webfähigen Screenreader was nicht lesen.

Meine Frage war eher rhetorisch. ;-)

Permanenter Link

Brigitte Bornemann
am 29.03.2011 - 17:40

Mein heutiger Linktipp und bisheriger Favorit zum Thema barrierefreie Formulare: Artikelserie "Reine Formsache" von Tomas Caspers
http://www.einfach-fuer-alle.de/artikel/barrierefreie-formulare-mit-html...

Permanenter Link
Jan Hellbusch

Jan Hellbusch (Autor)
am 29.03.2011 - 18:13

@Dominik:

Diese Inhalte beziehen sich auf die visuelle "Mehrfachkennzeichnung". ARIA kommt im Buch vor, aber leider nicht so intensiv wie wir es vorhatten. Grund: mangelnde Unterstützung in den Screenreadern. Siehe hierzu auch

http://www.incobs.de/produktinfos/screenreader/webtest_2010/index.php

Permanenter Link

Dominik Strauß
am 29.03.2011 - 18:38

@Jan

Danke für die Information und den interessanten Link :)

Gruß
Dominik

Permanenter Link

Peter
am 30.03.2011 - 07:53

Hoffentlich orientieren sich viele, viele VebdesignerInnen an den Inhalten Eures neuen Buchs und erstellen nur noch barrierefrei Webseiten.

Gruß, Peter

Permanenter Link

Der Caspers
am 30.03.2011 - 09:08

Artverwandt zum Thema Mehrfachkennzeichnung ein ziemlich interessanter Artikel von Henny Swan: Handling repeated adjacent links - http://www.spotlessinteractive.com/articles/accessibility/handling-repea...

Permanenter Link

Friederike von ...
am 30.03.2011 - 09:19

Als Webdesignerin bin ich gerade dabei mich in Sachen Barrierefreiheit weiter zu bilden um auch meine Kunden für das Thema zu sensibilisieren, das momentan mit Verlaub gesagt normalerweise schlichtweg ignoriert wird. Durch die letzten 3 Posts zu dem Buch die ich gerade gelesehbhabe ich wieder einiges dazu gelernt!

Und obwohl zu spät? für die Verlosung hier noch ein Linktip von mir:
http://www.die-barrierefreie-website.de/

Permanenter Link

Steffen Paasch
am 30.03.2011 - 12:42

Nachdem, was ich bisher hier lesen konnte bin ich mehr als gespannt auf die restlichen Inhalte. Meiner Meinung zielt das in Richtung Standardlektüre für Webworker.

Danke für die 3 Previews!

Permanenter Link

Herbert
am 31.03.2011 - 14:58

Barrierefreies Webdesign ist nicht so einfach, vorallem wenn entsprechende Prüf-/Test-Werkzeuge fehlen.

Link zum Thema Barrierefreiheit:

http://www.einfach-fuer-alle.de/

http://www.ohrenblicke.de

Permanenter Link

Lars
am 31.03.2011 - 22:27

Sehr gute Resource zum belesen:

WCAG 2.0 Übersetzungen

Permanenter Link
Nicolai Schwarz

Nicolai Schwarz (Webkraut)
am 01.04.2011 - 00:01

Donnerstag Abend, Mitternacht. Das heißt: Ihr könnt diesen Beitrag gerne weiter kommentieren, aber für das Gewinnspiel zählen nur die bisherigen Kommentare. Wir geben die Gewinner in der kommenden Woche bekannt.

Permanenter Link

Maik
am 07.04.2011 - 10:49

Netter Artikel, ich selbst versuche wenn ich eine Webseite erstelle relativ Barrierefrei zu arbeiten. Ab und an muß man dann aber auch ein paar Kommpromisse eingehen. Aber die Error-Meldung per Fieldset/Legend find ich genial. Und werde das wohl in ein neues Projekt gleich mal ausprobieren wie das im Workflow so an kommt.
Also nochmals Danke für den Artikel.

Permanenter Link

Peter
am 08.04.2011 - 08:11

Zu "Formulare und Fehlerbehandlung".

Da ich alle meine Formulare bzw. die dahinter werkelnden Scripte zusammen mit einer blinden Nutzerin entwickle, verfolge ich diesen Ansatz:

Im Fehlerfall erfolgt eine erste Fehlermeldung bereits im Seitentitel (meta title). Damit erhält der Nutzer assistiver Programme bereits beim Laden der Seite die entsprechende Information.

Details werden dann in einer zusätzlich eingeblendeten Überschrift und einem kurzen Textabsatz unmittelbar am Inhaltsbeginn ausgegeben. Zu diesem kann über die Skiplinks gesprungen werden. Angedruckt werden die Namen der betreffenden Eingabefelder und der aufgetretene Fehler.
Auch hier erhält der Nutzer die notwendigen Informationen zu einem frühestmöglichen Zeitpunkt. Mittels Formularmodus kann dann das Formular angesprungen werden.

Vielleicht ist das nicht der Weisheit letzter Schluß. Den Nutzer über aufgetretene Fehler rechtzeitig zu informieren, finde ich aber richtig.

Allerdings ist das nicht BIENE-tauglich, denn die Fehlermeldung "ist zu weit vom Formular entfernt".

Das ist zwar im konkreten Fall völliger Unsinn, denn ausser der Fehlermeldung und dem Formular gibt es keine weiteren Inhalte, aber es soll erwähnt werden, da diese eigentlich sehr stringente Nutzerführung eben nicht barrierefrei sein soll (oder ist).

Beispiel

Permanenter Link
Jan Hellbusch

Jan Hellbusch (Autor)
am 08.04.2011 - 08:25

@Peter:

Die beschriebenen Methoden sind zwei Möglichkeiten von vielen und beide in den Techniken der WCAG zu finden. Die FIELDSET/LEGEND-Lösung zielt u.a. auch auf den Formularmodus ab, aber natürlich auch auf Sehende und Sehbehinderte. Der Ansatz mit TITLE ist eher nur an Screenreadernutzer ausgerichtet. Letztlich kommt es darauf an, die verschiedenen Nutzergruppen gleichermaßen anzusprechen.

Permanenter Link

Peter
am 08.04.2011 - 09:37

@Jan:

Ich halte ja die beschriebenen Methoden nicht für falsch oder untauglich. Die Hervorhebung des FIELDSET finde ich für "Optiker" sogar sehr nett.

Nur bedingt das natürlich, dass jedes Eingabefeld ein eigenes FIELDSET bekommt. Das hat aber wohl mit der eigentlichen Aufgabe dieses Elementes, nämlich die Strukturierung eines Formulars (Zusammenfassung von Eingabefeldern zu "Funktionseinheiten") nicht mehr viel zu tun. Das "semantische" FIELDSET wird als Gestaltungsmittel mißbraucht, welches dann auch wieder nur für Sehende die Information transportiert.
Dass LEGEND dann die "notwendige alternative Info" ist dazu, dürfte klar sein.

Ob sich die Title-Information wirklich nur an Screenreader-Nutzer richtet, kann man sicher unterschiedlich beurteilen.

Eine entsprechende Fehlermeldung am Seitenbeginn ist dagegen auch für Sehende ausgesprochen nützlich. Besonders dann, wenn sich das Formular irgendwo am Ende einer längeren Seite befindet.

Im Bedarfsfall kann man natürlich von der Fehlermeldung einen Sprung zum Formular abieten. Ein Direktlink zum Eingabefeld wird dann nur schwierig, wenn von der Fehlermeldung mehrere Eingabefelder betroffen sind.

Ich denke die Diskussion zeigt, dass Regeln sicher richtig und notwendig sind. Will man eine Seite auf die Einhaltung von Regeln prüfen, muß man allerdings den Verstand hinzuziehen.

Ein Sprunklink zum unmittelbar folgenden Element ist Unsinn und erfüllt lediglich eine "zu genau formulierte" Regel.

Ich würde mir bei Prüfungen und Beurteilungen mehr die Ausrichtung am Sinn und Nutzen einer Lösung wünschen, die auf den konkreten Fall Rücksicht nimmt.

Wenn also Sehende wie Nichtsehende gleichermaßen mit den notwendigen Informationen versorgt werden, die Bedienung der Seite mit Maus, Tastatur oder assistiven Techs gleichermaßen möglich ist, dabei Redundanz vermieden werden kann und die angebotenen "Hilfestellungen" nicht sinnfrei sind, wäre für mich ein Prüfschritt erfüllt. Weniger kann mehr sein...

Permanenter Link

ednong
am 23.04.2011 - 00:41

Hm,
an was man alles denken sollte, wenn man es gut machen möchte. Einleuchtend. Bei "fetter Schrift" sollte man allerdings zur Hervorhebung keinen anderen Schnitt (=Font) auswählen. So eine Seite habe ich auch mal gesehen. War dann bei mir nicht fett, da ich den Font nicht hatte ;)

Permanenter Link

Die Kommentare sind geschlossen.