La mentira del modo texto: por qué las TUI modernas son una pesadilla para la accesibilidad

 (xogium.me)
6 puntos por GN⁺ 2026-05-04 | 2 comentarios | Compartir por WhatsApp
  • La suposición de que las apps de terminal, por estar basadas en texto, son accesibles por naturaleza se rompe con las TUI modernas, y frameworks como Ink, Bubble Tea y tcell pueden crear un entorno más hostil para usuarios de lectores de pantalla
  • La CLI acumula la salida como un flujo lineal de stdin/stdout en orden temporal, pero una TUI trata la terminal como una cuadrícula 2D de celdas de caracteres, lo que dificulta que los lectores de pantalla sigan el flujo
  • gemini-cli puede hacer que Ink vuelva a dibujar el árbol de componentes de React sobre la cuadrícula de la terminal, moviendo el cursor entre spinner, temporizador e historial de conversación, lo que puede provocar lecturas repetidas, crashes y retrasos de entrada en Speakup y NVDA
  • Herramientas antiguas como nano, vim, menuconfig e Irssi reducen el ruido de actualizaciones de coordenadas y minimizan la interferencia con la línea de entrada mediante ocultación del cursor, foco en una sola columna y uso de la región de desplazamiento de VT100
  • Para crear herramientas de terminal accesibles, hay que evitar frameworks de UI declarativos que tratan la terminal como un lienzo y el redibujado agresivo, y garantizar un comportamiento más cercano a flujos CLI simples y lineales

El malentendido de que “como es texto, es accesible”

  • La suposición de que las aplicaciones que se ejecutan en la terminal son accesibles por naturaleza no coincide con el entorno real de uso
  • La expectativa de que un lector de pantalla pueda interpretar fácilmente texto ASCII puro porque no hay gráficos, DOM complejo ni canvas WebGL se rompe en las TUI modernas
  • Frameworks de interfaz de terminal como Ink (JS/React), Bubble Tea (Go) y tcell buscan mejorar la experiencia del desarrollador (DX), pero para usuarios con discapacidad visual pueden crear un entorno más hostil
  • En muchos casos, una TUI moderna resulta peor en accesibilidad que una interfaz gráfica mal implementada

Diferencias estructurales entre CLI y TUI

  • CLI: flujo lineal

    • Una CLI funciona sobre stdin/stdout; al ingresar un comando, el resultado se agrega debajo y el cursor baja
    • Como la salida es lineal y se acumula en orden temporal, encaja bien con lectores de pantalla a nivel de kernel como Speakup

  • TUI: cuadrícula 2D

    • Una TUI trata la ventana de la terminal no como un flujo de texto, sino como una cuadrícula 2D donde cada celda de carácter se usa como si fuera un píxel
    • Al renunciar al flujo temporal y priorizar la disposición espacial, se vuelve una estructura difícil de seguir para los lectores de pantalla

