Web Content Accessibility Guidelines

Die Web Content Accessibility Guidelines^[1] (WCAG) – deutsch: Richtlinien für barrierefreie Webinhalte – sind eine Empfehlung der Web Accessibility Initiative (WAI) des World Wide Web Consortiums (W3C) zur barrierefreien Gestaltung der Inhalte von Internetangeboten. Webseiten, die diesen Richtlinien entsprechen, sind auch für Menschen mit sensorischen und motorischen (und in gewissen Rahmen mentalen) Einschränkungen zugänglich, d. h. sie können die angebotenen Informationen erfassen und notwendige Eingaben tätigen. Die WCAG stehen im Zentrum zahlreicher Richtlinien und Spezifikationen, die die WAI zur Förderung eines barrierefreien Internets erarbeitet hat. In Deutschland steckt die praktische Umsetzung dieser Richtlinien noch im Anfangsstadium und wird seit 2002 durch die gesetzliche Verankerung in der Barrierefreie Informationstechnik-Verordnung (BITV) gefördert.

Die alte Version WCAG 1.0 hatte seit Mai 1999 Empfehlungsstatus. Die aktuelle Version WCAG 2.0^[2] wurde nach mehr als neunjähriger Beratung am 11. Dezember 2008 verabschiedet.^[3] Inzwischen liegt eine autorisierte deutsche Übersetzung vor.^[4]

Hintergründe

Die WAI erarbeitet Richtlinien zur barrierefreien Gestaltung des Internets. Die Tätigkeit ist dabei nicht auf die Inhalte der Webseiten allein ausgerichtet. Ebenso existieren Empfehlungen für Autorenwerkzeuge und Benutzeragenten (Browser, Mediaplayer und andere assistive Technologien). Ebenso zählt zur Tätigkeit eine umfassende Information zum Thema barrierefreies Internet.

Mit der zunehmenden Verbreitung des World Wide Web (WWW) in den 90er Jahren und damit der Verbreitung grafisch dargestellter Webseiten wurde das Problem akut, dass die Informationen der Webangebote für Menschen mit Behinderungen nicht mehr zugänglich waren. Diese auf den ersten Blick bizarr wirkende Entwicklung - der zunehmende Ausschluss dieser Menschen bei gleichzeitig vereinfachter Bedienung für andere - hat mehrere Gründe. In den 80er Jahren war die zeichen- und zeilenorientierte Darstellung der Bedienoberflächen von Betriebssystemen wie MS-DOS, Unix, CPM gut zugänglich für gehörlose, blinde oder vergleichbar behinderte Menschen, da die lineare Struktur der Darstellung in zeilenorientierten Terminalprogrammen bzw. der Verzicht auf akustische Ausgaben keine Barrieren für Braillezeilen und anderen assistierende Technologien darstellen. Behinderte und Nichtbehinderte konnten so unbehindert kommunizieren. Auch grafisch orientierte Darstellungen der Systemoberflächen stellen an sich noch keine Barriere für Menschen dar, deren Sehfähigkeiten eingeschränkt sind oder die eine Maus nicht bedienen können. Beispielsweise unterstützen moderne Versionen des Betriebssystem Windows umfassend die Bedienung mit der Tastatur. Die Probleme liegen hauptsächlich in der fehlenden Anwendung der existierenden Standards. Folgende Gründe spielen eine Rolle:

• die hohe Komplexität des Webdesigns: zahlreiche unterschiedliche Technologien erschweren die Erstellung von Webangeboten, die allgemein gut zugänglich sind.
• fehlende Standardkonformität der Browser
• fehlendes Problembewusstsein bei Webdesignern
• die Bedienung ist nicht unabhängig vom verwendeten Gerät möglich: Steuerung und Eingaben mit Maus, Tastatur und anderen Eingabegeräten müssen jedoch möglich sein.

Einige Beispiele problematischen Webdesigns:

• Bevor CSS umfassend unterstützt wurde, waren HTML-Tabellen ein bevorzugtes Mittel zur Gestaltung des Layouts. Die dadurch erzeugte flächige Struktur kann von Braillezeilen oder Screenreadern nicht geeignet wiedergegeben werden, da die Darstellung oft nicht den tatsächlichen Zusammenhang der Daten wiedergibt.
• Hyperlinks, deren beschreibender Text keinen Hinweis auf das Ziel enthält (z. B. ein Link mit dem Text "hier"), sind ebenfalls für Sehgeschädigte nur schwer zu erfassen.

