Am 21. Mai fand im Rahmen des Global Accessibility Awareness Day (GAAD) unser eLeDia.summit statt. Einen Tag lang haben wir uns in verschiedenen Webinaren mit Barrierefreiheit beim digitalen Lernen beschäftigt. Lesen Sie hier hilfreiche Informationen für barrierefreies Lernen.
Barrierefreieheits-Check: Warum nur 9 % der PDFs den Test bestehen
Beim eLeDia.summit zum Thema Barrierefreiheit hat Nico Maikowski von der Stiftung Pfennigparade Business. Inklusiv. einen ernüchternden Blick auf den Status quo geworfen – und zugleich gezeigt, wie viel sich mit einfachen Mitteln verbessern lässt.
Über barrierefreie Webseiten reden wir mittlerweile selbstverständlich. Über barrierefreie Dokumente viel zu selten. Dabei sind Dokumente – PDFs, Word-Dateien, Skripte, Schulungsunterlagen – noch immer der Bereich, der die meisten Hürden produziert. Genau hier setzte der vierte Vortrag des eLeDia.summit an: Nico Maikowski, Teamleiter Digitale Barrierefreiheit bei Pfennigparade Business. Inklusiv., hat Zahlen, Werkzeuge und Praxistipps mitgebracht. Was bleibt, ist ein klares Bild: Der Weg zu barrierefreien Dokumenten ist machbar – wenn man die richtigen Schritte kennt.
Es geht um deutlich mehr Menschen, als viele denken
Etwa zehn Prozent der Bevölkerung in Deutschland haben einen Schwerbehindertenausweis – das sind rund 8 Millionen Menschen mit einem Grad der Behinderung von 50 oder mehr. Diese Zahl ist beeindruckend genug. Sie ist aber, so Maikowski, nur die halbe Wahrheit. Die zweite Hälfte sind die situativen Beeinträchtigungen, die jede und jeden treffen können: den Vater, der mit Kind auf dem Arm einhändig telefoniert. Der Rentner mit altersbedingter Sehschwäche, der ein amtliches PDF-Formular online ausfüllen soll. Lernende, die nach einem langen Bildschirmtag lieber zuhören, statt zu lesen. Alle profitieren von strukturierten, sauber ausgezeichneten Dokumenten.
Diese Logik kennen wir aus der Architektur als Curb-Cut-Effekt: Die abgesenkte Bordsteinkante wurde für Rollstuhlfahrer*innen gebaut – heute hilft sie auch Eltern mit Kinderwagen, Reisenden mit Koffer und Radfahrer*Innen. Genauso verhält es sich mit digitalen Dokumenten. Ein gut strukturiertes PDF mit Tags und Alternativtexten hilft Screenreader-Nutzer*innen – und allen anderen, weil es besser durchsuchbar, kopierbarer und langfristig nutzbar ist.
Der Status quo: ernüchternde 9 Prozent
Eine aktuelle Studie des BFIT-Bund (2026) hat fast 70.000 PDF-Dokumente öffentlicher Stellen geprüft. Das Ergebnis fasste Maikowski ohne Beschönigung zusammen:
- Nur 9 % der untersuchten Dokumente sind PAC-konform – bestehen also den automatisierten Prüfdurchlauf des PDF Accessibility Chekers (PAC).
- Bei 53 % findet der Prüfer konkrete Fehler, die die Nutzung behindern.
- 37 % sind komplett ohne Tags – für Screenreader praktisch unzugänglich.
- Die Quote verbessert sich seit fünf bis sechs Jahren kaum. Die absolute Zahl barrierefreier Dokumente wächst, ihr prozentualer Anteil bleibt im einstelligen Bereich.
Dass diese Zahlen mehr als ein Verwaltungsproblem sind, wird in Lernkontexten besonders schnell sichtbar: Schulungsunterlagen, Studienskripte und Handbücher sind häufig PDFs – und damit liegt genau hier die größte Lücke im sonst gut etablierten Inklusionsanspruch. „Dokumente sind der Punkt, an dem man sich am meisten den Kopf zerbricht – und an dem am meisten Fehler liegen“, beschreibt Nico Maikowski die Situation.
Die häufigsten Fehler – und warum sie so leicht zu vermeiden wären
Spannend an Maikowskis Analyse ist, dass die Top-Fehler kaum technisch anspruchsvoll sind. Es sind Routine-Versäumnisse, die mit wenigen Minuten pro Dokument vermeidbar wären:
- Der Dokumententitel fehlt. Statt eines sprechenden Titels wird im PDF-Reader nur der kryptische Dateiname angezeigt – Screenreader lesen exakt das vor.
- Der Textkontrast ist zu schwach. Gerade Grau- und Gelbtöne sind beliebt im Design, aber für Sehbeeinträchtigte oft unleserlich. Allein dieser Fehler macht 35 % der Beanstandungen aus.
- Die Sprache des Dokuments ist nicht hinterlegt. Ohne Sprachattribut versucht der Screenreader, ein deutsches Dokument auf englisch vorzulesen – oder umgekehrt. Das macht den Inhalt unbrauchbar.
- Die Struktur fehlt komplett. Überschriften sind keine Überschriften, sondern nur fett formatierter Text. Listen sind keine Listen. Tabellen haben keine Header. Damit verliert das Dokument seine Navigation.
- Alternativtexte fehlen oder sind nichtssagend. Bilder ohne Alt-Text sind für Screenreader unsichtbar; Bilder mit „grafik1.jpg“ als Beschreibung genauso.
- Die PDF-Erstellung erfolgt über „Drucken“ statt „Exportieren“. Beim Drucken-zu-PDF wirft Word die komplette semantische Struktur weg – das fertige PDF ist ein leerer, optisch identischer Container ohne Tags.
So funktioniert es richtig: Word als Ausgangspunkt
Die gute Nachricht: Die allermeisten Lerndokumente entstehen in Word – und Word kann von Haus aus alles, was man für ein barrierefreies PDF braucht. Es geht weniger um Spezialwissen und mehr um die konsequente Nutzung der Bordmittel.
Formatvorlagen statt Optik-Tricks
Das wichtigste Prinzip ist banal: Überschriften sind Überschriften, weil sie das Format „Überschrift 1“, „Überschrift 2“ usw. bekommen – nicht, weil sie fett und größer aussehen. Erst die Formatvorlage gibt dem PDF nachher die Tag-Struktur (H1, H2 …), an der sich Screenreader orientieren. Dasselbe gilt für Listen (echte Aufzählungen, nicht eingerückte Striche), Absätze und Zitate. Wer hier durchgängig die Word-Werkzeuge benutzt, hat den größten Schritt schon getan.
Bilder, Tabellen, Hyperlinks
Drei Detailpunkte, die in der Praxis am häufigsten geprüft werden:
- Bilder: Per Rechtsklick „Alternativtext“ eintragen – ein bis zwei Sätze, idealerweise unter 150 Zeichen, ein Satz ist empfohlen. Wer in der Office-Variante mit „QuickInfo“ arbeitet, sollte auch diese füllen, weil sie ebenfalls in den Alt-Text des PDF übergeht.
- Tabellen: Erste Zeile als Kopfzeile definieren, bei Bedarf auch die erste Spalte. Verschachtelte Tabellen (Tabelle in Tabelle) konsequent vermeiden – sie zerstören die Tastatur-Navigation.
- Hyperlinks: Sprechende Linktexte verwenden („Zur Studie des BFIT-Bund“) statt „hier klicken“ oder roher URL. Auch die QuickInfo am Link kann zusätzliche Orientierung geben.
Dokumenteneigenschaften – die unsichtbaren Pflichtfelder
Bevor das Word-Dokument zu PDF wird, lohnt ein Blick in die Dokumenteneigenschaften. Dort sollten mindestens drei Felder gefüllt sein: Titel (wird zum PDF-Dokumententitel), Sprache (entscheidend für die korrekte Aussprache durch Screenreader) und – ein häufig vergessener Punkt – das Einbetten der Schriftarten. Letzteres garantiert, dass das PDF an jedem Rechner gleich aussieht und Sonderzeichen sauber dargestellt werden, auch dann, wenn die verwendete Schrift dort nicht installiert ist.
Word-eigenen Barrierefreiheits-Checker nutzen
Word bringt einen eigenen Checker mit: „Überprüfen“ → „Barrierefreiheit überprüfen“. Er listet die häufigsten Lücken (fehlende Alt-Texte, schwache Kontraste, leere Überschriften) übersichtlich auf und springt direkt an die problematische Stelle. Dieser Schritt sollte vor jedem Export zur Routine werden.
Und am Ende: Exportieren, nicht drucken
Wenn das Word-Dokument fertig ist, geht es über „Datei → Exportieren → PDF/XPS-Dokument erstellen“ zum PDF. Wichtig sind dabei die Optionen, die Word standardmäßig anbietet, aber gelegentlich versteckt: „Textmarken aus Überschriften erstellen“, „Dokumentstrukturtags für Barrierefreiheit“ und die Sprach-/Schrifteinbettung müssen aktiviert sein. Wer stattdessen über „Drucken“ → „PDF“ geht, opfert alle diese Strukturen – und beginnt von vorn.
Nach dem Export: Prüfen mit PAC und Adobe Acrobat
Das fertige PDF in den PDF Accessibility Checker (PAC) ziehen – das kostenlose Tool prüft das Dokument gegen die offiziellen Kriterien und liefert in Sekunden einen Bericht: grün bedeutet, dass alle technischen Anforderungen erfüllt sind, rot zeigt punktgenau, wo Tags fehlen, welche Überschrift leer ist oder welche Tabelle keinen Header hat.
Aber – und das ist der wichtige Einwand, den Maikowski mehrfach betont hat – PAC reicht nicht aus. Der Checker prüft nur das, was sich technisch prüfen lässt. Eine leere Überschrift, die formell ein Tag hat, ist technisch korrekt, semantisch aber wertlos. Ein Alt-Text, der „grafik“ lautet, besteht den Test, hilft aber niemandem. Die ehrliche Aussage lautet deshalb: PAC ist ein notwendiges, aber kein hinreichendes Werkzeug. Ergänzend braucht es einen menschlichen Blick – im Idealfall durch jemanden, der das Dokument mit einem Screenreader durchgeht.
Wer tiefer einsteigen will, bekommt mit dem Adobe-Acrobat-Plug-in zusätzlich Werkzeuge an die Hand: die logische Struktur des Dokuments visualisiert (welche Überschrift folgt auf welche, sind alle Inhalte erreichbar), die Lesereihenfolge im Detail und ein Side-by-Side-Vergleich von Tags und gerendertem Layout.
Weiterführende Ressourcen
Drei Anlaufstellen, die Nico Maikowski besonders empfohlen hat:
- BFIT-Bund Handreichung für barrierefreie Dokumente: umfassende Anleitungen für Word, Excel, PowerPoint und InDesign – Quelle der oben zitierten Studie und der Standard-Empfehlungen.
- PAC – PDF Accessibility Checker: kostenloses Test-Tool, das gegen die offiziellen Kriterien prüft.
- Stiftung Pfennigparade – Test- und Beratungsangebot: Kriterienkatalog mit 60-70 Punkten und qualitative Tests durch zertifizierte Spezialist*innen (ADS, IAP).
Take-Away
Barrierefreie Dokumente sind kein Spezialthema für Spezialist*innen – sie sind handwerkliches Grundwissen für alle, die Lerninhalte produzieren. Die wichtigsten Schritte stecken längst in Word: Formatvorlagen statt Optik-Tricks, Alt-Texte statt leerer Bilder, Export statt Drucken. Wer diesen Workflow ein paar Mal durchläuft, baut nach kurzer Zeit selbstverständlich barrierefreie Dokumente – und sorgt damit nicht nur dafür, dass behinderte Menschen lernen können, sondern auch dafür, dass alle anderen besser lernen.
Wir bei eLeDia sehen das als zentralen Baustein einer barrierefreien Moodle-Welt: Plattform, Tools wie ReadSpeaker und Inhalte greifen erst dann wirklich, wenn auch die Dokumente die Hausaufgaben gemacht haben. An genau diesem Punkt setzte der Vortrag von Nico Maikowski an – und nahm uns dabei das Gefühl, das sei alles unerreichbar weit weg. Es ist nicht weit weg. Es fängt beim nächsten Skript an, das wir in Word verfassen.
Mehr Infos über Barrierefreiheit in Moodle finden Sie auch auf unsere Seite
