Board

Hinweise zu Board

Board gehört zu den Pinnwänden, nicht zu den kollaborativen Whiteboards. Pinnwände wie Padlet und TaskCards ordnen Beiträge in vorformatierten Spalten an und haben einen ähnlichen Funktionsumfang wie Board. Whiteboards wie Miro und Mural bieten dagegen eine weitgehend freie Arbeitsfläche und deutlich mehr Funktionen. Der vorliegende Bericht ergänzt die Reihe der Pinnwandtests des Kompetenzzentrums um Board als hochschuleigene, in Moodle integrierte Variante.

Anders als die bisher geprüften Pinnwände wird Board nicht als Cloud-Dienst bezogen, sondern als Moodle-Plugin vom Typ Aktivitätsmodul mit der Kennung mod_board in der Moodle-Instanz der Hochschule installiert. Beiträge, Kommentare und Bewertungen liegen damit in der Datenbank der jeweiligen Hochschule. Nach Angabe des Anbieters werden keine Daten an externe Dienste übertragen. Für die Erklärung zur Barrierefreiheit ist die Hochschule als betreibende Stelle selbst verantwortlich.

Entwickelt und gepflegt wird Board von Brickfield Education Labs mit Sitz in Irland. Das Unternehmen ist von Moodle als zertifizierte Integration geführt und auf Werkzeuge zur Prüfung und Verbesserung der Barrierefreiheit von Moodle-Inhalten spezialisiert. Der Quellcode steht unter der GNU General Public License in Version 3 und wird öffentlich auf GitHub gepflegt. Bezogen wird das Modul über den Moodle-Marketplace.

Die Entwicklung wird über Drittmittel finanziert. Die Anfangsförderung stellte das National Institute for Digital Learning der Dublin City University aus dem SATLE-Fonds des National Forum bereit, weitere Mittel kamen vom Athlone Institute of Technology und vom University College London. Die Erweiterungen an der Kommentarfunktion, darunter Benachrichtigungen sowie ein Symbol mit Kommentarzähler, wurden von der Charité Universitätsmedizin Berlin finanziert. Nach Angabe des Anbieters ist das Modul für die Moodle-Versionen 4.5, 5.0, 5.1 und 5.2 freigegeben. Die Entwicklung läuft in Zweigen je Moodle-Reihe, der jüngste ist MOODLE_405_STABLE mit dem Release 1.405.05. Eine Anwenderdokumentation liegt als Board User Guide vor.

Herstellerangaben zur Barrierefreiheit

Brickfield Education Labs gibt in der Projektdokumentation an, dass Board die WCAG 2.2 auf Konformitätsstufe AA durchgängig erfülle. Eine Selbstauskunft nach EN 301 549 oder ein Voluntary Product Accessibility Template liegen nicht vor. Die Angabe ist damit nicht durch ein dokumentiertes Prüfverfahren belegt, und unsere Befunde weichen in mehreren Punkten davon ab.

Alle Teilaufgaben außer dem Verschieben fremder Beiträge wurden vollständig und selbstständig gelöst, die Beitragsinhalte sind erreichbar und werden vorgelesen. Die Eingabemaske für einen neuen Beitrag ist übersichtlich, und beim Verschieben wird die Zielspalte als Liste beschrifteter Links angeboten. Dass der eigene Kommentar gespeichert wurde, war eindeutig erkennbar.

Erschwert wird die Arbeit vor allem durch die fehlende Spaltenstruktur. Die Orientierung auf dem Board ist die einzige Teilaufgabe, deren Verständlichkeit nur mit Stufe drei bewertet wurde: lösbar, aber mit hohem Aufwand. 

Barrieren und Usability-Probleme

• Eine Orientierung auf dem Board wird erschwert, weil eine sinnvolle, semantisch korrekt ausgezeichnete Überschriftenstruktur fehlt. Mit dem Screenreader erscheinen die Spalten nacheinander statt nebeneinander, und die Schalter eines Beitrags lassen sich der zugehörigen Spalte nicht zuverlässig zuordnen.

• Bilder erhalten als Alternativtext den Bildtitel, den die verfassende Person beim Hochladen eintragen muss. Dass dieses Feld als Alternativtext dient, ist im Formular nicht zu erkennen. Bildtitel sind in der Regel kein vollwertiger Ersatz für Alternativtexte.