Problemas que se hacen visibles en gemini-cli

  • gemini-cli es una herramienta escrita con Node.js y el framework Ink, y por fuera parece una interfaz de chat simple
  • Internamente, Ink intenta ajustar un árbol de componentes de React a la cuadrícula de la terminal
  • Al usarlo con Speakup (Linux) o NVDA (Windows), la aplicación no solo falla de manera simple, sino que también le lanza al lector de pantalla un flujo constante de cosas para leer

  • Una pantalla que funciona como un lienzo reactivo

    • Como el framework trata la pantalla como un lienzo reactivo, cada actualización provoca un redibujado
    • Cuando la IA está “pensando”, mueve el cursor de hardware a la posición del temporizador para actualizar el spinner o el tiempo transcurrido, escribe el nuevo tiempo y luego lo regresa a la posición original
    • Para un usuario vidente es un movimiento instantáneo que pasa desapercibido, pero para un usuario de lector de pantalla suena repetidamente como “Responding... Time elapsed 1s... Responding... Time elapsed 2s...”
    • A medida que el cursor salta momentáneamente entre el indicador de estado, el spinner y el historial de conversación, Speakup intenta leer lo que haya debajo del cursor en ese instante
    • Como resultado, las actualizaciones del temporizador y fragmentos de la conversación se mezclan, dificultando concentrarse en lo que realmente se está escribiendo

  • Inestabilidad con NVDA y al pegar texto

    • En Windows, si se abre una terminal con NVDA, se conecta por SSH a un equipo Linux y luego se entra a una sesión de screen para pegar texto, NVDA puede crashear de inmediato o el sistema puede volverse muy inestable
    • Cada vez que se escribe un carácter o se pega texto, el estado de la aplicación cambia y el framework decide que debe volver a renderizar la interfaz
    • Si el historial de conversación forma parte del estado, intenta redibujar o recalcular de inmediato el layout de miles de líneas de texto
    • Cuantos más mensajes haya en la conversación, más seguido ocurre este problema
    • Ni siquiera la combinación Insert+5, pensada para evitar anuncios de contenido dinámico, logra esquivarlo

  • Bucle de retraso en la entrada

    • Cuando un framework como Ink corre en un entorno de un solo hilo como Node.js, la degradación de rendimiento empeora a medida que crece el historial
    • Si se pega un bloque grande de texto, hay que calcular diferencias sobre miles de líneas
    • El sistema se ocupa calculando cómo redibujar la pantalla y el procesamiento de entrada se retrasa
    • Incluso al presionar una sola tecla, puede haber que esperar hasta 10 segundos para que el carácter vuelva a mostrarse

Por qué las herramientas antiguas sí funcionan

  • Herramientas como nano, vim y menuconfig no se usan porque sean siempre perfectas en accesibilidad
  • La clave es que estas herramientas pueden ocultar completamente el cursor o reducir el ruido generado por el seguimiento de la posición del cursor

  • nano y vim: ocultar el cursor

    • Si nano se ejecuta con opciones que muestran la posición del cursor, como --constantshow, o si se usa vim sin cierta configuración, la usabilidad puede romperse
    • Cuando el cursor es visible y el seguimiento está activado, Speakup prioriza las actualizaciones de posición del cursor por encima del eco de caracteres
    • Si el usuario escribe “a”, en vez de oír “a” puede oír “Column 2”, y si escribe “b”, puede oír “Column 3”
    • Estas herramientas antiguas pueden configurarse para suprimir el cursor visual o las actualizaciones de la barra de estado, permitiendo que el lector de pantalla dependa del flujo de entrada de caracteres y no de las actualizaciones de coordenadas
    • Los frameworks modernos por lo general no ofrecen un modo “no-cursor” o “headless”, y asumen que el cursor visual es obligatorio

  • menuconfig: foco en una sola columna

    • El menuconfig del kernel de Linux funciona porque mantiene estrictamente el foco en una sola columna
    • Aunque tiene bordes y títulos, el área activa es una lista vertical, y el cursor se mantiene fijo en esa lista
    • El cursor no se mueve a la esquina inferior derecha para actualizar un reloj y luego a la esquina superior izquierda para actualizar un título
    • La complejidad espacial se mantiene baja, por lo que el lector de pantalla no pierde el rumbo

  • Irssi: uso de la región de desplazamiento

    • Irssi no es accesible por casualidad, sino que es una herramienta de chat que desde hace más de 20 años aprovecha la región de desplazamiento de VT100 mediante un motor de renderizado personalizado
    • Cuando llega un mensaje nuevo, le indica al driver de la terminal que “defina las filas 1 a 23 como región de desplazamiento”
    • Luego envía la orden de “desplazar hacia arriba”, la terminal mueve el contenido hacia arriba y después dibuja el texto nuevo en la parte inferior de esa región
    • Este método minimiza la interferencia con la línea de entrada
    • En vez de reescribir manualmente todos los caracteres de la pantalla, se apoya en capacidades de hardware de la terminal
    • Los frameworks modernos ignoran estas capacidades de hardware y optan por calcular diferencias de estado de pantalla para reescribir caracteres, lo que cuesta más cómputo y es hostil para la accesibilidad

