Es gibt eine hartnäckige Fehlannahme in der Entwicklergemeinschaft: Wer eine Anwendung im Terminal betreibt, ohne Grafiken, ohne komplexes DOM und ohne WebGL-Canvas, der liefert automatisch ein barrierefreies Produkt. Schließlich ist es doch „nur Text" – und Text kann ein Screenreader problemlos vorlesen. Diese Logik klingt plausibel, ist aber in der Praxis gefährlich falsch.
Das Architekturproblem: Stream versus Grid
Der entscheidende Denkfehler liegt im Unterschied zwischen zwei grundlegend verschiedenen Konzepten: dem klassischen Textstrom und dem modernen Zeichen-Grid. Traditionelle Terminals arbeiteten mit sequenziellen Ausgabeströmen – ein Zeichen nach dem anderen, linear und für Screenreader gut interpretierbar. Moderne TUI-Frameworks wie Ink (JavaScript/React), Bubble Tea (Go) oder tcell hingegen behandeln das Terminal als zweidimensionale Zeichenfläche. Sie positionieren Elemente pixelgenau auf einem virtuellen Raster, überschreiben Bereiche mit ANSI-Escape-Sequenzen und rendern komplexe Layouts – visuell beeindruckend, für assistive Technologien jedoch weitgehend unlesbar.
Screenreader greifen auf den Textpuffer des Terminals zu und erwarten einen sinnvollen, geordneten Datenstrom. Was sie stattdessen vorfinden, sind fragmentierte Zeichenfolgen, Escape-Codes für Farben und Cursor-Bewegungen sowie Inhalte, die je nach Bildschirmgröße dynamisch umgebrochen oder neu angeordnet werden. Das Ergebnis: blinde Nutzer erhalten entweder kryptischen Zeichensalat oder gar keine verwertbare Information.
Developer Experience vs. User Experience
Die Ironie ist kaum zu übersehen. Frameworks wie Bubble Tea oder Ink wurden entwickelt, um die Developer Experience (DX) zu verbessern – Entwickler sollen schneller, eleganter und mit weniger Boilerplate-Code ansprechende Terminal-Oberflächen bauen können. Doch dieser Komfort für die Entwicklerseite geht direkt auf Kosten der Zugänglichkeit für einen Teil der Nutzerschaft. Während grafische Oberflächen durch Standards wie ARIA-Labels, Accessibility-APIs und gesetzliche Vorgaben (etwa den European Accessibility Act) zunehmend unter Druck stehen, barrierefrei zu sein, existiert im TUI-Bereich kaum vergleichbarer Druck oder Bewusstsein.
Dabei sind Terminals traditionell ein wichtiges Werkzeug für technisch versierte blinde Nutzer. Viele Entwickler, Systemadministratoren und Power-User mit Sehbehinderung setzen seit Jahrzehnten auf kommandozeilenbasierte Werkzeuge – gerade weil diese zuverlässig mit Screenreadern funktionierten. Die neue Generation hübsch gestalteter TUIs droht diesen Personenkreis systematisch auszuschließen.
Abstraktion als doppelschneidiges Schwert
Das Problem lässt sich in einen breiteren Kontext einordnen: Die Softwareentwicklung lebt von Abstraktionen. Komplexität wird verborgen, um Produktivität zu steigern. Doch jede Abstraktion hat ihren Preis – sie verringert das Verständnis für die darunterliegenden Mechanismen. Wer ein TUI-Framework nutzt, ohne zu verstehen, wie Terminals intern mit Zeichenpuffern und Accessibility-APIs interagieren, baut unwissentlich Barrieren ein. Die Lösung liegt nicht im Verzicht auf moderne Frameworks, sondern in einem bewussteren Umgang: Entwickler müssen Barrierefreiheit als festen Bestandteil des Designs betrachten, nicht als nachträgliche Korrekturmaßnahme.
Konkret bedeutet das: TUI-Frameworks müssten Accessibility-Hooks anbieten, semantische Informationen über Elemente exportieren und mit Screenreader-APIs wie AT-SPI (Linux) oder UIA (Windows) kommunizieren. Einige Projekte beginnen, in diese Richtung zu denken – doch der Weg zu wirklich barrierefreien Terminal-Anwendungen ist noch weit. Solange „es läuft im Terminal" als Qualitätsmerkmal für Zugänglichkeit gilt, werden blinde Nutzer weiterhin ausgeschlossen – ausgerechnet von einer Technologie, die einst als ihre Domäne galt.
Quellen: Hacker News