Die Kompatibilität von Webseiten mit heutigen und zukünftigen Hilfsmitteln wie Screenreadern, Vergrößerungssystemen, Spracheingaben usw. wird dadurch maximiert, indem Code gemäß Standards geschrieben wird. Darüber hinaus müssen Komponente (Links, Formulare, Widgets usw.) so umgesetzt werden, dass vor allem semantische Informationen (Name, Rolle, Wert) korrekt an Accessibility APIs von Betriebssystemen übertragen werden.
Accessibility-Checkliste: Kompatibel
Diese Accessibility Checkliste hilft bei der Überprüfung einer Webseite auf Konformität zu den Erfolgskriterien der Richtlinie 4.1 der Web Content Accessibility Guidelines (WCAG) 2.0 bzw. den Bedingungen der Anforderung 4.1 der Barrierefreien Informationstechnik-Verordnung – BITV 2.0.
- Eine Validierung von Webseiten mit dem W3C-Validator gilt als Best-Practice. Damit Informationen korrekt in eine Datenstruktur für Hilfsmittel übertragen werden können, genügt allerdings eine Teilvalidierung nach dem Kriterium 4.1.1.
- Komponenten auf einer Webseite (Links, Formulare und Widgets) müssen Name, Rolle und Wert an die Accessibility-API des Betriebssystems übertragen, damit Nutzer von Hilfsmitteln die Komponenten identifizieren können. Der Name (die Bezeichnung)
- ist bei Links entweder der Linktext oder das title-Attribut und kann mit ARIA-Attributen ergänzt oder ersetzt werden,
- ist bei Formularelementen eine verknüpfte Beschriftung (möglich sind aber auch u.a. ein title-Attribut, Text etwa in <button> oder ein value-Attribut etwa in <input type=“submit“>) und kann mit ARIA-Attributen ergänzt oder ersetzt werden und
- wird in Widgets normalerweise durch ARIA-Attribute (aria-label, aria-labelledby und/oder aria-describedby) bestimmt.
Die Rolle wird
- bei Links entweder durch <a href> oder durch Zuweisung der Rolle mit dem role-Attribut
- bei Formularen entweder durch den Einsatz der in HTML vorgesehenen Elemente für Formulare oder durch Zuweisung der Rolle mit dem role-Attribut) und
- bei Widgets durch Zuweisung der Rolle mit dem role-Attribut
bestimmt. Der Wert einer Komponente wird ermittelt
- anhand des Werts des href-Attributs (bei Links),
- anhand des Inhalts des Eingabefelds, des ausgewählten Eintrags in Auswahllisten, der aktivierten Option bei Checkboxen oder Radio-Buttons oder der ARIA-Attribute (bei Formularelementen) oder
- anhand von ARIA-Attributen, die Zustände und Eigenschaften der Komponenten bestimmen (bei Widgets).
- Frames benötigen ein title-Attribut zur Identifizierung des Frame-Inhalts.
- Komponenten mit eigener Benutzungsstelle (z.B. in Flash, PDF oder Java) benötigen Name, Rolle und Wert. Diese können i.d.R. nur in spezieller Software (z.B. Adobe Acrobat Professional) zugewiesen werden.
Weitere Accessibility-Checklisten
- Anforderung 1.1: Textalternativen
- Anforderung 1.2: Zeitbasierte Medien
- Anforderung 1.3: Anpassbar
- Anforderung 1.4: Unterscheidbar
- Anforderung 2.1: Per Tastatur zugänglich
- Anforderung 2.2: Ausreichend Zeit
- Anforderung 2.3: Anfälle
- Anforderung 2.4: Navigierbar
- Anforderung 3.1: Lesbar
- Anforderung 3.2: Vorhersehbar
- Anforderung 3.3: Hilfestellung bei der Eingabe
- Anforderung 4.1: Kompatibel
Graue Haare
Dieser Beitrag ist Teil der Serie "Accessibility-Checkliste gegen graue Haare". Zuletzt musste ich mich mit der Barrierefreien Informationstechnik-Verordnung (BITV) 2.0 auseinandersetzen, die gerne als deutsche Fassung der Web Content Accessibility Guidelines (WCAG) 2.0 angesehen wird. Die BITV 2.0 weicht allerdings erstaunlich oft von den WCAG 2.0 ab.
Im Zuge der Untersuchung musste ich mich auch mit dem sogenannten "BITV-Test" der DIAS GmbH - eine Prüfanleitung für barrierefreies Webdesign - auseinandersetzen, um seine Zuverlässigkeit zu bewerten. Auffällig war insbesondere die deutliche Abweichung des "BITV-Tests" von der BITV 2.0 (und den WCAG 2.0).
Diese beiden Umstände haben mich dazu veranlasst, graue Haare für die BITV 2.0 und den "BITV-Test" wie folgt zu vergeben:
Ein graues Haar gibt es für die BITV 2.0, wenn eine Anforderung oder eine Bedingung inhaltlich von den WCAG 2.0 abweicht. Ein graues Haar gibt es auch für einzelne Prüfschritte im "BITV-Test", wenn
- im Prüfschritt die Bedingung aus der BITV 2.0 nicht geprüft werden kann (z.B. weil nur eine Best-Practice-Technik geprüft wird),
- im Prüfschritt etwas geprüft wird, das nicht in der BITV 2.0 verlangt wird und
- der Prüfschritt so allgemein gehalten wird, dass er nicht zuverlässig eingesetzt werden kann.
Für solche Anforderungen und Bedingungen der BITV 2.0, die im Einklang mit den Richtlinien und Erfolgskriterien aus den WCAG 2.0 sind, und solche Prüfschritte im "BITV-Test", die eine Überprüfung der BITV 2.0 zulassen, gibt es drei farbige Haare und ein "OK".
BITV 2.0 (Anlage 1) und WCAG 2.0
Die Anforderung der BITV 2.0 zu „Kompatibel“ weicht ein wenig von der entsprechenden Richtlinie in den WCAG 2.0 ab, indem die Kompatibilität zu sichern statt zu maximieren ist. Für die Praxis ist das nicht relevant, denn die konkreteren Bedingungen sind es, die erfüllt sein müssen.
Auf Priorität I der BITV 2.0 werden zwei Bedingungen zu „Kompatibel“ formuliert:
Für Auszeichnungssprachen wie HTML gilt es nach Bedingung 4.1.1 Syntaxanalyse sicherzustellen:
- dass Elemente öffnende und schließende Tags besitzen,
- dass Elemente korrekt verschachtelt werden,
- dass Attribute für ein Element nur einmal vorkommen und
- dass IDs auf einer Webseite einzigartig sind.
Im Kern geht es bei dieser Bedingung darum, dass Hilfsmittel aufgrund von inkorrektem Code nicht „stolpern“.
Die Validierung mit dem W3C-Validator bietet derzeit keine Filterung seiner Ergebnisse, um die Erfüllung dieses Kriteriums „auf einem Blick“ prüfen zu können. Ein experimentelles Bookmarklet verschafft dabei Abhilfe.
Hinweis: Ob eine Validierung oder auch nur die Teilvalidierung nach dieser Bedingung die Barrierefreiheit fördert, ist nicht eindeutig. Nichtsdestotrotz ist die vollständige Validierung jeder Webseite erstrebenswert, denn die Einhaltung von Webstandards fördert die Zugänglichkeit für jede Software.
Mit Bedingung 4.1.2 Name, Rolle, Wert werden wichtige Voraussetzungen für die Zugänglichkeit von Webseiten in Hilfsmitteln wie Screenreadern, Vergrößerungssystemen oder Spracheingaben beschrieben. Komponenten der Benutzungsschnittstelle wie
- Links
- Formularelemente
- Komponenten mit eigener Benutzungsschnittstelle (z.B. in Flash, PDF, Java)
- Widgets (z.B. Slider, Baumnavigation usw.)
benötigen immer
- einen Namen. Bei Links ist das i.d.R. der Linktext und bei Formularen und Komponenten mit eigener Benutzungsschnittstelle meist die Beschriftung. Bei komplexeren Komponenten muss eine Bezeichnung mit einer ARIA-Technik vorgenommen werden.
- eine Rolle. Mit dem Einsatz von standardisierten Komponenten (z.B. <a> oder <input> in HTML) wird die Rolle automatisch an Hilfsmittel übertragen. Das gilt auch für standardisierte Komponente in Flash oder PDF. Bei Widgets muss das role-Attribut zum Einsatz kommen.
- ggf. einen Wert. Auch hier gilt, dass standardisierte Elemente den Wert automatisch übertragen. Bei Widgets müssen Zustände und Eigenschaften mit den in ARIA vorgesehenen Attributen angegeben werden.
Name, Rolle und Wert werden an die Accessibility-API des Betriebssystems übertragen und können dann dort von Hilfsmitteln „abgeholt“ werden. Erst mit diesen Informationen kann beispielsweise ein Screenreader eine Komponente als Link oder Schaltfläche identifizieren.
Semantische Elemente (<a>, <input> usw.) sollten bevorzugt für Komponenten eingesetzt werden. Dort, wo HTML oder andere Auszeichnungssprachen keine passende Semantik bieten, muss das role-Attribut mit weiteren ARIA-Eigenschaften eingesetzt werden. Sollten unpassende Elemente (z.B. <span>) für Komponenten eingesetzt werden, dann müssen sie u.a. mit dem role-Attribut repariert werden; erst solche Maßnahmen erlauben es, dass die Komponenten mittels Hilfsmitteln erfasst werden können (zur Steuerung solcher Komponenten siehe Bedingung 2.1.1).
Einige Rollen, Zustände und Eigenschaften aus der ARIA-Spezifikation werden in HTML5 ebenfalls spezifiziert. Weil einige ARIA-Attribute in absehbarer Zeit mit HTML5 ersetzt werden können, können sie teilweise als Übergangstechnik angesehen werden (bis die Zugänglichkeitsunterstützung von HTML5 durchgängig in allen Browsern gewährleistet ist).
ARIA ist insbesondere für solche Komponenten der Benutzungsschnittstelle erforderlich, die über die in HTML standardisierten Komponenten hinaus gehen. Widgets (Akkordeons, Drag and Drop-Funktionen usw.) müssen in Hilfsmitteln erfasst und gesteuert werden können. Die Bestimmung von Name, Rolle und Wert in solchen komplexen Komponenten muss i.d.R. mit den Widget roles aus ARIA und den zugehörigen Attributen erfolgen. Die Widget roles werden ein fester Bestandteil des barrierefreien Webdesigns bleiben.
Name, Rolle und Wert müssen auch für verschiedene eingebettete Objekte in HTML berücksichtigt werden. Beispiele sind:
- Frames benötigen ein aussagefähiges title-Attribut, das den Inhalt des Frames identifiziert.
- Multimedia sollte mit den HTML5-Elementen <audio> und <video> eingebettet werden, damit Hilfsmittel zugängliche Steuerelemente für das Abspielen der Multimedia erhalten. Hinweis: Diese Elemente stammen aus der HTML5-Spezifikation und bieten bereits jetzt eine gute Zugänglichkeit.
Bei Komponenten mit eigener Benutzungsschnittstelle (etwa in Flash oder PDF) müssen durch den Einsatz standardisierter Komponenten Name, Rolle und Wert an die Accessibility APIs der jeweiligen Betriebssysteme übertragen werden. In PDF wird das beispielsweise durch den Einsatz von tagged PDF bzw. durch Einhaltung des PDF/UA-Standards erreicht. Beispiele sind:
- In Flash müssen alle Steuerelemente bezeichnet werden.
- In PDF müssen alle Steuerelemente bezeichnet werden.
„BITV-Test“ und BITV 2.0
Der „BITV-Test“ bietet drei Prüfschritte zu Anforderung 4.1 („Kompatibel“) an:
Der Prüfschritt 4.1.1a Valides HTML fordert die vollständige Validierung von Webseiten. Dabei stellen weder BITV 2.0 noch WCAG 2.0 diese Anforderung, sondern es wird in Bedingung 4.1.1 nur teilweise auf ganz bestimmte Merkmale im Code verwiesen. Das kann zwar durch eine Validierung einer Webseite gesichert werden, aber die vollständige Validierung ist bestenfalls eine Technik von vielen, um die Bedingung 4.1.1 zu erfüllen.
Prüfschritt 4.1.1b Verzicht auf veraltete Elemente und Attribute stellt ein Rätsel dar. Dort wird geprüft, ob HTML-Elemente oder -Attribute, die in früheren HTML-Spezifikationen (z.B. HTML 3.2) bzw. nie spezifiziert waren, genutzt werden. Abgesehen davon, dass der Prüfschritt 4.1.1a diesen Aspekt ebenfalls prüft, gibt es keine Bedingung in der BITV 2.0, die diesen Prüfschritt begründet.
Die Anleitung zu Prüfschritt 4.1.2a Name und Rolle von Bedienelementen verfügbar lässt eine Prüfung von Links und – mit Einschränkungen – Formularelementen nach Bedingung 4.1.2 zu. In der Anleitungen werden Widgets erwähnt, aber nicht eingehend behandelt, und Komponenten mit eigener Benutzungsstelle (z.B. Flash) werden nicht erwähnt. Da das Kriterium vor allem auf Widgets und Komponenten mit eigener Benutzungsschnittstelle abzielt, greift die Prüfanleitung deutlich zu kurz.
Der Einsatz des Prüfwerkzeugs aViewer ist dem Grunde nach richtig, allerdings kann das bei sehr komplexen Anwendungen schwierig sein, mit diesem Tool die Erfüllung des Kriteriums bis ins letzte Detail vorzunehmen. Angebracht sind hier Tests mit Hilfsmitteln.
Zur Serie "Accessibility-Checkliste gegen graue Haare
Den Anlass für diese Serie finden Sie im einleitenden Beitrag Accessibility-Checkliste gegen graue Haare beschrieben.
Es ist wichtig, dass es in Deutschland Regelungen zur Barrierefreiheit im Web gibt. Allerdings steht die BITV 2.0 in Widerspruch zu internationalen Webstandards und weiteren Industrienormen, was in der Praxis durchaus ein Problem darstellt. Dass der "BITV-Test" diese Differenzen nicht relativiert, sondern verstärkt, hat zur Folge, dass barrierefreies Webdesign in Deutschland missverstanden wird. Die WCAG 2.0 sind stabile und international anerkannte Standards, die in den erläuternden Dokumenten laufend auf den aktuellen Stand der Technik gehalten werden. Die BITV 2.0 ist hingegen starr, und der "BITV-Test" bietet keinesfalls eine geeignete Basis, eine Konformität zu der BITV 2.0 (oder den WCAG 2.0) reliabel zu überprüfen.
Die Serie besteht aus einer Reihe von Checklisten, die jeweils die einzelnen Anforderungen der BITV 2.0 abbilden. Ergänzt werden die Checklisten mit Kritik an einzelne Bedingungen der BITV 2.0 und Kritik an einzelne Prüfschritte im "BITV-Test". Insgesamt handelt es sich bei dieser Serie um 12 Accessibility-Checklisten, die bei Bedarf auch aktualisiert werden:
- Anforderung 1.1: Textalternativen
- Anforderung 1.2: Zeitbasierte Medien
- Anforderung 1.3: Anpassbar
- Anforderung 1.4: Unterscheidbar
- Anforderung 2.1: Per Tastatur zugänglich
- Anforderung 2.2: Ausreichend Zeit
- Anforderung 2.3: Anfälle
- Anforderung 2.4: Navigierbar
- Anforderung 3.1: Lesbar
- Anforderung 3.2: Vorhersehbar
- Anforderung 3.3: Hilfestellung bei der Eingabe
- Anforderung 4.1: Kompatibel