• Screenreader-Nutzende können nicht feststellen, ob sie einen Beitrag bereits als wichtig bewertet haben und wie viele Bewertungen es gibt.

• In der geprüften Version war die Kommentarfunktion erst im geöffneten Beitrag erreichbar, und ein neu abgesendeter Kommentar wurde erst nach erneutem Öffnen vorgelesen. Das inzwischen vorhandene Kommentarsymbol auf der Beitragskarte gibt die Anzahl der Kommentare nicht an den Screenreader weiter.

Hinweise für die Nutzung

• Steuern Sie die Spaltenüberschriften (H3) über die Überschriftennavigation an. Alle Beiträge zwischen zwei Spaltenüberschriften gehören zur vorangehenden Spalte. Die Beiträge enden mit den Kommentar- und Bewertungsschaltern.

• Um zu prüfen, ob ein Beitrag Kommentare hat, aktivieren Sie den Beitrag. Im Dialogfenster wird die Anzahl ausgegeben. Öffnen Sie den Beitrag nach dem Absenden eines Kommentars erneut, damit der neue Kommentar vorgelesen wird.

• Die Anzahl der Bewertungen wird mit dem Screenreader nicht ausgegeben.

• Notieren Sie sich, welche Beiträge Sie bereits bewertet haben.

Alle Funktionen waren erreichbar und aktivierbar, Barrieren, die auf die Vergrößerung zurückgehen, wurden nicht festgestellt. Beitragsmaske und Dialogfenster bleiben auch stark vergrößert vollständig nutzbar. Beim Bewerten erscheint eine Rückfrage, sodass die Speicherung eindeutig erkennbar ist und auch vorhandene Bewertungen ablesbar sind. Die Darstellung mit einer Erweiterung zur Farbanpassung funktionierte ohne Einschränkung.

Der wesentliche Kritikpunkt betrifft die Abgrenzung der Spalten.

Die technischen Tests mit einer Vergrößerung auf 200 Prozent und 400 Prozent (320 pixel Breite) ergaben keine Barrieren. Alle Inhalte sind sichtbar und erreichbar und erscheinen in der richtigen Reihenfolge. Die Anordnung der Spalten nebeneinander bleibt erhalten, sodass horizontales Scrollen notwendig ist.

Barrieren und Usability-Probleme

• Der Kontrast zur Abgrenzung der Spalten ist unzureichend. Die Spaltenfläche ist im Stylesheet des Moduls fest auf das helle Grau #eaeaea gesetzt, die Beitragskarte auf #fbfbfb. Beide unterscheiden sich mit einem Kontrastverhältnis von 1,16 zu 1 praktisch nicht, und gegenüber einem weißen Boardhintergrund erreicht die Spaltenfläche 1,20 zu 1. Ohne eine eigene Hintergrundfarbe verschwimmen Board, Spalte und Beitrag also ineinander.

• Ob man einen Beitrag selbst bereits bewertet hat, ist am Sternsymbol nicht zu erkennen, auch nicht bei invertierten Farben.

• In der geprüften Version war auf der Beitragskarte nicht zu sehen, ob und wie viele Kommentare ein Beitrag hat. Seit Release 1.405.02 zeigt ein Sprechblasensymbol die Anzahl an.

Hinweise für die Nutzung

• Aus dem Test ergeben sich keine besonderen Bedienhinweise. Alle Funktionen waren auf dem üblichen Weg erreichbar.

• Wenn Sie ein Board selbst einrichten, wählen Sie eine dunkle Hintergrundfarbe. Die hellgrauen Spalten heben sich dann deutlich voneinander ab.

Mit Spracherkennung, Sprachsteuerung und Bildschirmtastatur ließ sich Board vollständig bedienen, die Gesamtnutzbarkeit wurde mit der höchsten Stufe der Skala bewertet. Die Spracherkennung schrieb unmittelbar in die Textfelder, ein Umweg über ein Diktierfenster war nicht erforderlich. Dass der Verschiebeschalter als Symbol auf der Beitragskarte liegt, machte unmittelbar erkennbar, welches Element anzusteuern ist, und die tabellarische Anordnung der Spalten erleichterte das Verständnis der Boardstruktur erheblich.

