EfA 2006 – Teil 5: BITV-Selbstbewertung

Vorab etwas Grundsätzliches

Bei aller Kritik an einzelnen Details der BITV, das liegt in der Natur des Internets,sie ist als politische Richtlinie unentbehrlich. Weniger als technisch umsetzbare Richtlinie für Webentwickler, sondern viel mehr als Signal, dass es auch im World Wide Web Menschen mit Behinderung gibt, die an der allgemeinen Entwicklung teilhaben wollen.

Versetzen wir uns einen Moment zurück in die 90er Jahre. Wenn damals die Sprache auf das Thema ›Barrierefreies Internet‹ kam, war die übliche Antwort: »Wie, Blinde? Was machen die denn im Internet?« Das hat sich zum Glück mittlerweile geändert, und das ist sicher in weiten Teilen der Existenz der BITV zu verdanken. Sie hat das Thema erstmalig in den Fokus der Fachleute gerückt, in deren Verantwortung es liegt, den Zugang und die Nutzung für alle potenziellen Nutzer sicherzustellen. Wie sich in vielen Tests zeigte hat der Zwang, sich mit Qualitätsstandards zu befassen, zu einer deutlichen Verbesserung der Angebote des Bundes und vieler Länder geführt.

Bei einzelnen Anforderungen der Verordnung hingegen kann man kein einheitliches Urteil zu deren Sinnhaftigkeit und Umsetzbarkeit fällen. Natürlich sind die grundlegenden Prinzipien eines barrierefreien Angebotes immer gleich, egal welche Versionsnummer die BITV oder auch deren Vorlage in Form der internationalen Web Content Accessibility Guidelines (WCAG) tragen mag. Um die kommenden WCAG 2.0 zu zitieren:

• Inhalte müssen wahrnehmbar sein
• Benutzerschnittstellen im Inhalt müssen bedienbar sein
• Inhalte und Bedienelemente müssen verständlich sein
• Inhalte sollten robust genug sein, um mit aktuellen und zukünftigen Benutzeragenten zu arbeiten (inklusive assistiver Hilfsmittel)

Hierbei handelt es sich sozusagen um die universellen Prinzipien der barrierefreien Informationstechnik – diese müssen erfüllt sein, wenn man ein Angebot als barrierefrei bezeichnen will. Wie diese Prinzipien nun mit Leben, d. h. mit umsetzbaren Vorgaben für Konzepter, Gestalter, Texter und Techniker, gefüllt werden steht auf einem anderen Blatt. Der aktuelle Stand der WCAG 2.0 weist leider in weiten Teilen in eine Richtung, die an ihrer Umsetzbarkeit in eine eventuelle BITV 2.0 erhebliche Zweifel aufkommen lassen.

Bleiben also nur die bestehenden Vorgaben der BITV bzw. der WCAG 1.0: ein Teil der Vorgaben wurde von der technischen Entwicklung eingeholt. Im Original finden sich eine Reihe von Checkpunkten, die als Interims-Lösungen gekennzeichnet sind (»Until user agents … « im englischen Original bzw. »bis Benutzeragenten … « in der deutschen Übersetzung), so zum Beispiel die Richtlinien 7 und 10.

In der BITV fehlt diese Einschränkung aus formaljuristischen Gründen, dafür hat der Gesetzgeber als Ersatz die 3 Jahre / 5 %-Regel in der Begründung zur BITV eingeführt. Diese besagt:

»Die Sicherstellung der Verwendbarkeit assistiver Technologien und Browser ist insbesondere dann unverhältnismäßig, wenn die assistiven Technologien [sic] und Browser älter als drei Jahre sind und der Verbreitungsgrad in der einschlägigen Benutzergruppe unter 5 % liegt.«

Nur – wer legt fest, ob diese Werte bei problematischen assistiven Hilfsmitteln erreicht sind? Die Verbreitung und die Marktanteile assistiver Hilfsmittel wie z. B. Screenreader kennen wir nicht; falls Sie eine kennen freuen wir uns über eine kurze Nachricht.

Die Streichliste

Im Anhang D des Entwurfs der WCAG 2 findet sich eine Auflistung der alten »until user agents …«-Klauseln, die nach einhelliger Expertenmeinung einen Stand erreicht haben, an dem sie als erledigt gelten können: Beispiele hierfür sind die Checkpunkte 1.5 (Textäquivalente für Imagemaps), 10.2 (explizite Labels), 10.3 (Textfluss in Layouttabellen), 10.5 (Trennzeichen zwischen Links), und unser aller Liebling 10.4 (Platzhalter in Formularen).

Andere sind deutlich abgeschwächt worden, wie die Checkpunkte 3.4 (skalierbare Schriften), 7.3 (Einfrieren von Bewegungen), 13.6 (Skip Links für alles und jedes) und 3.2 (Validierung).

Die überholten Checkpunkte haben wir bei unserem letzten Relaunch nicht mehr berücksichtigt. Auch im BIK-Test werden eine ganze Reihe dieser Punkte nicht mehr geprüft und der Wegfall entsprechend begründet.

Zum Abschluss noch eine Liste von Dingen, die bei der letzten Überarbeitung unserer Seiten ebenfalls entfallen sind:

