TechCheck: Analyse und Tipps zum Barrierefreiheitsstandard WCAG 2
Cedrico Knoesel
Softwareentwickler
Das Barrierefreiheitsstärkungsgesetz (BFSG) und die Barrierefreie-Informationstechnik-Verordnung (BITV) setzen in Deutschland den rechtlichen Rahmen für die Barrierefreiheit im privaten und öffentlichen Sektor, respektive. Beide beziehen sich in § 4 BFSG bzw. § 3 Abs. 2 BITV auf harmonisierte Normen der Barrierefreiheit, wie die EN 301 549. Demnach wird beim Einhalten dieser Norm vermutet, dass die Anforderungen der entsprechenden Verordnung erfüllt sind. So kann diese als konkrete Anforderungsvorschrift zur Barrierefreiheit angesehen werden.
Die Norm EN 301 549 selbst verweist wiederum in Kapitel 9 für Webinhalte auf die Web Content Accessibility Guidelines (WCAG), welche ein international anerkannter Standard für Barrierefreiheit ist und vom World Wide Web Consortium (W3C) entwickelt wird. Somit hat die WCAG praktische Relevanz für jeden, der sich an Barrierefreiheitsgesetze halten möchte oder muss. Dieser TechCheck widmet sich dieser Richtlinie.
Geschichte der Entwicklung des Standards
Die erste Version von WCAG wurde im Jahr 1999 veröffentlicht. Zwei Jahre danach begann bereits die Weiterentwicklung für die Version 2.0, welche dann 2008 veröffentlicht wurde. Diese Version wurde in den Jahren 2018 und 2023 mit der Veröffentlichung der Versionen 2.1 und 2.2 leicht erweitert. Währenddessen haben jedoch bereits Ende 2016 erste Studien für eine Komplettüberarbeitung der Richtlinie, die Version 3.0, gestartet. Diese Version ist allerdings noch heute in Entwicklung und wird frühestens 2029 veröffentlicht.
Die aktuelle Empfehlung vom W3C ist die Version 2.2. Für das BFSG und BITV ist allerdings bisher noch nur die Version 2.1 relevant. Das wird sich erst mit einer Aktualisierung der Norm EN 301 549 ändern, welche bereits in Arbeit ist. Die Versionen 2.0 bis 2.2 verfolgen ähnliche Konzepte, daher verwenden wir im Folgenden an vielen Stellen nur „WCAG 2“, wenn von diesen gemeinsamen Konzepten die Rede ist.
Aufbau und Konformität mit WCAG 2
WCAG 2 ist zunächst in vier Prinzipien aufgeteilt. Diese sind Wahrnehmbar, Bedienbar, Verständlich und Robust. Das sind die vier Grundpfeiler der Barrierefreiheit von Webinhalten. Dabei lassen sie sich wie folgt beschreiben:[1]
Wahrnehmbar: Informationen und Inhalte müssen dem Nutzer so präsentiert werden, dass sie von ihm wahrgenommen werden können. Hier geht es zum Beispiel um angemessene Kontraste und Farben oder aber auch Textalternativen für visuelle Inhalte für seheingeschränkte Nutzer.
Bedienbar: Die Navigation und Interaktion mit Kontrollelementen muss so gestaltet sein, dass sie von allen Nutzergruppen bedienbar ist. Das betrifft zum Beispiel das Ermöglichen einer Tastaturnavigation für Personen, die eine Maus nicht benutzen können (oder wollen).
Verständlich: Die Informationen und Aktionsmöglichkeiten müssen verständlich sein. Das bedeutet, dass zum Beispiel keine zu komplexe Sprache verwendet werden soll oder die Navigation und der Aufbau der Seiten vorhersehbar ist.
Robust: Inhalte müssen robust genug gestaltet sein, sodass sie kompatibel mit heutigen und möglichst auch zukünftigen assistiven Technologien sind. In diese Sparte fällt zum Beispiel das Verwenden von korrekten HTML-Tags, sodass Screenreader den Inhalt korrekt interpretieren können.
In diese vier Prinzipien sind dann 12 (bzw. ab Version 2.1 13) Richtlinien eingeteilt. Diese beschreiben grundlegende Ziele, die die Zugänglichkeit von angebotenen Inhalten für Personengruppen mit unterschiedlichen Anforderungen und Einschränkungen erhöhen. Eine Richtlinie ist dabei selbst noch nicht testbar. Ein Beispiel hierfür ist die folgende Richtlinie:
Richtlinie 1.4 (Unterscheidbar): Erleichtern Sie es Nutzern Inhalte zu sehen und zu hören, einschließlich des Unterscheidens von Vordergrund und Hintergrund. [2]
Eine Richtlinie besteht dann aus unterschiedlichen Erfolgskriterien. Diese sind die tatsächlich testbaren Kriterien. Sie beschreiben einzelne Aspekte, die eingehalten werden müssen, auch um die Konformität mit dem Standard zu behaupten. Die obige Richtlinie hat zum Beispiel unter anderem folgendes Erfolgskriterium:
Erfolgskriterium 1.4.1 (Farbnutzung): Farbe wird nicht als einziges Kriterium verwendet, um Informationen zu übermitteln, eine Aktion anzudeuten, eine Antwort anzufordern oder visuelle Element voneinander zu unterscheiden.[3]
Jedes Erfolgskriterium ist eingeteilt in die drei Level A, AA und AAA. Wenn man alle Erfolgskriterien mit Level A erfüllt, ist man konform gemäß Level A – die niedrigste Konformitätsstufe. Wenn zusätzlich noch alle mit Level AA erfüllt sind, enthält erhält man die Stufe AA und analog mit AAA. In aktueller Gesetzgebung (BFSG und BITV) wird eine Konformität nach Stufe AA erfordert, demnach ist diese als Pflicht und AAA als Kür anzusehen. Es ist zudem selten sinnvoll, alle Kriterien aus AAA zu erfüllen.
Die Richtlinien und Erfolgskriterien enthalten dann noch zusätzlich informative Techniken zur Erfüllung der Kriterien. Diese Techniken sind nicht erforderlich für eine Konformität, aber sie bieten verlässliche Wege, um die Erfolgskriterien zu erfüllen.
Praktische Tipps zur Umsetzung der Barrierefreiheit von Webseiten
Nach der vielen Theorie bisher kommen wir nun hin zur praktischen Frage: Was muss ich tatsächlich tun, damit ich konform gemäß WCAG 2 bin?
Wir haben gerade gesehen, dass zur Einhaltung der Barrierefreiheitsanforderungen gem. BFSG, eine WCAG-Konformität von Level AA erforderlich ist. Demnach muss ich als Ersteller von Webinhalten dafür sorgen, dass meine Inhalte alle Erfolgskriterien der Stufe A und AA erfüllen. Anzumerken sei noch, dass gem. § 5.2.2 WCAG 2.2 Konformität stets nur für komplette Webseiten ausgesprochen werden kann. D.h. die Erfolgskriterien müssen für alle Inhalte gleichmäßig gelten.
Des Weiteren können wir hier keine bindenden Empfehlungen für eine rechtskonforme Einhaltung aller dieser Kriterien geben. Dies bedarf einer individuellen Prüfung. Es gibt allerdings Tools, die eine Konformität prüfen können. Eine Auflistung solcher Tools hat auch das W3C selbst veröffentlicht.[4] Hiermit können die eigenen Webangebote auf Schwachstellen in der Barrierefreiheit geprüft werden. Außerdem gibt es eine anpassbare Schnellübersicht der Erfolgskriterien ebenfalls vom W3C selbst veröffentlicht mit den Techniken zur Erfüllung der Kriterien.[5]
Allerdings ist es zu empfehlen bereits im Entwicklungsprozess grundlegende Anforderungen an die Barrierefreiheit zu beachten. Das spart im Nachhinein Zeit und Kosten. Außerdem erhöhen viele Prinzipien der Barrierefreiheit auch die Nutzerfreundlichkeit der Inhalte an sich. Es folgen ein paar grundlegende Tipps und Empfehlungen, die während des Entwicklungsprozesses beachtet werden sollten. Diese sind weder vollständig noch repräsentativ für Anforderungen aus allen Nutzergruppen.
Tipp 1: Verwende Alternativtexte für visuelle Elemente
Jedes Bild sollte mit Alternativtexten ausgestattet werden. Diese sind erforderlich für zum Beispiel blinde Personen, die einen Screenreader verwenden, um sich die Inhalte vorlesen zu lassen. In HTML geht das über das Attribut alt beim <img> Tag für Bilder. Hier ist ein Beispiel:
<img alt="Eine Pudel mit Hut." src="poodle-with-hat.jpg"/>
Auch bei Websitebaukästen gibt es üblicherweise die Möglichkeit beim Einbinden von Bildern Alternativtexte zu hinterlegen.
Tipp 2: Verwende stets die vorgesehenen Tags
Wir stellen uns vor, wir möchten eine Überschrift für einen Blog-Beitrag erstellen. Eine Möglichkeit wäre jetzt, dass wir die Schriftgröße erhöhen und eventuell noch fett formatieren. In HTML würde das dann so aussehen:
<p style=“font-size: 1.8em; font-weight: bold;“>
Hutmode für Pudel
</p>
Für sehende Nutzer ist es erkennbar, dass es sich hier um eine Überschrift halten soll, da der Text fett und größer ist. Ein Screenreader liest den Titel aber genauso vor, wie den restlichen Text, da er Schriftgrößen oder ähnliches nicht vorliest. Hier ist die Überschrift dann nicht mehr als solche erkennbar. Die Lösung dafür bietet HTML selbst:
<h1>Hutmode für Pudel</h1>
Der Tag <h1> fügt dabei automatisch die semantische Information hinzu, dass es sich um eine Überschrift handelt. Screenreader sind damit kompatibel und können dann sogar von Überschrift zu Überschrift springen, was die Navigation deutlich erleichtert.
Auch in Editoren von Websitebaukästen gibt es häufig Optionen, um Überschriften zu kennzeichnen.
Generell bietet HTML bereits nativ eine Vielzahl an Tags an. Es empfiehlt sich diese auch zu nutzen. So sollte man zum Beispiel <menu>, <nav>, <article> oder <dialog> verwenden, anstatt stets nur <div> zu nutzen.
Tipp 3: Verwende ARIA-Labels
ARIA-Labels sind zusätzliche Attribute von HTML-Tags, die tiefere semantische Bedeutungen den Elementen hinzufügen können.[6] Assistive Technologien können diese Informationen dann nutzen. Ein Beispiel ist folgender Button zum Schließen:
<button aria-label=”Schließen” onclick=…>X</button>
Das ARIA-Label fügt hier die semantische Bedeutung hinzu, dass es sich um einen Button zum Schließen eines Elements handelt.
Tipp 4: Definiere die Sprache der Website
Viele Browser unterstützen mittlerweile eine automatische Übersetzung von fremdsprachigen Inhalten. Dazu muss der Browser allerdings informiert werden, in welcher Sprache die Inhalte ursprünglich vorliegen. In HTML geht das über das lang Attribut im <html> Tag. Hier ein Beispiel:
<html lang=“de“>
<body>…</body>
</html>
Das teilt dem Browser mit, dass es sich bei dieser Website um eine deutsche Seite handelt. Einem zum Beispiel polnischen Nutzer kann dann vom Browser angeboten werden, diese Inhalte von Deutsch auf Polnisch zu übersetzen.
Tipp 5: Nutze selbst einmal einen Screenreader
Im Entwicklungsprozess ist es üblich die Anwendung auf unterschiedlichen Geräten (Desktop, Mobile, …) zu testen. Jedoch hat ein Großteil der sehenden Bevölkerung noch nicht einmal einen Screenreader generell verwendet. So ist es kaum möglich sich vorzustellen vor welchen Hürden manche Nutzergruppen stehen können. Ein Selbstversuch mit einem Screenreader kann dabei viel Einsicht bringen. Windows hat zum Beispiel selbst einen integrierten Screenreader, den man mit Strg+Win+Enter starten kann.
Im Ergebnis bleibt
Mit dem European Accessibility Act und dem Barrierefreiheitsstärkungsgesetz hat der Gesetzgeber den Druck auf die Umsetzung digitaler Barrierefreiheit erhöht. Das zeigt, dass eine Auseinandersetzung mit Barrierefreiheit immer notwendiger wird. In diesem TechCheck haben wir die Web Content Accessibility Guidelines als eins der bekanntesten Standards für digitale Barrierefreiheit von Webinhalten analysiert. Das Thema scheint zunächst komplex, allerdings gibt es einige leicht umzusetzende Punkte, die bereits mit wenig Aufwand die Barrierefreiheit verbessern können.
[1] Siehe https://www.w3.org/WAI/WCAG22/Understanding/intro#understanding-the-four-principles-of-accessibility (zuletzt abgerufen am 24.02.2026).
[2] Übersetzt aus WCAG 2.2, abrufbar unter: https://www.w3.org/TR/WCAG22/ (zuletzt abgerufen am 24.02.2026).
[3] Übersetzt aus WCAG 2.2 abrufbar unter: https://www.w3.org/TR/WCAG22/ (zuletzt abgerufen am 24.02.2026).
[4] https://www.w3.org/WAI/test-evaluate/tools/list/ (zuletzt abgerufen am 24.02.2026).
[5] https://www.w3.org/WAI/WCAG22/quickref/ (zuletzt abgerufen am 24.02.2026).
[6] Weitere Informationen hier: https://developer.mozilla.org/de/docs/Web/Accessibility/ARIA (zuletzt abgerufen am 24.02.2026).
Brüssel plant überraschende Kurskorrektur beim AI Act
Florian Hackel
Rechtsanwalt und Fachanwalt für IT-Recht
Adrian Janßen
Studentische Hilfskraft
Ein aktueller Entwurf der Europäischen Kommission offenbart Pläne für eine gezielte Überarbeitung („Digital Omnibus on AI“) des erst kürzlich in Kraft getretenen EU AI Acts. Die Initiative zielt darauf ab, die bürokratische Last für Unternehmen und Verwaltungen radikal zu reduzieren und die Wettbewerbsfähigkeit der Union zu stärken, ohne dabei das hohe Schutzniveau zu beeinträchtigen. Im Folgenden werden ausschnittsweise die relevantesten Anpassungen erläutert.
KI-Kompetenz Pflicht, Ade[1]
Art. 4 AI Act sah ursprünglich eine horizontale Verpflichtung für alle Anbieter und Betreiber von KI-Systemen vor, die KI-Kompetenz (AI literacy) ihrer Mitarbeiter zu gewährleisten. Diese soll nun entfernt und durch eine neue Bestimmung in Art. 4 AI Act ersetzt werden. Die Pflicht soll auf die Kommission und die Mitgliedstaaten verlagert werden. Diese sollen Anbieter und Betreiber dazu ermutigen und unterstützen, Maßnahmen zur Gewährleistung eines ausreichenden Niveaus an KI-Kompetenz bei ihrem Personal zu ergreifen.
Bisheriger Art. 4 AI Act: „Providers and deployers of AI systems shall take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account […].
Geplante Anpassung: „The Commission and Member States shall encourage providers and deployers of AI systems to take measures to ensure a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account their technical knowledge, experience, level of education and training and the context the AI systems are to be used in, and considering the persons or groups of persons on whom the AI systems are to be used.“
Die ursprüngliche horizontale Verpflichtung wurde als ineffektiv und als ungeeignete Einheitslösung angesehen. Zudem hätte sie eine zusätzliche Compliance-Last erzeugt, insbesondere für kleine Unternehmen. Obwohl die Änderung die Bürokratie reduzieren und die Implementierung insbesondere für KMU vereinfachen kann, bedeutet die Streichung der Verpflichtung, dass die Anbieter und Betreiber keinen direkten Anreiz mehr haben, in die KI-Kompetenz ihrer Mitarbeiter zu investieren, obwohl diese Kompetenz insbesondere mit Blick auf mögliche Haftungsrisiken bei Fehlern der Mitarbeiter im Umgang mit KI bereits aus Eigeninteresse des Unternehmens einen möglichst hohen Stellenwert haben sollte. Die Haftungsrisiken entstehen z.B., wenn menschliches Versagen bei der Überwachung, Validierung oder durch die Fehlinterpretation von KI-Ergebnissen zu Schäden führt. Ein nicht ausreichend geschulter Mitarbeiter könnte beispielsweise die Hinweise eines Hochrisiko-KI-Systems ignorieren oder dessen Empfehlungen falsch interpretieren und in einem ungeeigneten Kontext anwenden. Eine Investition in die KI-Kompetenz ist eine präventive Risikomanagement-Maßnahme, um das Risiko potenzieller Schadensersatzansprüche Dritter zu reduzieren und das Vertrauen von Kunden in die eigenen KI-unterstützten Produkte zu fördern. Zudem sieht auch der bisherige Art. 4 AI Act gar keine Einheitslösung vor und lässt Spielraum für eine individuelle Lösung, sodass auch dieses Argument fraglich ist.
Geplante Verschiebung der Compliance-Fristen für Hochrisiko-KI[2]
Nach der aktuellen Rechtslage greifen gem. Art. 113 AI Act die Pflichten für Hochrisiko-KI-Systeme des Anhang III ab dem 2. August 2026. Für KI-Systeme, die als Sicherheitskomponenten in regulierten Produkten gemäß Anhang I verbaut sind, beginnt die Compliance-Pflicht nach jetzigem Stand erst am 2. August 2027. Die Europäische Kommission schlägt nun jedoch vor, den Beginn dieser Verpflichtungen flexibler zu gestalten und direkt an die Verfügbarkeit harmonisierter technischer Standards sowie weiterer Unterstützung zu koppeln. Das bedeutet, dass der genaue Zeitpunkt des Inkrafttretens derzeit nicht feststeht, sondern von der Geschwindigkeit der Normungsorganisationen abhängt. Sollten die Standards rechtzeitig fertig und genehmigt sein, würden die Regeln für Anhang-III-Systeme sechs Monate und für Anhang-I-Produkte zwölf Monate nach der Genehmigung wirksam werden. Falls sich die Erarbeitung der Standards hingegen verzögert, sollen fest definierte Termine als Sicherheitsnetz greifen. Diese sind der 2. Dezember 2027 für Anhang-III-Systeme und der 2. August 2028 für Produkte des Anhangs I. Sollte der Änderungsvorschlag allerdings nicht vor dem ursprünglichen Stichtag im August 2026 verabschiedet werden, bliebe es bei den alten, früheren Fristen.
Reduzierte Registrierungspflichten für bestimmte Nicht-Hochrisiko-KI-Anwendungen[3]
Die Verpflichtung für Anbieter, KI-Systeme in der EU-Datenbank für Hochrisiko-Systeme zu registrieren (gemäß Anhang III), soll angepasst werden. Konkret sollen Art. 49 Abs. 2 AI Act und Abschnitt B von Anhang VIII AI Act entfernt werden. Dies soll für KI-Systeme gelten, die in Hochrisikobereichen eingesetzt werden, für die der Anbieter jedoch zu dem Schluss gekommen ist, dass sie kein hohes Risiko darstellen, da sie nur für eng gefasste oder prozedurale Aufgaben verwendet werden (Ausnahme gem. Art. 6 Abs. 3 AI Act). Trotzdem muss ein Anbieter, der ein System unter die Ausnahme des Art. 6 Abs. 3 AI Act einstuft, seine Risikobewertung dokumentieren, bevor das System in Verkehr gebracht wird. Diese Dokumentation kann von den national zuständigen Behörden angefordert werden. Problematisch ist diese Änderung insbesondere deswegen, da sie Anbietern ermöglicht, einseitig zu entscheiden, dass ihr System zwar der Beschreibung eines risikoreichen Systems entspricht, tatsächlich aber kein erhebliches Risiko für die Grundrechte darstellt. Die bisherige Regelung sollte zumindest eine gewisse öffentliche Kontrolle ermöglichen, da durch die Aufnahme in die Datenbank zuständige Regulationsstellen einen einfachen Einstiegspunkt in eine Überprüfung des Systems nach dem AI Act ermöglicht würde. Durch die Neuregelung entfällt dieser Einstiegspunkt, was es öffentlichen Stellen wesentlich schwerer machen dürfte, von den Unternehmen selbst falsch bewertete Systeme zu identifizieren.
Verarbeitung besonderer Kategorien personenbezogener Daten zur Bias-Erkennung [4]
Es soll eine Rechtsgrundlage eingefügt werden, die es Anbietern und Betreibern aller KI-Systeme und -Modelle (und nicht mehr nur Hochrisiko) erlauben soll, besondere Kategorien personenbezogener Daten ausnahmsweise zu verarbeiten. Dies soll mithilfe eines neuen Art. 4a AI Act geschehen, der Art. 10 Abs. 5 AI Act ersetzen soll. Die Verarbeitung wäre in diesem Fall zulässig, soweit sie notwendig ist, um Bias (Voreingenommenheit) zu erkennen und zu korrigieren. Dies dient einem wesentlichen öffentlichen Interesse, nämlich dem Schutz natürlicher Personen vor den nachteiligen Auswirkungen von Voreingenommenheit von KI-Systemen, einschließlich der Diskriminierung durch diese. Die Verarbeitung soll unter Einhaltung strenger Auflagen, die den bisherigen Art. 10 Abs. 5 lit. a bis f AI Act entsprechen, erfolgen, um die Grundrechte und -freiheiten der betroffenen Personen zu schützen.
“To the extent necessary to ensure bias detection and correction in relation to high-risk AI systems in accordance with Article 10 (2), points (f) and (g), of this Regulation, providers of such systems may exceptionally process special categories of personal data, subject to appropriate safeguards for the fundamental rights and freedoms of natural persons. In addition to the safeguards set out in Regulations (EU) 2016/679 and (EU) 2018/1725 and Directive (EU) 2016/680, as applicable, all the following conditions shall be met in order for such processing to occur: […]”
“Paragraph 1 may apply to providers and deployers of other AI systems and models and deployers of high-risk AI systems where necessary and proportionate if the processing occurs for the purposes set out therein and provided that the conditions set out under the safeguards set out in this Paragraph.“
Spagat zwischen Wettbewerb und Sicherheit
Der Entwurf verdeutlicht, dass die Kommission gewillt ist, den AI Act noch vor seinem vollen Geltungsbeginn signifikant „nachzuschärfen“. Während die bürokratischen Erleichterungen für KMU angesichts der globalen Konkurrenz ein wichtiges Signal sind, birgt das Paket (politischen) Zündstoff. Die Verlagerung der Verantwortung weg von den Unternehmen, etwa bei der KI-Kompetenz, und die neuen Ausnahmen bei der Registrierungspflicht sind eine starke Aufweichung des ursprünglichen Schutzniveaus. Es bleibt abzuwarten, wie viele dieser weitreichenden Vereinfachungsvorschläge die kommenden politischen Verhandlungen tatsächlich in ihrer bisher vorgesehenen Form überstehen werden.
[1] Digital Omnibus on AI Regulation Proposal S. 12, 20 f.
[2] Digital Omnibus on AI Regulation Proposal S. 18
[3] Digital Omnibus on AI Regulation Proposal S. 14, 24
[4] Digital Omnibus on AI Regulation Proposal S. 13, 21