Kursthemen

  • Starthilfe

    Alles einklappen Alles aufklappen

     Was erwartet mich in diesem Kurs?

    Der Workshop, welcher am 25.01.2023 vom Kompetenzzentrum Digitale Barrierefreiheit.nrw ausgerichtet wurde, fand unter der Leitung von Jan Hellbusch statt. Thematisch wurden folgende Schwerpunkte abgedeckt:


    Dieser Kurs fasst die wichtigsten Inhalte in komprimierter Form zusammen.

  • Funktionsweise(-n) von Screenreadern

    • Grundsätzlich kann man einen Screenreader wie eine zusätzliche Ebene über Webbrowser und der drunterliegenden Seitenstruktur verstehen. Der Browser generiert für den Screenreader einen sogenannten Accessiblility Tree. Der Screenreader arbeitet die meiste Zeit auf diesem Abbild und nicht direkt auf dem Domain Object Model (DOM), wie es die Webbrowser tun. Aria-Elemente aus dem DOM werden immer an den Accessibility Tree weitergegeben, aber nicht jeder Browser geht mit DOM-Objekten gleich um. Auch die Screenreader interpretieren daher das selbe Objekt teils unterschiedlich.

      Ähnlich wie bei Browsern kann die Ausgabe von Webinhalten eines Screenreaders daher je nach Browser-& Screenreader-Kombination variieren. Die meistgenutzen Kombinationen sind (Stand: Februar 2023):

      - JAWS + Chrome
      - NVDA + Firefox
      - VoiceOver + Safari
      - (Narrator + Edge)


      Zum weiteren Grundlagenwissen im Umgang mit Screenreadern gehört deren Aufteilung in zwei distinktive Modi: den Lesemodus und den Formular- bzw. Fokusmodus.


      Lesemodus

      Im Lesemodus arbeitet ein Screenreader nicht direkt im DOM, d. h. Eingaben in Formularfeldern erfolgen nur im Formularmodus. Zudem werden die Pfeiltasten nicht an den Browser durchgegeben, sondern zur Steuerung des Screenreaders genutzt. Dementsprechend werden eventuelle Überschreibungen durch JavaScript, welche sich auf die Pfeiltasten (oder andere Funktionstasten des Screenreaders) beziehen, ignoriert. Dies betrifft weitere Tasten wie:

      • Escape
      • Enter
      • Tab
      • Leertaste

      Je nach Screenreader können weitere Tasten durch diesen belegt sein, bspw. H für Navigation über die Heading-Elemente und F für die Navigation über Formulare in JAWS.


      Formular-/Fokusmodus


      Im Formular- bzw. Fokusmodus (der Name wechselt abhängig des genutzten Screenreaders) entfällt die Navigation des Screenreaders über das "virtuelle DOM". Stattdessen wird über die Tab-Taste der Fokus des Screenreaders über das DOM gelenkt, wodurch bspw. Formular-Elemente direkt angesprochen und gesteuert/gefüllt werden können. Somit wird es auch möglich, Funktionen, welche via JavaScript auf verschiedene Tasten gelegt wurden, zu bedienen.

  • ARIA - Accessible Rich Internet Applications

    • Allgemeines 

      Als Faustregel für den Einsatz von ARIA gilt: lässt sich eine Funktionalität mit HTML5 Syntax umsetzen, dann ist diese zu bevorzugen. Screenreader interpretieren "saubere" HTML5-Elemente und Konstruktionen selbstständig korrekt, ohne dass diese mit ARIA-Tags versehen werden müssen. In solchen Fällen schaden ARIA-Tags eher, als zu helfen. Elemente, welche nicht vollständig nur mit HTML5-Elementen umgesetzt werden können - bspw. Reiternavigationen - bedürfen hingegen ARIA-Tags.

    • Rollen

      ARIA kann verschiedene Rollen für Elemente definieren. Diese sorgen dafür, dass ein Screenreader die Elemente auf eine bestimmte Art interpretiert. Zu den Rollen gehören:

      • Document-Roles
      • Landmark-Roles
      • Widget-Roles
      • Live-Region-Roles
      • Window-Roles
      • Abstract-Roles

      Document-Roles

      Bei den Document-Roles handelt es sich an erster Stelle um einen Ersatz für ehemals nicht zum HTML-Standard gehörende Elemente, welche mittlerweile jedoch größtenteils im HTML5-Standard existieren und somit diese spezifischen Roles obsolet machen.  Dieser historische Werdegang erklärt jedoch, wieso sie insbesondere in älteren Websiten anzutreffen sind. Ein häufiger Fallstrick: befindet sich auf einem Element role="presentation", so überschreibt diese jegliche Aria-Rollen. Obwohl diese Rolle nicht mehr genutzt werden sollte, findet sie sich durchaus noch in einigen Frontend-Frameworks, bspw. Bootstrap 4.

      Eine kleine Ausnahme stellt jedoch die role="application" dar. Mit dieser lässt sich ein Screenreader codeseitig in den Formularmodus umschalten, was im Einzelfall die Bedienung einer komplexen Seite vereinfachen kann. Allerdings muss in so einem Szenario unbedingt ein korrektes Labelling sämtlicher Elemente innerhalb dieses Bereichs erfolgen!

      Landmark-Roles

      Landmark-Roles greifen in die Navigation eines Screenreaders ein. Auf technischer Seite ist ein role="heading" gleichzusetzen mit Heading-Tags wie h1, h2, h3 usw.; weshalb - eine korrekte Nutzung von HTML5-Elementen vorausgesetzt - ein Einsatz insbesondere dieser Rolle eher überflüssig ist. Es sollten aber alle Struktur-Elemente einer Seite entweder durch eine Headline oder durch eine Landmark-Role gekennzeichnet sein, um eine saubere Navigation des Screenreaders zu gewährleisten. Schachtelungen sind dabei durchaus gangbar (Beispiel: H-Elemente innerhalb eines Form-Elements).

      Widget-Roles

      Widget-Roles dienen der Vermittlung von Funktionalitäten, welche nicht nativ durch HTML5-Elemente abgedeckt werden können. Dies beinhaltet bspw. Akkordeons, Slider und dergleichen, sprich interaktive Elemente. Besonders wichtig ist in diesem Zusammenhang das Focus-Management, welches bei solchen Elementen meistens durch die Programmierung übernommen werden muss. Als Faustregel lässt sich hierfür merken, dass insbesondere aria-label zur Nachbildung von HTML5-Code genutzt werden sollte, wenn dieser für ein Element nicht zur Verfügung steht.

      Verdeutlichen lässt sich dies durch ein Select-Element. Hier wäre ein Name-Attribut bzw. Label stets einem Aria-Label vorzuziehen. Wird der entsprechende Select jedoch ohne das Select-Element umgesetzt - was aufgrund verschiedener Anforderungen vorkommen kann, insbesondere bei dynamisch nachladenden Daten - so ist ein Aria-Label zwingend erforderlich.

      Live-Region-Roles

      Möchte man dynamische Inhalte vermitteln, welche die Aufmerksamkeit des Screenreaders abseits der Seitenstruktur erhalten, so lassen sich die Live-Region-Roles einsetzen. Mögliche Anwendungsfälle wären Fehlermeldungen, Timeouts usw. Vorsicht ist jedoch immer dann geboten, wenn ein Element besonders häufig Events auslöst, wie zum Beispiel Media-Player. Werden diese mit einer Live-Region-Role in Verbindung gebracht, liest ein Screenreader zum Beispiel für jede verstrichene Sekunde die aktuelle Laufzeit vor, was die Nutzung der Seite bei einem laufenden Audio/Video-Inhalt praktisch unmöglich macht. Dementsprechend sollten Live-Region-Roles nur spärlich zum Einsatz kommen.

      Durch setzen des Wertes aria-live="polite" wird der entsprechende Inhalt der Live-Region nur dann vorgelesen, wenn die Interaktion abgeschlossen ist und wird daher als Standardwert empfohlen. Mit aria-live="assertive" wird der Inhalt hingegen immer sofort vorgelesen, was zu Verwirrungen führen bzw. als störend empfunden werden kann.

      Window-Roles

      Window-Roles kommen zum Einsatz, wenn "Fenster" innerhalb der eigentlichen Seite vermittelt werden müssen, z.B. Popups oder Modale, und sind daher eng mit den Widget-Roles verbunden. Sie verhindern jedoch nicht, dass sich der Screenreader aus einem solchen "Window-Widget" hinausbewegen lässt; so ist es bspw. bei Modalen weiterhin notwendig, den Hintergrund des Modals für den Screenreader unzugänglich zu machen, was sich unter Anderem über das Focus-Management bewerkstelligen lässt.

      Abstract-Roles

      Die Abstract-Roles sind für den Einsatz in der Webentwicklung zu vernachlässigen.

    • Benennung von Elementen

      Möchte man ein Element auf besondere Weise für den Screenreader benennen, so gibt es mehrere Möglichkeiten, die sich in ihrer Spezifität allerdings bedingen. Die Abfolge ist dabei wie folgt:

      1. aria-labelledby
        • Überschreibt alle anderen folgenden Attribute; kann genutzt werden, um den Namen/Inhalt eines Elements über den Inhalt eines anderen Elements mit einer entsprechend verknüpften ID zu benennen
        • Die Abfolge der Werte ist "name rolle wert"
      2. aria-label
        • Überschreibt alle "normalen" Attribute eines HTML5-Elements, außer aria-labelledby
        • Im Vergleich zu labelledby handelt es sich bei label um einen "flachen" Wert, sprich einen String wie auch bei dem name-Attribut
      3. name-Attribut
        • Das "Go-To" zur Benennung eines Elements, sofern es dieses nativ unterstützt
      4. title-Attribut
        • Sollte im Vergleich zu dem name-Attribut eher als ein Fallback betrachtet werden

      Tipp für Entwickler*innen: die Dev-Tools des Chrome zeigen alle Attribute an, während die Dev-Tools des Firefox nur selektiv Attribute anzeigen.

    • Sichtbarkeit

      Die wohl mächtigste Eigenschaft, um einen Screenreader zu beeinflussen, ist aria-hidden. Hierüber wird ein Element für den Screenreader vollkommen unsichtbar, nicht jedoch für den Browser. Dabei ist zu bedenken, dass ein via aria-hidden ausgeblendetes Element nicht sichtbar werden kann, solange eines seiner Parent-Elemente aria-hidden besitzt. Dies kann schnell zu einer Inkonsistenz des DOM für Nutzer*innen von Screenreadern führen, etwa wenn in einem Formular ein Feld nur in einem besonderen Zustand eingeblendet werden soll, dessen umgebendes Element ein aria-hidden besitzt, während die Sichtbarkeit des Felds über CSS gesteuert wird.

      Da sich Screenreader aber an CSS-Werten, welche die Sichtbarkeit von Elementen bedingen, orientieren, ist aria-hidden eher für ein Szenario gedacht, in welchem einzelne Elemente explizit nur für Screenreader ausgeblendet werden sollen. Ein Element, welches mit einem display: none versehen ist, wird nämlich auch von Screenreadern ignoriert. Deshalb sollte stets display: none  bzw. visibility: hidden genutzt werden, um Elemente auszublenden, nicht zuletzt auch deshalb, weil die Logik bzw. Struktur der Seite für alle Benutzer*innen gleich bleibt.

      Dementsprechend ist Vorsicht beim Einsatz von aria-hidden geboten; auf keinen Fall sollte es auf fokussierbaren Elementen genutzt werden, da so unter Umständen die Nutzbarkeit der Seite eingeschränkt wird. Hingegen kann es sinnvoll für Elemente von rein visueller Natur genutzt werden, beispielsweise animierte Elemente ohne eigene Funktionalität.

      Ein praktisch sinnvoller Einsatz von aria-hidden lässt sich am Beispiel von Slidern erläutern: bei diesen sind sämtliche Slides stets im DOM sichtbar, um die CSS-basierten Slide-Effekte zu ermöglichen. Für einen Screenreader handelt es sich dabei also um aufeinander folgende Elemente. Mit einem aria-hidden, welches auf allen Slides außer der aktuell aktiven gesetzt ist, kann dieser Zustand umgangen werden.

      Ergänzend dazu kann aria-hashpopup genutzt werden, um eine Fokussierung von überlappenden Elementen für den Screenreader zu erzwingen. Allerdings wird über den Screenreader nicht vermittelt, dass tatsächlich ein überlappendes Element vorliegt - somit sollte dieser Zustand zusätzlich über den Inhalt des Popups kommuniziert werden.

      Schließend soll noch angemerkt sein, dass Elemente, welche zur Interaktion genutzt werden können, eine Mindestgröße von 24x24 Pixeln aufweisen sollten.

  • HTML5 Formular(-elemente)

    • Obwohl die meisten HTML5-Formularelemente zumindest ordnungsgemäß von Screenreadern verarbeitet werden können, gibt es - je nach Element - zusätzliche Eigenheiten, welche für eine optimale Barrierearmut beachtet werden sollten. Um beispielsweise Inputs für den Screenreader kenntlich zu machen genügt grundsätzlich ein korrekt gesetztes name-Attribut. Weitere Möglichkeiten zur Beschreibung durch aria-Attribute sind zwar möglich, können aber zu unerwünschten Dopplungen führen. Einige Besonderheiten sind:

      Checkboxen

      •  Checkboxen, die etwas ändern, sollten role=“switch“ besitzen

      Buttons

      • Inhalt eines Buttons ist für den Screenreader der Name des Buttons, sprich es ist kein zusätzliches Tag erforderlich sofern der Inhalt korrekt platziert wurde
      • Sonderfall: Toggle-Buttons. Für diesen ist zwingend ein aria-pressed="true/false" zu setzen.
        • Aber: Toggles, deren Inhalt sich ändern, sollten kein aria-pressed besitzen - z.B. Play/Pause-Buttons

      Selects

      • Selects benötigen grundsätzlich ein aria-label, wenn der Inhalt nicht statischer Natur ist

    • Formularvalidierung

      Generell sollte eine Formularvalidierung, welche Clientseitig erfolgt, stets durch eine Live-Region-Role gestützt werden. Dabei muss das Element, welche die Fehleranzeige beinhalten soll, auf dem ersten Render bereits im DOM vorhanden sein und mit role="status" ausgestattet werden. Der Inhalt des Elements, bspw. ein p-Element, kann dann dynamisch gerendert werden und wird trotzdem korrekt vom Screenreader vorgelesen.

  • Barrierefreiheit in Moodle

      Der Stand der Dinge - Einige Beispiele

      Leider fällt es - nicht zuletzt durch das Alter und die somit "historisch gewachsenen" Strukturen von Moodle - nicht leicht, eine allgemeine Aussage zu der Barrierefreiheit bzw. Barrierearmut von Moodle zu treffen. Im Folgenden sind deshalb einige Beispiele aufgelistet, welche diese Problematik verdeutlichen und Anhaltspunkte dafür bieten sollen, bei welchen Komponenten es sich lohnen könnte, nochmal explizit die Barrierefreiheit vor einem produktiven Einsatz in einem Kurs zu überprüfen.

    • Negativbeispiel: Lückentext

      Für eine*n erfahrene*n Screenreader-Nutzer*in, die*der sich in Moodle auskennt, ist die Verwendung der Aktivität Lückentext möglich, aber nicht komfortabel.

      Beim Moodle Lückentext wurde ein zusätzliches Label für das Input-Feld eingefügt. Das ist nicht notwendig und kann im schlechtesten Fall eher stören. Stattdessen könnte einfach ein aria-label auf dem Input-Feld verwendet werden.

      Die Benennung der Inputs durch die Label sind außerdem ungünstig, weil jedes Feld mit "Antwort" betitelt ist. Dadurch weiß ein*e Screenreader-Nutzer*in nicht, bei welcher Lücke im Text sie*er sich befindet.


    • Icon Test
      Test Lückentext

      In diesem Test Lückentext lassen sich die zuvor angesprochenen Probleme inspizieren.

    • Negativbeispiel: Filebrowser

      Falls in einem Moodle-Kurs eine größere Anzahl von Dateien bereitgestellt werden soll, kann die Aktivität Verzeichnis (mod_folder)  verwendet werden. Hier können Dateien mit Hilfe einer Ordnerstruktur abgelegt werden. 

      Diese Ordnerstruktur ist jedoch im DOM mit Hilfe von mehren geschachtelten Tabelle aufgebaut. Dieser Aufbau ist Problematisch für Screenreader und sollte vermieden werden.



      Eine Anleitung zu Best-Practices ist hier zu finden (Link zu Best-Practices)

    • Negativbeispiel: Inhaltstyp H5P - Zeitstrahl


      Bei dem Inhaltstyp H5P - Zeitstrahl wird ein DOM generiert, welches für den Screenreader vollkommen unbrauchbar ist, woraus resultiert, dass die in diesem Zeitstrahl abgebildeten Informationen für Nutzer*innen von Screenreadern unzugänglich werden (genaugenommen kann keine Kongruenz zwischen der Zeit-Komponente und der Inhalt-Komponente hergestellt werden). Hier bedarf es weiterer Anpassungen. Optional können die Inhalte auch in einer anderen Form, beispielsweise in Textform unterhalb des Inhaltstyps H5P - Zeitstrahl  vermittelt werden.

      Durch semantisch und inhaltlich richtigen HTML-Code könnte hier schon einiges verbessert werden. Es gibt zwei untereinander platzierte Objekte (der Zeitstrahl an sich und die Beschreibung des Ereignisses + Navigationspfeile darüber), deren Zusammenhang für Screenreader-Nutzer*innen nicht sichtbar ist.


      Die Strukur des DOM, welche die Screenreader in diesem Beispiel zur Orientierung verwenden, wird wie folgt widergegeben:

      • Beschreibung über das angewählte Ereignis
      • Button zu vorherigem Event
      • Button zu nächstem Event
      • Zeitstrahl-Items, sortiert nach Datum
      • Kategorien, wenn vorhanden
      • Zeitstrahl-Jahre

      1) Der Zeitstrahl
      Die Jahre im Zeitstrahl werden erst nach den 10er Abschnitten gruppiert (2010, 2020), wonach die restlichen Jarheszahlen zwischen jenen Schritten folgen (2011, 2012... 2019). In der zweiten Gruppe befinden sich außerdem die Epochen, sofern diese verwendet werden. Eine Epoche, die für 2020-2022 definiert wurde, wird zwischen 2021 und 2022 eingefügt. Welchen Zeitraum Epochen markieren ist somit an keiner Stelle ersichtlich, sondern nur visuell sichtbar.



      2) Anordnung von Inhalten & Zusammenhang
      Nur im oberen Teil der Ansicht eines Ereignisses werden alle nötigen Informationen über ein Event mitgeteilt. Im Zeitstrahl steht zu einem Event jeweils nur die Überschrift und der Zeitpunkt. Wenn dieses Feld angeklickt wird, weiß der Screenreader nicht, dass dadurch mehr Informationen im oberen Teil der Ansicht zu sehen sind.

      3) Vor-& Zurück Navigation
      Der Button, der zum vorherigen Event navigiert, sollte im DOM da angeordnet werden, wo er sich von der Positionierung via CSS tatsächlich befindet, nämlich vor der Beschreibung zum Ereignis. Selbiges gilt für den Button, welcher zum nächsten Event navigiert.

    • Positivbeispiel: Inhaltstyp H5P - Drag&Drop


      Die Drag-& Drop Funktionalität des Inhaltstyps H5P Drag&Drop ist grundsätzlich gut per Tastatur bedienbar, sofern sie richtig konfiguriert wurde.

      Bei der Bedienung per Tastatur kann ein Element mit Klick auf die Leertaste "aufgenommen" werden. Dies wird durch ein aria-grabable ermöglicht. Ist ein Element gewählt, wandert der Fokus zu den Ablagefeldern, durch die man per Pfeiltasten navigieren kann. Auf dem entsprechenden Feld drückt man erneut die Leertaste, um das Element dort abzulegen.

      Der*die Quiz-Ersteller*in muss natürlich eine Beschreibung oder Hilfestellung als Text liefern, damit das Quiz inhaltlich bearbeitet werden kann. Außerdem sollte auf die korrekte Einstellung des Quiz geachtet werden. Zum Beispiel sollten die Elemente so eingestellt werden, dass sie auf allen relevanten Ablagezonen abgelegt werden dürfen. Andernfalls kann es vorkommen, dass per Tastatur nur das richtige Ablagefeld angewählt werden kann.

  • Weiterführende Links