Die Lüge des Textmodus: Warum moderne TUIs ein Albtraum für die Barrierefreiheit sind

 (xogium.me)
6 Punkte von GN⁺ 2026-05-04 | 2 Kommentare | Auf WhatsApp teilen
  • Die Annahme, dass Terminal-Apps textbasiert und damit von Natur aus barrierefrei seien, zerbricht bei modernen TUIs; Frameworks wie Ink, Bubble Tea und tcell können für Screenreader-Nutzer sogar ein feindlicheres Umfeld schaffen
  • CLIs arbeiten mit linearen stdin/stdout-Streams, in denen sich Ausgaben chronologisch ansammeln, während TUIs das Terminal als zeichenzellenbasiertes 2D-Raster behandeln, dem Screenreader nur schwer folgen können
  • Bei gemini-cli zeichnet Ink den React-Komponentenbaum passend zum Terminalraster neu und bewegt dabei den Cursor zwischen Spinner, Timer und Gesprächsverlauf, was bei Speakup und NVDA wiederholtes Vorlesen, Abstürze und Eingabeverzögerungen auslösen kann
  • Ältere Werkzeuge wie nano, vim, menuconfig und Irssi reduzieren den Lärm durch Koordinatenaktualisierungen und minimieren Störungen der Eingabezeile durch versteckten Cursor, Fokus auf einer einzelnen Spalte und die Nutzung von VT100-Scrollbereichen
  • Wer barrierefreie Terminal-Werkzeuge bauen will, sollte deklarative UI-Frameworks vermeiden, die das Terminal wie eine Leinwand behandeln und aggressiv neu zeichnen, und stattdessen ein Verhalten nahe an einfachen, linearen CLI-Streams sicherstellen

Das Missverständnis „Text ist also barrierefrei“

  • Die Annahme, dass Anwendungen, die im Terminal laufen, von Natur aus barrierefrei sind, passt nicht zur realen Nutzungspraxis
  • Die Erwartung, dass Screenreader rohen ASCII-Text leicht interpretieren können, weil es keine Grafik, kein komplexes DOM und keine WebGL-Canvas gibt, bricht bei modernen TUIs zusammen
  • Terminal-UI-Frameworks wie Ink (JS/React), Bubble Tea (Go) und tcell sollen die Developer Experience (DX) verbessern, können für blinde Nutzer aber ein feindlicheres Umfeld schaffen
  • In Sachen Barrierefreiheit sind moderne TUIs oft sogar schlechter als schlecht umgesetzte grafische Oberflächen

Strukturelle Unterschiede zwischen CLI und TUI

  • CLI: linearer Stream

    • CLIs arbeiten auf Basis von stdin/stdout; man gibt einen Befehl ein, das Ergebnis wird darunter angefügt und der Cursor wandert nach unten
    • Weil die Ausgabe linear ist und sich chronologisch aufbaut, passt sie gut zu kernelnahen Screenreadern wie Speakup

  • TUI: 2D-Raster

    • TUIs behandeln das Terminalfenster nicht als Textstream, sondern als 2D-Raster, in dem einzelne Zeichenfelder wie Pixel beschrieben werden
    • Damit wird der zeitliche Fluss aufgegeben und ein räumliches Layout priorisiert, was für Screenreader schwer nachzuverfolgen ist

