Was WCAG 2.2 AA tatsächlich von einer Lernplattform verlangt

Wenn Ihre Lernplattform die Öffentlichkeit, Behörden, Hochschulen oder Beschäftigte in der EU bedient, ist Barrierefreiheit kein netter Zusatz mehr. Sie ist eine rechtliche Pflicht mit konkreten Terminen – und einige davon liegen nah genug, um schon in diesem Jahr wichtig zu sein.

Dieser Beitrag erklärt, was „barrierefrei“ bei einer Lernplattform tatsächlich bedeutet, wer welche Frist einhalten muss, wo diese Plattformen am häufigsten scheitern und wie stark sich die Kosten unterscheiden, je nachdem ob Barrierefreiheit von Anfang an eingebaut oder erst nach einer Beschwerde ergänzt wird. Er richtet sich an Menschen, die über Entwickeln oder Kaufen entscheiden, nicht an Compliance-Fachleute, und vermeidet deshalb unnötige Normensprache. Dies ist ein praktischer Leitfaden und keine Rechtsberatung. Lassen Sie Ihre konkreten Pflichten juristisch prüfen, wenn Geld und Fristen auf dem Spiel stehen.

Die Kurzfassung

Der Standard, auf den fast alle Gesetze verweisen, sind die Web Content Accessibility Guidelines, WCAG, auf Konformitätsstufe AA. WCAG kennt drei Stufen: A ist das Mindestmaß, AA die von Aufsichtsstellen tatsächlich verlangte Stufe und AAA ein anspruchsvolles Ziel, das selten vollständig vorgeschrieben wird.

Die aktuelle Fassung ist WCAG 2.2 von Ende 2023. Viele Gesetze nennen noch 2.1, weil sie vor Veröffentlichung der neuen Version geschrieben wurden. 2.2 übernimmt fast alles aus 2.1 und ergänzt einige Kriterien, die gerade für Lernprodukte wichtig sind. WCAG 2.2 AA ist daher das sinnvolle Ziel: Es erfüllt die heutigen Regeln und nimmt künftige vorweg.

Barrierefreiheit ist keine Funktion, die später hinzugefügt wird. Sie ist eine Eigenschaft jeder Oberfläche, jedes Formulars und jeder Interaktion. Das erklärt den Rest – vor allem, weshalb sie früh günstig und spät teuer ist.

Wer wann verpflichtet ist

Eine einzige weltweite Regel gibt es nicht. Mehrere können gleichzeitig für dieselbe Plattform gelten.

Einige Punkte sind besonders wichtig.

Für den öffentlichen US-Sektor läuft ein echter Countdown. Das Justizministerium hat unter ADA Title II feste Termine gesetzt. Größere öffentliche Einrichtungen hatten bis April 2026 Zeit, kleinere bis April 2027. Wenn Sie an Schulbezirke, Community Colleges oder staatliche Universitäten verkaufen, stehen Ihre Käufer unter Zeitdruck und fragen heute in der Beschaffung danach.

Private Unternehmen sind nicht ausgenommen. Im ADA steht kein Satz, der Websites ausdrücklich WCAG vorschreibt. Gerichte haben Websites und Apps privater Unternehmen jedoch wiederholt einbezogen; der praktische Maßstab ist WCAG AA. Der Druck kommt hier nicht als Stichtag, sondern als Forderungsschreiben einer Kanzlei. Edtech ist ein häufiges Ziel, weil Menschen mit Behinderungen selbstverständlich zur Zielgruppe gehören.

Die EU hat den Kreis im Juni 2025 erweitert. Öffentliche Hochschulen waren bereits erfasst. Der European Accessibility Act dehnt Pflichten auf viele private digitale Verbraucherdienste aus. Verkauft Ihre Plattform Onlinekurse an Menschen in der EU, sollten Sie nicht annehmen, außerhalb des Anwendungsbereichs zu liegen.

Durch verschiedene Türen kommt also derselbe Standard: WCAG AA. Wer einmal dafür baut, beantwortet alle.

WCAG in klarer Sprache: vier Fragen

WCAG ordnet sich um vier Prinzipien, auf Englisch als POUR abgekürzt: Perceivable, Operable, Understandable, Robust. Ohne Fachsprache sind es vier einfache Fragen.