Problemas en cómo se gestionan los issues de gemini-cli

  • Google y los mantenedores de gemini-cli parecen preocuparse por la accesibilidad, pero en el repositorio se están dejando de lado regresiones importantes de accesibilidad
  • Regresiones de accesibilidad como Issue #3435 e Issue #11305 no tienen discusión, hoja de ruta ni corrección
  • Issue #1553 era un issue para rastrear este tipo de fallas de accesibilidad, pero no se resolvió y un bot lo cerró automáticamente
  • El bot cerró el issue con una frase genérica diciendo que no había actividad reciente y que se estaba administrando el backlog
  • Cerrar reportes de accesibilidad porque los mantenedores no los tocaron durante meses no es orden: es esconder evidencia
  • Se transmite la señal de que, si un bug se ignora el tiempo suficiente, deja de existir, mientras que el software real sigue siendo inutilizable para usuarios con discapacidad visual
  • Puede que mejoren los indicadores de “Closed Issues” del proyecto, pero los problemas de accesibilidad siguen sin resolverse

Conclusión para crear herramientas de terminal accesibles

  • Si realmente importa la accesibilidad en aplicaciones para terminal, hay que dejar de usar frameworks de UI declarativos que tratan la terminal como un lienzo
  • El stack TUI “moderno” está optimizado para que al desarrollador le resulte fácil escribir código al estilo React, sacrificando la capacidad de la máquina para renderizar texto de manera eficiente
  • Si una aplicación no garantiza que el usuario pueda ocultar el cursor, o depende de redibujados agresivos para mostrar spinners y temporizadores, entonces es una herramienta inaccesible
  • Para usuarios con discapacidad visual, un flujo CLI simple y lineal es mucho mejor que una TUI “inteligente” que introduce retrasos, no deja de hablar y dispersa el cursor por toda la pantalla

Lecturas relacionadas