Bei reiner Tastaturbedienung sind alle Bedienelemente erreichbar, tragen aussagekräftige deutsche Namen und lassen sich auslösen. Auch Bewertungen und Kommentare lassen sich mit der Tastatur speichern. Der Tastaturfokus ist überall sichtbar, der Fokusring erreicht gemessen 3,71 zu 1 gegenüber der Beitragsfläche und 3,42 zu 1 gegenüber der Spaltenfläche und erfüllt damit den Grenzwert von 3 zu 1. Die Einschränkungen liegen in der Länge des Weges.

Barrieren und Usability-Probleme

• Der Tabulatorweg lässt sich nicht abkürzen. Auf dem geprüften Board mit vier Spalten und 18 Beiträgen zählt der Boardbereich 133 Haltepunkte, bis zur letzten Spalte sind rund 100 Tastenanschläge nötig. Die Spalten sind nicht als Bereiche ausgezeichnet, eine Navigation über Landmarken ist deshalb nicht möglich.

• Jeder Beitrag belegt zwei Haltepunkte mit derselben Wirkung: Überschrift und Beitragstext öffnen beide das Dialogfenster.

• In den Dialogfenstern liegen Bedienelemente ohne Beschriftung im Tabulatorweg: elf Schalter der Emoji-Auswahl im Kommentarfeld und acht Verweise des Dateiauswählers. Der Screenreader gibt dort nur „Schalter“ aus. Diese Elemente stammen aus dem Kern von Moodle, wirken sich aber in den Dialogfenstern von Board aus.

• In der geprüften Version war die Kommentarfunktion erst im geöffneten Beitrag erreichbar, was den Weg zu den Kommentaren zusätzlich verlängerte. In der neuen Version wird das Beitragsfenster auch durch das Aktivieren des Kommentarschalters geöffnet.

Hinweise für die Nutzung

• Aktivieren Sie zum Verschieben den Verschiebeschalter auf der Beitragskarte und wählen Sie im Dialogfenster die Zielposition.

• Verwenden Sie zum Auslösen der Symbolschalter die Eingabetaste, also Enter.

• Ein Dialogfenster verlassen Sie mit Escape. Der Fokus kehrt danach auf das Bedienelement zurück, von dem Sie gekommen sind.

Neurodivergenz und Teilleistungsstörungen wirken sich sehr individuell aus. Die Rückmeldungen aus dem Test sind daher nicht automatisch auf alle Personen in gleicher Ausprägung übertragbar. Die wiederkehrenden Beobachtungen zeigen dennoch typische Barrieren und geben Hinweise für eine barrierefreie Gestaltung.

Die Struktur des Boards war in beiden Sitzungen sofort verständlich, Wahrnehmbarkeit, Bedienbarkeit und Verständlichkeit der Orientierung wurden mit der höchsten Stufe bewertet. Das Erstellen eines Beitrags gelang ohne Einschränkung, und dass Links einen eigenen Namen bekommen können, wurde als Gewinn an Übersichtlichkeit hervorgehoben. Die Bedienung über die Tastatur wurde ausdrücklich gelobt, der eigene Beitrag war in der Zielspalte sofort wiederzufinden, weil er dort oben erscheint. Per Touch wurden alle Teilaufgaben selbstständig gelöst, die Bedienung wurde als verständlich und intuitiv beurteilt.

Die Barrieren für diese Gruppe hängen daran, wie deutlich Elemente gekennzeichnet sind und wie gut sich Inhalte ohne zusätzlichen Aufwand erfassen lassen.

Barrieren und Usability-Probleme

• Wer Beitragstext mit der Maus markiert, um ihn von einem Vorlesewerkzeug lesen zu lassen, löst damit das Öffnen des Dialogfensters aus. Der markierte Text lässt sich erst vorlesen, wenn das Fenster wieder geschlossen ist. Die Bedienbarkeit dieser Teilaufgabe wurde mit der niedrigsten Stufe der Skala bewertet. Ursache ist, dass die gesamte Beitragsfläche den Befehl zum Öffnen trägt und nicht zwischen einer Textmarkierung und einem Klick unterschieden wird.

• Vorlesewerkzeuge lesen am Ende jedes Beitrags die Zahl neben dem Sternsymbol mit, weil sie als sichtbarer Text im Bewertungsschalter steht. Der Lesefluss bricht dadurch ab.

• Das Sternsymbol ist nicht als Bedienelement gekennzeichnet. Ohne Umrandung oder abgesetzte Fläche ist per Touch nicht erkennbar, dass es sich um einen Schalter handelt. Der Kontrast des Symbols selbst ist mit 12,21 zu 1 gegenüber der Beitragsfläche gut. Es fehlt die Kennzeichnung als Bedienelement, nicht der Kontrast.