• Wahrnehmbar. Kann ein Mensch Inhalte über mehr als einen Sinn aufnehmen? Videos brauchen Untertitel für Menschen, die sie nicht hören, und eine Abschrift für Screenreader. Bedeutungsvolle Bilder brauchen Textbeschreibungen.
• Bedienbar. Funktioniert alles ohne Maus? Schaltflächen, Menüs, Quiz und Videosteuerungen müssen allein mit der Tastatur nutzbar sein.
• Verständlich. Ist die Oberfläche klar und vorhersehbar? Beschriftungen sind eindeutig, Fehlermeldungen erklären die Lösung und Elemente verändern sich nicht überraschend.
• Robust. Funktioniert die Seite mit assistiver Technik? Ein Screenreader muss zu jedem Bedienelement Art, Namen und Zustand korrekt ansagen können.

Jedes einzelne WCAG-Kriterium konkretisiert eine dieser Fragen. Fast jeder Prüfbericht lässt sich darauf zurückführen.

Wo Lernplattformen tatsächlich scheitern

Allgemeine Ratschläge behandeln Websites. Lernplattformen spielen Videos ab, führen zeitbegrenzte Prüfungen durch, betten fremde Inhalte ein und halten lange interaktive Sitzungen. Dort treten wiederholt dieselben Fehler auf.

Video- und Audiolektionen ohne Untertitel oder Transkript. Das ist der häufigste E-Learning-Fehler und bereits ein klarer Verstoß gegen Stufe A. Automatische Untertitel sind ein Anfang, reichen bei Fachbegriffen, Namen und Akzenten allein aber nicht aus.

Nicht anpassbare Quiz-Timer. Ein starrer Countdown, den Lernende weder verlängern noch abschalten können, verletzt ein WCAG-Kriterium zur Zeitbegrenzung. Er benachteiligt zudem Screenreader-Nutzer und alle, die mehr Zeit brauchen. Bei Prüfungen treffen Barrierefreiheit und Fairness aufeinander; lesen Sie dazu auch Prüfungen so gestalten, dass Täuschungen erschwert werden.

Drag-and-drop-Aufgaben, die eine Maus verlangen. Zuordnungs- und Sortieraufgaben werden oft ohne Tastaturalternative gebaut und schließen damit ganze Nutzergruppen aus. WCAG 2.2 fordert ausdrücklich eine Alternative zum Ziehen.

Status nur durch Farbe. Ein grüner Punkt für „erledigt“ und ein roter für „überfällig“ sagt Menschen, die beide nicht unterscheiden, nichts. Farbe darf einen Status unterstützen, aber niemals allein vermitteln.

Zu geringer Kontrast auf Markenfarben. Hellgrauer Text oder Weiß auf einer blassen Markenfarbe verfehlen regelmäßig das geforderte Kontrastverhältnis. Automatische Scans finden diesen Fehler besonders oft; meist begann er mit einer Designentscheidung ohne Kontrastprüfung.

Eigene Komponenten ohne Namen und Rolle. Fortschrittsbalken, Akkordeons, Tabs und Dialoge aus generischen Elementen teilen einem Screenreader oft nichts Brauchbares mit. Lernende hören „Schaltfläche“ und wissen nicht wofür – oder hören das Element gar nicht. So scheitert das Prinzip „Robust“ in der Praxis.

Tastaturfallen und unsichtbarer Fokus. Wer mit Tab in einen Videoplayer oder Dialog gelangt, aber nicht mehr heraus, sitzt fest. Verbirgt das Design zusätzlich die Fokusmarkierung, weiß die Person nicht, wo sie sich befindet.

Der Inhalt im Inhalt. Ihre Plattform kann barrierefrei sein, während das SCORM-Paket, PDF-Arbeitsheft oder die eingebettete Präsentation es nicht ist. Ein Screenreader liest weder ein ungetaggtes PDF noch ein schlecht erstelltes SCORM-Modul. Die Konformität ist nur so stark wie der unzugänglichste ausgelieferte Inhalt – und vieles davon ist Content, nicht Code.

Anmelderätsel und winzige Touch-Ziele. WCAG 2.2 ergänzt Regeln, die Lernprodukte direkt betreffen: Die Authentifizierung darf niemanden zu Gedächtnis- oder Rätselaufgaben zwingen, und interaktive Ziele müssen groß genug sein, um sie zuverlässig zu treffen, besonders auf Smartphones.

Die ehrlichen Kosten: einbauen oder nachrüsten

Was wenige Anbieter offen sagen: Barrierefreiheit ist günstig, wenn sie zur Bauweise gehört, und teuer, wenn sie zum Reparaturprojekt wird.