2 comentarios

 
GN⁺ 2026-05-05
Comentarios de Hacker News

  • Al ver la UI de renderizado de Claude Code, me di cuenta por primera vez de que una TUI se parece menos a una interfaz de línea de comandos y más a un sistema de UI estilo DOS o Borland
    Revisando la configuración CLAUDE_CODE_NO_FLICKER=1, se notaba que esta TUI estaba construida para superponer varias capas usando códigos de control del terminal
    También leí la implementación de terminal Ink para React: https://github.com/vadimdemedes/ink
    Me pareció interesante cómo termina viéndose no como gráficos basados en píxeles, sino como los viejos WordPerfect o WordStar, y desde la perspectiva de un usuario con discapacidad visual la usabilidad es parecida. Aun así, recuerdo que los pads braille de 80x25 para herramientas DOS funcionaban mejor que muchos lectores de pantalla posteriores

  • Mientras más veo las TUI que están de moda hoy, peor me parecen. Se sienten como si hubieran juntado las peores prácticas acumuladas desde los inicios de la programación y las hubieran envuelto en una masa gelatinosa difícil de manejar, pesada y lenta, a punto de colapsar por su propio peso

    • Esas cosas no son realmente interfaces de terminal, sino más bien intentos de imitar una UI gráfica tipo Windows dentro del terminal
      Son de la misma clase de cosas que se hacían en DOS cuando Windows no era común o no era lo bastante bueno, así que no sorprende que sean un desastre o que estén hechas sin entender las capacidades del terminal donde corren

  • Siempre me ha parecido un poco curioso por qué las TUI son populares. La fuerza del terminal está en el modelo de streaming, y las utilidades combinables son una ventaja mucho menos común en las UI gráficas
    Entiendo que las limitaciones del terminal pueden hacer que el diseño de una TUI se concentre más en el propósito de la herramienta que en adornos superficiales, pero personalmente no me parece una razón tan convincente

    • Las TUI nuevas como Claude Code, OpenCode o Crush no existen principalmente por la composabilidad o el streaming de texto, sino más bien por la convergencia de varios vientos a favor
      Ya existe un grupo considerable de ingenieros que vive dentro del terminal usando Vim/Neovim/tmux/zellij, y mucho trabajo de desarrollo consiste en ejecutar scripts desde ahí, así que hay demanda por mover la mayor cantidad posible de tareas a ese entorno
      En plataformas principales como macOS y Linux, la distribución mediante gestores de paquetes está prácticamente resuelta, mientras que distribuir apps nativas multiplataforma sigue bastante fragmentado
      Gracias a esa demanda y a las ventajas de distribución, los componentes para TUI como Ink para React y Bubble Tea para Go han mejorado mucho, y Electron carga con la imagen de apps lentas y pesadas, así que muchos desarrolladores lo evitan
      Al final, los productos exitosos a veces terminan pasando a otras formas, como Claude Code evolucionando a Claude Cowork u OpenCode sumando OpenCode Web, pero es mucho más fácil probar rápidamente el product-market fit de una herramienta para desarrolladores con una TUI, y aun después de lanzar otras interfaces muchos usuarios van a seguir en el terminal
    • Para cosas básicas como vim encaja bien, pero para casi todo lo demás creo que es mejor una herramienta de línea de comandos normal o una interfaz web. Gran parte de la popularidad parece venir de querer sentirse como un hacker con 10 ventanas de terminal abiertas, aunque en realidad se busca una experiencia parecida a una UI gráfica
    • Hoy ya pasó totalmente de moda, pero uno puede pensar en TN3270. Era más basado en formularios que en streaming, y centrado en el teclado
      También se habría podido imitar fácilmente con una UI gráfica, pero los atajos de teclado quedaron para después
      Todavía me encuentro usuarios que extrañan esos flujos de trabajo antiguos, y lo describen como una “interfaz de texto antigua”, o sea, una TUI. Pero cuando los escuchas bien, lo que de verdad quieren es un flujo centrado en atajos y extremadamente rápido. Cuando se capturan datos, lo importante no es la animación sino la velocidad
      A los principiantes les gustan los fuegos artificiales visuales, pero a los expertos ya no les importa eso
    • Las TUI funcionan sobre ssh sin trabajo extra
      Las limitaciones que impone el terminal hacen que las apps en general se vean y se comporten de forma parecida. Afuera, en el mundo normal, los estándares de experiencia de usuario se ignoran a diario solo porque es posible, pero las TUI son, por decirlo así, el punto óptimo con menos sorpresas
    • La fuerza de las TUI está en varias cosas: consumen pocos recursos, dependen menos del mouse, permiten aplicar key bindings acordes a la memoria muscular de vi a más tareas, y hacen posible una organización más profunda
      Gracias a herramientas TUI pude construir mi propio IDE invisible cuando lo necesito. Con guake y yakuake puedo ocultarlo, y con zellij queda organizado por proyectos y pestañas. Para un trabajo como el de ahora, donde se mezclan varios roles, me queda perfecto
      Eso sí, no creo que nadie lo llamara elegante

  • Desde la perspectiva de quien mantiene un proyecto, puede verse distinto. Quienes poseen y mantienen un proyecto pueden definir qué significan Open y Closed en los issues, y el usuario no tiene por qué estar de acuerdo
    Por ejemplo, Open puede usarse para “todavía no clasificado” o “se está trabajando activamente”, y Closed puede significar “vimos este ticket pero por ahora nadie del equipo va a trabajarlo”
    Es decir, Closed no tiene que significar necesariamente “fue rechazado y esta decisión es final”, también puede significar “no es algo en lo que estemos trabajando ahora”. Puede que no sea intuitivo para todos, pero si ayuda al equipo del proyecto a organizar la carga de trabajo, puede justificarse

  • Estoy de acuerdo con esta evaluación. Más aún, si los desarrolladores hubieran respetado y formalizado mejor CUA, es decir, el estándar de interfaz Common User Access de IBM, habría sido mucho más fácil: https://en.wikipedia.org/wiki/IBM_Common_User_Access
    Si los desarrolladores quieren experimentar con distintas composiciones de UI, que lo hagan, pero manteniendo detrás una CUA que tanto máquinas como personas puedan invocar. Lamentablemente, la ergonomía nunca ha sido una fortaleza de los desarrolladores

  • Este es un problema bien documentado entre TUI y Windows
    En los 90, cuando la mayoría de los sistemas SAP pasaron de terminales AS/400 a Windows NT, mucha gente decía que la productividad había caído muchísimo
    Nunca trabajé en SAP, pero mi madre sí, y el flujo de trabajo, que era completamente tabular y basado en teclas de función, pasó a uno de agarrar el mouse, moverlo y hacer muchos clics. En varias funciones desaparecieron la navegación con Tab y las teclas F
    Ella me mostró cómo podía recorrer todo el sistema a una velocidad increíble solo con ESC ESC F4 F3 TAB TAB, y eso ni siquiera era el sistema real, sino el terminal
    En resumen, las apps basadas en Windows son buenas para la capacidad de descubrimiento y para usuarios nuevos, mientras que las apps basadas en terminal son más rápidas y mejores para la navegación basada en memoria y para los usuarios avanzados

    • Ese es un problema de ciertas UI gráficas específicas, no del concepto de UI gráfica en sí. Un buen framework de UI gráfica debería incluir por defecto previsibilidad y rutas rápidas centradas en el teclado, para que cada app no tenga que volver a tomar esas decisiones
      De hecho, todas las apps exitosas para expertos o usuarios avanzados están hechas pensando en rutas rápidas. Incluso la cinta de Microsoft, que recibe mucho odio sin motivo, es un buen ejemplo. Se puede usar con teclado, se puede personalizar y al mismo tiempo es fácil de descubrir
    • No hay ninguna razón por la que esa funcionalidad no pudiera conservarse en la versión gráfica. Es simplemente un fracaso de diseño de experiencia de usuario muy común cuando personas que nunca usaron ni usarán el sistema reciben la orden de diseñar la siguiente versión, pero eso tiene poco que ver con si es una UI gráfica o una TUI
      La UI gráfica solo relaja las restricciones, y por eso mismo hace más fácil arruinar la experiencia de usuario

  • La TUI se suponía que era una opción simple, pero ahora se convirtió en una web app disfrazada de terminal

    • Pero sin las opciones de accesibilidad de la web, sin una buena edición de texto, con opciones de personalización muy básicas y, en lugar de ejecutarse en un sandbox, exigiendo un entorno de cómputo confiable
      Está lejos de una web app, y en casi todos los ejes es mucho peor

  • Sobre el mito de que “como es texto, es accesible”: no, no lo es. Nadie que entienda del tema cree eso
    Cuando los desarrolladores dicen algo así, se refieren a documentos de texto y, de manera condicional, a apps de terminal de un solo comando como grep, cut o ls. Es difícil pensar que alguien lo haya dicho de una TUI

  • El problema no es usar un framework de UI declarativo en sí, sino que los motores de renderizado que producen estos frameworks no consideran la accesibilidad

    • Leyendo el artículo, queda claro que una UI declarativa también puede funcionar si se implementa correctamente y se ofrece una opción para apagar el ruido
      Pero parece que a nadie le importó eso y todo se quedó en “es un terminal, hagámoslo bonito”
    • ¿El terminal siquiera tiene soporte de accesibilidad desde el inicio?

  • Las TUI van a redescubrirse sin elementos tipo ventana. Todavía poca gente se da cuenta, pero podrían volverse basadas en sprites, como la consola de una C64. Puede que alguien ya lo esté haciendo en algún lugar
    Las ventanas y paneles ya se pueden dejar ir. Un entorno de texto tranquilo sigue siendo parte del ADN cultural humano incluso en 2026, y este medio sigue estando enormemente inexplorado
    La agresividad cognitiva de la web moderna, en comparación, me parece mucho más cercana a una pesadilla. En un sentido muy alucinatorio, con imágenes, video y anuncios mezclados sin contexto
 
