Le mensonge du mode texte : pourquoi les TUI modernes sont un cauchemar pour l’accessibilité

 (xogium.me)
6 points par GN⁺ 2026-05-04 | 2 commentaires | Partager sur WhatsApp
  • L’hypothèse selon laquelle les applications de terminal sont intrinsèquement accessibles parce qu’elles sont basées sur du texte ne tient plus avec les TUI modernes ; des frameworks comme Ink, Bubble Tea et tcell peuvent créer un environnement plus hostile pour les utilisateurs de lecteurs d’écran
  • Un CLI empile sa sortie comme un flux linéaire via stdin/stdout, dans l’ordre chronologique, alors qu’une TUI traite le terminal comme une grille 2D de cellules de caractères, ce qui rend le suivi du flux plus difficile pour les lecteurs d’écran
  • gemini-cli peut, via Ink, redessiner l’arbre de composants React pour l’adapter à la grille du terminal, en déplaçant le curseur entre spinner, minuterie et historique de conversation, ce qui peut provoquer des lectures répétées, des plantages et des retards de saisie avec Speakup et NVDA
  • Des outils plus anciens comme nano, vim, menuconfig et Irssi réduisent le bruit des mises à jour de coordonnées et limitent les interférences avec la ligne de saisie grâce au masquage du curseur, à un focus en colonne unique et à l’usage des zones de défilement VT100
  • Pour créer des outils de terminal accessibles, il faut éviter les frameworks d’interface déclaratifs qui traitent le terminal comme un canevas et les redessinages agressifs, et garantir un comportement plus proche d’un flux CLI simple et linéaire

L’idée fausse selon laquelle « c’est accessible parce que c’est du texte »

  • L’hypothèse selon laquelle une application exécutée dans un terminal est intrinsèquement accessible ne correspond pas aux conditions réelles d’utilisation
  • L’idée qu’un lecteur d’écran puisse facilement interpréter du texte ASCII brut parce qu’il n’y a ni graphismes, ni DOM complexe, ni canevas WebGL s’effondre face aux TUI modernes
  • Des frameworks d’interface terminal comme Ink (JS/React), Bubble Tea (Go) et tcell cherchent à améliorer l’expérience développeur (DX), mais peuvent créer un environnement plus hostile pour les utilisateurs aveugles ou malvoyants
  • Dans bien des cas, les TUI modernes sont pires en matière d’accessibilité qu’une interface graphique mal implémentée

Différence structurelle entre CLI et TUI

  • CLI : un flux linéaire

    • Un CLI fonctionne sur la base de stdin/stdout ; on saisit une commande, le résultat s’ajoute en dessous, puis le curseur descend
    • Comme la sortie est linéaire et s’accumule dans l’ordre chronologique, cela convient bien à des lecteurs d’écran au niveau noyau comme Speakup

  • TUI : une grille 2D

    • Une TUI traite la fenêtre du terminal non comme un flux de texte, mais comme une grille 2D où chaque cellule de caractère est utilisée comme un pixel
    • En abandonnant le flux temporel au profit d’une mise en page spatiale, on obtient une structure difficile à suivre pour les lecteurs d’écran