tabindex

Das tabindex-Attribut zur Veränderung der Tabreihenfolge bei Tastaturbedienung haben wir hier eigentlich noch nie benutzt und können dies auch nicht wirklich empfehlen. Mehr dazu im Artikel »Widersprüche in der Barrierefreiheit – Tastaturbedienung und Tabindex«.

accesskey

Das accesskey-Attribut hatten wir in den Anfangstagen dieser Site im Einsatz, uns aber sehr schnell wieder davon getrennt. Weitere Informationen zu diesem Thema finden Sie in den Artikeln »Accesskeys and Reserved Keystroke Combinations«, »Using Accesskeys - Is it worth it?« und »Access + Key Still Equals Accesskey«.

Breadcrumbs

Auch wenn sich Breadcrumbs streng genommen nicht aus den Vorgaben zur Barrierefreiheit ableiten lassen, so werden sie doch oftmals als Best Practice empfohlen. Wir haben beim vergangenen Relaunch aus einer ganzen Reihe von Gründen auf Breadcrumbs verzichtet. Zum einen sind Breadcrumbs in Form von Pfadangaben kaum brauchbar, wenn es sich um dynamische Strukturen handelt und eine Zuordung in einen einzigen Pfad unmöglich ist. Wir müssten also eine Entscheidung für den Nutzer treffen, die nicht notwendigerweise dessen Sichtweise wiederspiegelt.

Zum anderen würden die Breadcrumbs auf Grund der flachen Struktur der Seiten dann doch nur das wiedergeben, was bereits an anderer Stelle im Dokument in der Navigation angeboten wird. Man erhält also im besten Fall eine Verdopplung, im schlimmsten Fall aber sogar eine Verwirrung des Nutzers. Weitere Informationen zu diesem Thema finden Sie in einer Veröffentlichung von Spring S. Hull von der Wichita State University: »Influence of Training and Exposure on the Usage of Breadcrumb Navigation«.

Die Wackelkandidaten

Validierung

Die Bedingung 3.2 der BITV besagt:

»Mittels Markup-Sprachen geschaffene Dokumente sind so zu erstellen und zu deklarieren, dass sie gegen veröffentlichte formale Grammatiken validieren.«

Jede Seite bei ›Einfach für Alle‹ wird vor der Veröffentlichung mit einem Validator überprüft. Zusätzlich haben wir Mechanismen installiert, die uns bei auftretenden Fehlern per RSS informieren. Trotzdem kann es passieren, dass wir einen Fehler nicht bemerken. Grenzen der Validität gibt es in unseren Tutorials, wenn bewusst fehlerhafter Code zum Zwecke der Verdeutlichung eingesetzt wird.

Sprachauszeichnung

Die Bedingung 4.1 der BITV besagt:

»Wechsel und Änderungen der vorherrschend verwendeten natürlichen Sprache sind kenntlich zu machen.«

Wir bemühen uns bereits bei der Erstellung der Inhalte, sämtliche Sprachwechsel auszuzeichnen. Da uns kein Verfahren bekannt ist, dass diese Aufgabe ohne manuelle Eingriffe zuverlässig erledigt, sind wir hier auf Handarbeit angeweisen. Dabei kann es naturgemäß zu Fehlern oder Versäumnissen kommen. Wir bemühen uns aber, sämtliche Worte, bei denen es durch eine falsche Aussprache zu Verwechselungen kommen könnte (z. B. Tag im Sinne von Wochentag oder HTML-Tag), korrekt auszuzeichnen.

Abkürzungen

Die Bedingung 4.2 der BITV besagt:

Abkürzungen und Akronyme sind an der Stelle ihres ersten Auftretens im Inhalt zu erläutern und durch die hierfür vorgesehenen Elemente der verwendeten Markup-Sprache kenntlich zu machen.

Zur Auszeichnung von Abkürzungen und Akronymen verwenden wir die dafür vorgesehenen HTML-Elemente abbr> und acronym>. Problematisch ist hingegen der erste Teil der Bedingung, da niemand vorhersehen kann, wo das »erste Auftreten« tatsächlich stattfindet. In unserem Weblog stehen fast täglich neue Meldungen – was heute noch »erstes Auftreten« ist, kann morgen schon durch drei neuere Meldungen ersetzt worden sein.

Statt dessen versuchen wir, nicht-gängige Abkürzungen und Akronyme im Kontext zu erläutern, d. h. ihre Bedeutung in lesebarem Text und nicht nur in title-Attributen wiederzugeben. Dass dies nicht bei sämtlichen Vorkommen von Abkürzungen sinnvoll ist versteht sich von selbst, da ansonsten der Lesefluß unnötig durch immer wiederkehrende gleichlautende Erklärungen unterbrochen würde.

Damit endet unsere Relaunch-Serie

Die Fortsetzung folgt in der Überarbeitung unserer BITV-Serie, in der auch weitere Begründungen für den Wegfall von Checkpunkten nachzulesen sind.

Diskutieren Sie mit!

Wir würden gerne Ihre Meinung wissen: Teilen Sie uns Ihre Erfahrungen mit und diskutieren Sie diesen Artikel mit anderen Experten.