Der Grund ist strukturell. Sie lebt in Komponenten: semantisches Markup, korrekte Beschriftungen, sinnvolle Fokussteuerung und Untertitel im Content-Prozess. Entwickelt ein Team diese Gewohnheiten ab der ersten Komponente, ist der Zusatzaufwand gering und besteht überwiegend aus Disziplin und Tests. Er verschwindet in den normalen Kosten guter Entwicklung.

Eine Nachrüstung ist ein anderes Projekt. Dieselbe Schaltfläche kann bereits auf vierzig Seiten verwendet werden. Eine Korrektur verbessert zwar alle, danach müssen aber alle vierzig erneut geprüft werden – ebenso jeder Aufgabentyp, Dialog und jede Seite, deren Fokusreihenfolge nie bedacht wurde. Sie ergänzen keine Funktion. Sie öffnen das Fundament eines laufenden Systems, und zwar unter einer rechtlichen Frist.

Dasselbe gilt für die Sicherheit von Schülerdaten: Architektureigenschaften sind vor dem Start günstig und danach teuer. Sicherheit und Barrierefreiheit verlieren Prioritätskämpfe aus demselben Grund – wenn sie funktionieren, sind sie unsichtbar. Das sichtbare Feature gewinnt, bis das Versäumnis öffentlich wird. Wenn Sie überhaupt über eine Eigenentwicklung nachdenken, gehört Barrierefreiheit von Anfang an in den Umfang und damit zu den tatsächlichen Kostentreibern einer E-Learning-Entwicklung.

So prüfen Sie Ihren aktuellen Stand

Für eine ehrliche erste Einschätzung brauchen Sie kein formelles Audit. Vier Durchgänge zeigen den Großteil der Risiken.

1. Führen Sie einen automatischen Scan aus. axe, WAVE oder die Lighthouse-Prüfung finden Kontrastprobleme, fehlende Beschriftungen und Strukturfehler in Minuten. Das Ergebnis ist eine Untergrenze, kein Urteil: Automatik erkennt nur etwa ein Drittel bis die Hälfte der echten Probleme.
2. Legen Sie die Maus weg. Absolvieren Sie Lektion und Quiz nur mit der Tastatur: Tab zum Bewegen, Eingabe und Leertaste zum Auslösen, Pfeiltasten in Menüs. Wenn Sie steckenbleiben oder die Orientierung verlieren, geschieht Tastaturnutzern dasselbe.
3. Schalten Sie einen Screenreader ein. VoiceOver ist auf jedem Mac vorhanden, NVDA unter Windows kostenlos. Schließen Sie die Augen und navigieren Sie durch eine Lektion. Das ist anfangs unangenehm und lehrreicher als jeder Bericht.
4. Prüfen Sie die Content-Ebene getrennt. Öffnen Sie ein typisches SCORM-Modul, Kurs-PDF und Lernvideo. Prüfen Sie jedes für sich auf Untertitel, Tags und Navigation. Diese Ebene kann scheitern, obwohl die Plattform besteht.

Wenn Sie kaufen, kommt ein fünfter Schritt hinzu: Verlangen Sie das VPAT des Anbieters, auch Accessibility Conformance Report genannt. Darin erklärt er Kriterium für Kriterium, wie das Produkt WCAG erfüllt. Wer kein Dokument vorlegen kann – oder perfekte Konformität ohne jede Einschränkung behauptet – sagt in beiden Fällen viel aus.

Was „konform“ leistet – und was nicht

WCAG 2.2 AA senkt das rechtliche Risiko und öffnet die Plattform vor allem für ungefähr jeden sechsten Menschen weltweit, der mit einer erheblichen Behinderung lebt. Das ist ein großer Anteil jeder Lerngruppe.

Konformität garantiert dennoch keine gute Erfahrung. Eine Plattform kann alle Prüfpunkte technisch bestehen und mit assistiver Technik mühsam bleiben. Die Checkliste ist der Boden, nicht die Decke. Sie ist auch kein einmal erworbenes Zertifikat. Jede neue Funktion, jeder Upload und jede Fremdeinbettung kann einen neuen Fehler erzeugen. Gute Teams behandeln Barrierefreiheit deshalb als dauerhaften Teil ihrer Entwicklungs- und Prüfprozesse, nicht als einmalige Aufräumaktion.

Die Schlussfolgerung entspricht jener für Sicherheit und Daten. Eigenschaften, die Nutzer und Unternehmen schützen, sind frühe Architekturentscheidungen, solange sie noch günstig sind. Entweder Barrierefreiheit gehört jetzt ins Fundament, oder Sie bezahlen später für dessen Umbau – unter dem Zeitplan eines anderen.