Die Probleme, die sich bei gemini-cli zeigen

  • gemini-cli ist ein mit Node.js und dem Ink-Framework geschriebenes Werkzeug und wirkt oberflächlich wie ein simples Chat-Interface
  • Intern versucht Ink, den React-Komponentenbaum an das Terminalraster anzupassen
  • Bei der Nutzung mit Speakup (Linux) oder NVDA (Windows) scheitert die Anwendung nicht einfach nur, sondern überschüttet den Screenreader fortlaufend mit neu zu lesenden Inhalten

  • Ein Bildschirm, der sich wie eine reaktive Leinwand verhält

    • Das Framework behandelt den Bildschirm wie eine reaktive Leinwand, weshalb jede Aktualisierung ein Neuzeichnen auslöst
    • Während die KI „nachdenkt“, bewegt es den Hardware-Cursor zur Position des Timers, schreibt die neue Zeit und setzt ihn dann wieder zurück
    • Für sehende Nutzer ist das ein sofort vorübergehender Vorgang, für Screenreader-Nutzer klingt es aber wie „Responding... Time elapsed 1s... Responding... Time elapsed 2s...“ in Dauerschleife
    • Während der Cursor kurz zwischen Statusanzeige, Spinner und Gesprächsverlauf springt, versucht Speakup jeweils den Inhalt unter dem Cursor vorzulesen
    • Dadurch vermischen sich Timer-Aktualisierungen und Gesprächsfragmente, sodass es schwer wird, sich auf die eigentliche Eingabe zu konzentrieren

  • Instabilität mit NVDA und beim Einfügen

    • Wenn man unter Windows mit NVDA ein Terminal öffnet, sich per SSH auf ein Linux-System verbindet, an eine screen-Sitzung anhängt und dann Text einfügt, kann NVDA sofort abstürzen oder das System stark instabil werden
    • Jedes eingegebene Zeichen und jedes eingefügte Textstück verändert den Zustand der Anwendung, woraufhin das Framework entscheidet, dass die Oberfläche neu gerendert werden muss
    • Wenn der Gesprächsverlauf Teil dieses Zustands ist, versucht es sofort, das Layout von tausenden Textzeilen neu zu berechnen oder neu zu zeichnen
    • Je mehr Gesprächsnachrichten vorhanden sind, desto häufiger tritt dieses Problem auf
    • Selbst die Tastenkombination Insert+5, mit der dynamische Inhaltsmeldungen vermieden werden sollen, hilft hier nicht

  • Schleife aus Eingabeverzögerungen

    • Wenn Frameworks wie Ink in einer Single-Thread-Umgebung wie Node.js laufen, nimmt der Leistungsabfall mit wachsendem Verlauf stark zu
    • Beim Einfügen großer Textblöcke müssen Differenzen über tausende Zeilen berechnet werden
    • Das System ist dann damit beschäftigt zu ermitteln, wie der Bildschirm neu gezeichnet werden soll, und verarbeitet Eingaben verspätet
    • Schon nach einem einzelnen Tastendruck kann man bis zu 10 Sekunden warten, bis das Zeichen wieder angezeigt wird

Warum alte Werkzeuge funktionieren

  • Werkzeuge wie nano, vim und menuconfig werden nicht genutzt, weil sie in Sachen Barrierefreiheit immer perfekt wären
  • Entscheidend ist vielmehr, dass diese Werkzeuge den Cursor vollständig verbergen oder den Lärm aus der Cursorpositionsverfolgung reduzieren können

  • nano und vim: Cursor verbergen

    • Wenn man nano mit Optionen wie --constantshow startet, die die Cursorposition anzeigen, oder vim ohne bestimmte Einstellungen nutzt, kann die Benutzbarkeit zusammenbrechen
    • Wenn der Cursor sichtbar ist und die Verfolgung aktiv bleibt, priorisiert Speakup Cursorpositionsaktualisierungen gegenüber dem Zeichen-Echo
    • Gibt der Nutzer „a“ ein, hört er statt „a“ dann „Column 2“, bei „b“ entsprechend „Column 3“
    • Diese alten Werkzeuge lassen sich so konfigurieren, dass visuelle Cursor- oder Statusleistenaktualisierungen unterdrückt werden, sodass sich der Screenreader auf den Zeichen-Eingabestream statt auf Koordinatenaktualisierungen stützt
    • Moderne Frameworks bieten in der Regel keinen „no-cursor“- oder „headless“-Modus und setzen voraus, dass ein sichtbarer Cursor unverzichtbar ist

  • menuconfig: Fokus auf einer einzelnen Spalte

    • Das menuconfig des Linux-Kernels funktioniert, weil es strikt einen Fokus in nur einer Spalte beibehält
    • Es gibt zwar Rahmen und Überschriften, aber der aktive Bereich ist eine vertikale Liste, und der Cursor bleibt auf diese Liste fixiert
    • Er springt nicht zur Aktualisierung einer Uhr nach rechts unten und danach zur Titelaktualisierung nach links oben
    • Die räumliche Komplexität bleibt gering, sodass Screenreader nicht die Orientierung verlieren

  • Irssi: Nutzung von Scrollbereichen

    • Irssi ist nicht zufällig zugänglich, sondern ein Chat-Werkzeug, das seit mehr als 20 Jahren über eine eigene Rendering-Engine VT100-Scrollbereiche nutzt
    • Wenn eine neue Nachricht ankommt, weist es den Terminaltreiber an: „Definiere Zeile 1 bis 23 als Scrollbereich“
    • Danach sendet es den Befehl zum Hochscrollen, das Terminal verschiebt den Inhalt nach oben und zeichnet den neuen Text unten in diesem Bereich ein
    • Auf diese Weise werden Störungen der Eingabezeile minimiert
    • Statt jedes Zeichen auf dem Bildschirm manuell neu zu schreiben, stützt es sich auf Hardware-Funktionen des Terminals
    • Moderne Frameworks ignorieren solche Hardware-Funktionen oft, berechnen stattdessen Zustandsdifferenzen des Bildschirms und schreiben Zeichen neu; das ist rechenintensiver und barrierefeindlich