• Die Emoji-Auswahl im Kommentarfeld ist mit der Tastatur umständlich zu bedienen.

• Die Bewertung mit dem Sternsymbol erlaubt nur Zustimmung. Eine abgestufte oder ablehnende Rückmeldung wurde vermisst, ebenso die Möglichkeit, fremde Beiträge zu verschieben.

• Ob man einen Beitrag selbst bereits bewertet hat, ist weder am Sternsymbol noch mit dem Vorlesewerkzeug zu erkennen, auch nicht bei angepassten Farben.

• In der geprüften Version war die Kommentarfunktion auf der Beitragskarte nicht zu finden, sondern erst im geöffneten Beitrag erreichbar. In der aktuellen Version ist ein Kommentarsymbol auf der Karte sichtbar.

Hinweise für die Nutzung

• Öffnen Sie einen Beitrag zuerst und markieren Sie den Text im Dialogfenster, wenn Sie ihn vorlesen lassen möchten. Eine Markierung auf der Beitragskarte öffnet das Dialogfenster und unterbricht das Vorlesewerkzeug.

• Erweiterungen zur Farbanpassung lassen sich einsetzen. Die Einstellungen werden übernommen.

• Welche Beiträge Sie bereits bewertet haben, müssen Sie sich merken.

Die Aufgabe, einen von einer anderen Person erstellten Beitrag zu verschieben, wurde in keiner Sitzung gelöst. Board sieht diese Funktion für Studierende nicht vor. Die zugehörige Einstellung im Aktivitätsformular bezieht sich ausdrücklich nur auf die eigenen Beiträge. Lehrende haben nur die Möglichkeit, Studierenden das Verschieben eigener Beiträge zu erlauben. Eine eigene Berechtigung nur für das Verschieben fremder Beiträge kennt Board nicht. Dieses Recht ist Teil der Berechtigung mod/board:manageboard, mit der Lehrende das gesamte Board verwalten. Hochschulen können die Rollen in Moodle anpassen, aber nur mit den Berechtigungen, die das Plugin mitbringt. Studierende könnten dann aber nicht nur alle Beiträge verschieben, sondern auch Spalten anlegen, umbenennen und löschen, fremde Beiträge bearbeiten und löschen und über den Export einsehen, wer welchen Beitrag verfasst hat. Die Anonymität der Beiträge wäre damit aufgehoben. Wir raten deshalb davon ab.

Das ist keine Zugänglichkeitsbarriere, sondern eine Funktionsgrenze. Mehrere Testpersonen haben sich gewünscht, fremde Beiträge verschieben zu können. Für viele didaktische Szenarien wäre das sinnvoll, etwa beim gemeinsamen Sortieren gesammelter Ideen. Wir empfehlen dem Anbieter, dafür eine eigene Berechtigung vorzusehen, die sich unabhängig von der Verwaltung des Boards vergeben lässt. Alternativ ließe sich die bestehende Einstellung zum Verschieben um die Option erweitern, dass Studierende alle Beiträge verschieben dürfen.

• Vergeben Sie sprechende, klar voneinander unterscheidbare Spaltenüberschriften und verwenden Sie im Arbeitsauftrag genau diese Bezeichnungen. Im Test führte eine Abweichung zwischen Auftrag und Spaltenüberschrift unmittelbar zu Verwechslungen.

• Halten Sie die Zahl der Spalten und die Zahl der Beiträge je Spalte überschaubar. Mit dem Screenreader werden die Spalten nacheinander gelesen, bei Tastaturbedienung wächst der Tabulatorweg mit jedem Beitrag um sechs Haltepunkte.

• Wählen Sie eine dunkle Hintergrundfarbe für das Board, damit sich die Spalten deutlich voneinander abheben. Sie können sie in den Einstellungen der Aktivität als Hex-Code eintragen, eine Farbpalette steht nicht zur Verfügung. Mit Schwarz #000000 ergibt sich gegenüber der Spaltenfläche ein Kontrastverhältnis von 17,5 zu 1, mit Dunkelblau #000060 ein Verhältnis von 14,9 zu 1.

• Verwenden Sie nicht die Einstellung, die die Spaltenüberschriften für Studierende ausblendet. Die Spaltenüberschriften sind die einzigen Überschriften, über die sich das Board mit einem Screenreader strukturiert erfassen lässt.