Prinzipiell stellt Barrierefreiheit keinen hohen Zusatzaufwand dar und ist lediglich ein Teilaspekt einer umfassenden Usability von Computertechnologien. Voraussetzung ist jedoch, dass die zusätzlichen Anforderungen von Anfang an in die Planungsprozesse mit einbezogen werden, denn nachträgliche Änderungen sind oft zu aufwändig. Auch bedeutet Barrierefreiheit nicht den Verzicht auf gutes Design. Reine HTML-Seiten sind nicht prinzipiell barrierefrei und gerade multimediale Inhalte können bei bestimmten Behinderungsarten die Zugänglichkeit fördern. Beispielsweise können von Geburt an Gehörlose oft nur schlecht lesen, da die Schrift von der Lautsprache abgeleitet ist, die sie nicht oder nur schlecht beherrschen. Illustrierende Bilder können dann das Verständnis des Textes fördern, der zusätzlich einfach gehalten sein sollte.

Vergleichbare Probleme treten auch in anderen Bereichen des computerbasierten Arbeitens auf. Beispielsweise wird die Arbeit als Programmierer für blinde Menschen zunehmend schwieriger, da mit der Verbreitung grafischer orientierter Notationen von Softwaremodellen in Form von UML etc. die fehlende Zugänglichkeit der UML-Diagramme für Blinde ausschließend wirkt.

Auswirkungen der WCAG

Obwohl die Empfehlungen des W3C keine gesetzliche Gültigkeit bezüglich der Entwicklung des Internets besitzen, sind sie dennoch von hoher Verbindlichkeit für die Entwicklung. Allgemein wird von Software Konformität mit den W3C-Standards erwartet. Das betrifft in erster Linie die Browser, die die wichtigste Schnittstelle zum Internet darstellen. Der Grund dafür liegt unter anderem in der unparteilichen Arbeit des W3C und der offenen und diskursiven Entwicklung der Standards des W3C. Hinzu kommt, dass die WCAG bereits in die Gesetzgebung einzelner Staaten übernommen wurden. Auch hatte die US-Regierung bereits sehr frühzeitig Unterstützung für die Richtlinien signalisiert. Beispielsweise hat die Bundesregierung mit der BITV die Richtlinien der WCAG 1.0 rechtlich verbindlich für alle Internetauftritte des Bundes gemacht. Einzelne Bundesländer übernehmen das nach und nach auch für die Landesebene. Salopp gesagt hat damit eine Empfehlung des W3C erstmals als eine Verordnung rechtsgültigen Status erhalten.

Obwohl die gültigen Hypertextstandards des WWW (HTML, XHTML) die Möglichkeit bieten, Webseiten mit zusätzlichen Angaben zugänglich zu machen, wurden diese nie umfassend genutzt, sodass klar wurde, dass eigenständige Richtlinien zur Barrierefreiheit notwendig sind. In der Tat haben die WCAG auch Erfolg, wenn auch von einer allgemeinen Barrierefreiheit des Internets noch immer nicht gesprochen werden kann. Zahlreiche internationale und nationale Initiativen unterstützen diese Empfehlungen. Beispielsweise vergibt die Aktion Mensch jährlich den BIENE-Award für besonders gelungene zugängliche Internetangebote in verschiedenen Kategorien. Die Preisträger sind auch Demonstrationen eines gelungenen Webdesigns.

Aktuelles

Die WCAG 2.0 haben am 11. Dezember 2008 Empfehlungsstatus erhalten. Im Gegensatz zu den WCAG 1.0 konzentrieren sie sich nicht mehr auf HTML und CSS als wichtigste Standards des Internets, sondern beschreiben allgemeiner, wie Layouts, Interaktionen u.a. gestaltet sein müssen, damit das Angebot barrierefrei ist. Die Umsetzung dieser Richtlinien für die einzelnen Technologien wie HTML, Java, Flash oder PDF obliegt den jeweils verantwortlichen Institutionen bzw. Unternehmen. Damit bleiben die WCAG offen für die raschen technologischen Entwicklungen des Internets und neue Techniken lassen sich integrieren.

Die Empfehlungen im Einzelnen

Die einzelnen zu prüfenden Punkte der WCAG 1.0 sind in 14 Gruppen unterteilt und besitzen drei verschiedene Prioritäten (A, AA, AAA). Die WAI bietet rund um die WCAG zahlreiche unterstützende Angebote an, um die Umsetzungen der Richtlinien zu erleichtern. Die Kernpunkte werden in folgender Übersicht dargestellt^[5]:

• klare Strukturierung des Dokuments mit Überschriften und Listen, das Layout erfolgt nach Möglichkeit mit CSS
• der Zweck bzw. die Funktion von Bildern und Animationen wird durch alt-Attribut beschrieben
• zu multimedialen Angeboten existieren textliche Alternativen, Untertitel und Transkription für Audio und Audiodeskription für Video
• Diagramme werden im Text oder durch Verwendung des longdesc-Attributs beschrieben
• Frames besitzen aussagekräftige name-Attribute und das noframes-Element wird genutzt
• Tabellen sind möglichst Zeile für Zeile lesbar. Ihr Inhalt wird auch zusammengefasst beschrieben.
• Verwendung benutzerseitiger Imagemaps
• Skripte, Applets etc. sind barrierefrei oder es existieren barrierefreien Alternativen
• Tabellen werden nur für die Darstellung von Daten verwendet.