Die Probleme bei der Bearbeitung von gemini-cli-Issues

  • Google und die Maintainer von gemini-cli wirken zwar so, als nähmen sie Barrierefreiheit ernst, im Repository bleiben aber wichtige Regressionen in der Barrierefreiheit liegen
  • Bei Barrierefreiheitsregressionen wie Issue #3435 und Issue #11305 gibt es weder Diskussion, noch Roadmap, noch Fixes
  • Issue #1553 sollte genau solche Ausfälle der Barrierefreiheit nachverfolgen, wurde aber nicht gelöst und stattdessen automatisch von einem Bot geschlossen
  • Der Bot schließt das Issue mit einer Standardformulierung, wonach es wegen langer Inaktivität und zur Pflege des Backlogs beendet werde
  • Einen Bericht zur Barrierefreiheit zu schließen, nur weil Maintainer monatelang nichts daran getan haben, ist keine Aufräumarbeit, sondern eher das Verbergen von Belegen
  • Es sendet das Signal, dass Bugs verschwinden, wenn man sie nur lange genug ignoriert, während die Software für blinde Nutzer in der Praxis weiterhin unbenutzbar bleibt
  • Die Kennzahl „Closed Issues“ des Projekts mag dadurch besser aussehen, die Barrierefreiheitsprobleme sind damit aber nicht gelöst

Fazit für den Bau barrierefreier Terminal-Werkzeuge

  • Wer Barrierefreiheit bei Terminal-Anwendungen ernst nimmt, sollte aufhören, deklarative UI-Frameworks zu verwenden, die das Terminal wie eine Leinwand behandeln
  • „Moderne“ TUI-Stacks sind darauf optimiert, dass Entwickler Code bequem wie in React schreiben können, und opfern dafür die Fähigkeit der Maschine, Text effizient zu rendern
  • Wenn eine Anwendung nicht sicherstellt, dass Nutzer den Cursor verbergen können, oder auf aggressives Neuzeichnen angewiesen ist, um Spinner und Timer anzuzeigen, wird sie zu einem unzugänglichen Werkzeug
  • Für blinde Nutzer ist ein einfacher, linearer CLI-Stream weitaus besser als eine „smarte“ TUI, die verzögert reagiert, ständig neue Inhalte vorliest und den Cursor über den ganzen Bildschirm verstreut

Verwandte Beiträge