• Erläutern Sie die Struktur des Boards zu Beginn mündlich oder in der Aktivitätsbeschreibung: wie viele Spalten es gibt, wie sie heißen und was in welche Spalte gehört.

• Wenn Sie Bilder hochladen, tragen Sie die Bildbeschreibung für blinde Nutzer*innen in das Feld Bildtitel ein.

• Erklären Sie, was die Sternbewertung bedeutet. Formulieren Sie in der Aufgabenstellung, wofür der Stern stehen soll, etwa für Zustimmung oder als Hinweis auf besonders relevante Beiträge. Eine ablehnende oder abgestufte Rückmeldung ist nicht vorgesehen.

• Weisen Sie darauf hin, wo die Kommentare zu finden sind, nämlich im geöffneten Beitrag und in aktuellen Versionen auch über das Sprechblasensymbol auf der Beitragskarte, und dass ein neuer Kommentar unter Umständen erst nach erneutem Öffnen des Beitrags erscheint.

• Rechnen Sie damit, dass Screenreader-Nutzende und Nutzende von Vorlesewerkzeugen nicht erkennen können, ob ein Beitrag bereits bewertet wurde. Wenn die Zahl der Bewertungen für die Aufgabe wesentlich ist, geben Sie das Ergebnis zusätzlich mündlich oder in Textform bekannt.

• Verzichten Sie auf die Sortierung nach Sternanzahl, wenn die Reihenfolge für die Aufgabe relevant ist. Eine Umsortierung während der Arbeitsphase erschwert das Wiederfinden von Beiträgen erheblich, insbesondere bei Screenreader-Nutzung und starker Vergrößerung.

• Legen Sie fest, ob Studierende ihre eigenen Beiträge verschieben und Beiträge bewerten dürfen, und teilen Sie mit, was gilt. Formulieren Sie Arbeitsaufträge nur für Aktionen, die die Rolle der Studierenden zulässt. Das Verschieben fremder Beiträge gehört nicht dazu. Die Berechtigung zum Verwalten des Boards sollten Sie Studierenden dafür nicht geben, weil sie weit mehr erlaubt und die Anonymität der Beiträge aufhebt.

• Planen Sie für das zeitgleiche Arbeiten am Board großzügige Zeitfenster ein. Der Test mit Screenreader dauerte eine Stunde, die übrigen Sitzungen zwischen 25 und 35 Minuten.

• Verbalisieren Sie während einer gemeinsamen Arbeitsphase, was auf dem Board geschieht, und lesen Sie neue Beiträge vor.

• Klären Sie mit Ihrem Moodle-Support, in welchem Intervall sich das Board automatisch aktualisiert. Der Wert wird zentral in der Moodle-Instanz eingestellt, war nicht Gegenstand des Tests und ist für das zeitgleiche Arbeiten wichtig.

Der folgende Text ist als Vorlage für die Aktivitätsbeschreibung gedacht. Er kommt ohne Verweise auf die Bildschirmdarstellung aus und bleibt so auch mit Screenreader und Vorlesefunktion verständlich.

Auf diesem Board sammeln wir Beiträge in mehreren Spalten. Bitte tragen Sie Ihre Beiträge in die Spalte ein, die im Arbeitsauftrag genannt ist. So arbeiten Sie mit dem Board:

• Einen Beitrag anlegen: Aktivieren Sie in der gewünschten Spalte den Schalter zum Hinzufügen eines Beitrags, tragen Sie Überschrift und Text ein und speichern Sie.

• Einen Beitrag lesen: Aktivieren Sie den Beitrag. Er öffnet sich in einem Dialogfenster, das Sie mit der Escape-Taste wieder schließen. Wenn Sie sich den Text vorlesen lassen möchten, markieren Sie ihn im geöffneten Dialogfenster.

• Einen eigenen Beitrag verschieben: Aktivieren Sie auf der Beitragskarte den Verschiebeschalter und wählen Sie im Dialogfenster die Zielspalte. Eine Ziehbewegung ist nicht nötig.

• Einen Beitrag kommentieren: Aktivieren Sie den Beitrag, tragen Sie den Kommentar im Dialogfenster ein und senden Sie ihn ab. Öffnen Sie den Beitrag danach erneut, damit der neue Kommentar vorgelesen wird.

