Web Content Accessibility Guidelines

Logo für eine Konformität mit den WCAG 2.2 auf Stufe AAA
Logo für eine Konformität mit den WCAG 2.2 auf Stufe AAA

Die Web Content Accessibility Guidelines[1] (WCAG; englisch für „Richtlinien für barrierefreie Webinhalte“) sind ein internationaler Standard zur barrierefreien Gestaltung von Internetangeboten, der in der Europäischen Union für öffentliche Stellen ab 23. September 2019 für neue und ab 23. September 2020 für bestehende Websites und ab 23. Juni 2021 für mobile Anwendungen mit WCAG 2.1 Stufe AA verbindlich ist.[2][3][4][5] Die Web Accessibility Initiative (WAI) des World Wide Web Consortiums (W3C) hat die WCAG ausgearbeitet, die Internationale Organisation für Normung (ISO) hat die WCAG 2.0 zum Standard ISO/IEC 40500:2012 erklärt, und das Europäische Komitee für Normung (CEN), das Europäische Komitee für elektrotechnische Normung (CENELEC) und das Europäische Institut für Telekommunikationsnormen (ETSI) haben die WCAG 2.1 zur Norm EN 301 549 V2.1.2 (2018-08) erklärt.

Webseiten, die diesen Richtlinien entsprechen, sind auch für Menschen mit sensorischen und motorischen (und in gewissem 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[6] wurde nach mehr als neunjähriger Beratung am 11. Dezember 2008 verabschiedet,[7] inzwischen liegt eine autorisierte deutsche Übersetzung vor.[8] Im Juni 2018 hat die WAI die WCAG 2.1 verabschiedet[9]. Version 2.2 der WCAG wurde am 5. Oktober 2023 veröffentlicht.[10]

Hintergründe

[Bearbeiten | Quelltext bearbeiten]

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 1980er Jahren war die zeichen- und zeilenorientierte Darstellung der Bedienoberflächen von Betriebssystemen wie MS-DOS, Unix, CP/M 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 andere assistierende Technologien darstellen. Behinderte und Nichtbehinderte konnten so ungehindert 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

[Bearbeiten | Quelltext bearbeiten]

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 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 deutsche 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 vergab die Aktion Mensch von 2003 bis 2010 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

[Bearbeiten | Quelltext bearbeiten]

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 WCAG wurden weiterentwickelt; im Juni 2018 wurden die WCAG 2.1 als W3C Recommendation (Web Standard) veröffentlicht.

Der WCAG-Test ist ein Testverfahren zur Prüfung der Zugänglichkeit von Webangeboten. Er wurde im Rahmen der vom Bundesministerium für Arbeit und Soziales geförderten Projektreihe „BIK – barrierefrei informieren und kommunizieren“ entwickelt und macht die Anforderungen der WCAG handhabbar.[11]

Die Empfehlungen im Einzelnen

[Bearbeiten | Quelltext bearbeiten]

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:[12]

  • 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 barrierefreie 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.

Übersicht der 4 Prinzipien und 13 Richtlinien der WCAG 2.1
Wahrnehmbarkeit Textalternativen Stellen Sie Textalternativen für alle Nicht-Text-Inhalte zur Verfügung, sodass diese in andere vom Benutzer benötigte Formen geändert werden können, wie zum Beispiel Großschrift, Braille, Symbole oder einfachere Sprache.
Zeit-basierte Medien Stellen Sie Alternativen für zeit-basierte Medien zur Verfügung.
Anpassbar Erstellen Sie Inhalte, die auf verschiedene Arten dargestellt werden können (einfacheres Layout), ohne dass Informationen oder Struktur verloren gehen.
Unterscheidbar Machen Sie es Benutzern leichter, Inhalt zu sehen und zu hören einschließlich der Trennung von Vorder- und Hintergrund.
Bedienbarkeit Per Tastatur zugänglich Sorgen Sie dafür, dass alle Funktionalitäten per Tastatur zugänglich sind.
Ausreichend Zeit Geben Sie den Benutzern ausreichend Zeit, Inhalte zu lesen und zu benutzen.
Anfälle Gestalten Sie Inhalte nicht auf Arten, von denen bekannt ist, dass sie zu Anfällen führen.
Navigierbar Stellen Sie Mittel zur Verfügung, um Benutzer dabei zu unterstützen zu navigieren, Inhalte zu finden und zu bestimmen, wo sie sich befinden.
Eingabe Modalitäten Erleichtern Sie den Benutzern die Bedienung über verschiedene Eingaben über die Tastatur hinaus.
Verständlichkeit Lesbar Machen Sie Inhalt lesbar und verständlich.
Vorhersehbar Sorgen Sie dafür, dass Webseiten vorhersehbar aussehen und funktionieren.
Hilfestellung bei der Eingabe Helfen Sie den Benutzern dabei, Fehler zu vermeiden und zu korrigieren.
Robustheit Kompatibel Maximieren Sie die Kompatibilität mit aktuellen und zukünftigen Benutzeragenten, einschließlich assistierender Techniken.

Literatur

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

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. ↑ Richtlinien für barrierefreie Webinhalte (WCAG) 2.0. World Wide Web Consortium, 29. Oktober 2009, abgerufen am 10. Februar 2017.
  2. ↑ Durchführungsbeschluss (EU) 2018/2048 der Kommission vom 20. Dezember 2018 über die harmonisierte Norm für Websites und mobile Anwendungen zur Unterstützung der Richtlinie (EU) 2016/2102 des Europäischen Parlaments und des Rates, abgerufen am 30. April 2019
  3. ↑ Artikel 12 von Richtlinie (EU) 2016/2102 des Europäischen Parlaments und des Rates vom 26. Oktober 2016 über den barrierefreien Zugang zu den Websites und mobilen Anwendungen öffentlicher Stellen, abgerufen am 10. Februar 2017
  4. ↑ Mitteilung der Kommission an das Europäische Parlament gemäß Artikel 294 Absatz 6 des Vertrags über die Arbeitsweise der Europäischen Union betreffend den Standpunkt des Rates im Hinblick auf den Erlass einer Richtlinie des Europäischen Parlaments und des Rates über den barrierefreien Zugang zu den Websites und mobilen Anwendungen öffentlicher Stellen COM(2016) 484 final , abgerufen am 10. Februar 2017 „Dem Vorschlag zufolge sollen Websites einiger öffentlicher Stellen EU-weit barrierefrei zugänglich gemacht werden, indem dafür gesorgt wird, dass sie den gleichen technischen Normen und Standards entsprechen (Web Content Accessibility Guidelines WCAG 2.0 Level AA des W3C – WCAG 2.0).“
  5. ↑ Gregor Eibl: Richtlinie der EU über den barrierefreien Zugang zu den Websites und mobilen Anwendungen öffentlicher Stellen. (PDF; 0,7 MB) Bundeskanzleramt Österreich, 31. Januar 2017, abgerufen am 10. Februar 2017.
  6. ↑ 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).
  7. ↑ heb: Neuer Webstandard für Barrierefreiheit WCAG 2.0 verabschiedet. heise online, 12. Dezember 2008, abgerufen am 13. Dezember 2008.
  8. ↑ Richtlinien für barrierefreie Webinhalte (WCAG) 2.0. In: W3C. Deutsche Behindertenhilfe Aktion Mensch e. V., 29. Oktober 2009, abgerufen am 28. Oktober 2010.
  9. ↑ https://www.w3.org/TR/WCAG21/
  10. ↑ Web Content Accessibility Guidelines (WCAG) 2.2. In: w3.org. 5. Oktober 2023, abgerufen am 27. Februar 2024 (englisch).
  11. ↑ Der WCAG-Test. Das Projekt BIK – barrierefrei informieren und kommunizieren; abgerufen am 5. Oktober 2023.
  12. ↑ WAI QuickTips, deutsche Übersetzung. W3C, 2001; abgerufen am 21. November 2006.
Standards des World Wide Web Consortiums (W3C)
Empfehlungen

ActivityPub | ARIA | Canonical XML | CDF | CSS | DOM | Geolocation API | HTML | HTML5 | InkML | ITS | JSON-LD | MathML | OWL | P3P | PLS | PNG | RDF | RDF-Schema | RIF | SCXML | SISR | SKOS | SMIL | SOAP | SRGS | SSML | SVG | SPARQL | Timed Text | Turtle | VoiceXML | WSDL | XForms | XHTML | XHTML+RDFa | XInclude | XLink | XML | XML Base | XML-Encryption | XML Events | XML Information Set | XML Namespace | XML Schema | XML Signature | XPath | XPointer | XProc | XQuery | XSL | XSL-FO | XSLT (Elemente)

Arbeitsentwürfe
und Kandidaten

CCXML | CURIE | SMIL Timesheets | sXBL | WICD | XFrames | XBL | XHTML+MathML+SVG | XMLHttpRequest

Anmerkungen

XAdES | XFDL | XHTML+SMIL | XUP

Richtlinien

Web Content Accessibility Guidelines | Multimodal Interaction Activity | Markup Validation Service

Initiativen

Web Accessibility Initiative