2 Kommentare

 
GN⁺ 2026-05-05
Hacker-News-Kommentare

  • Als ich mir die gerenderte UI von Claude Code ansah, wurde mir zum ersten Mal klar, dass eine TUI eher einem UI-System im Stil von DOS oder Borland ähnelt als einer Kommandozeilenoberfläche
    Beim Blick auf die Einstellung CLAUDE_CODE_NO_FLICKER=1 wurde sichtbar, dass diese TUI mehrere Ebenen mithilfe von Terminal-Steuercodes übereinanderlegt
    Ich habe auch die Terminal-Implementierung von Ink für React gelesen: https://github.com/vadimdemedes/ink
    Spannend fand ich, wie das Ergebnis nicht wie pixelbasierte Grafik wirkt, sondern eher wie früher bei WordPerfect oder WordStar, und für sehbehinderte Nutzer ist die Nutzbarkeit ähnlich. Allerdings erinnere ich mich, dass 80x25-Braille-Pads für DOS-Tools besser funktionierten als spätere Screenreader

  • Je mehr man sich die heute populären TUIs ansieht, desto schlechter wirken sie. Es fühlt sich an, als hätte man alle schlechtesten Praktiken aus den Anfängen des Programmierens zusammengeworfen und in eine schwerfällige, träge Gallerte gepackt, die unter ihrem eigenen Gewicht zusammenbrechen könnte

    • Solche Dinge sind keine Terminal-UIs, sondern eher Versuche, grafische UIs wie Windows innerhalb des Terminals nachzuahmen
      Das ist dieselbe Kategorie wie das, was man früher unter DOS baute, als Windows noch nicht weit verbreitet oder nicht gut genug war, daher überrascht es nicht, wenn es katastrophal ist oder ohne Verständnis für die Fähigkeiten des laufenden Terminals entwickelt wurde

  • Ich fand es immer etwas erstaunlich, warum TUIs so beliebt sind. Die Stärke des Terminals liegt im Streaming-Modell, und kombinierbare Utilities sind ein Vorteil, der bei grafischen UIs viel seltener ist
    Ich verstehe den Punkt, dass die Beschränkungen des Terminals das TUI-Design dazu zwingen können, sich stärker auf den Zweck des Werkzeugs als auf Schmuck zu konzentrieren, aber persönlich finde ich das nicht besonders überzeugend

    • Der neue TUI-Trend mit Claude Code, OpenCode und Crush ist weniger das Ergebnis von Kombinierbarkeit oder Text-Streaming als vielmehr das Zusammentreffen einiger günstiger Rückenwinde
      Es gibt bereits eine recht große Gruppe von Engineers, die mit Vim/Neovim/tmux/zellij leben und im Terminal zu Hause sind, und da viele Entwicklungsaufgaben ohnehin über Skripte im Terminal laufen, besteht Nachfrage, möglichst viele Arbeitsabläufe dorthin zu verlagern
      Auf wichtigen Plattformen wie macOS und Linux ist Distribution über Paketmanager praktisch gelöst, während die Distribution nativer Cross-Platform-Apps weiterhin fragmentiert ist
      Dank dieser Nachfrage und der Distributionsvorteile sind TUI-Komponenten wie Ink für React oder Bubble Tea für Go deutlich besser geworden, und Electron hat ein Image als langsame, aufgeblähte App-Plattform, das Entwickler eher abschreckt
      Am Ende wechseln erfolgreiche Produkte oft auch in andere Formen, etwa wenn Claude Code zu Claude Cowork führt oder OpenCode um OpenCode Web erweitert wird, aber die Product-Market-Fit von Developer-Tools lässt sich per TUI schneller testen, und auch nach einer anderen UI bleiben viele Nutzer dem Terminal treu
    • Für grundlegende Dinge wie vim passt das gut, aber für fast alles andere sind gewöhnliche Kommandozeilen-Tools oder Weboberflächen meiner Meinung nach besser. Ein großer Teil der Beliebtheit scheint daher zu kommen, dass man sich wie ein Hacker mit zehn Terminalfenstern fühlen will, in Wirklichkeit aber eine Erfahrung ähnlich einer grafischen UI möchte
    • Heute ist das völlig aus der Mode, aber man könnte an TN3270 denken. Das war eher formularbasiert als streamingorientiert und stark auf die Tastatur ausgerichtet
      Das hätte man auch leicht in einer grafischen UI nachbilden können, aber Tastaturkürzel wurden später zur Nebensache
      Auch heute trifft man noch Nutzer, die solche alten Arbeitsabläufe vermissen, und sie beschreiben das als „alte Textoberflächen“, also als TUI. Hört man genauer hin, wollen sie in Wahrheit vor allem einen blitzschnellen, tastaturzentrierten Ablauf. Bei der Dateneingabe zählt nicht Animation, sondern Geschwindigkeit
      Anfänger mögen Eye-Candy, Fortgeschrittene achten irgendwann nicht mehr darauf
    • TUIs funktionieren über ssh ohne Zusatzaufwand
      Durch die Beschränkungen des Terminals sehen Apps meist ähnlich aus und verhalten sich ähnlich. In der Außenwelt werden UX-Standards im Alltag ignoriert, obwohl sie möglich wären, aber TUI ist gewissermaßen der Punkt mit den wenigsten Überraschungen
    • Die Stärke von TUIs liegt in einigen Punkten: geringer Ressourcenverbrauch, weniger Mausabhängigkeit, die Möglichkeit, vi-Muscle-Memory in mehr Aufgaben über Keybindings mitzunehmen, und tiefere Organisation
      Mit TUI-Tools konnte ich mir bei Bedarf eine eigene unsichtbare IDE bauen. Dank guake und yakuake lässt sie sich verbergen, und dank zellij ist sie nach Projekten und Tabs organisiert. Für gemischte Tätigkeiten wie meine heutige Arbeit passt das perfekt
      Stilvoll würde das aber wohl niemand nennen

  • Aus Sicht von Projekt-Maintainern kann man das anders sehen. Die Menschen, die ein Projekt besitzen und pflegen, können in den Issues festlegen, was Open und Closed bedeuten, und Nutzer müssen dem nicht unbedingt zustimmen
    Man kann Open zum Beispiel im Sinn von „noch nicht eingeordnet oder aktiv in Bearbeitung“ verwenden und Closed im Sinn von „wir haben dieses Ticket gesehen, aber im Moment wird niemand im Team daran arbeiten“
    Das heißt, Closed muss nicht zwingend „abgelehnt und endgültig entschieden“ bedeuten, sondern kann „aktuell kein Arbeitsgegenstand“ heißen. Auch wenn das nicht für alle intuitiv ist, lässt es sich rechtfertigen, wenn es dem Projektteam hilft, die Arbeitsmenge zu ordnen

  • Ich stimme dieser Einschätzung zu. Noch weiter gedacht wäre es viel einfacher gewesen, wenn Entwickler das bereits ziemlich zufriedenstellende CUA, also den IBM-Standard Common User Access, eingehalten und weiter formalisiert hätten: https://en.wikipedia.org/wiki/IBM_Common_User_Access
    Wenn Entwickler mit verschiedenen UI-Konfigurationen experimentieren wollen, kann man sie das tun lassen, solange im Hintergrund ein CUA erhalten bleibt, das sowohl Maschinen als auch Menschen aufrufen können. Leider war Ergonomie nie eine Stärke von Entwicklern

  • Das ist ein gut dokumentiertes Problem zwischen TUI und Windows
    Als in den 90ern die meisten SAP-Systeme von AS/400-Terminals auf Windows NT umgestellt wurden, berichteten viele von stark sinkender Produktivität
    Ich habe nicht bei SAP gearbeitet, aber meine Mutter schon, und der Wechsel ging von vollständig tabellarischen, auf Funktionstasten basierenden Abläufen hin zu Mausgreifen, Bewegen und viel Klicken. In vielen Funktionen verschwanden Tab-Navigation und F-Tasten
    Sie zeigte mir, wie man mit ESC ESC F4 F3 TAB TAB mit enormer Geschwindigkeit durchs ganze System kam, und das war nicht einmal das eigentliche System, sondern ein Terminal
    Kurz gesagt: Windows-basierte Apps sind besser für Auffindbarkeit und neue Nutzer, terminalbasierte Apps sind schneller und besser für Navigation aus dem Gedächtnis und für Power-User

    • Das ist ein Problem einer bestimmten grafischen UI, nicht des Konzepts grafische UI an sich. Gute grafische UI-Frameworks sollten Vorhersagbarkeit und schnelle, tastaturzentrierte Wege bereits mitbringen, sodass nicht jede App diese Entscheidungen erneut treffen muss
      Erfolgreiche Apps für Experten oder Power-User sind tatsächlich immer mit Blick auf solche schnellen Wege gebaut. Selbst das oft grundlos gehasste Ribbon von Microsoft ist ein Beispiel dafür. Es ist per Tastatur bedienbar, anpassbar und zugleich gut auffindbar
    • Es gibt überhaupt keinen Grund, diese Funktionen in der grafischen UI-Version nicht zu erhalten. Das ist ein typischer Fehlschlag im UX-Design, wenn Menschen, die das System nie benutzt haben und nicht benutzen, den Auftrag bekommen, die nächste Version zu entwerfen, hat aber wenig mit grafischer UI versus TUI zu tun
      Grafische UIs lockern nur die Beschränkungen, wodurch es leichter wird, die User Experience zu ruinieren

  • TUI sollte ursprünglich eine einfache Option sein, jetzt ist sie zu einer Web-App im Terminal-Kostüm geworden

    • Aber ohne die Accessibility-Optionen des Webs, ohne gute Textbearbeitung, mit nur sehr grundlegenden Anpassungsmöglichkeiten, und statt in einer Sandbox zu laufen, verlangt sie eine vertrauenswürdige Computing-Umgebung
      Von einer Web-App ist das weit entfernt und auf den meisten Achsen deutlich schlechter

  • Zum Mythos „weil es Text ist, ist es zugänglich“: Nein, ist es nicht. Niemand glaubt das wirklich
    Entwickler sagen so etwas über Textdokumente und unter Vorbehalt über einzelne Terminal-Apps wie grep, cut oder ls. Dasselbe über TUIs zu sagen, ist schwer vorstellbar

  • Das Problem ist nicht die Nutzung deklarativer UI-Frameworks an sich, sondern dass die von diesen Frameworks erzeugten Rendering-Engines Barrierefreiheit nicht berücksichtigen

    • Aus dem Artikel wird klar, dass auch deklarative UI funktionieren kann, wenn man sie korrekt implementiert und Optionen zum Abschalten von Lärm anbietet
      Aber offenbar hat sich niemand darum gekümmert, sondern ist bei „Es ist ein Terminal, also machen wir es hübsch“ stehen geblieben
    • Gibt es im Terminal überhaupt von Haus aus Accessibility-Support?

  • TUI wird noch einmal neu entdeckt werden, diesmal ohne fensterartige Elemente. Nur wenige merken es bisher, aber es könnte am Ende sprite-basiert sein wie eine C64-Konsole. Vielleicht macht das irgendwo schon jemand
    Fenster und Panels kann man inzwischen ruhig verabschieden. Ruhige Textumgebungen sind auch 2026 noch Teil der kulturellen DNA der Menschheit, und in diesem Medium ist noch erstaunlich wenig erforscht
    Die kognitive Aggressivität des modernen Webs kommt mir tatsächlich eher wie ein größerer Albtraum vor, in einem sehr halluzinatorischen Sinn aus wahllos vermischten Bildern, Videos und Werbung ohne Kontext
 