• Einen Beitrag bewerten: Mit dem Sternsymbol auf der Beitragskarte vergeben Sie einen Stern, etwa als Zustimmung. Abgestufte oder ablehnende Bewertungen sind nicht möglich.

Beiträge anderer Personen können Sie lesen, kommentieren und bewerten, aber nicht verschieben.

• Weisen Sie darauf hin, dass Beiträge in der Voreinstellung anonym sind, Lehrende die Zuordnung aber sehen können. Das Modul kann dazu einen Hinweistext anzeigen.

• Bitten Sie die Studierenden um Rückmeldung zu Barrieren und stellen Sie einen Weg bereit, auf dem sie sich melden können.

9.1.1.1b Alternativtexte für Grafiken und Objekte

Beiträge können Bilder enthalten. Ein eigenes Feld für den Alternativtext gibt es nicht. Stattdessen gibt das Modul den Bildtitel, der beim Hochladen als Pflichtfeld einzutragen ist, als alt-Attribut aus, auf der Beitragskarte wie im Dialogfenster. Dass dieser Titel als Alternativtext dient, ist im Formular nicht erkennbar, und ein Bild lässt sich nicht als dekorativ kennzeichnen. Wird ein Bild als Datei angehängt, erscheint es nur als Link mit dem Dateinamen. Empfohlen wird, das Feld als Alternativtext zu beschriften, einen kurzen Hinweis zum Inhalt zu ergänzen und eine Kennzeichnung als dekoratives Bild anzubieten.

9.1.3.1a Überschriften und Strukturen

Die Spaltenstruktur wird nicht so ausgezeichnet, dass sie sich mit dem Screenreader als Struktur erfassen lässt. Die Durchsicht des Quelltextes zeigt, woran das liegt. Die Spaltenüberschrift ist ein div-Element, das über role="heading" und aria-level="3" als Überschrift wirkt. Die sichtbare Beitragsüberschrift dagegen ist ein div-Element ohne Rolle. Ein zusätzliches Element mit role="heading" und aria-level="4" ist im Markup angelegt, trägt aber die Klasse hidden und wird an keiner Stelle eingeblendet. Das deckt sich mit der Beobachtung, dass Werkzeuge zur Anzeige der Überschriftenstruktur nur die Spaltenüberschriften auflisten. Die Hierarchie springt außerdem von der Überschrift erster Ebene der Seite unmittelbar auf die dritte Ebene, und die Spalten selbst sind reine div-Elemente ohne Rolle und ohne Bezeichnung.

Empfohlen wird eine Auszeichnung der Spalten als Bereiche, etwa über role="region" in Verbindung mit aria-labelledby zur Spaltenüberschrift, sowie eine durchgängige Hierarchie mit echten Überschriftenelementen: Titel des Boards als H1, Spaltenüberschriften als H2, Beitragsüberschriften als H3. Ein echtes Überschriftenelement ist einem div mit role="heading" vorzuziehen, weil es von mehr Werkzeugen ausgewertet wird. Zusätzlich sollte der zugängliche Name der Bedienelemente eines Beitrags die Beitragsüberschrift und, wo sinnvoll, die Spalte mitführen.

9.1.4.11 Kontraste von Grafiken und grafischen Bedienelementen

Das Sternsymbol wurde nicht als Bedienelement erkannt, weil es sich nicht sichtbar von der Beitragskarte abhebt. Gleiches gilt für die Abgrenzung der Spalten voneinander. Um den Kontrast geht es dabei nicht: Das Sternsymbol erreicht gegenüber der Beitragsfläche 12,21 zu 1, der Fokusring 3,71 zu 1 beziehungsweise 3,42 zu 1. Alle Werte liegen über dem Grenzwert von 3 zu 1. Ob man einen Beitrag selbst bewertet hat, zeigt das Sternsymbol derzeit nicht an, es wird in beiden Zuständen gleich dargestellt. Empfohlen wird eine sichtbare Begrenzung der interaktiven Symbole und eine erkennbare Unterscheidung zwischen bewertetem und nicht bewertetem Beitrag, die nicht allein über die Farbe getragen wird. Da die Spaltenfläche fest auf #eaeaea gesetzt ist, wären eine einstellbare Spaltenfarbe oder eine sichtbare Spaltenbegrenzung eine spürbare Verbesserung.

9.2.1.1 Ohne Maus bedienbar

Alle Bedienelemente sind mit der Tastatur erreichbar und auslösbar, die Dialogfenster sind vollständig bedienbar, und das Verschieben ist ohne Ziehbewegung möglich. Das Erfolgskriterium ist erfüllt. Die Bedienelemente sind allerdings als div-Elemente mit role="button" und tabindex="0" umgesetzt, nicht als button-Elemente. Empfehlenswert sind echte button-Elemente, damit die Fehlerquellen bei der Tastaturbedienung entfallen. Damit hängt ein Befund aus dem Test zusammen: Die Leertaste löste das Bedienelement aus, unterdrückte aber nicht das Blättern der Seite. Der Befund ließ sich bei einer Gegenprüfung nicht reproduzieren. Der Quelltext erklärt, warum das nicht überall gleich auftritt: Das Modul wertet die Tasten im Ereignis keypress aus und unterdrückt dort die Standardaktion. Das Blättern hängt aber am Ereignis keydown, das das Modul nicht behandelt. Ob die Seite springt, entscheidet damit der Browser. Unabhängig davon empfehlen wir, bereits im Ereignis keydown der Elemente mit der Rolle button die Standardaktion der Leertaste zu unterdrücken.

9.2.4.3 Fokus-Reihenfolge schlüssig

Die Tabulatorreihenfolge entspricht der visuellen Anordnung und ist schlüssig. Kritisch ist ihre Länge: Der Boardbereich des geprüften Boards enthält 133 Haltepunkte, je Beitrag sechs. Zwei davon führen zum selben Ziel, weil sowohl die Beitragsüberschrift als auch der Beitragstext das Dialogfenster öffnen. Empfohlen wird, je Beitrag nur einen Haltepunkt für das Öffnen vorzusehen und die Spalten als Bereiche auszuzeichnen, damit der Tabulatorweg über Landmarken abgekürzt werden kann. Sinnvoll wäre zusätzlich eine Tastenkombination für den Sprung von Spalte zu Spalte.

9.2.4.6 Überschriften und Beschriftungen aussagekräftig

Die Bezeichnung Bewertung beschreibt die Funktion nicht zutreffend. Empfohlen wird eine Bezeichnung, die die Funktion benennt, etwa Als wichtig kennzeichnen. Der zugängliche Name des Schalters sollte zusätzlich den aktuellen Zustand und die Anzahl der Bewertungen mitführen. Derzeit besteht der Schalter im Wesentlichen aus der Zahl der Bewertungen, was dazu führt, dass Vorlesewerkzeuge diese Zahl am Ende jedes Beitrags mitlesen.

9.4.1.2 Name, Rolle, Wert verfügbar

Die Bedienelemente des Boards tragen aussagekräftige Namen. In den Dialogfenstern liegen jedoch Bedienelemente ohne zugänglichen Namen im Tabulatorweg: elf Schalter der Emoji-Auswahl im Kommentarfeld und acht Verweise des Dateiauswählers. Diese Elemente stammen aus dem Kern von Moodle, sind aber in den Dialogfenstern von Board wirksam. Empfohlen wird, die Befunde an die Moodle-Entwicklung weiterzugeben und die Emoji-Auswahl aus dem Tabulatorweg zu nehmen, solange sie eingeklappt ist.

Ein zweiter Punkt betrifft die Schalter des Moduls selbst. Der Bewertungsschalter und der Kommentarschalter enthalten die jeweilige Anzahl als sichtbaren Text in einem span-Element. Beide tragen zugleich ein aria-label, beim Bewertungsschalter mit Beitrag und Spalte, beim Kommentarschalter mit dem festen Text View comments. Ein aria-label ersetzt den Inhalt des Elements vollständig, die Zahlen gehören damit nicht zum zugänglichen Namen. Empfohlen wird, die Zahl in das aria-label aufzunehmen, etwa als Kommentare anzeigen, „drei Kommentare“. Beim Bewertungsschalter sollte zusätzlich aria-pressed ausweisen, ob man den Beitrag selbst bewertet hat.

9.4.1.3 Statusmeldungen programmatisch verfügbar

