Barrierefreie Inhalte mit imc Express erstellen

Wir möchten, dass imc Express allen Lernenden weltweit zur Verfügung steht, auch Menschen mit Behinderungen. Um dies zu erreichen, war uns das Thema Barrierefreiheit bei der Entwicklung von imc Express sehr wichtig.

Jede Ausgabe Ihrer Lerninhalte wird neben der visuellen Darstellung auch in einer zweiten, barrierefreien Darstellung veröffentlicht. Diese Darstellung entspricht den Anforderungen der WCAG 2.2 Level AA. Sie enthält dieselben Informationen und dieselben Funktionen wie die visuelle Version und ist direkt von dieser aus erreichbar.

Einige Anforderungen hängen jedoch davon ab, was Sie schreiben, und nicht vom Player. Die folgenden Richtlinien behandeln genau diese Punkte. Werden sie nicht befolgt, kann keine Einstellung in imc Express das Ergebnis nachträglich korrigieren.

Richtlinien für Autoren

Sagen Sie laut, was Ihre Videos zeigen

Dies ist der wichtigste Punkt – und derjenige, dessen Nichtbeachtung die teuersten Folgen hat.

Barrierefreiheitsrichtlinien verlangen eine Audiodeskription für Videos – eine separate Erzählung dessen, was auf dem Bildschirm zu sehen ist. Diese separate Tonspur ist nicht erforderlich, wenn der eigene Soundtrack des Videos bereits alles vermittelt, was das Bild zeigt, denn dann gibt es nichts mehr zu beschreiben. Diesen Weg verfolgt imc Express: Die Plattform liefert keine separate Audiodeskriptionsspur.

Schreiben Sie die Beschreibung also in Ihr Skript:

• Anstelle von „wie Sie hier sehen können“ sagen Sie „die Grafik zeigt, dass der Anteil von 20 auf 60 Prozent steigt“.
• Anstelle von „klicken Sie auf die angezeigte Schaltfläche“ sagen Sie „klicken Sie auf die rote Weiter-Schaltfläche unten rechts“.
• Wenn Text auf dem Bildschirm erscheint, lesen Sie ihn laut vor oder fassen Sie ihn zusammen.
• Wenn ein Vorgang ohne Kommentar demonstriert wird, beschreiben Sie jeden Schritt, während er stattfindet.

Ein kurzer Test, bevor ein Video veröffentlicht wird: Spielen Sie es bei ausgeschaltetem Bildschirm ab. Jemand, der es noch nicht gesehen hat, sollte dennoch in der Lage sein, dem Geschehen zu folgen. Wenn etwas fehlt, gehört es in das Skript.

Fügen Sie jedem Video mit Sprachausgabe Untertitel hinzu

Wenn Ihr Video Untertitel enthält, lädt die barrierefreie Version diese und bietet eine beschriftete Steuerung zum Ein- und Ausschalten an. Wenn Ihr Inhalt keine Untertitel enthält, können auch keine angezeigt werden – der Player kann sie nicht selbst erstellen.

Untertitel zahlen sich doppelt aus: Wenn kein separates Transkript vorliegt, erstellt die barrierefreie Version das Texttranskript des Videos anhand der Zeitangaben der Untertitel. Das Hinzufügen von Untertiteln erfüllt somit in einem Schritt sowohl die Anforderung an Untertitel als auch die Anforderung an ein Transkript.

Versehen Sie jedes aussagekräftige Bild mit einer Bildunterschrift

Die barrierefreie Version entnimmt die Textalternative eines Bildes aus dessen Bildunterschrift. Ist keine vorhanden, greift sie auf den mit dem Asset gespeicherten Titel zurück, und ist auch dieser leer, wird das Bild als dekorativ angekündigt.

Das ist das korrekte Verhalten bei dekorativen Bildern. Ein Bild jedoch, das Informationen enthält und weder eine Bildunterschrift noch einen Asset-Titel hat, wird einem Screenreader-Nutzer überhaupt nicht angezeigt. Wenn ein Bild etwas aussagt, versehen Sie es mit einer Bildunterschrift.

Wenn ein Bild beschriftete Hotspots enthält, erscheinen deren Beschreibungen als nummerierte Liste unterhalb des Bildes, und die Markierungen auf dem Bild selbst werden vor assistiver Technologie ausgeblendet. Verfassen Sie diese Beschreibungen so, dass sie auch ohne das Bild für sich allein stehen.