Les problèmes mis en évidence par gemini-cli

  • gemini-cli est un outil écrit avec Node.js et le framework Ink ; en apparence, il ressemble à une simple interface de chat
  • En interne, Ink essaie d’ajuster l’arbre de composants React à la grille du terminal
  • Lorsqu’on l’utilise avec Speakup (Linux) ou NVDA (Windows), l’application ne se contente pas d’échouer simplement : elle inonde continuellement le lecteur d’écran de texte à lire

  • Un écran qui se comporte comme un canevas réactif

    • Comme le framework traite l’écran comme un canevas réactif, chaque mise à jour déclenche un redessinage
    • Quand l’IA est en train de « réfléchir », il déplace le curseur matériel jusqu’à la position de la minuterie pour mettre à jour un compteur ou un spinner, écrit la nouvelle valeur, puis revient à la position d’origine
    • Pour un utilisateur voyant, cette opération passe instantanément ; pour un utilisateur de lecteur d’écran, cela se transforme en répétitions du type « Responding... Time elapsed 1s... Responding... Time elapsed 2s... »
    • Comme le curseur se déplace fugitivement entre l’indicateur d’état, le spinner et l’historique de conversation, Speakup tente de lire ce qui se trouve sous le curseur à chaque instant
    • Résultat : les mises à jour de la minuterie et des fragments de conversation se mélangent, ce qui rend difficile la concentration sur ce qu’on est réellement en train de saisir

  • Instabilité avec NVDA et lors du collage

    • Sous Windows, si l’on ouvre un terminal avec NVDA, qu’on se connecte à une machine Linux en SSH, puis qu’on rejoint une session screen pour y coller du texte, NVDA peut planter immédiatement ou le système devenir fortement instable
    • À chaque caractère saisi ou texte collé, l’état de l’application change, et le framework estime qu’il faut rerendre l’interface
    • Si l’historique de conversation fait partie de l’état, il peut tenter de redessiner ou de recalculer instantanément la mise en page de milliers de lignes de texte
    • Plus il y a de messages dans la conversation, plus le problème survient souvent
    • Même la combinaison Insert+5, utilisée pour éviter les notifications de contenu dynamique, ne permet pas d’échapper au problème

  • La boucle de latence à la saisie

    • Quand un framework comme Ink tourne dans un environnement mono-thread comme Node.js, les dégradations de performance augmentent à mesure que l’historique grossit
    • Si l’on colle un gros bloc de texte, il faut calculer les différences sur des milliers de lignes
    • Le système passe son temps à calculer comment redessiner l’écran, ce qui retarde le traitement de la saisie
    • Il peut alors falloir attendre jusqu’à 10 secondes avant qu’un caractère réapparaisse après avoir appuyé sur une touche

Pourquoi les anciens outils fonctionnent

  • Si des outils comme nano, vim et menuconfig restent utilisables, ce n’est pas parce qu’ils sont toujours parfaits en matière d’accessibilité
  • L’essentiel, c’est qu’ils peuvent masquer complètement le curseur ou réduire le bruit produit par le suivi de sa position

  • nano et vim : masquer le curseur

    • L’utilisation de nano avec une option affichant la position du curseur, comme --constantshow, ou de vim sans réglages particuliers, peut dégrader fortement l’usage
    • Lorsque le curseur est visible et que son suivi est actif, Speakup donne la priorité aux mises à jour de position du curseur plutôt qu’à l’écho des caractères
    • Si l’utilisateur saisit « a », il entend « Column 2 » au lieu de « a » ; s’il saisit « b », il entend ensuite « Column 3 »
    • Ces anciens outils peuvent être configurés pour supprimer les mises à jour du curseur visuel ou de la barre d’état, ce qui permet au lecteur d’écran de s’appuyer sur le flux de saisie des caractères plutôt que sur les mises à jour de coordonnées
    • Les frameworks modernes ne proposent généralement ni mode « no-cursor » ni mode « headless » et partent du principe qu’un curseur visuel est indispensable

  • menuconfig : un focus en colonne unique

    • Le menuconfig du noyau Linux fonctionne parce qu’il maintient strictement un focus en colonne unique
    • Même avec des bordures et des titres, la zone active reste une liste verticale, et le curseur y reste fixé
    • Le curseur ne part pas en bas à droite pour mettre à jour une horloge avant de revenir en haut à gauche pour rafraîchir un titre
    • La complexité spatiale reste faible, ce qui évite aux lecteurs d’écran de se perdre

  • Irssi : l’usage des zones de défilement

    • Irssi n’est pas accessible par hasard : c’est un outil de chat qui exploite depuis plus de 20 ans les zones de défilement VT100 via son propre moteur de rendu
    • Lorsqu’un nouveau message arrive, il demande au pilote du terminal de « définir les lignes 1 à 23 comme zone de défilement »
    • Il envoie ensuite une commande de défilement vers le haut ; le terminal déplace alors le contenu, puis écrit le nouveau texte en bas de cette zone
    • Cette approche minimise les interférences avec la ligne de saisie
    • Au lieu de réécrire manuellement tous les caractères à l’écran, elle s’appuie sur les capacités matérielles du terminal
    • Les frameworks modernes ignorent ces capacités matérielles et choisissent de recalculer les différences d’état de l’écran puis de réécrire les caractères, une méthode plus coûteuse en calcul et hostile à l’accessibilité

