Abschnittsübersicht

◄HTML5 Formular(-elemente)
►Weiterführende Links

      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.


    • 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.

◄HTML5 Formular(-elemente)
►Weiterführende Links