Beginnen Sie jeden Abschnitt mit einer Überschrift

Überschriften dienen nicht nur der Strukturierung der Seite. Die barrierefreie Version übernimmt den Dokumenttitel aus der ersten Überschrift in Ihrem Inhalt; nur wenn keine vorhanden ist, greift sie auf den Titel der veröffentlichten Ausgabe zurück. Inhalte, die ohne Überschrift beginnen, erreichen den Lernenden daher mit einem weniger spezifischen Seitentitel, und ein Abschnitt ohne Überschrift wird als „Abschnitt 2“ statt nach seinem Thema angekündigt.

Halten Sie die Überschriftenebenen in der richtigen Reihenfolge ein und springen Sie nicht von Ebene 1 direkt zu Ebene 3, nur um etwas kleiner erscheinen zu lassen.

Sorgen Sie dafür, dass Linktexte für sich allein aussagekräftig sind

Nutzer von Bildschirmleseprogrammen rufen häufig eine Liste aller Links auf einer Seite auf, in der die umgebenden Sätze entfernt sind. „Hier klicken“, „mehr“ und „weiterlesen“ sind in einer solchen Liste nutzlos. Benennen Sie stattdessen das Ziel: „Sicherheitshinweise herunterladen (PDF)“.

Integrieren Sie gesprochene Erläuterungen ebenfalls in den Text

In der barrierefreien Version ist die automatische Sprachausgabe absichtlich deaktiviert – der Screenreader des Lernenden sorgt für die Sprachausgabe, und zwei Stimmen gleichzeitig helfen niemandem.

Die Folge ist, dass alles, was nur im Voiceover gesagt und nirgendwo schriftlich festgehalten wird, in dieser Version verloren geht. Wenn Ihr Kommentar den sichtbaren Text ergänzt, fügen Sie ihn in das Transkriptfeld für dieses Element ein. Die barrierefreie Version zeigt ein Transkript an, sobald es vom sichtbaren Text abweicht, sodass die Ergänzung den Lernenden erreicht.

Struktur und Sprache

Gliedern Sie Ihre Inhalte sorgfältig und verwenden Sie eine klare, präzise Sprache. Dadurch werden die Inhalte leichter verständlich und die Navigation wird vereinfacht – für alle Lernenden, nicht nur für diejenigen, die assistive Technologien nutzen.

Nutzung barrierefreier Inhalte

Bei Verwendung eines Screenreaders können Nutzer mit der [Tab]-Taste zur barrierefreien Version des Inhalts navigieren.

Alternativ kann der barrierefreie Inhalt auch wie folgt aufgerufen werden:
Drücken Sie auf dem Startbildschirm des Inhalts die [Tab]-Taste und anschließend die [Enter]-Taste.

Was die barrierefreie Version bietet

Die barrierefreie Darstellung basiert auf semantischem HTML und nicht auf einem Canvas, wodurch sie für assistive Technologien überhaupt erst zugänglich wird. Insbesondere bietet sie:

• eine Überschriftenstruktur und Seitenmarkierungen, damit assistive Technologien wiederholte Inhalte überspringen und zwischen Abschnitten wechseln können;
• eine Textalternative für jedes Bild und eine Texttranskription zu jedem Video;
• Untertitel mit beschrifteten Steuerelementen, sofern der Inhalt diese bereitstellt;
• Videosteuerelemente, die vollständig über die Tastatur bedienbar sind, einschließlich Suchfunktion und Lautstärkeregelung;
• einen Namen für jedes Steuerelement, sodass nichts einfach als „Schaltfläche“ angesagt wird;
• gesprochene Ansagen für Elemente, die sich von selbst ändern, wie z. B. Quiz-Feedback oder die Freischaltung eines Abschnitts;
• eine durchgehend sichtbare Fokusanzeige und eine Leseposition, die den Aktionen des Lernenden folgt, anstatt an den Anfang der Seite zurückzuspringen.

Was bedeutet ARIA?

ARIA steht für „Accessible Rich Internet Applications“. Es handelt sich um eine Reihe von HTML-Attributen, die entwickelt wurden, um die Barrierefreiheit interaktiver Webinhalte und Anwendungen zu verbessern. Diese Attribute liefern zusätzliche Informationen für assistive Technologien wie Screenreader, um Menschen mit Behinderungen eine bessere Benutzererfahrung zu ermöglichen.

