Inklusion bedeutet mehr als Konformität 
veröffentlicht in 2018
zuletzt bearbeitet in
Die Anforderungen an barrierefreies Webdesign werden durch die EN 301549 definiert. Diese Europäische Norm ist die rechtliche Grundlage für digitale Barrierefreiheit, die sich aus der Europäischen Webseitenrichtlinie sowie dem European Accessibility Act (EAA) ergeben. In Deutschland werden die Anforderungen durch die Behindertengleichstellungsgesetze auf Bundes- und Landesebene sowie das Barrierefreiheitsstärkungsgesetz (BFSG) übernommen.
Ein zentraler Teil der EN 301549 sind die Anforderungen an Webseiten, Dokumente und Software. Bei den einzelnen Anforderungen wird größtenteils auf die Erfolgskriterien der Web Content Accessibility Guidelines (WCAG) 2.1 verwiesen.
Hinweis: Die aktuelle Version der WCAG ist 2.2. Die aktualisierten Anforderungen werden in der EN 301549 eingearbeitet. Eine Aktualisierung der verbindlichen Vorgaben wird für Herbst 2027 erwartet. Die WCAG 2.2 ergänzt die WCAG 2.1 um neun neue Kriterien.
Tatsächlich gehen die Anforderungen von Nutzenden mit einer Behinderung über die Anforderungen aus EN 301549 und WCAG 2.2 hinaus. Das liegt nicht nur an einzelnen Anforderungen in den WCAG 2.2, die eher minimalistischen Charakter haben, sondern selbstverständlich auch an Software oder Anforderungen der Nutzenden selbst. Deswegen darf die Konformität zu den Barrierefreiheitsrichtlinien lediglich als Ausgangspunkt für digitale Inklusion, das heißt eine gut nutzbare Website für möglichst alle Nutzende, angesehen werden.
Barrierefreiheit ist dabei ein erreichbares Ziel für jede Organisation, aber:
- Webinhalte sind erst dann für die meisten Nutzer zugänglich und nutzbar, wenn die Konformität zu den WCAG 2.2 erreicht wurde. Realistisch ist dabei Konformitätsstufe AA.
- Mit barrierefreien Inhalten können weitere Aspekte wie ein positives Nutzungserlebnis sinnvoll angestrebt werden.
- Webinhalte müssen kontinuierlich und in einem inklusiven Entstehungsprozess geplant und regelmäßig mit den betroffenen Nutzern evaluiert werden, damit möglichst wenige Nutzer ausgegrenzt werden.
Die Konformität zu den Barrierefreiheitsrichtlinien kommt nicht "frei Haus", sondern setzt Sensibilisierung, Schulungen oder Investitionen in neuer Software voraus. Viel wichtiger ist aber, dass die Konformität der Schlüssel zur Inklusion in der digitalen Welt ist. Ohne Barrierefreiheit gibt es keine Inklusion.
WCAG-Konformität ist der erste Schritt
Die WCAG 2.2 beschreiben die Mindestanforderungen an die digitale Barrierefreiheit. Sie finden in dieser Richtlinie insgesamt 86 Erfolgskriterien. Die Richtlinie wird außerdem durch unzählige erläuternde Dokumente und weitere Webstandards zur Barrierefreiheit ergänzt. Die zentrale Einstiegsseite beim W3C finden Sie auf
https://www.
Mit den WCAG 2.2 gibt es einen ausführlich dokumentierten Webstandard mit prüfbaren Kriterien und umfangreichen Erläuterungen. Diese helfen dabei einzuschätzen, ob Techniken im Web für alle nutzbar sind oder ob sie Barrieren erzeugen und nur einen Teil der Nutzenden erreichen. Die Kriterien sind Qualitätsmerkmale, die Ihre digitalen Produkte und Dienstleistungen robuster und professioneller machen.
Und dennoch: Wenn eine Webseite konform zu den WCAG 2.2 oder zur EN 301549 ist, ist eine gute Nutzbarkeit nicht garantiert. Auch barrierefreie Websites können schwer zu nutzen sein. Ein wesentlicher Grund ist, dass die WCAG 2.2 nicht alle Aspekte einer barrierefreien Nutzung abdeckt. Beispiele dafür sind:
- Testbarkeit: Auch die WCAG 2.2 stellt in mancher Hinsicht ein Kompromiss zwischen verschiedenen Interessensgruppen dar. Anforderungen, die objektiv getestet werden können, finden Sie eher bei den Mindestanforderungen. Andere Anforderungen, die objektiv nicht gut getestet werden können oder zum Beispiel die Gestaltung einschränken könnten, finden Sie eher auf der (optionalen) Konformitätsstufe AAA der WCAG 2.2. Zu letzteren Themen zählen Aspekte der Verständlichkeit oder der Leserlichkeit, die beide nicht universell festgelegt werden können.
- Kompatibilität: Es gibt diverse Eingabegeräte als Maus- und Tastaturersatz sowie Software zum Beispiel für Bildschirmtastaturen oder Spracherkennung, die alle auf vorhandenen Schnittstellen des Betriebssystems aufsetzen. Für die Ausgabe gibt es Screenreader, die Inhalte in Sprache oder Braille umwandeln, und Vergrößerungssysteme. Nicht alle der Hilfsmittel unterstützen Webstandards auf ausreichende Weise und nicht alle Nutzer setzen die aktuellste Software ein. So kann es durchaus passieren, dass standardkonforme Webseiten mit einem fünf Jahre alten Screenreader genutzt werden, und Kompatibilitätsprobleme dazu führen, dass eine Webseite oder einzelne Komponenten der Webseite nicht oder nur eingeschränkt nutzbar sind.
Vor allem umfasst die WCAG 2.2 die Gebrauchstauglichkeit nicht. Gebrauchstauglichkeit ist ein Thema, das potenziell alle Nutzende betrifft. Barrierefreiheit umfasst Themen, die Nutzende mit einer Behinderung im besonderen Maße einschränken.
Wenn Ihre Webseiten durch einen Accessibility-Consultant als "barrierefrei" attestiert wird, können vereinzelte Probleme doch auftreten. Daher sind Nutzertests durch Menschen mit verschiedenen Behinderungen möglicherweise notwendig.
Ein inklusiver Ansatz ist erforderlich
Dass die Messlatte für Barrierefreiheit vor allem in einem individuellen Kontext viel zu kurz greifen kann, liegt auf der Hand. Um ein positives Nutzungserlebnis bei möglichst vielen Menschen mit Behinderungen zu erreichen, müssen die Anforderungen einzelner Nutzergruppen und Nutzer in die Gestaltungsüberlegungen für Webinhalte einfließen. Die Arbeitsweisen und spezifischen Anforderungen der verschiedenen Nutzergruppen können dabei auf Konformitätsstufe AA oder AAA der WCAG 2.2 nicht vorkommen.
Vor der Umsetzung eines barrierefreien Webdesigns sollten die möglichen Anforderungen und die Schnittmengen zu den Richtlinien einzeln vergegenwärtigt werden:
- Sehbehinderte stellen eine heterogene Nutzergruppe dar. Wichtige Aspekte für die Webentwicklung sind insbesondere die Anpassung der Bildschirmeinstellungen und die Berücksichtigung ausreichender Kontrastverhältnisse für Text.
- Blinde Nutzer verwenden Screenreader, um Bildschirminhalte mithilfe nicht-visueller Ausgabegeräte (akustisch über eine Sprachausgabe oder haptisch über eine Braillezeile) zu vermitteln. Screenreader wiederum stützen sich auf den Accessibility-Tree eines Betriebssystems. Screenreadernutzer profitieren von einer Konformität zu den WCAG 2.2 im besonderen Maße.
- Manche Nutzer mit körperlichen Einschränkungen können die Tastatur (oder den Mauszeiger) nicht benutzen. Wichtig für die Konformität ist aber, dass die Nutzbarkeit sämtlicher Funktionen nicht nur per Mauszeiger, sondern ebenso per Tastatur gewährleistet wird. Für Mobilgeräte bieten die WCAG 2.2 einige weitergehende Anforderungen für die barrierefreie Nutzung durch Menschen mit körperlichen Einschränkungen.
- Menschen mit Lernbehinderungen benötigen unter anderem Leichte Sprache. Anforderungen hierzu finden sich in den Webstandards zur Barrierefreiheit leider nicht. Die WCAG 2.2 umfasst einige Anforderungen zur ablenkungsfreien Interaktion. Die in Deutschland geltende Barrierefreie Informationstechnik-Verordnung – BITV 2.0 legt darüber hinaus fest, dass die Startseite eines Webangebots einführende Informationen in Leichter Sprache enthalten muss.
- Für gehörlose Nutzer sind insbesondere akustische Informationen auch in Textform anzubieten. Die Darstellung von Inhalten in Gebärdensprache wird nach den WCAG 2.2 nur für Audio-Inhalte in Videos empfohlen. Die BITV 2.0 legt hingegen fest, dass die Startseite eines Webangebots ein Gebärdensprachvideo mit Vorstellung der wesentlichen Inhalte des Webauftritts enthalten muss.
Ob die Konformität zu den WCAG 2.2 ausreicht oder ob in konkreten Fällen Nutzeranforderungen zusätzlich berücksichtigt werden müssen, lässt sich an vielen Beispielen diskutieren. Es gibt verschiedene objektive Gründe, die die Berücksichtigung von Nutzeranforderungen nahe legen:
- Eine Webseite kann alle Anforderungen an Farbe erfüllen, aber die Webseite kann vielleicht immer noch nicht von Sehbehinderten genutzt werden, weil Grafiken mit Text nicht anpassbar sind (zum Beispiel in einem Kontrastmodus).
- Webseiten können HTML-konform aufbereitet sein, so dass Browser alle Informationen der Webseite korrekt in den Accessibility-Tree des Betriebssystems hineinschreiben. Dennoch könnte ein Screenreader die Informationen dort falsch auswerten und es müssen Anpassungen im Code vorgenommen werden, um die fehlerhafte Bearbeitung durch den Screenreader zu überbrücken.
- Die Tastaturbedienung kann sichergestellt sein, aber beispielsweise nur für die Tab-Taste. Dabei gibt es Best-Practice-Empfehlungen für das Fokus-Management, die eine Optimierung der Tastaturbedienung insbesondere für zusammengesetzte Widgets vorgibt; diese erlauben beispielsweise eine Auswahl eines Elements in einer Gruppe von Elementen per Pfeiltasten.
- Texte einer Webseite könnten möglichst einfach und verständlich geschrieben werden nicht nur gemäß den WCAG 2.2, sondern auch nach den Prinzipien aus DIN ISO 24495-1 Einfache Sprache. Für Nutzende, die auf Leichte Sprache angewiesen sind, sind solche Texte möglicherweise nicht gut verständlich. Es müssen die strengeren Regeln aus DIN SPEC 33429 "Empfehlungen für Deutsche Leichte Sprache" angewandt werden.
- Die Anforderungen zu Gebärdensprache könnten nach WCAG 2.2 und BITV 2.0 vollständig erfüllt sein. Diese betreffen aber nur ganz bestimmte Inhalte. Die meisten Webseiten bieten ihre Inhalte in Textform an. Solche Inhalte müssen auch für gehörlose Nutzende, die vorwiegend in Gebärdensprache kommunizieren, auch verständlich vermittelt werden.
Der zentrale Gedanke lautet: Webseiten werden von Menschen mit ganz unterschiedlichen Voraussetzungen genutzt. Damit Sie Barrieren möglichst vermeiden, müssen Sie Nutzenden mit einer Behinderung immer entgegenkommen. Der erste Schritt ist die konsequente Erfüllung der Mindestanforderungen. Über die Mindestanforderungen hinaus gibt es aber viel Spielraum für mehr Barrierefreiheit und Inklusion.
Barrierefreiheit ist auch eine Haltung
Barrierefreiheit sollte stets proaktiv verfolgt werden. Nur so kann sie bereits in frühen Phasen der Webseitenentwicklung ausreichend berücksichtigt werden. Auf diese Weise kann sich in Ihrer Organisation eine echte Barrierefreiheitskultur entwickeln, die langfristig zu besser nutzbaren Webseiten führt.
Es liegt im Interesse aller Beteiligten – Nutzende und Betreiber von Websites –, ein hohes Qualitätsniveau zu erreichen. Sowohl bei der Entwicklung von Komponenten, Inhalten und Designs als auch bei der Auswahl von Frameworks und Redaktionssystemen kann und sollte Barrierefreiheit gezielt priorisiert werden. Durch regelmäßige Konformitätsprüfungen lassen sich digitale Produkte dauerhaft verbessern.
Aus Sicht der Nutzenden ist es wünschenswert, dass alle Webseiten jederzeit problemlos gelesen und bedient werden können — Das erleichtert so vieles im Alltag. Es darf keine Utopie sein, dass barrierefreie Webseiten der Standard und nicht die Ausnahme sind. Digitale Barrierefreiheit ist der Schlüssel zu echter digitaler Inklusion.
Blättern zur nächsten oder vorherigen Seite
- HTML ist das Handwerk, CSS die Kunst, und Barrierefreiheit ist das Ziel. HTML und CSS
- Tabellenlayouts, blind-GIFs und feste Schriftgrößen sollten durch standardkonforme Lösungen ersetzt werden. Abschließende Bemerkungen