deshalb
IE 6 must die

euer Lars

am 24.09.2009 war ich auf dem Symposium Barrierefreies Webdesign in Düsseldorf.

Es konnte in verschiedenen Vorträgen fundiertes Fachwissen in Sachen Webentwicklung mitgenommen werden, das war ja auch bei den ‘hochkarätigen’ Sprechern zu erwarten. Ich persönlich hatte in manchen Beiträge einen größeren Bezug auf Barrierefreies Internet erhofft. Aber Accessibility ist ja nicht nur ein Thema für gehandicapte Menschen. Webseiten sollten ja für alle Personen sinnvoll bedienbar sein.

Hier die ersten Punkte in Sachen best practice im Bereich Internetprogrammierung:

Aus dem Vortrag von Timo Wirth (Teamleiter Frontend Aperto AG) – Formulare sind Gespräche: Mitmachbarrieren im Web 2.0 abbauen

Zur Gestaltung von Fehlermeldungen auf Störungen bei Formulareingaben:
- In der ersten Zeile sollte eine vernünftige Aussage über den aufgetreten Fehler stehen. Damit dies das Erste ist was ein Screenreader vorliest und auch für jedermann das Problem sofort sichtbar ist. Sowie eine deutliche Farbgebung und grafische Anordnung die eine schnelle Informationsaufnahme unterstützt.
- Der Browsertitel der Fehlermeldungsseite sollte das Wort Fehler enthalten.

Die Überprüfung von Eingaben in Formularfelder sollte sofort in der gleichen Zeile durchgeführt werden (Inline Validierung). Wird zum Beispiel überprüft ob eine gültige Emailadresse eingeben wurde, kann direkt nach falscher Eingabe ein Warnhinweis erscheinen, damit ein Screenreader bei Fehlern nicht jedesmal das gesamte Formular erneut vorliest.

Der allseits bekannte * zum Markieren von Pflichtfeldern in Formularen ist überflüssig, da zum Steigern der Nutzbarkeit möglichst nur wirklich erforderliche Daten abgefragt werden sollten. Und Besucher auch nicht mit Seiten voller Eingabefelder genötigt werden.
Erfasse wichtige Daten nebenbei.
Weniger Formulare, weniger Barrieren.

Auszeichnungen nach WAI ARIA (Web Accessibility Initiative’s Accessible Rich Internet Applications) werden auch von Screenreadern sofort verarbeitet. Im Bezug auf Fehlermeldungen zum Beispiel role=’alert’
ARIA ist eine rein semantische Erweiterung für HTML, es werden in dynamischen Webanwendungen Informationen zu Rollen, Eigenschaften und Zuständen der Elemente hinzugefügt. Es macht Webseiten die mit JavaScript und Ajax angereichert sind für behinderte Menschen, besonders Blinde, durch die Screenreader-Kompatibilität, besser zugänglich.
Barrierefreie Web 2.0 Anwendungen mit WAI ARIA
siehe auch Slideshow am Ende dieses Beitrages.

Auch der Einsatz sogenannter CAPTCHAs ist fraglich, diese werden verwendet, um zu entscheiden, ob das Gegenüber ein Mensch oder eine Maschine ist. Um SPAM-Bots auszuschließen.

eine sinnvolle Umsetzung in akustische Formen für Hörbehinderte gibt es nicht und nicht nur Timo Wirth ist der Meinung, das Verhindern von Datenmüll darf nicht auf die Benutzer einer Webseite abgeschoben werden. Dazu gibt es verschiedene Technologien um dieses serverseitig abzufangen.

1. Sinnhaftigkeit prüfen
2. Geschwindigkeit messen

siehe auch

• Captchas sind Blödsinn – Alternativen gegen Spam
• PHP-Skript Bad Behavior (englisch)