Einleitung
Mit dem kommenden Barrierefreiheitsstärkungsgesetz zur Einhaltung von Barrierefreiheitsstandards für die Privatwirtschaft, bekomme ich als Accessibility Consultant häufig die Fragen: Wie soll man das denn prüfen? Wie weiß ich, ob meine Webseite barrierefrei ist? Wer entscheidet das denn? Die Antworten auf diese Fragen drehen sich meist um die WCAG, die Web Content Accessibility Guidelines.
Damit Digitale Barrierefreiheit für ein Produkt, sei es Webseite, App, E-Mail, PDF, etc, einheitlich umgesetzt werden kann, hat die Web Accessibility Initiative (WAI) des World Wide Web Consortium (W3C) die Web Content Accessibility Guidelines, kurz WCAG, entwickelt. Darin wird ein Standard definiert, der das Web, vor allem für Menschen mit Behinderungen und Einschränkungen, zugänglicher machen soll.
Diese Richtlinien bilden die Basis der Barrierefreiheit in digitalen Medien. Werden diese Richtlinien nicht eingehalten, so gelten die Inhalte als nicht WCAG konform und sind somit nicht barrierefrei. Sie enthalten Vorgaben zu Design, Inhalt und Code und sind somit relevant für alle, die Inhalte fürs Web erstellen.
Mit Hilfe der WCAG ist es möglich, die Barrierefreiheit von Inhalten mit den definierten Erfolgskriterien abzugleichen. Werden diese Erfolgskriterien eingehalten, so besteht Konformität nach geltenden Empfehlungen oder gesetzlichen Standards.
Wer überprüfen möchte, ob die vorgeschriebenen Barrierefreiheitsanforderungen eingehalten werden, kommt um die Web Content Accessibility Guidelines nicht umhin.
Versionen
Im Mai 1999 wurden die WCAG 1.0 veröffentlicht. Der Fokus lag dabei überwiegend auf HTML und war mit seinen 14 Richtlinien damals ein großer Schritt für die Barrierefreiheit des Webs.
Trotz der Geschwindigkeit technologischen Fortschritts dauerte der Sprung auf WCAG 2.0 fast 10 Jahre. Im Dezember 2008 wurden vier Prinzipien der Barrierefreiheit eingeführt, um ein größeres Spektrum von Technologien abzudecken. Die Prinzipien enthalten jeweils Richtlinien, die Entwickler:innen, Designer:innen und Contentersteller:innen dabei unterstützen sollen, digitale Inhalte zugänglich zu machen. Mit der darauffolgenden Version 2.1 wurden Erfolgskriterien hinzugefügt.
Im Herbst 2023 wurde WCAG Version 2.2 offiziell veröffentlicht und hat zu den bestehenden 78 Erfolgskriterien neun neue Erfolgskriterien eingeführt. Bei allen bisherigen Erweiterungen ab Version 2.0 handelt es sich um Verbesserungen, die unternommen werden mussten, seit Veröffentlichung im Jahr 2018.
Unter dem Codenamen “Silver” befinden sich schon die WCAG 3.0 in Arbeit und sollwn in den nächsten Jahren mit einer komplett neuen Struktur veröffentlicht werden.
Bisher, und auch bei Inkrafttreten des Barrierefreiheitsstärkungsgesetzes, müssen erstmal nur WCAG 2.1 und vermutlich WCAG 2.2 referenziert werden, wenn es um die Einhaltung der Konformität zur Barrierefreiheit geht.
Aufbau der WCAG 2.2
Die WCAG 2.2 bestehen aus 13 Richtlinien (Guidelines), die innerhalb von vier Prinzipien kategorisiert sind. Für jede Richtline gibt es testbare Erfolgskriterien, die wiederum drei Konformitätslevel enthalten: A, AA, und AAA. Level A steht dabei für ein Minimum an Barrierefreiheit und Level AAA für das höchste Maß.
Mit WCAG 2.0 wurden vier Prinzipien eingeführt, die vorschreiben, dass Inhalte wahrnehmbar (Perceivable), bedienbar (Operable), verständlich (Understandable) und robust (Robust) sein müssen – typischerweise abgekürzt mit dem Akronym POUR.
Den vier Prinzipien sind Richtlinien zugeordnet. Jede dieser 13 Richtlinien besteht aus einer Nummerierung und einem Statement, das beschreibt, was für die Erfüllung der Richtlinie benötigt wird.
Die vier Prinzipien
Wahrnehmbar (Perceivable) bedeutet, dass Nutzer:innen in der Lage sein müssen, Webinhalte auf irgendeine Weise wahrnehmen zu können, indem sie einen oder mehr Sinne verwenden.
Diesem Prinzip sind vier Richtlinien zugeordnet:
- 1.1 – Alternativen in Textform: Für alle Inhalte, die nicht in Textform existieren, müssen Alternativen in Textform bereitgestellt werden
- 1.2 – Zeitbasierte Medien: Für zeitbasierte Medien müssen Alternativen bereitgestellt werden.
- 1.3 – Anpassbar: Inhalte sollten auf verschiedene Arten dargestellt werden können, ohne dass Information oder Struktur verloren geht.
- 1.4 – Unterscheidbar: Inhalte sollen leichter sicht- und hörbar gemacht werden, indem vordergründige Inhalte von hintergründigen getrennt werden.
Bedienbar (Operable) bedeutet, dass Nutzer:innen in der Lage sein müssen, Bedienelemente einer Nutzeroberfläche zu bedienen.
Diesem Prinzip sind fünf Richtlinien zugeordnet:
- 2.1 – Tastaturnavigation: Alle Funktionen müssen per Tastaturnavigation steuerbar sein.
- 2.2 – Ausreichend Zeit: Zum Lesen und Benutzen von Inhalten muss ausreichend Zeit gegeben werden.
- 2.3 – Anfälle und körperliche Reaktionen: Inhalte sollen nicht auf Arten gestaltet werden, bei denen bekannt ist, dass sie Anfalle oder körperliche Reaktionen auslösen können.
- 2.4 – Navigierbar: Es gibt Möglichkeiten, Inhalte zu navigieren und finden und Nutzer* innen muss klar sein, wo sie sich befinden.
- 2.5 – Eingabeoptionen: Die Steuerung von Funktionen muss simpel sein über verschiedene Eingabemöglichkeiten (nicht nur Tastatur) hinweg.
Verständlich (Understandable) bedeutet, dass Inhalte von Nutzer:innen verstanden werden können.
Diesem Prinzip sind drei Richtlinien zugeordnet:
- 3.1 – Lesbar: Inhalte in Textform müssen lesbar und verständlich sein.
- 3.2 – Vorhersehbar: Webseiten sollten in Darstellung und Steuerung vorhersehbar sein.
- 3.3 – Eingabeunterstützung: Nutzer*innen muss geholfen werden, Fehler zu vermeiden und zu korrigieren.
Robust (Robust) bedeutet, dass Inhalte mit bewährten Webtechnologien und Standards entwickelt werden sollen, die auf verschiedenen Benutzeragenten funktionieren, sowohl jetzt als auch in Zukunft.
Diesem Prinzip ist eine Richtlinie zugeordnet:
- 4.1 – Kompatibilität: Mit aktuellen und zukünftigen Benutzeragenten (User Agents), inklusive assistiven Technologien, muss die Kompatibilität so hoch wie möglich sein.
Dadurch, dass sich die WCAG auf Prinzipien und Richtlinien fokussiert und nicht auf spezifische Technologien, wird deutlich gemacht, dass es bei der Implementierung von Barrierefreiheit in erster Linie darum geht, wie Menschen mit Inhalten interagieren.
Dadurch wird versucht, so viele Menschen mit Behinderungen und Einschränkungen wie möglich einzubeziehen.
Die Guidelines innerhalb der Prinzipien lassen bei ihren Formulierungen viel Interpretationsspielraum übrig. Um die Richtlinien umsetzbar, messbar und testbar zu machen, wird jede Richtlinie in spezifische, technische Anforderungen heruntergebrochen. Das sind die Erfolgskriterien (Success Criteria).
Erfolgskriterien
In den WCAG 2.2 gibt es 86 Erfolgskriterien. Sie sind die kleinste Einheit des Standards. Ein Erfolgskriterium ist ein testbares, technisches Statement, das spezifische Barrieren adressiert. Sie sind so beschrieben, dass bestimmt werden kann, ob Inhalte die Anforderungen eines Kriteriums erfüllen.
Ich werde in diesem Text nicht auf jedes einzelne Erfolgskriterium eingehen, aber habe drei Beispiele mitgebracht:
- Erfolgskriterium 2.4.2 Seitentitel: Webseiten haben Titel, die das Thema oder den Zweck beschreiben.
- Erfolgskriterium 3.1.1 Sprache der Seite: Die natürliche Sprache jeder Webseite kann programmatisch bestimmt werden.
- Erfolgskriterium 3.1.4 Abkürzungen: Es gibt einen Mechanismus, um Abkürzungen ausgeschrieben anzuzeigen oder sie zu erklären.
WCAG Konformität
Konformität zum WCAG Standard ist erreicht, wenn die Erfolgskriterien erfüllt werden. Wenn es Inhalte gibt, die die Erfolgskriterien nicht erfüllen, so sind sie nicht konform. Welches Erfolgskriterium für welche Inhalte gilt, kommt auf den jeweiligen Inhalt an.
Da die Erfolgskriterien jeweils spezifische Barrieren zu verschiedenen Arten von Inhalten betreffen, sei es Audio, Video, Text, Bilder, etc., gelten natürlich nur die Erfolgskriterien für die Inhalte, die sich auf der Webseite befinden. Also hat eine Webseite keine Videos, so müssen die Erfolgskriterien, die Videos betreffen, nicht erfüllt werden, um WCAG konform zu sein.
Wird eine Webseite einem Audit unterzogen, überprüft man also, ob Inhalte die Kriterien erfüllen, um dann festzustellen, ob die Webseite insgesamt den Anforderungen der WCAG entspricht.
Grundsätzlich gilt, dass eine Webseite entweder WCAG konform oder nicht konform ist. So etwas wie “teilweise konform” gibt es nicht. Ein Erfolgskriterium ist klar testbar und messbar und ist dadurch entweder erfüllt oder nicht erfüllt.
Konformitätslevel: A, AA, AAA
Bei den Web Content Accessibility Guidelines gibt es drei Konformitätslevel: A, AA und AAA.
Diese Level gibt es, um den Bedürfnissen verschiedener Gruppen und unterschiedlicher Situationen gerecht zu werden. A steht dabei für ein absolutes Minimum an Barrierefreiheit und AAA steht für ein hohes Maß an Barrierefreiheit.
Zur Veranschaulichung hilft ein Beispiel:
Dass Farbe nicht der einzige Weg ist, Informationen oder interaktive Elemente anzudeuten, ist ein Level A Erfolgskriterium (1.4.1. Nutzung von Farbe).
Das Erfolgskriterium 1.4.3 Kontrast (Minimum) gibt ein Mindestkontrastverhältnis von 4.5:1 für Darstellung von Text und Bildern von Text vor. Dieses Kriterium fällt unter das Level AA.
Wenn ich das Konformitätslevel AAA erreichen möchte, greift das Erfolgskriterium 1.4.6 Kontrast (Erweitert), das für Darstellung von Text und Bildern von Text ein Mindestkontrastverhältnis von 7:1 vorschreibt.
Je höher das Kontrastverhältnis von Text zu Hintergrund, desto lesbarer ist der Text.
Die Level bauen aufeinander auf. Das bedeutet, dass zur Erfüllung des Levels AA alle Erfolgskriterien des Level A erfüllt sein müssen. Muss Level AAA erreicht werden, so müssen dabei ebenfalls die zwei vorherigen Level erfüllt sein.
Level A
Die Erfüllung von Level A ist das absolute Minimum für die Barrierefreiheit von Webinhalten. Wird dieses Level nicht erfüllt, so könnte Inhalt für Menschen mit Behinderungen oder Einschränkungen komplett unzugänglich sein.
Um Konformität nach Level A zu erreichen, müssen alle Erfolgskriterien, die dem Level zugeordnet sind, erfüllt werden. Wahlweise kann auch eine Alternative, die ebenfalls konform ist, angeboten werden.
Level A ist am einfachsten zu erreichen und hat auch die größte Wirkung in Bezug auf Barrierefreiheit. Trotzdem geht es hier um ein Minimum an Barrierefreiheit, das nicht die Bedürfnisse aller Menschen mit Behinderung abdeckt.
Ein paar Beispiele für Anforderungen, die unter das Level fallen:
- Alternativtexte für Bilder
- Videos sind untertitelt
- Tastaturnavigation ist möglich
Insgesamt fallen 31 Erfolgskriterien unter das Level A.
Level AA
Die Erfüllung der Erfolgskriterien von Level AA ist essenziell für die Barrierefreiheit von Webinhalten. Dabei werden die Barrierefreiheitsanforderungen der meisten Menschen mit Behinderung abgedeckt. Trotzdem bleiben immer noch Barrieren für manche bestehen.
Für die Erfüllung von Level AA müssen ebenfalls alle Kriterien von Level A erfüllt oder ebenfalls konforme Alternativen angeboten werden.
Ein paar Beispiele für Anforderungen, die unter das Level AA fallen:
- besser lesbares Kontrastverhältnis zwischen Text- und Hintergrundfarben
- Inhalte sind über mehrere Geräte (und Viewports) verfügbar
- Inhalte einer Webseite sind zoombar
Insgesamt fallen 24 weitere Erfolgskriterien unter das Level AA, plus die 31 Erfolgskriterien von Level A.
Level AAA
Level AAA ist das höchste Konformitätslevel für Barrierefreiheit. Die Erfüllung aller Erfolgskriterien für das Level sind vielleicht nicht immer möglich, aber selbst, wenn nicht alle Kriterien erreicht werden können, ist es trotzdem empfehlenswert zu versuchen, ein paar der Kriterien, die die Inhalte der eigenen Webseite o.ä. betreffen, zu erfüllen.
Ein paar Beispiele für Anforderungen, die unter das Level AAA fallen:
- ein höheres Mindestkontrastverhältnis als bei Level AA
- Alle Funktionalitäten von Inhalt sind per Tastatur navigierbar, ohne spezielle Timings für einzelne Tastenanschlage
- Animationen können nutzerseitig deaktiviert werden
Für Level AAA müssen 31 weitere Erfolgskriterien erfüllt werden, sowie alle Kriterien von Level A und Level AA erfüllt oder konforme Alternativen geboten werden.
Unterstützung bei Erfüllung von WCAG
Wer sich die Erfolgskriterien mal durchgelesen hat, wird schnell merken, dass sie manchmal einen recht großen Interpretationsspielraum bieten. Ich selbst sitze durch meine Arbeit als Accessibility Consultant manchmal vor Kriterien, nach deren Durchlesen ich fast mehr Fragen als Antworten erhalten habe. Manche sind so formuliert, dass die Erfüllung mit verschiedenen Maßnahmen erreicht werden kann. Ein Beispiel: Erfolgskriterium 1.4.1 Verwendung von Farbe (Level A) besagt:
Farbe wird nicht als einziges Mittel genutzt, um Information zu vermitteln, eine Aktion anzudeuten, eine Reaktion zu erwarten oder ein visuelles Element zu unterscheiden.
Dass das so wage klingt, liegt nicht nur an meiner Übersetzung, die Formulierung ist recht offen gehalten.
Understanding WCAG
Die WCAG bietet in ihrem Bereich Understanding WCAG 2.2 zu jedem Erfolgskriterium eine Hilfe zum Verständnis und zur Implementierung an.
Je Kriterium werden folgende Informationen bereitgestellt:
- Erklärung, warum es das Kriterium gibt (Absicht)
- Aufzählung der Vorteile und wie welche Barrieren dadurch behoben werden
- Anwendungsbeispiele
- Testfälle
- Links zu Lösungsvorschlägen
- Links zu Negativbeispielen
- Weitere nützliche Informationen
Techniques for WCAG
Wie bereits erwähnt, gibt es oftmals viele verschiedene Lösungsansätze, um ein Kriterium zu erfüllen. Dafür bieten die WCAG auch den Bereich Techniques for WCAG 2.2. Das ist eine Sammlung hilfreicher Lösungsmöglichkeiten und typischer Fallstricke, inklusive Beschreibung, Beispiele, Code und Tests.
Praktischerweise findet sich neben jedem Erfolgskriterium in den WCAG auch der passende Link zur jeweiligen Understanding- und Techniques-Seite.
How to Meet WCAG (Quick Reference)
Die Bereiche Understanding und Techniques werden außerdem in einem Checklistenformat bereitgestellt mit dem Namen How to Meet WCAG (Quick Reference).
Die Quick Reference ist sehr praktisch für den Alltag von Designer:innen und Entwickler:innen, da dort alle Richtlinien, Erfolgskriterien, und Lösungen sowie Fallstricke aufgezählt werden. Dabei kann auch flexibel zwischen Inhalten gesprungen werden und alle Informationen werden kompakt bereitgestellt.
Es gibt sogar Filterungsmöglichkeiten nach Konformitätslevel oder für verschiedene Rollen, Themen und Technologien. Außerdem kann nach Inhalten gefiltert werden, sodass nur Erfolgskriterien angezeigt werden zu bestimmten Arten von Inhalt, bspw. Animationen, Audio, Formulare, etc. So kann stets nur das angezeigt werden, was gerade benötigt wird.
Dankbarerweise sind alle Bereiche untereinander querverlinkt. Das heißt, selbst wenn mehr Informationen aus dem Unterstanding-Bereich gebraucht werden, ist der Weg zurück zur Quick Reference in einem Klick möglich.
Erfüllung der WCAG
Die drei oben genannten Bereiche sollen bei der Erfüllung der Erfolgskriterien und bei der Umsetzung helfen. Sie sind keine Vorgaben, sondern eine Hilfestellung. Es ist außerdem nicht empfehlenswert, den erstbesten Lösungsvorschlag stumpf anzunehmen und umzusetzen.
Zum Beispiel kann in den Lösungsvorschlägen genannt werden, dass, um ein Eingabefeld (input field) als Pflichtfeld zu kennzeichnen, das Attribut aria-required verwendet werden kann. Jedoch bietet HTML auch das native HTML-Attribut required. Beide Lösungen sorgen für das gleiche Ergebnis: Das Eingabefeld wird zum Pflichtfeld. Aber grundsätzlich gilt, dass native HTML- Elemente besseren Browser- und Screenreader-Support haben.
Deswegen wäre es geschickter, dieses zu verwenden, als mit einem Aria-Attribut zu arbeiten. Es ist also wichtig, dass wir ein gutes technisches Verständnis für unsere Arbeit mitbringen und bestenfalls regelmäßig testen, damit wir die richtigen Entscheidungen treffen können bei der Umsetzung von Barrierefreiheit.
Grenzen der WCAG
Die Web Content Accessibility Guidelines sind offizielle Empfehlungen, die in Barrierefreiheitsgesetzen zahlreicher Länder der Welt festgehalten werden. Dabei wird meist das Level AA vorgegeben, ab WCAG Version 2.0 aufsteigend.
Während die WCAG schon einen Großteil von Barrieren für verschiedene Geräte, Bedienarten und Behinderungen abdeckt, bedeutet WCAG Konformität nicht gleich, dass die Webseite auch (für alle) gut bedienbar ist. Eine Webseite, App o.ä. kann das Konformitätslevel AAA erfüllen, aber trotzdem eine schlechte Usability haben.
Die Richtlinien sind lediglich ein Messwert, um bei der Implementierung von Barrierefreiheit zu unterstützen.
Manche Behinderungen, gerade im Bereich der kognitiven Behinderungen und Lernbehinderungen, werden von den WCAG gar nicht abgedeckt.
Allein dadurch, dass es Abstufungen in Konformitätslevel gibt, bedeutet “Barrierefreiheit nach Level AA”, dass Inhalte für einen Großteil von Menschen immer noch nicht barrierefrei sind.
Zum Beispiel müssen nach Level AA Abkürzungen nicht zwangsweise erläutert werden. Hat eure Webseite also viele Abkürzungen ohne Erklärungen, dann ist das eine Barriere für zahlreiche Menschen – mit Behinderung oder ohne.
Konformität vs. Usability
Bei der Umsetzung von barrierefreien Inhalten stellen wir uns gerade häufig in erster Linie die Frage nach der Konformität nach WCAG. Dabei sollten wir uns nicht nur fragen “Erfülle ich alle nötigen Erfolgskriterien?”, sondern sollten uns eher fragen “Ist das, was ich erstellt habe, auch gut nutzbar?”
Um das herauszufinden, sind User Tests oder Umfragen wichtig, bei denen wir in Erfahrung bringen, ob wir tatsächlich Barrierefreiheit und sogar gute Usability erreicht haben.
Als meine Kollegen Funktionen einer Webseite an sehbehinderten und blinden Menschen getestet haben, mussten sie mit Erschrecken feststellen, dass einige Funktionen gar nicht benutzbar waren. Das heißt, obwohl sie vorher gewissenhaft versucht haben, alles barrierefrei umzusetzen, konnten sie mit dem Nutzungsverhalten sehender Menschen, eklatante Barrieren für sehbehinderte Menschen nicht bemerken.
Konformität vs. gelebte Inklusion
Im Vortrag Evolving Accessibility, Thinking beyond compliance to inclusion, haben Alistair Duggin und Amani Ali anhand der GOV.UK Webseite gezeigt, wie gelebte Inklusion, die über reine Konformität hinausgeht, aussehen kann.
So wird in einem Kontaktformular, bei dem E-Mail-Adresse und Telefonnummer angegeben werden müssen, ebenfalls erfragt, wie Nutzer:innen kontaktiert werden möchten: schriftlich (kein Anruf), per Anruf (kein Text) oder falls anders, kann per Freitextfeld eine andere Präferenz angegeben werden.
Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenBei Barrierefreiheit nach WCAG Konformität hätte die Erfüllung der Erfolgskriterien für Formularfelder ausgereicht. Indem aber Kontaktmöglichkeiten auswählbar waren, wurde das Kontaktformular für einen Großteil von Menschen barrierefrei gemacht, deren Bedürfnisse durch die Richtlinien nicht angesprochen werden.
Bugs
Selbst wenn Inhalte barrierefrei umgesetzt wurden nach WCAG, kann es sein, dass durch Bugs bei Assistiven Technologien (z.B. Screenreader, Braille Tastatur), oder Browsern bestimmte Funktionen trotzdem nicht verfügbar und nutzbar sind. Durch diese unvorhergesehenen Barrieren können Menschen ausgeschlossen werden.
WCAG sind ein Tool
Durch Gesetzgebung und das Abhaken von Erfolgskriterien kann schnell der Eindruck entstehen, dass WCAG Konformität das Ziel für die Barrierefreiheit von Inhalten ist. Dabei sollten die WCAG Kriterien eher als Tool gesehen werden auf dem Weg zur digitalen Barrierefreiheit. Sie sind die Basis für die Vermeidung von Barrieren.
Barrierefreiheit muss in allen Bereichen, von Konzeption und Design über Entwicklung bis hin zu Testing, mitgedacht und eingeplant werden. Ist nach einem erfolgreichen Audit Konformität nach WCAG erreicht, hören wir bitte nicht auf barrierefreie Inhalte zu designen, coden oder texten.
Fazit
Die Richtlinien helfen Designer:innen, Entwickler:innen und Redakteur:innen dabei, ihre Arbeiten zukunftssicher barrierefrei umzusetzen.
Zum Beispiel sollten Designer:innen sich nicht mehr nur fragen, ob die Farbe, die sie für ihren Primary Button verwenden möchten, hübsch ist, sondern auch, ob sie gut sichtbar ist und ausreichend Kontrast hat.
Entwickler:innen müssen sicherstellen, dass die gebaute Komponente auch ausschließlich per Tastatur navigierbar ist.
Redakteur:innen müssen Alternativtexte für Bilder pflegen, die sinnvoll sind oder sich darüber Gedanken machen, wie die Inhalte der komplexen Grafik, die sie verwenden wollen, auch für Menschen, die eingeschränkt oder gar nicht sehen können, wahrnehmbar gemacht werden können.
Die Web Content Accessibility Guidelines sind ein sinnvolles und nützliches Hilfsmittel, um die ersten Schritte zur digitalen Barrierefreiheit zu gehen. Sie haben aber ihre Grenzen und weisen noch Lücken auf. Sie decken nicht die Bedürfnisse aller Menschen ab, geschweige denn, decken alle Maßnahmen ab, die für barrierefreie Inhalte unternommen werden können. Wenn alle unsere Inhalte die Erfolgskriterien erfüllen und wir gesetzeskonform sind, sollten wir an dieser Stelle nicht aufhören, digitale Barrierefreiheit in unsere Arbeit zu integrieren.
Schließlich erstellen wir Inhalte für Menschen, nicht für Gesetze, die eingehalten werden müssen.
Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen
