Nextcloud und die Barrierefreiheit im Web: Wo die offene Collaboration-Plattform heute steht – und wo sie noch hakt

Wer Nextcloud in einem Unternehmen, einer Behörde oder einer Hochschule einführt, hört in der Regel dieselben Argumente: Datenhoheit, offene Schnittstellen, keine Lizenzkosten, modulare Erweiterbarkeit. Selten fällt in diesen Gesprächen das Wort Barrierefreiheit. Das ist insofern bemerkenswert, als die Plattform inzwischen weit mehr ist als ein Dateiaustausch. Sie ist Kalender, Adressbuch, Chat, Videokonferenz, Office-Umgebung, Aufgabenverwaltung, Knowledge Base – also ein Arbeitsplatz. Und ein Arbeitsplatz, der nicht von allen Beschäftigten bedient werden kann, ist kein vollwertiger Arbeitsplatz, sondern eine Baustelle mit hübscher Oberfläche.

Die Debatte um Web Accessibility hat in den vergangenen zwei Jahren deutlich an Fahrt gewonnen. Das liegt nicht nur an einer gewachsenen Sensibilität für Inklusion, sondern auch an handfestem regulatorischem Druck: Mit dem Barrierefreiheitsstärkungsgesetz (BFSG) gelten in Deutschland seit Juni 2025 neue Anforderungen für viele digitale Produkte und Dienstleistungen, flankiert von der europäischen Norm EN 301 549 und den WCAG-Richtlinien in Version 2.1 beziehungsweise 2.2. Für öffentliche Stellen war Barrierefreiheit nach BITV 2.0 ohnehin schon länger verpflichtend. Nextcloud ist in beiden Welten unterwegs – und damit auch in beiden Haftungsdimensionen.

Ein interessanter Aspekt dabei: Die Diskussion über barrierefreie Software wird häufig als reines Frontend-Thema geführt, also als Frage von Kontrasten, Alternativtexten und Tastaturfallen. In einer Plattform wie Nextcloud greift das zu kurz. Barrierefreiheit ist hier ein Zusammenspiel aus Serverkonfiguration, Design-System, App-Ökosystem, Versionsstand und nicht zuletzt der Bereitschaft der Betreiber, ihre Instanz entsprechend einzurichten. Wer eine Nextcloud aufsetzt und hofft, das Thema erledige sich mit dem nächsten Update, wird enttäuscht werden.

Warum Nextcloud überhaupt ein Accessibility-Thema ist

Man muss sich die Nutzergruppen vor Augen führen. Ein IT-affiner Entscheider denkt bei Barrierefreiheit vielleicht zuerst an Screenreader-Nutzer. Tatsächlich ist das Spektrum deutlich breiter: Menschen mit Sehbehinderung und Blindheit, mit motorischen Einschränkungen, die auf Tastatursteuerung oder Sprachsteuerung angewiesen sind, mit kognitiven Einschränkungen, mit Legasthenie, mit Farbfehlsichtigkeit. Dazu kommen temporäre Einschränkungen – ein gebrochener Arm, ein Migräneanfall, ein lautes Großraumbüro – und situative Faktoren. Nicht zuletzt altern Belegschaften. Wer heute eine Plattform für zehn Jahre einführt, plant für Menschen, die in zehn Jahren andere Fähigkeiten haben als heute.

In der öffentlichen Verwaltung kommt ein zweiter Faktor hinzu: Beschäftigte mit Behinderung haben nach § 164 Abs. 4 SGB IX einen Anspruch auf barrierefreie Gestaltung des Arbeitsplatzes. Ein Intranet, ein Dokumentenmanagement oder eine Collaboration-Plattform, die nicht bedienbar ist, kann zu einem Fall für die Schwerbehindertenvertretung werden – und im Zweifel für die Integrationsämter, die Ausgleichszahlungen nach § 178 SGB IX verlangen können. Das ist keine theoretische Spitzfindigkeit, sondern gelebte Praxis in vielen Behörden.

Für Nextcloud-Nutzer bedeutet das: Man sollte die Frage nicht nur an die Community weiterreichen, sondern selbst aktiv werden. Es gibt Instanz-einstellungen, es gibt Themes, es gibt App-Auswahlentscheidungen, es gibt Konfigurationen, die den Unterschied ausmachen. Und es gibt Bereiche, wo man sich eingestehen muss, dass die Plattform noch nicht dort ist, wo sie sein sollte.

Das Design-System als Fundament – und seine Grenzen

Nextcloud hat in den letzten Jahren einen größeren Umbau seiner Benutzeroberfläche durchlaufen. Der Dateibrowser wurde von einer serverseitig gerenderten Tabelle auf eine Vue-basierte Anwendung umgestellt, ältere App-Masken wurden in ein einheitliches Design-System überführt. Das hat Vorteile für Konsistenz, aber auch Nebenwirkungen für Barrierefreiheit: Vue-Komponenten bringen ihre eigenen ARIA-Muster mit, und wenn diese nicht sauber implementiert sind, entstehen Barrieren, die in der alten Tabellenwelt schlicht nicht existierten.

Ein konkretes Beispiel: Eine klassische HTML-Tabelle mit Zeilen und Spaltenköpfen wird von Screenreadern zuverlässig als Tabelle angekündigt, solange man sie nicht mit div-Elementen nachbaut. Wird daraus eine virtuelle Liste mit eigenen Rollen, muss die Zugänglichkeits-API des Browsers korrekt gefüttert werden. Fehlt ein role-Attribut, fehlt der Hinweis auf die Spaltenüberschrift, dann hört der Screenreader eine mehr oder weniger sinnfreie Aneinanderreihung von Wörtern. Solche Fehler sind nicht immer offensichtlich, sie treten erst im realen Umgang zutage.

Die gute Nachricht: Nextcloud hat reagiert. Im Projekt gibt es ein Accessibility-Team, das sich explizit um Abnahmekriterien kümmert, es gibt automatisierte Prüfungen in der Continuous Integration, und seit einigen Versionen findet sich in den persönlichen Einstellungen ein Bereich für Barrierefreiheit mit Optionen für dunkles Design, hohen Kontrast und Bewegungsreduktion. Das klingt unspektakulär, ist aber der Hebel, an dem Administratoren ohne Programmierkenntnisse direkt ansetzen können.

Zu den Einstellungen gehört unter anderem die Möglichkeit, das Farbschema umzustellen, Animationen zu reduzieren und Links dauerhaft zu unterstreichen. Gerade letzteres wird unterschätzt: Wer Farben schlecht unterscheidet, erkennt Links im Fließtext möglicherweise nicht, wenn sie nur durch Blauton und Fettung abgesetzt sind. Die Unterstreichung ist eine einfache, wirkungsvolle Maßnahme – und sie kostet nichts.

Von der WCAG-Stufe zum Betrieb: Was Administratoren einstellen können

Für den Betrieb einer eigenen Instanz lassen sich grob drei Ebenen unterscheiden, auf denen Barrierefreiheit beeinflusst wird.

Erste Ebene: Theme und Grundeinstellungen

Über das Theming-Modul von Nextcloud lassen sich Firmenfarben hinterlegen – und genau hier lauern die ersten Fehler. Ein knalliges Corporate-Design mit hellgelbem Hintergrund und weißer Schrift ist visuell vielleicht markenkonform, aber es erfüllt die Kontrastanforderungen der WCAG nicht. Das Kontrastverhältnis zwischen Text und Hintergrund sollte mindestens 4,5:1 betragen, bei großen Überschriften 3:1. Wer diese Werte in seinem Branding nicht einhalten kann, sollte für die Arbeitsumgebung ein eigenes, kontrastreicheres Theme hinterlegen. Es ist erstaunlich, wie oft in Projekten die Markenfarbe gegen die Lesbarkeit gewinnt – und wie regelmäßig das später bereut wird.

Zu den Grundeinstellungen gehört außerdem ein klarer Fokusindikator. Tastaturnutzer müssen sehen, wo sie sich gerade befinden. Die Standardfokusringe moderner Browser reichen häufig nicht aus, weil sie in bunte Layouts einbleichen. Ein eigenes, deutlich sichtbares Fokus-Styling ist deshalb empfehlenswert.

Zweite Ebene: Apps und Funktionsumfang

Nicht jede Nextcloud-App ist gleich gut zugänglich. Die Kernanwendungen – Dateien, Kalender, Kontakte, Talk – werden kontinuierlich geprüft. Bei Erweiterungen aus dem App Store sieht die Lage gemischt aus. Manche werden von einzelnen Entwicklern gepflegt und sind nie mit Screenreadern getestet worden. Hier hilft eine nüchterne Bewertung: Welche Apps müssen wirklich für alle Beschäftigten zugänglich sein? Wo gibt es Alternativen? Ist eine Funktion zwingend für den Arbeitsablauf, oder ist sie eine Bequemlichkeit, die manche nutzen und andere ignorieren können?

Eine pragmatische Vorgehensweise ist die Einteilung in „Kern-Anwendungsfälle“ und „Nice-to-have“. Dateizugriff, Kalender, Chat und Videokonferenz gehören zur ersten Kategorie, und für diese muss man im Zweifel Nachbesserungen einfordern oder selbst beitragen. Ein Foto-Verwaltungs-Plugin für die Betriebsfeier gehört zur zweiten – hier darf man gelassen bleiben.

Dritte Ebene: Inhalte und Redaktion

Diese Ebene wird am häufigsten übersehen. Selbst die barrierefreieste Plattform wird zur Barriere, wenn Beschäftigte dort PDFs ablegen, die aus Scans ohne Textebene bestehen. Oder Videos, die keine Untertitel haben. Oder Bilder, deren Alternativtext lautet „IMG_2043.jpeg“. Barrierefreiheit ist auf dieser Ebene keine Softwarefrage, sondern eine Frage der redaktionellen Gewohnheit. Wer Nextcloud als Dokumentenplattform betreibt, sollte Mindeststandards definieren: barrierefreie PDFs, aussagekräftige Dateinamen, Alternativtexte beim Einstellen von Bildern. Das ist mühsam, aber es ist die einzige nachhaltige Lösung.

Der Fokus- und Tastatur-Test: Wo Nextcloud in der Praxis glänzt

Wer Nextcloud einmal konsequent ohne Maus bedient hat, kennt die typischen Stolpersteine. Grundsätzlich ist die Tastaturbedienung in den Kernanwendungen recht ordentlich. Man kann sich durch die Navigation hangeln, Dialoge öffnen, Dateien auswählen. In den letzten Versionen wurden Fokusfallen reduziert, also Situationen, in denen Tastaturnutzer in einem Dialog festhängen und ihn nicht mehr verlassen können. Auch das Zurücksetzen des Fokus nach dem Schließen eines Dialogs funktioniert inzwischen deutlich zuverlässiger als noch vor einigen Jahren.

Trotzdem gibt es Bereiche, in denen es hakt. In komplexen Masken – etwa beim Teilen von Ordnern oder beim Anlegen umfangreicher Freigaben – kann die Reihenfolge der fokussierbaren Elemente unlogisch wirken. Dann springt der Fokus von der oberen Leiste in den Inhaltsbereich und retour, statt der visuellen Struktur zu folgen. Solche Dinge lassen sich mit einem einfachen Test aufspüren: Bildschirm abdecken, nur mit Tab, Shift-Tab, Enter und Escape arbeiten. Wer dabei ins Schwimmen gerät, hat eine Barriere gefunden.

Ein weiterer Klassiker ist der Dateiupload. Drag-and-drop ist bequem, aber wer keine Maus bedienen kann, ist darauf angewiesen, dass ein alternativer Upload-Button über die Tastatur erreichbar ist – und zwar nicht erst nach drei Menüebenen. Hier hat sich die Lage verbessert, aber es bleibt eine der Stellen, an denen man als Administrator ein Auge darauf haben sollte.

Screenreader im Einsatz: Was NVDA, JAWS und VoiceOver über Nextcloud sagen

Die automatisierte Prüfung mit Tools wie axe oder Lighthouse liefert eine gute Ausgangsbasis, aber sie erkennt nur einen Teil der Probleme. Ein fehlendes Alternativtext-Attribut fällt auf, ein irreführender Zustandstext nicht. Deshalb sind manuelle Tests mit echten Screenreadern unverzichtbar – und dort zeigt sich ein differenzierteres Bild.

Grundsätzlich liest NVDA unter Windows die Kernnavigation von Nextcloud verständlich vor. Die Dateiliste wird als solche angekündigt, Aktionen sind erreichbar. Problematisch wird es bei sehr großen Verzeichnissen: Wenn Tausende Dateien auf einmal gerendert werden, verlieren einige Screenreader die Orientierung, weil die DOM-Struktur zu umfangreich wird. Die Antwort darauf sind Virtualisierung und paginierte Listen – technisch anspruchsvoll und in der Umsetzung nicht immer konsistent.

Auch Live-Regionen sind ein Thema. Wenn im Hintergrund eine Datei hochgeladen wird und der Fortschritt in einer Statusleiste erscheint, muss diese Änderung über eine ARIA-Live-Region angekündigt werden, damit Screenreader-Nutzer davon erfahren. In manchen Ansichten geschieht das, in anderen nicht. Das ist kein Beinbruch, aber es zeigt, dass Barrierefreiheit kein Zustand ist, den man einmal erreicht, sondern ein fortlaufender Prozess, der mit jeder UI-Änderung neu ausbalanciert werden muss.

Ein weiterer Punkt: Sprache und Aussprache. Nextcloud unterstützt eine große Zahl von Lokalisierungen. Für deutschsprachige Umgebungen ist das erfreulich, weil Menüpunkte wie „Teilen“ oder „Ordner“ in der Muttersprache erscheinen. Bemerkenswert ist, dass die Sprachausgabe je nach Screenreader unterschiedlich mit zusammengesetzten Substantiven umgeht. „Dateiablage“ kann zu einer unfreiwilligen Wortakrobatik führen. Das ist kein Versäumnis der Plattform, sondern ein generelles Problem der deutschen Sprache im Zusammenspiel mit Synthesizern – und ein Grund mehr, auf klare, kurze Beschriftungen zu setzen.

Videokonferenzen mit Talk: Untertitelung als Gamechanger

Der vielleicht spannendste Bereich ist Nextcloud Talk. Videokonferenzen sind für gehörlose und schwerhörige Menschen ohne Untertitel praktisch unbrauchbar – Lippenlesen funktioniert nur bei guter Bildqualität und direkter Kameraausrichtung, was in der Praxis selten gegeben ist. Auch für Menschen mit auditiven Verarbeitungsstörungen oder in lauten Umgebungen sind Live-Untertitel eine enorme Erleichterung.

Nextcloud hat hier mit der Transkriptionsfunktion einen Weg eingeschlagen, der auf Whisper-basierten Modellen aufsetzt und je nach Konfiguration lokal betrieben werden kann. Das ist in mehrfacher Hinsicht bemerkenswert: Erstens bleibt der Datenfluss unter eigener Kontrolle, was für Behörden und sensible Branchen ein zentrales Kriterium ist. Zweitens lässt sich die Transkription selbst hosten, wenn man bereit ist, die nötige GPU-Kapazität vorzuhalten. Drittens ergeben sich daraus Folgeanwendungen – etwa durchsuchbare Besprechungsprotokolle, die wiederum selbst eine Barrierefreiheitsfunktion darstellen.

Ehrlich gesagt: Die Qualität der Transkription ist nicht in jeder Umgebung überzeugend. Bei schlechter Mikrofonqualität, bei Fachjargon, bei Dialekt oder bei mehreren gleichzeitig sprechenden Personen sinkt die Trefferquote deutlich. Das ist keine Besonderheit von Nextcloud, sondern gilt für alle gängigen Systeme. Wichtig ist es, die Erwartungen realistisch zu justieren und Untertitel als Unterstützung zu begreifen, nicht als vollwertigen Ersatz für professionelle Schriftdolmetschung – die bei rechtlich relevanten Veranstaltungen weiterhin nötig bleibt.

Barrierefreiheit in den Mobile Apps

Nextcloud betreibt native Apps für iOS und Android. Dort sieht die Lage anders aus als im Web, weil die Plattformen eigene Accessibility-Frameworks mitbringen – VoiceOver auf iOS, TalkBack auf Android. Die Apps unterstützen grundlegende Bedienung mit diesen Systemen, aber die Abdeckung ist nicht so tief wie in etablierten Consumer-Apps. Das ist ein Ressourcenthema: Die Mobile-Teams sind klein, und Barrierefreiheit konkurriert mit Funktionserweiterungen.

Wer Nextcloud mobil in einem Unternehmen einsetzt, sollte deshalb testen, welche Funktionen betroffene Beschäftigte tatsächlich brauchen. Häufig sind das Dateizugriff, Freigaben und Kalender. Diese sind in der Regel solide bedienbar. Bei komplexen Einstellungen oder der Verwaltung von Freigaben kann die Web-Oberfläche die bessere Wahl sein. Die Kombination von Gerät und Aufgabe ernst zu nehmen, ist pragmatischer als die Forderung nach vollständiger Parität.

Die Rechtslage: Was seit 2025 wirklich gilt

Das Barrierefreiheitsstärkungsgesetz hat zum 28. Juni 2025 eine Reihe von Pflichten eingeführt, die sich an Hersteller und Dienstleister richten, die Verbraucherprodukte und -dienstleistungen anbieten. Der Anwendungsbereich ist breiter als gemeinhin angenommen: E-Books, Online-Shops, Bankdienstleistungen, Personenbeförderung, elektronische Kommunikationsdienste. Interne Collaboration-Plattformen für Beschäftigte fallen nicht automatisch darunter, solange sie nicht gegenüber Endkunden geöffnet sind.

Das heißt aber nicht, dass Betreiber aus dem Schneider sind. Erstens gibt es den schon erwähnten arbeitsrechtlichen Anspruch auf barrierefreie Arbeitsplatzgestaltung. Zweitens gibt es für öffentliche Stellen die BITV 2.0, die auf WCAG 2.1 AA verweist und auch interne Anwendungen einschließt, sofern sie einem erweiterten Nutzerkreis zugänglich sind. Drittens werden bei öffentlichen Ausschreibungen zunehmend Nachweise über die Konformität mit EN 301 549 verlangt. Wer eine Nextcloud beschafft und in einem Vergabeverfahren bestehen will, muss sich mit dem Thema befassen, ob er will oder nicht.

Ein weiterer Punkt: Der European Accessibility Act greift in der gesamten EU, und die nationalen Umsetzungen unterscheiden sich in Detailfragen. Wer Nextcloud in einem Konzern mit Standorten in mehreren Ländern betreibt, sollte die lokalen Umsetzungen prüfen. Nicht selten ergeben sich daraus strengere Anforderungen, als in Deutschland gelten.

Testen ohne Studium: ein pragmatischer Werkzeugkasten

Man muss kein Accessibility-Experte sein, um brauchbare Prüfungen durchzuführen. Einige Werkzeuge haben sich bewährt:

Browser-DevTools: Chrome, Firefox und Edge bringen integrierte Prüfungen mit, die grundlegende Kontrast- und Strukturprobleme sichtbar machen. Firefox hat mit dem Accessibility-Inspector ein besonders nützliches Werkzeug, weil es den Accessibility-Tree anzeigt statt nur das DOM.
axe DevTools (Browser-Erweiterung): liefert detaillierte Ergebnisse und schlägt Korrekturen vor. Für Deep-Links in einzelne Ansichten sehr praktisch.
Lighthouse: gibt einen groben Score und eignet sich für Trendmessungen. Ein Lighthouse-Score von 100 bedeutet allerdings nicht, dass die Anwendung barrierefrei ist – er bedeutet, dass die automatisierten Tests bestanden wurden.
NVDA (Windows, kostenlos): der Standard für Screenreader-Tests in Europa. Wer selbst Erfahrung sammeln will, kommt um eine Testinstallation nicht herum.
Orca (Linux): für Administratoren, die selbst auf Linux arbeiten, oft die naheliegendste Option. Die Unterstützung für moderne Webanwendungen ist in den letzten Jahren gewachsen, bleibt aber hinter NVDA zurück.
VoiceOver (macOS, iOS): für Apple-Umgebungen. VoiceOver hat eine etwas andere Interaktionslogik, weshalb man es nicht als Ersatz für NVDA-Tests betrachten sollte, sondern als Ergänzung.
Nur-Tastatur-Test: das günstigste und wirksamste Verfahren. Bildschirm dimmen, Maus weglegen, arbeiten.
Zoom-Test: Browser auf 200 Prozent vergrößern und prüfen, ob die Oberfläche noch bedienbar bleibt. WCAG 1.4.4 verlangt genau das, ohne horizontales Scrollen für normalen Text.

Diese Werkzeuge ersetzen keine Tests mit betroffenen Nutzern. Sie liefern aber eine solide Basis, um den Zustand der eigenen Instanz einzuschätzen und Prioritäten abzuleiten. Wer einmal mit einer Person gesprochen hat, die auf einen Screenreader angewiesen ist, wird feststellen, dass sich die Wahrnehmung von „Barrieren“ grundlegend verändert. Barrieren, die man selbst nie erlebt, übersieht man systematisch.

Beiträge aus der Community: Warum es sich lohnt, mitzumachen

Nextcloud ist ein Open-Source-Projekt und lebt davon, dass Fehler gemeldet und behoben werden. Für Barrierefreiheit gilt das in besonderem Maße, weil die Testabdeckung in diesem Bereich ressourcenintensiv ist. Ein detaillierter Bug-Report mit Angaben zu Browser, Screenreader, Version, betroffener Ansicht und erwartetem Verhalten ist Gold wert. Pauschale Meldungen der Form „Ist nicht barrierefrei“ helfen dagegen niemandem.

Es gibt im Projekt Arbeitsgruppen und regelmäßige Gesprächsrunden zu Barrierefreiheit, in denen Prioritäten diskutiert werden. Wer die Möglichkeit hat, Entwicklungsressourcen beizusteuern, sollte das tun – ein Patch für einen fehlenden Fokusring ist oft in wenigen Zeilen erledigt. Wer das nicht kann, kann zumindest systematisch testen und melden. Und wer selbst Entwickler beschäftigt, kann diese Zeit als Teil der Beschaffungsstrategie begreifen: Open Source heißt auch, Verantwortung für den eigenen Werkzeugkasten zu übernehmen.

Was in der Praxis noch fehlt

Es wäre unseriös, den Eindruck zu erwecken, Nextcloud sei in Sachen Barrierefreiheit bereits am Ziel. Es gibt Bereiche, in denen Nachholbedarf besteht.

Erstens: Konsistenz zwischen den Apps. Was in der Datei-App funktioniert, ist in der Deck- oder Forms-App nicht selbstverständlich. Ein einheitliches Accessibility-Konzept, das alle Erweiterungen bindet, wäre wünschenswert – und wird in der Community auch diskutiert.

Zweitens: Dokumentation. Wer heute wissen möchte, welche Konformitätsstufe Nextcloud in welcher Version erfüllt, findet dazu nur verstreute Informationen. Ein öffentlich geführtes Accessibility Conformance Report (ACR) nach dem Vorbild US-amerikanischer VPAT-Dokumente würde Beschaffungsprozesse enorm erleichtern. Einige Hersteller in vergleichbaren Märkten liefern das bereits. Hier ist Luft nach oben, und es wäre eine verhältnismäßig günstige Maßnahme mit großer Wirkung.

Drittens: Barrierefreie Dokumentbearbeitung. Beim gemeinsamen Bearbeiten von Office-Dateien über Collabora oder OnlyOffice werden Tabellen, Bilder und Formatierungen verändert. Ob diese Änderungen barrierefreie Strukturen erhalten oder zerstören, hängt stark von den eingesetzten Editoren ab. Wer in einer Behörde mit Pflicht zur barrierefreien Dokumentenerstellung arbeitet, sollte den gesamten Erstellungsprozess prüfen – nicht nur den Export.

Viertens: Custom-Themes. Viele Organisationen passen das Erscheinungsbild an. Wenn dabei Kontraste, Fokusindikatoren und Systemschriftgrößen nicht mitgedacht werden, wird eine ansonsten gut zugängliche Instanz durch Konfiguration barrierebehaftet. Hier braucht es klare Richtlinien, nicht nur für die IT, sondern auch für die Kommunikationsabteilungen, die das Design vorgeben.

Ein realistischer Fahrplan für Betreiber

Wer jetzt anfängt, sollte nicht versuchen, alles gleichzeitig zu lösen. Ein pragmatischer Fahrplan kann so aussehen:

Schritt 1: Bestandsaufnahme. Welche Anwendungsfälle sind kritisch? Welche Personen sind betroffen? Wer im Haus hat Erfahrung mit assistiven Technologien? Gibt es bereits Beschwerden aus der Belegschaft?

Schritt 2: Konfigurieren. Theme und Kontraste prüfen, Fokusindikatoren sicherstellen, Schriftgrößenanpassung ermöglichen, Bewegung reduzieren ermöglichen, Tastaturnutzung testen. Diese Maßnahmen kosten wenig und wirken unmittelbar.

Schritt 3: Messen. Automatisierte Prüfungen in den Auslieferungsprozess integrieren, manuelle Tests mit Screenreadern etablieren, Ergebnisse dokumentieren und wiederkehren lassen. Barrierefreiheit ist kein Projekt mit Enddatum.

Schritt 4: Ausbilden. Redakteure schulen, damit Alternativtexte, Dateinamen und Formate stimmen. Administratoren schulen, damit sie Know-how für die Beurteilung von Apps und Konfigurationen haben.

Schritt 5: Mitwirken. Fehler melden, Diskussionen verfolgen, gegebenenfalls Ressourcen in die Weiterentwicklung einbringen. Das ist keine Altruismus-Übung, sondern Investition in die eigene Plattform.

Fazit

Nextcloud ist in Sachen Web Accessibility in den vergangenen Jahren deutlich vorangekommen – nicht spektakulär, aber kontinuierlich. Die Grundlagen stimmen: ein Design-System, das Barrierefreiheit als Teil der Komponentenspezifikation begreift, Konfigurationsmöglichkeiten für individuelle Bedürfnisse, Bemühungen um Untertitelung in Videokonferenzen und ein wachsendes Problembewusstsein im Projekt. Gleichzeitig bleibt die Lage uneinheitlich, besonders im App-Ökosystem, und wer aus regulatorischen Gründen einen lückenlosen Nachweis über die Konformität mit WCAG 2.1 AA benötigt, wird in absehbarer Zeit einigen Aufwand in die Dokumentation und Nachbesserung stecken müssen. Das ist kein Grund, auf eine andere Lösung auszuweichen. Es ist ein Grund, die eigene Instanz ernsthaft zu prüfen und die Ergebnisse nicht in einer Schublade verschwinden zu lassen.

Der eigentliche Gewinn liegt ohnehin nicht in der Konformitätserklärung. Er liegt darin, dass alle Beschäftigten die Werkzeuge nutzen können, die ihnen zur Verfügung gestellt werden. Wer einmal erlebt hat, wie viel Reibung ein schlecht gestaltetes Formular für einen Menschen mit Sehbehinderung erzeugt, versteht, warum dieses Thema nicht mit einem Häkchen in der Beschaffungsliste erledigt ist. Barrierefreiheit ist am Ende eine Frage der Sorgfalt – und der Bereitschaft, die eigene Perspektive zu hinterfragen. Beides lässt sich in einer Nextcloud-Instanz üben. Nicht zuletzt deshalb lohnt es sich, dieses Thema nicht nur den Spezialisten zu überlassen.

Nextcloud und Barrierefreiheit Wo die Plattform heute steht und wo es noch hakt