Die Anzahl der Bewertungen wird mit dem Screenreader nicht ausgegeben, und ein neu abgesendeter Kommentar erscheint erst nach erneutem Öffnen des Beitrags. Im Quelltext findet sich an keiner Stelle eine Region mit aria-live. Nach dem Absenden eines Kommentars lädt das Modul die Kommentarliste neu und ersetzt dabei den gesamten Kommentarbereich des Dialogfensters, einschließlich des Schalters, der gerade den Fokus hatte. Den Zähler auf der Beitragskarte führt es seit Release 1.405.02 nach, angekündigt wird die Änderung aber nicht. Empfohlen wird, die Zahl der Bewertungen und die Zahl der Kommentare im zugänglichen Namen des jeweiligen Schalters zu führen und Änderungen über eine Live-Region anzukündigen. Nach dem Absenden eines Kommentars sollte der Fokus im Kommentarbereich erhalten bleiben, etwa auf dem Eingabefeld oder dem neuen Kommentar.

Dieses Erfolgskriterium ist in der rechtlich maßgeblichen Fassung V3.2.1 der EN 301 549 noch nicht enthalten, wohl aber in der Fassung V4.1.1. Es wird hier aufgeführt, weil der Hersteller die Konformität mit der WCAG 2.2 ausweist und weil das Kriterium für Pinnwände zentral ist. Das Verschieben eines Beitrags ist bei Board nicht auf eine Ziehbewegung angewiesen und war mit Screenreader, Spracherkennung, Tastatur und per Touch nutzbar. Das Erfolgskriterium ist erfüllt. Dieses Verhalten sollte erhalten bleiben, eine reine Drag-and-Drop-Lösung wäre ein Rückschritt.

• Eine Textmarkierung auf der Beitragskarte sollte nicht das Dialogfenster öffnen. Derzeit trägt die gesamte Beitragsfläche den Befehl zum Öffnen, sodass Vorlesewerkzeuge nicht auf markierten Text zugreifen können. Empfohlen wird, beim Auslösen zu prüfen, ob eine Textauswahl besteht, oder das Öffnen auf einen eigenen Schalter zu legen.

• Der Kommentarschalter auf der Beitragskarte, ab Release 1.405.02 vorhanden, löst das Auffindbarkeitsproblem. Er sollte zusätzlich die Anzahl der Kommentare im zugänglichen Namen führen und den Beitrag benennen, zu dem er gehört. Derzeit lautet sein Name unabhängig vom Beitrag und von der Anzahl View comments.

• Die Liste der Zielpositionen beim Verschieben sollte nach Spalten gruppiert werden.

• Für das Verschieben fremder Beiträge sollte es eine eigene Berechtigung geben, etwa mod/board:moveallposts, die Lehrende der Rolle Studierende in einer Aktivität gezielt zuweisen können. Alternativ ließe sich die bestehende Einstellung zum Verschieben eigener Beiträge um die Option erweitern, alle Beiträge verschieben zu dürfen. Derzeit lässt sich dieses Recht nur über mod/board:manageboard vergeben. Diese Berechtigung umfasst zugleich das Verwalten der Spalten, das Bearbeiten und Löschen fremder Beiträge und den Export mit den Namen der Verfassenden und hebt damit die Anonymität auf.

• Brickfield Education Labs: Board User Guide. https://docs.brickfield.ie/mod-board/

• Brickfield Education Labs: Quelltext des Moduls mod_board, Zweig MOODLE_405_STABLE, Releases 1.405.00 bis 1.405.05 mit Änderungsprotokoll CHANGES.md, abgerufen am 19.09.2026. https://github.com/brickfield/moodle-mod_board

• Moodle Market Place: https://marketplace.moodle.com/plugins/2693

• Moodle Docs: Override permissions, Moodle 4.5. https://docs.moodle.org/405/en/Override_permissions

• ETSI EN 301 549 V3.2.1 (2021-03): Accessibility requirements for ICT products and services. https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf

• ETSI EN 301 549 V4.1.1 (2026-09): Accessibility requirements for ICT products and services. https://www.etsi.org/deliver/etsi_en/301500_301599/301549/04.01.01_60/en_301549v040101p.pdf

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/

• W3C: ARIA Authoring Practices Guide. https://www.w3.org/WAI/ARIA/apg/

• BIK für Alle: BITV-Selbsttest, Prüfschritte 9.1.4.4 und 9.1.4.10. https://www.bitvtest.de/

• Kompetenzzentrum digitale Barrierefreiheit.nrw: Testergebnisse zu Padlet und TaskCards, Stand Mai 2023. https://barrierefreiheit.dh.nrw/tests/ergebnisse

• Padlet: Padlet Accessibility FAQs, abgerufen am 19.09.2026. https://padlet.help/l/en/article/pyr0huo2v4-padlet-accessibility-faq-jib