GN⁺ 2026-05-04
Lobste.rs-Kommentare

  • Dieser Artikel riecht wie viele andere Blogposts stark nach KI-unterstütztem Schreiben
    LLMs lieben solche Titel: „The Architectural Flaw“, „The Lag Loop“, „Why The ‘Old Guard’ Works“, „The Lost Art of Scrolling Regions“, „The ‘Stale Bot’ excuse: A Case Study in Neglect“

    • Schon der Titel liest sich wie KI-Massenware. Das Thema selbst ist zwar neu genug, dass eine Spam-Meldung vielleicht überzogen war, aber 1) ich ertrage diesen überall wiederholten Stil nicht mehr und 2) dadurch zweifle ich sogar an der Genauigkeit des Inhalts
      Das hätte ein großartiger Blogpost sein können, aber wenn es wirkt, als hätte der Autor nur eine Gliederung in ChatGPT geworfen und es dann dabei belassen, ist das für Leser und Autor gleichermaßen ein Verlust
    • Eines der Dinge, die ich an LLM-Schreibstil am meisten hasse, ist dieses „The <überhaupt kein etabliertes Konzept>“, wodurch es so wirkt, als sei es ein offizieller Fachbegriff
      Genauso, wenn ein sehr spezielles einmaliges Problem als „klassisches“ Problem bezeichnet wird

  • Wirklich deprimierend. Kurz gesagt: Es gibt zugängliche TUIs wie Irssi, aber moderne TUI-Frameworks ignorieren solche Vorbilder und verlassen sich stattdessen auf Grid-Diffs und Cursorbewegungen
    Screenreader lesen den Inhalt an der Cursorposition vor, wenn sich der Cursor bewegt, wodurch das Ergebnis durcheinandergerät oder es zu massivem Vorlese-Spam kommt

  • Ich bin nicht sicher, ob die technische Erklärung hier vollständig korrekt ist
    Insbesondere unterstützte Ink lange Zeit überhaupt kein inkrementelles Rendering, und die meisten mit Ink gebauten Apps aktivieren es noch immer nicht. Dieses inkrementelle Rendering ist zudem zeilenbasiert und bewegt den Cursor nicht tatsächlich zur Position eines Timers
    Gemini CLI benötigt zum Aktivieren des inkrementellen Renderings die Nutzung eines Alternate Buffers, was deaktiviert wird, wenn der eingebaute screenreaderfreundliche Modus aktiv ist, wie hier zu sehen ist. Die Dokumentation zur entsprechenden Option ist hier
    Außerdem sind Python rich/textual trotz einer langsameren und meist Single-Thread-orientierten Sprache oft deutlich schneller als Ink. Das Berechnen von Diffs über Tausende Zeilen hinweg ist nicht zwangsläufig so langsam und dauert auch keine 10 Sekunden
    Ich zweifle nicht daran, dass die User Experience frustrierend und kaputt ist, aber die konkret angegebene Ursache wirkt womöglich wie eine LLM-Halluzination oder basiert auf unvollständigen Informationen. Das inkrementelle Rendering von Ink funktioniert selbst dann nicht so, wie es beschrieben wird
    In Wirklichkeit ist es wahrscheinlich eher so, dass vollständige Screen-Redraws Screenreader verwirren und zeilenbasierte Redraws dazu führen, dass beliebige zusammenhanglose Textfragmente erneut vorgelesen werden, auch wenn sie mit der Änderung nichts zu tun haben

  • Es ist nicht fair, nur den TUIs die Schuld zu geben
    Das eigentliche Problem ist, dass die Barrierefreiheitsunterstützung fast im gesamten Stack miserabel ist
    Erstens verwenden die meisten GPU-gerenderten Terminalemulatoren überhaupt keine vom System bereitgestellten Accessibility-APIs. Wenn Text per GPU gerendert wird, können Accessibility-Tools ihn nicht „lesen“ und sehen nur ein Bild. Dazu gehören Kitty, Alacritty und WezTerm. Mein Terminal Ghostty ist unter macOS über Accessibility-APIs lesbar, ebenso iTerm2 und Terminal.app
    Zweitens gibt es keinerlei Terminal-Sequenzen oder standardisierte Verfahren, mit denen TUIs Barrierefreiheitsinformationen an den Terminalemulator übergeben könnten. Es bräuchte etwas wie ARIA-artige Annotationen für Terminalzellen, Laufbereiche und Regionen, aber solche Versuche gibt es nicht. Selbst wenn ein TUI den Cursor sauber handhabt, wird es in vielen Anwendungsfällen Probleme geben
    Als Beispiel habe ich in Ghostty an der Integration von OSC133 mit Accessibility-APIs gearbeitet, um jeden Shell-Prompt, jede Eingabe und jeden Befehl nicht nur als einfache Textbox, sondern als strukturell sinnvolle Elemente sichtbar zu machen. Das zeigt, dass Terminal-Spezifikation, TUI und Terminalemulator zusammenpassen müssen
    Der gesamte Stack ist verrottet, und es gibt kaum Leute, die ihn ernsthaft reparieren wollen. Auch ich kann mit meiner begrenzten Zeit nur mein Bestes tun, aber das ist ein riesiges Thema, das sogar Ökosystem-Politik erfordert, und kaum zu bewältigen
    Als Bonus ist die zugleich coole und schreckliche Realität, dass KI hier tatsächlich bei Verbesserungen der Barrierefreiheit hilft. Viele KI-Tools nutzen oder missbrauchen Accessibility-APIs, um Fensterlisten zu lesen und Eingaben auszuführen. Deshalb beginnen mehr Apps, Accessibility-Integration wegen KI-Anwendungsfällen deutlich ernster zu nehmen

    • Das Terminal wird wirklich zu einem kleinen Browser

  • Dass Claude Code und gemini-cli nicht auf readline basieren, macht mich jeden Tag wütend
    Sie haben ein paar ähnliche Tastenbelegungen eingebaut, aber der lange Schwanz vertrauter readline-Shortcuts fehlt
    Anthropic könnte ruhig zugeben, dass die Entscheidung „wir müssen es wie Webentwicklung machen“ ein Fehler war, und wieder bei readline anfangen
    Die Vorstellung, dass die vertraute Entwicklererfahrung der Leute, die solche Tools bauen, wichtiger sei als die vertraute Benutzererfahrung der Leute, die sie benutzen, ist falsch

    • Soweit ich das verstehe, liegt ein großer Teil des Problems darin, dass Ink im Grunde nur mit einem Rendering-Backend zufrieden ist und keine Input-Widgets bereitstellt
      Es gibt tatsächlich kaum bekannte Drittanbieter-Lösungen, die gut gepflegt werden. Wenn man eine flexible Eingabebox braucht, muss man sie von Grund auf selbst bauen
      Im Gegensatz zum hervorragenden Input-Widget von Textual oder einer anderen Bibliothek im JS-Ökosystem, OpenTUI
    • Ist readline nicht unter der GNU-Lizenz? Hat endlich jemand eine Version gebaut, die nicht GPL ist?
      Ich mag LLMs nicht, deshalb ist eine schlechte UI für mich persönlich eher ein Vorteil, aber es könnte Gründe geben, readline nicht zu verwenden

  • Ich glaube, Terminal-Editoren wie kakoune und helix werden es schwer haben, Barrierefreiheitsanforderungen zu erfüllen, sofern sie nicht den Trick des „Cursor-Versteckens“ nutzen
    Selbst dann sind sie wahrscheinlich nicht so zugänglich wie VS Code
    Welche zugänglichen plattformübergreifenden IDE-lites oder IDEs außer VS Code gibt es eigentlich? Die zunehmend feindselige Haltung von VS Code gefällt mir nicht. Vielleicht die IDEs von JetBrains

    • Es gibt emacspeak, das Emacs eine sehr zugängliche Oberfläche gibt
      Der Nachteil ist, dass Emacs selbst zwar plattformübergreifend ist, emacspeak wegen TTS aber möglicherweise schwach von Linux abhängt. Vielleicht auch nicht. Unter Windows habe ich es nie ausprobiert
    • Die erste Frage ist: Barrierefreiheit für wen? Wenn es um Gehörlose geht, braucht man Texte in der jeweiligen Landessprache und die lokale Gebärdensprache. In den USA ist das üblicherweise ASL
      Für blinde Menschen braucht man emacspeak oder die Accessibility-Tools der jeweiligen Plattform für Sehbehinderte
      Barrierefreiheit ist ein Spektrum, keine Checkbox

  • Links hat einen eigenen Braille-Terminalmodus, der gefälschte GUI-Elemente in einfachere Vollbildmenüs umwandelt und die Navigation per Pfeiltasten ebenfalls auf Zeilenbasis umstellt
    Ein weiteres interessantes Beispiel ist edbrowse. Das ist ein Textmodus-Browser des blinden Entwicklers Karl Dahlke, der im Gegensatz zu populäreren Textmodus-Webbrowsern keine TUI verwendet, sondern eine Befehlszeilenschnittstelle im Stil von ed

  • Wenn es sich um das Ink-Framework handelt, ist das wahrscheinlich der Grund, warum die CLI 100 % CPU verbraucht, für immer hängen bleibt und lange Chatverläufe immer wieder neu rendert. Schade