GN⁺ 2026-05-04
Comentarios en Lobste.rs

  • Este artículo, como muchas otras entradas de blog, tiene un fuerte olor a redacción asistida por IA
    A los LLM les encantan títulos de este estilo: “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”

    • Desde el título ya se lee como contenido producido en masa por IA. El tema en sí es novedoso, así que quizá reportarlo como spam fue excesivo, pero 1) ya no soporto más ese mismo estilo repetido por todas partes y 2) hasta me hace dudar de la precisión del contenido
      Podría haber sido una excelente entrada de blog, pero si parece que el autor solo le lanzó un esquema a ChatGPT y lo dejó ahí, eso perjudica tanto a lectores como al autor
    • Una de las cosas que más odio de la escritura con LLM es eso de escribir “The <algo que no es en absoluto un concepto establecido>” como si fuera un concepto formal
      Lo mismo pasa cuando llaman “clásico” a un problema muy específico y de una sola ocasión

  • Es realmente deprimente. En resumen, sí existen TUI accesibles como Irssi, pero los frameworks TUI modernos ignoran esos precedentes y dependen de diffing de cuadrículas y movimiento del cursor
    Los lectores de pantalla leen el contenido de la posición a la que se mueve el cursor, así que el resultado termina siendo caótico o genera una cantidad enorme de spam de lectura

  • Tengo dudas de que la explicación técnica aquí sea completamente correcta
    En particular, Ink durante mucho tiempo no soportó en absoluto renderizado incremental, y la mayoría de las apps que usan Ink todavía no lo activan. Incluso ese renderizado incremental es basado en líneas, así que en realidad no mueve el cursor a la posición exacta del temporizador
    Gemini CLI requiere usar el búfer alternativo para activar el renderizado incremental, y eso se desactiva cuando está activado el modo amigable con lectores de pantalla integrado. La documentación de esa opción está aquí
    Además, rich/textual de Python suele ser mucho más rápido que Ink incluso sobre un lenguaje más lento y mayormente de un solo hilo. Hacer diff de miles de líneas no necesariamente es tan lento, ni algo que deba tardar 10 segundos
    No dudo que la experiencia de usuario sea frustrante y esté rota, pero parece posible que la causa exacta propuesta sea una alucinación de LLM o se base en información incompleta. El renderizado incremental de Ink, incluso cuando está activado, no funciona como se describe
    En la práctica, es más probable que el redibujado completo de pantalla confunda a los lectores de pantalla, y que el redibujado por líneas haga que se vuelvan a leer fragmentos arbitrarios y cortados de texto que no tienen relación con el cambio

  • No es justo culpar solo a las TUI
    El verdadero problema es que el soporte de accesibilidad es pésimo en casi toda la pila
    Primero, la mayoría de los emuladores de terminal con renderizado por GPU no usan en absoluto las API de accesibilidad del sistema. Si el texto se renderiza en la GPU, las herramientas de accesibilidad no pueden “leerlo” y solo parece una imagen. Kitty, Alacritty y WezTerm entran en esta categoría. Mi terminal, Ghostty, sí puede leerse mediante la API de accesibilidad en macOS, y iTerm2 y Terminal.app también
    Segundo, no existe ninguna secuencia de terminal ni movimiento estandarizado para que una TUI transmita información de accesibilidad al emulador de terminal. Hace falta algo equivalente a anotaciones tipo ARIA para celdas de terminal, spans y regiones, pero no hay intentos de eso. Aunque una TUI maneje bien el cursor, el problema igual va a aparecer en muchos casos de uso
    Por ejemplo, en Ghostty hemos estado trabajando en integrar OSC133 con la API de accesibilidad para exponer cada prompt de shell, entrada y comando como elementos estructuralmente significativos en lugar de simples cajas de texto. Eso demuestra que la especificación del terminal, la TUI y el emulador de terminal tienen que encajar juntos
    Toda la pila está podrida, y casi nadie está intentando arreglarla de verdad. Yo también solo hago lo mejor que puedo con tiempo limitado, pero este es un tema enorme que hasta requiere política de ecosistema, así que es difícil de abarcar
    Como bonus, la realidad tan genial como terrible es que la IA sí está ayudando a mejorar la accesibilidad aquí. Muchas herramientas de IA usan o abusan de las API de accesibilidad para leer listas de ventanas y realizar entradas. Por eso más apps han empezado a tomarse mucho más en serio la integración de accesibilidad por los casos de uso de IA

    • El terminal de verdad se está convirtiendo en un navegador pequeño

  • Me molesta todos los días que Claude Code y gemini-cli no estén basados en readline
    Metieron algunas teclas parecidas, pero falta toda la larga cola de atajos readline conocidos
    Anthropic podría admitir que fue un error decidir “hay que hacerlo como desarrollo web” y volver a empezar con readline
    Es incorrecto pensar que la experiencia de desarrollo familiar para quienes crean estas herramientas importa más que la experiencia de usuario familiar para quienes las usan

    • Entiendo que gran parte de este problema se debe a que Ink en la práctica se conforma con ser un backend de renderizado y no ofrece widgets de entrada
      En realidad casi no hay soluciones populares de terceros bien mantenidas. Si necesitas una caja de entrada flexible, tienes que construirla tú mismo desde cero
      Contrasta con el excelente widget Input de Textual o con OpenTUI, otra librería del ecosistema JS
    • ¿readline no tiene licencia GNU? ¿Al fin alguien hizo una versión que no sea GPL?
      No me gustan los LLM, así que personalmente una UI mala me parece una ventaja, pero puede que haya alguna razón para no usar readline

  • Me parece que editores de terminal como kakoune y helix tendrían difícil pasar los criterios de accesibilidad a menos que usen el truco de “ocultar el cursor”
    Aun así, probablemente no serían tan accesibles como VS Code
    Fuera de VS Code, ¿qué IDE-lite o IDE multiplataforma accesible hay? No me gusta la actitud cada vez más hostil de VS Code. Tal vez podrían ser los IDE de JetBrains

    • Está emacspeak, que ofrece una interfaz muy accesible para Emacs
      La desventaja es que, aunque Emacs en sí es multiplataforma, emacspeak puede tener cierta dependencia de Linux por el TTS. O quizá no. Nunca lo he probado en Windows
    • Primero hay que preguntar accesibilidad para quién. Si es para personas sordas, entonces debe ofrecer texto en el idioma local y lengua de señas local. En Estados Unidos, normalmente sería ASL
      Si es accesibilidad para personas ciegas, entonces hace falta emacspeak o las herramientas de accesibilidad para personas con discapacidad visual de la plataforma
      La accesibilidad es un espectro, no una casilla para marcar

  • Links tiene un modo de terminal braille aparte, que reemplaza los elementos de GUI falsos por un menú de pantalla completa más simple y también cambia la navegación con flechas a navegación por líneas
    Otro caso interesante es edbrowse. Es un navegador en modo texto creado por Karl Dahlke, que es ciego, y a diferencia de los navegadores web en modo texto más populares, no usa una TUI sino una interfaz de línea de comandos estilo ed

  • Si es el framework Ink, probablemente esa sea la razón por la que el CLI usa 100% de CPU, se queda colgado para siempre y sigue redibujando historiales largos de chat. Una lástima