Accessible PDF Reader
Eine Web-App, die PDFs per Frage beantwortet — mit Barrierefreiheit als Fundament.
PDF hochladen, eine Frage zum Dokument stellen, die Antwort bei Bedarf vorlesen lassen. Konzipiert von der schwierigsten Nutzung her gedacht — blinde Screenreader-Nutzer — und durchgehend barrierefrei umgesetzt.
Konzept · Architektur · Frontend · Accessibility
2025
Python · FastAPI · OpenAI · pypdf · HTML/CSS/JS
Barrierefreiheit (Blind-first)
Ein Dokument befragen, statt es durchzulesen
Eine kleine, fokussierte Anwendung: Dokument hochladen, befragen, vorlesen. Dahinter eine bewusst entkoppelte Architektur – fünf Module, jede Datei mit einer Aufgabe. Zwei Entscheidungen prägen das Projekt: eine klar definierte Naht für späteres RAG und eine Barrierefreiheit, die von der blinden Nutzung her gedacht ist statt nachträglich aufgesetzt.
02 Architektur
Jede Datei eine Aufgabe
Fünf Module, klar geschnitten. Kein Modul kennt mehr als es muss: pdf.py weiß nichts von der KI, ai.py nichts vom Web-Framework. Das macht jede Komponente einzeln testbar und austauschbar.
Vier Bausteine – plus die entscheidende Naht
context.py – ein Erweiterungspunkt
Eine Funktion, ein Umbaupunkt
Die ganze App greift nur über diese eine Funktion auf den Dokumentkontext zu. Heute liefert sie den Volltext in den Prompt. Ein späterer RAG-Umbau – Embeddings, Vektorsuche – berührt ausschließlich diese Funktion. Die Signatur bleibt, main.py und ai.py merken nichts. Architektur ist die Entscheidung, was sich später nicht ändern muss.
03 Barrierefreiheit
Johanna Wendt – Hauptpersona
„Ich will eine Frage stellen können – nicht ein halbes Buch durchhören."
Johanna studiert berufsbegleitend und ist von Geburt an blind. Lange Dokumente – Skripte, Verträge, Behördenpost – arbeitet sie mit dem Screenreader durch. Statt sie linear durchzuhören, will sie sie gezielt befragen.
- Eine konkrete Frage ans Dokument stellen, statt es von vorn durchzuhören.
- Mit der eigenen Screenreader-Stimme und -Geschwindigkeit arbeiten.
- Jederzeit wissen, wo sie im Ablauf steht.
- Lange Dokumente komplett durchhören kostet enorm Zeit.
- Auto-Play-Audio und doppelte Ansagen kollidieren mit dem Screenreader.
- Inkonsistente Fokus-Reihenfolge, fehlende Labels, kontextlose Buttons.
Entscheidungen, die direkt aus der Persona folgen
Wie das Interface durch den Ablauf führt
Jeder Zustand hat eine definierte Ansage und ein klares Fokusziel – damit ein Screenreader-Nutzer nie im Unklaren ist, was gerade passiert.
04 Test & Betrieb
End-to-End mit einer Test-PDF geprüft
Vier Fragetypen, ein Ziel: Antwortet das System nur auf Basis des Dokuments – und sagt es ehrlich, wenn etwas nicht drinsteht?
4/4
Testfälle bestanden
5
entkoppelte Module
100 %
Antworten dokumentbasiert
0
Halluzinationen im Test
Wie getestet wurde
Geprüft wurde auf vier Dinge: korrekte Fakten, korrekte Details, sauberes Abweisen einer Frage ohne Antwort im Dokument, und deutsches Vorlesen per Web Speech API.
Was der Test zeigte
Deployment & Kostenschutz
Web Service
Laufender Server mit serverseitigem Key. Free-Tier schläft nach ~15 Min – Kaltstart 30–60 s, PDF danach neu laden.
Hartes Limit
OpenAI Auto-Recharge aus – die öffentliche Demo kann keine unbegrenzten Kosten verursachen.
05 Ergebnis
Eine lauffähige, barrierefreie App – sauber gebaut
PDF hochladen, befragen, vorlesen. End-to-End getestet, deployt, mit einer Architektur, die für RAG vorbereitet ist. Das System antwortet nur auf Basis des Dokuments – und sagt ehrlich, wenn etwas fehlt.
Was ich aus dem Projekt mitnehme
Eine gute Naht schlägt ein fertiges Feature
Die context.py-Schnittstelle erlaubt den Sprung zu echtem RAG, ohne die App umzubauen. Den Erweiterungspunkt früh und sauber zu setzen war wertvoller, als RAG sofort hinzustellen.
Barrierefreiheit gehört ins Fundament
Von der blinden Nutzung her zu denken hat Semantik, Fokus und Ansagen von Anfang an geformt. Nachträglich wäre das nie so konsistent geworden.