Le problème du traitement des issues dans gemini-cli

  • Google et les mainteneurs de gemini-cli donnent l’impression de se soucier de l’accessibilité, mais dans le dépôt, des régressions importantes en la matière restent à l’abandon
  • Des régressions d’accessibilité comme l’Issue #3435 et l’Issue #11305 ne font l’objet ni de discussions, ni d’une feuille de route, ni de correctifs
  • L’Issue #1553 avait été ouverte pour suivre ce type d’échec d’accessibilité, mais elle n’a pas été résolue et a été fermée automatiquement par un bot
  • Le bot a clôturé l’issue avec une formule générique expliquant qu’il n’y avait pas eu d’activité depuis longtemps et qu’il fallait gérer le backlog
  • Fermer des signalements d’accessibilité au motif que les mainteneurs n’y ont pas touché pendant des mois n’est pas du tri : c’est dissimuler les preuves
  • Cela envoie le signal que, si l’on ignore suffisamment longtemps un bug, il finit par ne plus exister, alors que le logiciel reste en pratique inutilisable pour les utilisateurs aveugles ou malvoyants
  • Les indicateurs de « Closed Issues » du projet peuvent s’améliorer, mais les problèmes d’accessibilité, eux, ne sont pas résolus

Conclusion : comment créer des outils de terminal accessibles

  • Si l’accessibilité compte dans une application pour terminal, il faut cesser d’utiliser des frameworks d’interface déclaratifs qui traitent le terminal comme un canevas
  • Les piles TUI dites « modernes » sont optimisées pour permettre aux développeurs d’écrire du code comme avec React, au prix de la capacité de la machine à rendre efficacement du texte
  • Si une application ne permet pas à l’utilisateur de masquer le curseur, ou si elle dépend de redessinages agressifs pour afficher des spinners et des minuteries, alors elle devient un outil inaccessible
  • Pour les utilisateurs aveugles ou malvoyants, un flux CLI simple et linéaire est bien préférable à une TUI « intelligente » qui introduit de la latence, déverse en continu du texte à lire et disperse le curseur sur tout l’écran

À lire aussi