Wir verwenden ARIA dort, wo Standard-HTML-Elemente allein nicht ausreichen – zum Beispiel, um eine Änderung anzukündigen, die stattfindet, ohne dass der Lernende etwas unternimmt. Wenn ein Standardelement bereits die richtige Bedeutung vermittelt, verwenden wir dieses Element, anstatt es mit ARIA zu beschreiben, da native Elemente in den meisten Situationen korrekt funktionieren.

Konformität mit WCAG 2.2 AA

Die Web Content Accessibility Guidelines legen fest, wie digitale Inhalte gestaltet werden müssen, damit sie für alle Nutzer zugänglich sind. Wir bewerten die barrierefreie Darstellung unserer Lerninhalte anhand der WCAG 2.2 Stufe AA, die 56 einzelne Erfolgskriterien umfasst, die unter vier Grundsätzen zusammengefasst sind.

Wahrnehmbar

Die Inhalte sind so gestaltet, dass sie erkennbar sind: ausreichender Farbkontrast, Textalternativen für Nicht-Text-Inhalte, Untertitel und Transkripte für Medien sowie eine Struktur, die mit einem Screenreader oder einer anderen assistiven Technologie gelesen werden kann.

Bedienbar

Jede Funktion ist ohne Maus erreichbar und nutzbar. Steuerelemente sind standardisierte, über die Tastatur bedienbare Elemente, die Fokusreihenfolge folgt dem Inhalt, und der Fokusindikator ist jederzeit sichtbar.

Verständlich

Die Seite gibt ihre Sprache an, damit ein Screenreader sie korrekt ausspricht. Steuerelemente verhalten sich konsistent, Rückmeldungen erfolgen in Worten und nicht allein durch Farben, und wenn der Inhalt ein Element erst nach einer Verzögerung verfügbar macht, wird dies erklärt, anstatt es dem Rätselraten zu überlassen.

Robust

Die barrierefreie Darstellung basiert auf gültigem, semantischem HTML mit eindeutigen Identifikatoren sowie korrekten Namen, Rollen und Werten, sodass sie browser-, geräte- und assistivtechnologieübergreifend funktioniert und nicht nur mit einer bestimmten Kombination.

Wie wir die Konformität überprüfen

Automatisierte Tests allein können Barrierefreiheit nicht gewährleisten. Je nach Studie erkennen automatisierte Tools zwischen einem Drittel und der Hälfte aller Barrieren – sie können einen fehlenden Alternativtext finden, aber nicht feststellen, ob der Text aussagekräftig ist. Wir kombinieren daher vier Methoden:

1. Automatisierte Tests der veröffentlichten Ausgabe mit axe-core, die die Regelsätze der WCAG 2.0, 2.1 und 2.2 abdecken.
2. Manuelle Codeüberprüfung des Renderers und der gemeinsam genutzten Schnittstellenkomponenten.
3. Manuelle Überprüfung des gerenderten Ergebnisses: wie Namen berechnet werden, wie Überschriften strukturiert sind, wohin der Fokus wandert.
4. Screenreader-Tests durch einen externen Tester, dessen Ergebnisse protokolliert und behoben werden.

Die letzten beiden Punkte sind entscheidend. Bei unserem eigenen Audit meldeten die automatisierten Tests fast keine Verstöße bei Inhalten, die dennoch einen Fehler der Stufe A enthielten: eine Reihe von Quizoptionen, deren Beschriftungen auf nicht vorhandene Elemente verwiesen, sodass sie für einen Screenreader keinen Namen hatten. Nur eine manuelle Überprüfung deckte dies auf.

Konformitätsbericht

Unser Barrierefreiheits-Konformitätsbericht (VPAT® 2.5) dokumentiert das Ergebnis für jedes der 56 Erfolgskriterien der WCAG 2.2 Level A und AA, zusammen mit den Bewertungsmethoden und den durchgeführten Korrekturmaßnahmen. Er umfasst die barrierefreie Darstellung der für die Lernenden bestimmten Inhalte.

Bericht zur Barrierefreiheitskonformität – WCAG 2.2 AA (PDF)