Wichtig ist auch die Überprüfung der Seiten auf Konformität - die sogenannte Validation. Dazu können zumindest teilweise auch entsprechende Softwarewerkzeuge genutzt werden. Jedoch lassen sich nicht alle Aspekte der Konformität automatisiert überprüfen.

Prinzipiell ist auch die Verwendung weiterer Technologien nicht ausgeschlossen, wenn bestimmte Grundsätze eingehalten werden. Beispielsweise lassen sich durchaus HTML, CSS und Javascript nutzen, wenn alle Informationen durch HTML dargestellt werden, CSS das Layout steuert und der Einsatz von Javascript auf die Verbesserung der Usability beschränkt wird. Wird die Darstellung von Informationen jedoch so integriert, dass die Funktionalität von Javascript, Java, Flash, CSS usw. zwingend notwendig ist, ist das Angebot nicht barrierefrei. Viele der erweiternden Technologien bieten eigenständige Funktionalitäten zur Verbesserung der Zugänglichkeit (Java, Flash), die jedoch oft nicht genutzt bzw. nicht durch die assistierende Technologie unterstützt wird.

Siehe auch

• Barrierefreies Internet
• Gesetz zur Gleichstellung behinderter Menschen
• Barrierefreiheit
• Design für Alle (in IKT)

Einzelnachweise

1. ↑ W3C (1999): Web Content Accessibility Guidelines 1.0, deutsche Übersetzung, zuletzt besucht: 21. November 2006
2. ↑ Ben Caldwell; Michael Cooper; Loretta Guarino Reid; Gregg Vanderheiden: Web Content Accessibility Guidelines (WCAG) 2.0. W3C, 11. Dezember 2008, abgerufen am 13. Dezember 2008 (englisch). 
3. ↑ heb: Neuer Webstandard für Barrierefreiheit WCAG 2.0 verabschiedet. heise online, 12. Dezember 2008, abgerufen am 13. Dezember 2008. 
4. ↑ Deutsche Behindertenhilfe Aktion Mensch e. V.: Richtlinien für barrierefreie Webinhalte (WCAG) 2.0. W3C, 29. Oktober 2009, abgerufen am 28. Oktober 2010 (deutsch). 
5. ↑ W3C (2001): WAI QuickTips, deutsche Übersetzung, zuletzt besucht: 21. November 2006

Literatur

• Jan Eric Hellbusch (2004): Barrierefreies Webdesign. Praxishandbuch für Webgestaltung und grafische Programmoberflächen, Heidelberg. ISBN 3-89864-260-7
• Jan Eric Hellbusch, Kerstin Probiesch (2011): Barrierefreiheit verstehen und umsetzen: Webstandards für ein zugängliches und nutzbares Internet, Heidelberg. ISBN 978-3-89864-520-1

Weblinks

• Die Web Content Accessibility Guidelines in der Version 1.0 deutsche Übersetzung
• Aktuelle Version 2.0 der Richtlinien – englisch
• Autorisierte deutsche Übersetzung der WCAG 2.0 – deutsch
• Aktion Mensch-Initiative für ein barrierefreies Web
• Der Biene-Preis für besonders gelungene barrierefreie Webangebote
• CSS-Zengarten, Demonstration der Möglichkeiten eines CSS-Layouts (englisch)

Standards des World Wide Web Consortiums

Empfehlungen (Recommendations): ATAG | Canonical XML | CSS | CharMod | CC/PP | DDR Simple API | DOM | EXI | Element Traversal | EMMA | GRDDL | HTML | ITS | MathML | OWL | P3P | PICS | PLS | PNG | POWDER | RDF | RDF-Schema | Ruby | SISR | SKOS | SML | SMIL | SOAP | SOAP MTOM | SPARQL | SRGS | SSML | SVG | SSML | UAAG | VoiceXML | WCAG | Webarch | WebCGM | WSDL | WS-Adressing | WS-Policy | XHTML | XML | XInclude | XKMS | XLink  | XML Base | XMLEnc-Decrypt | XML Events | XML Information Set | XML Namespace | XML Schema | XML Signature | XOP | XForms | XPath | XPointer | XProc | XQuery | XSL | XSLT

Arbeitsentwürfe (Working Drafts) und Kandidaten (Candidate Recommendations): Capture API | CCXML | CDF | Clipboard API | Contacts API | Cross-Origin Resource Sharing | CURIE | EARL | File API | HTML5 | HTML Canvas | HTML Microdata | Indexed Database API | InkML | LTLI | RIF | Selectors API | System Information API | WAI-ARIA | Web IDL | Web Sockets API | Web SQL Database | WICD | Widgets | XFrames | XBL