2 commentaires

 
GN⁺ 2026-05-05
Réactions sur Hacker News

  • En voyant l’interface de rendu de Claude Code, j’ai réalisé pour la première fois qu’un TUI ressemblait moins à une interface en ligne de commande qu’à un système d’interface à la DOS ou à la Borland
    En examinant le réglage CLAUDE_CODE_NO_FLICKER=1, j’ai vu que ce TUI était structuré pour superposer plusieurs couches d’affichage à l’aide de codes de contrôle du terminal
    J’ai aussi lu l’implémentation terminal d’Ink pour React : https://github.com/vadimdemedes/ink
    J’ai trouvé intéressant le processus qui fait que cela finit par ressembler à WordPerfect ou WordStar plutôt qu’à du graphisme basé sur des pixels, et du point de vue d’un utilisateur malvoyant, l’utilisabilité est comparable. Cela dit, je me souviens que les plages braille 80x25 pour les outils DOS fonctionnaient mieux que les lecteurs d’écran apparus ensuite

  • Plus j’examine les TUI à la mode aujourd’hui, plus ça me semble mauvais. On a l’impression qu’ils rassemblent toutes les pires pratiques accumulées depuis les débuts de la programmation, enveloppées dans une masse gélatineuse difficile à manipuler, lourde et lente, prête à s’effondrer sous son propre poids

    • Ce ne sont pas vraiment des interfaces terminal, mais plutôt des tentatives d’imiter une interface graphique façon Windows à l’intérieur d’un terminal
      C’est la même catégorie de choses qu’on fabriquait sous DOS à l’époque où Windows n’était pas courant ou pas assez bon ; il n’est donc pas étonnant que ce soit désastreux, ou conçu sans comprendre les capacités du terminal dans lequel ça s’exécute

  • J’ai toujours trouvé un peu étonnant que les TUI soient si populaires. La force du terminal tient à son modèle de streaming, et les utilitaires composables sont un avantage bien plus rare dans les interfaces graphiques
    Je comprends que les contraintes du terminal puissent pousser la conception d’un TUI à se concentrer davantage sur l’objectif de l’outil que sur l’apparat, mais personnellement je ne trouve pas cela si convaincant

    • Les nouveaux TUI dans la lignée de Claude Code, OpenCode ou Crush ne reposent pas vraiment sur la composabilité ni sur le streaming texte ; ils sont plutôt le résultat de plusieurs vents favorables
      Il existe déjà un groupe assez important d’ingénieurs qui vivent dans le terminal avec Vim/Neovim/tmux/zellij, et comme beaucoup de tâches de développement consistent à exécuter des scripts dans le terminal, il y a une demande pour y déplacer le plus de travail possible
      Sur les principales plateformes comme macOS et Linux, la distribution via les gestionnaires de paquets est pratiquement résolue, alors que la distribution d’applications natives cross-platform reste fragmentée
      Grâce à cette demande et à ces avantages de distribution, les composants TUI comme Ink pour React ou Bubble Tea pour Go se sont beaucoup améliorés, tandis qu’Electron reste associé à l’image d’apps lentes et lourdes, ce qui rebute les développeurs
      Au final, les produits qui réussissent finissent parfois par évoluer vers d’autres formes — comme Claude Code avec Claude Cowork, ou OpenCode avec OpenCode Web — mais il est plus facile de tester rapidement l’adéquation produit-marché d’un outil développeur avec un TUI, et même après la sortie d’une autre interface, beaucoup d’utilisateurs resteront dans le terminal
    • Cela convient bien à des choses fondamentales comme vim, mais pour presque tout le reste, je pense qu’un outil en ligne de commande classique ou une interface web est préférable. Une bonne partie de la popularité vient sans doute du fait de vouloir se sentir comme un hacker avec 10 fenêtres terminal ouvertes, tout en désirant en réalité une expérience proche d’une interface graphique
    • Aujourd’hui c’est totalement passé de mode, mais on peut penser à TN3270. C’était orienté formulaires plutôt que streaming, et centré sur le clavier
      Cela aurait aussi pu être facilement imité en interface graphique, mais les raccourcis clavier sont devenus une réflexion tardive
      On rencontre encore des utilisateurs nostalgiques de ces anciens flux de travail, qui décrivent cela comme une « ancienne interface texte », c’est-à-dire un TUI. Quand on les écoute de près, ce qu’ils veulent vraiment, c’est un flux ultra-rapide, centré sur les raccourcis. Pour la saisie de données, ce qui compte, ce n’est pas l’animation mais la vitesse
      Les débutants aiment les effets visuels, mais les utilisateurs expérimentés n’y prêtent plus attention
    • Un TUI fonctionne au-dessus de ssh sans travail supplémentaire
      Les contraintes imposées par le terminal font que les applications se ressemblent globalement et se comportent de façon similaire. Dans le monde extérieur, les standards d’expérience utilisateur sont souvent ignorés simplement parce qu’ils sont possibles ; le TUI est, pour ainsi dire, un optimum avec un minimum de surprises
    • La force des TUI se situe à plusieurs niveaux : faible consommation de ressources, moindre dépendance à la souris, possibilité d’appliquer des raccourcis conformes à la mémoire musculaire vi à davantage de tâches, et organisation plus profonde
      Grâce aux outils TUI, j’ai pu me construire un IDE personnel invisible quand je n’en ai pas besoin. Avec guake et yakuake, je peux le masquer, et avec zellij, tout est organisé par projets et par onglets. Pour un travail mêlant plusieurs rôles comme aujourd’hui, c’est parfaitement adapté
      Cela dit, je ne pense pas que qui que ce soit qualifierait ça d’élégant

  • Du point de vue d’un mainteneur de projet, on peut voir les choses autrement. Les personnes qui possèdent et maintiennent un projet peuvent décider de ce que signifient Open et Closed dans les tickets, et les utilisateurs ne sont pas obligés d’être d’accord
    Par exemple, Open peut vouloir dire « pas encore trié ou activement en cours », et Closed « ce ticket a été vu, mais personne dans l’équipe ne va travailler dessus pour le moment »
    Autrement dit, Closed n’a pas forcément besoin de signifier « rejeté et décision finale » ; cela peut simplement vouloir dire « pas dans le périmètre actuel ». Ce n’est peut-être pas intuitif pour tout le monde, mais si cela aide les membres du projet à gérer leur charge de travail, cela peut se justifier

  • Je suis d’accord avec cette évaluation. Plus encore, cela aurait été bien plus simple si les développeurs avaient respecté et davantage normalisé le CUA, c’est-à-dire le standard d’interface Common User Access d’IBM, qui était déjà suffisamment satisfaisant : https://en.wikipedia.org/wiki/IBM_Common_User_Access
    Si les développeurs veulent expérimenter différentes compositions d’interface, qu’on les laisse faire, mais qu’ils conservent derrière un CUA pouvant être invoqué aussi bien par les machines que par les humains. Malheureusement, l’ergonomie n’a jamais été le point fort des développeurs

  • C’est un problème bien documenté entre les TUI et Windows
    Dans les années 1990, quand la plupart des systèmes SAP sont passés des terminaux AS/400 à Windows NT, beaucoup ont rapporté une forte baisse de productivité
    Je n’ai jamais travaillé chez SAP, mais ma mère oui, et on est passé d’un flux de travail entièrement tabulaire et basé sur les touches de fonction à quelque chose où il fallait attraper la souris, la déplacer et beaucoup cliquer. Dans plusieurs fonctions, la navigation par tabulation et les touches F ont disparu
    Elle me montrait comment traverser tout le système à une vitesse folle avec seulement ESC ESC F4 F3 TAB TAB, et ce n’était même pas le système réel mais juste le terminal
    En résumé, les applications Windows sont meilleures pour la découvrabilité et les nouveaux utilisateurs, tandis que les applications terminal sont plus rapides, plus fondées sur la mémoire pour la navigation, et mieux adaptées aux power users

    • C’est un problème de certaines interfaces graphiques en particulier, pas du concept d’interface graphique lui-même. Un bon framework d’interface graphique devrait intégrer par défaut la prévisibilité et des chemins rapides centrés sur le clavier, afin qu’il ne soit pas nécessaire de reprendre ces décisions dans chaque application
      En pratique, toutes les applications qui réussissent auprès des experts ou des utilisateurs avancés sont conçues avec ces chemins rapides en tête. Même le ruban de Microsoft, souvent détesté sans raison, en est un exemple. Il est pilotable au clavier, personnalisable et en même temps facile à découvrir
    • Il n’y a absolument aucune raison que cette capacité n’ait pas été préservée dans la version graphique. C’est une défaillance de conception de l’expérience utilisateur qui survient souvent quand des gens n’ayant jamais utilisé le système, et ne l’utilisant pas, reçoivent la mission de concevoir la version suivante ; cela n’a pas grand-chose à voir avec une interface graphique ou un TUI
      Les interfaces graphiques ne font qu’assouplir les contraintes, ce qui rend d’autant plus facile de dégrader l’expérience utilisateur

  • Le TUI était censé être à l’origine une option simple, mais c’est devenu une web app déguisée en terminal

    • Sauf qu’elle n’a ni les options d’accessibilité du web, ni un bon éditeur de texte, ni autre chose que des options de personnalisation très basiques, et qu’au lieu de tourner dans un sandbox, elle exige un environnement informatique de confiance
      On est loin d’une web app, et c’est bien pire sur la plupart des axes

  • À propos du mythe selon lequel « c’est du texte donc c’est accessible », non, ce n’est pas vrai. Personne ne croit cela
    Quand des développeurs disent ce genre de chose, ils parlent de documents texte et, sous certaines conditions, d’applications terminal à commande unique comme grep, cut ou ls. Il est difficile d’imaginer qu’ils disaient cela des TUI

  • Le problème n’est pas l’utilisation de frameworks d’interface déclaratifs en soi, mais le fait que le moteur de rendu produit par ces frameworks ne tient pas compte de l’accessibilité

    • L’article montre clairement que les interfaces déclaratives peuvent aussi fonctionner si elles sont correctement implémentées et qu’elles offrent des options pour couper le bruit
      Mais personne ne semble s’en être soucié, on dirait qu’on s’est contenté de « c’est un terminal, faisons-le joli »
    • Le terminal a-t-il seulement un support d’accessibilité à l’origine ?

  • Les TUI seront redécouverts sans éléments de type fenêtre. Peu de gens s’en rendent encore compte, mais cela pourrait devenir basé sur des sprites comme une console C64. Quelqu’un, quelque part, le fait peut-être déjà
    On peut désormais dire adieu aux fenêtres et aux panneaux. Un environnement textuel apaisé fait toujours partie de l’ADN culturel de l’humanité en 2026, et ce médium reste énormément sous-exploré
    À côté de ça, l’agressivité cognitive du web moderne ressemble franchement davantage à un cauchemar, dans un sens très hallucinatoire où images, vidéos et publicités se mélangent sans contexte
 
