Dieser Beitrag gehört zur Artikelserie Richtlinien für barrierefreie Webinhalte WCAG 2.0. Er soll die Erfolgskriterien, Bedeutung und Umsetzung der Richtlinie 4.1 Kompatibel darstellen sowie Website Beispiele aufzeigen.
„Maximieren Sie die Kompatibilität mit aktuellen und zukünftigen Benutzeragenten, einschließlich assistierender Techniken.“
Erfolgskriterien der Richtlinie 4.1
- 4.1.1 Syntaxanalyse: Bei Inhalt, der durch die Benutzung von Auszeichnungssprache implementiert wurde, haben Elemente komplette Start- und End-Tags, werden Elemente entsprechend ihrer Spezifikationen verschachtelt, enthalten Elemente keine doppelten Attribute und alle IDs sind einzigartig, außer wenn die Spezifikationen diese Eigenschaften erlauben. (Stufe A)
Anmerkung: Start- und End-Tags, bei denen entscheidende Zeichen in ihrer Formation fehlen, wie eine schließende spitze Klammer oder nicht zueinander passende Anführungszeichen von Attribut-Werten, sind nicht vollständig. - 4.1.2 Name, Rolle, Wert: Für alle Bestandteile der Benutzerschnittstelle (einschließlich, aber nicht beschränkt auf: Formularelemente, Links und durch Skripte generierte Komponenten) können Name und Rolle durch Software bestimmt werden; Zustände, Eigenschaften und Werte, die vom Benutzer festgelegt werden können, können durch Software festgelegt sein; und die Benachrichtigung über Änderungen an diesen Elementen steht den Benutzeragenten zur Verfügung, einschließlich assistierender Techniken. (Stufe A)
Anmerkung: Dieses Erfolgskriterium ist hauptsächlich für Webautoren gedacht, die ihre eigenen Bestandteile der Benutzerschnittstelle entwickeln oder skripten. Standard-HTML-Steuerelemente erfüllen zum Beispiel bereits dieses Erfolgskriterium, wenn sie entsprechend der Spezifikation benutzt werden.
Bedeutung der Richtlinie
Bei der Richtlinie 4.1 kompatibel geht es vor allem darum, dass die Kompatibilität mit assistierenden Techniken (AT) maximiert wird. Häufig wird die Richtlinie auch als 4.1 Robustheit beschrieben.
Grundlegend geht es darum, dass jede Website in jedem Browser und jeder Browserversion ordnungsgemäß und robust funktionieren soll. Dabei ist es wichtig, dass die Website ein valides HTML hat. Für ein valides HTML ist es notwendig, dass jedes Element über ein vollständiges Start- und Endtag verfügt, das diese gemäß ihrer Spezifikation geschachtelt sind, dass keine doppelten Attribute in den Elementen vorhanden sind und das die Element-IDs eindeutig sind.
Um zu überprügen, ob die Website Browserkompartibel ist, bietet browsershots einen einfachen und guten Browserkompartibilitätstest.
Um eine Kompattibilität bzw. Validität dies zu gewährleisten sollten zunächst abgelehnte Funktionen von W3C-Techniken vermieden werden.
Zudem ist es wichtig, dass keine technischen Inhalte dargestellt werden, bei denen diese Technik nicht die Barrierefreiheit unterstützt.
Der Inhalt sollte grundsätzlich in eine Datenstruktur aufgegliedert werden können, damit diese genau interpretiert werden können und die Benutzeragenten mit der Aufgliederung keine Schwierigkeiten haben.
In der Regel sind Standard-HTML-Elemente barrierefrei, dennoch gibt es auch clientseitige Steuerelemente, die den Standard nicht erfüllen.
Zudem besagt die Richtlinie, dass für alle Bestandteile der Benutzerschnittstelle ein Name und eine Rolle bestimmt werden soll, damit diese mit assiestierenden Techniken wie z. B. Screenreadern, Vergrößerungssoftware oder Spracherkennungssoftware kompatibel ist.
Umsetzung und Beispiele der Richtlinie
Um die Richtlinie umzusetzen und die Kompatibilität zu gewährleiten, sollte generell HTML und XHTMl gemäß ihrer entsprechenden Spezifikationen benutzt werden.
Zudem sollte sichergestellt werden, dass sie Website wohlgeformt ist. Dieses wird am besten überprüft, indem das Dokument einem konformen XML-Parser analysiert wird. Daraufhin würde der Validierungs-Bericht Fehler in der Wohlgeformtheit darstellen.
Damit eien Website analysiert werden kann sollte dafür gesorgt werden, dass Start- und End-Tags benutzt werden, id-Attribute einmalig auf einer Website sind und dann Elemente keine doppelten Attribute enthalten.
Ein häufiger Fehler im Code tritt auf, da beim opening-tag eine spitze Klammer fehlt und damit die Begrenzung des Tags unklar ist oder das beim closing-tag der Schrägstrich fehlt:
Beispiel fehlerhafter Code
Einige Tools zum Validieren von HTML und XHTML sind beispielsweise der W3C Markup Validation Service, der HTML/XML Validator und der WDG HTML Validator sowie eine große Anzahl an weiteren Validatoren.
Der gängigste Validator ist der W3C Markup Validation Service. Dabei kann noch ausgewählt werden, um welchen doctype es sich handelt und die jeweilige Website darauf überprüfen. Der Validator gibt dann an, wie viele Fehler und Warnungen im HTML der Website gefunden wurden und zeigt damit an, wie valide der HTML Code ist. Im folgenden wird ein Beispiel einer Website gezeigt, die mit Hilfe des W3C Validators geprüft wurde:
W3C Validator
Anschließend zeigt der W3C Validator aufgelistet die Anzahl an Fehler und Warnungen:
W3C Validator Fehlerliste
Die Inhalte und Erfolgskriterien der Richtlinie 4.1 Kompatibel sind in der deutschen Übersetzung nachzulesen unter www.w3.org.
Der nächste Artikel beschäftigt sich mit der WCAG 2.0 Richtlinie 3.3 Hilfestellung bei der Eingabe.