GN⁺ 2026-05-04
Avis sur Lobste.rs

  • Cet article, comme d'autres billets de blog du même genre, dégage fortement une odeur de rédaction assistée par IA
    Les LLM adorent ce type de titres : « 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 »

    • Rien qu'au titre, ça se lit comme du contenu produit à la chaîne par IA. Le sujet lui-même est nouveau, donc le signaler comme spam était peut-être excessif, mais 1) je ne supporte plus ce même style répété partout et 2) ça me fait aussi douter de l'exactitude du contenu
      Ça aurait pu être un excellent billet de blog, mais si l'auteur a juste balancé un plan dans ChatGPT et s'est arrêté là, tout le monde y perd, autant les lecteurs que l'auteur
    • Un des traits que je déteste le plus dans l'écriture par LLM, c'est ce genre de formule du type « The <concept qui n'est absolument pas établi> », qui donne l'impression qu'il s'agit d'une notion officielle
      C'est pareil quand on qualifie de problème « classique » un souci très spécifique et ponctuel

  • C'est vraiment déprimant. En résumé, il existe des TUI accessibles comme Irssi, mais les frameworks TUI modernes ignorent ces précédents et reposent sur des diffs de grille et des déplacements de curseur
    Les lecteurs d'écran lisent le contenu à l'endroit où le curseur se déplace, donc le résultat devient incohérent ou produit un énorme spam vocal

  • Je me demande si l'explication technique donnée ici est totalement exacte
    En particulier, Ink n'a pendant longtemps pas du tout pris en charge le rendu incrémental, et la plupart des applications qui utilisent Ink ne l'activent toujours pas. Même ce rendu incrémental est basé sur les lignes, donc il ne déplace pas réellement le curseur jusqu'à la position du timer
    Pour Gemini CLI, activer le rendu incrémental nécessite l'utilisation du buffer alternatif, et cela est désactivé quand le mode intégré compatible avec les lecteurs d'écran est activé. La documentation de l'option concernée est ici
    À noter aussi que rich/textual en Python est souvent bien plus rapide qu'Ink, même sur un langage plus lent et majoritairement mono-thread. Calculer des diffs sur des milliers de lignes n'est pas forcément si lent, et certainement pas au point de prendre 10 secondes
    Je ne doute pas que l'expérience utilisateur soit frustrante et cassée, mais la cause précise avancée semble pouvoir venir d'une hallucination de LLM ou d'informations incomplètes. Le rendu incrémental d'Ink, même activé, ne fonctionne pas comme décrit
    En réalité, il est très probable que ce soit le redessin complet de l'écran qui perturbe les lecteurs d'écran, et que le redessin ligne par ligne soit mauvais autrement, en faisant relire au hasard des fragments de texte disjoints sans rapport avec le changement

  • Accuser uniquement les TUI n'est pas juste
    Le vrai problème, c'est que la prise en charge de l'accessibilité est médiocre dans presque toute la pile
    D'abord, la plupart des émulateurs de terminal à rendu GPU n'utilisent pas du tout les API d'accessibilité fournies par le système. Quand le texte est rendu par le GPU, les outils d'accessibilité ne peuvent pas le « lire » et n'y voient qu'une image. Kitty, Alacritty et WezTerm sont dans ce cas. Mon terminal Ghostty, lui, peut être lu via les API d'accessibilité sur macOS, tout comme iTerm2 et Terminal.app
    Ensuite, il n'existe absolument aucune séquence de terminal ni mouvement standard permettant à une TUI de transmettre des informations d'accessibilité à l'émulateur de terminal. Il faudrait l'équivalent de commentaires de type ARIA pour les cellules de terminal, les zones d'exécution et les régions, mais il n'y a aucune tentative en ce sens. Même si une TUI gère bien le curseur, ça posera problème dans beaucoup de cas d'usage
    Par exemple, sur Ghostty, nous avons travaillé à intégrer OSC133 avec les API d'accessibilité afin d'exposer chaque prompt de shell, saisie et commande comme des éléments structurellement significatifs, et non comme de simples blocs de texte. Cela montre bien que la spécification des terminaux, les TUI et les émulateurs de terminal doivent fonctionner ensemble
    Toute la pile est pourrie, et il y a très peu de gens qui veulent vraiment la corriger. Moi aussi j'ai un temps limité et je fais de mon mieux, mais c'est un sujet immense qui demande même de la politique d'écosystème, donc c'est difficile à porter
    En bonus, la réalité à la fois fascinante et terrible, c'est que l'IA aide ici à améliorer l'accessibilité. Beaucoup d'outils d'IA utilisent, ou abusent de, l'API d'accessibilité pour lire la liste des fenêtres et effectuer des saisies. Du coup, davantage d'applications commencent à prendre l'intégration de l'accessibilité beaucoup plus au sérieux à cause des cas d'usage liés à l'IA

    • Le terminal est vraiment en train de devenir un petit navigateur

  • Ça m'énerve tous les jours que Claude Code et gemini-cli ne soient pas basés sur readline
    Ils ont ajouté quelques frappes similaires, mais il manque toute la longue traîne des raccourcis readline familiers
    Anthropic pourrait reconnaître que vouloir « faire comme du développement web » était une erreur et repartir sur readline
    L'idée selon laquelle l'expérience de développement familière pour les développeurs qui créent ces outils serait plus importante que l'expérience utilisateur familière pour ceux qui les utilisent est fausse

    • Si je comprends bien, une grande partie du problème vient du fait qu'Ink se contente essentiellement d'être un backend de rendu et ne fournit pas de widget de saisie
      Il n'existe pratiquement aucune solution tierce connue et bien maintenue. Si on a besoin d'une zone de saisie souple, il faut la construire soi-même dès le départ
      À comparer avec l'excellent widget Input de Textual ou, dans l'écosystème JS, la bibliothèque OpenTUI
    • readline n'est pas sous licence GNU ? Quelqu'un a enfin créé une version non GPL ?
      Je n'aime pas les LLM, donc le fait que l'UI soit mauvaise est personnellement un avantage, mais il y a peut-être une raison pour laquelle ils n'utilisent pas readline

  • J'ai l'impression que des éditeurs de terminal comme kakoune ou helix auraient du mal à passer les critères d'accessibilité, à moins d'utiliser l'astuce consistant à « masquer le curseur »
    Ils risquent malgré tout d'être moins accessibles que VS Code
    À part VS Code, quels IDE ou IDE légers multiplateformes sont accessibles ? L'attitude de VS Code, de plus en plus hostile, ne me plaît pas. Peut-être les IDE de JetBrains

    • Il y a emacspeak, qui fournit à Emacs une interface très accessible
      L'inconvénient, c'est que même si Emacs lui-même est multiplateforme, emacspeak a peut-être une dépendance assez forte à Linux à cause de la synthèse vocale. Ou peut-être pas. Je ne l'ai jamais essayé sous Windows
    • Il faut d'abord demander : accessible pour qui ? Si c'est pour les personnes sourdes, il faut proposer du texte dans la langue locale et la langue des signes locale. Aux États-Unis, c'est généralement l'ASL
      Si c'est pour les personnes aveugles, il faut emacspeak ou les outils d'accessibilité de la plateforme pour les déficients visuels
      L'accessibilité est un spectre, pas une case à cocher

  • Links a un mode terminal braille distinct, qui remplace les faux éléments d'interface graphique par un menu plein écran plus simple et transforme la navigation aux flèches en navigation par ligne
    Un autre cas intéressant est edbrowse. C'est un navigateur en mode texte créé par Karl Dahlke, qui est aveugle, mais contrairement aux navigateurs web en mode texte plus populaires, il n'utilise pas de TUI et emploie une interface en ligne de commande de style ed

  • Si c'est bien le framework Ink, ça expliquerait probablement pourquoi certaines CLI utilisent 100 % du CPU et restent figées à redessiner indéfiniment de longs historiques de conversation. C'est dommage