टेक्स्ट मोड का झूठ: आधुनिक TUI accessibility के लिए दुःस्वप्न क्यों हैं

 (xogium.me)
6 पॉइंट द्वारा GN⁺ 2026-05-04 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • यह मान लेना कि terminal apps टेक्स्ट-आधारित होने के कारण स्वाभाविक रूप से accessible होते हैं, आधुनिक TUI में टूट जाता है; Ink, Bubble Tea, tcell जैसे frameworks screen reader users के लिए और अधिक शत्रुतापूर्ण माहौल बना सकते हैं
  • CLI में output stdin/stdout की linear stream के रूप में समयक्रम में जुड़ता जाता है, जबकि TUI terminal को character-cell आधारित 2D grid की तरह संभालता है, जिससे screen readers के लिए flow का पीछा करना कठिन हो जाता है
  • gemini-cli में Ink React component tree को terminal grid के हिसाब से फिर से render करता है, और spinner, timer, तथा conversation history के बीच cursor घुमाते हुए Speakup और NVDA में बार-बार पढ़ना, crash, और input lag पैदा कर सकता है
  • nano, vim, menuconfig, Irssi जैसे पुराने tools cursor hiding, single-column focus, और VT100 scroll region के उपयोग से coordinate update के शोर को घटाते हैं और input line में हस्तक्षेप कम करते हैं
  • accessible terminal tools बनाने के लिए terminal को canvas की तरह संभालने वाले declarative UI frameworks और aggressive re-rendering से बचना होगा, और simple, linear CLI stream के करीब behavior सुनिश्चित करना होगा

“टेक्स्ट है, इसलिए accessible है” — यह गलतफ़हमी

  • यह धारणा कि terminal पर चलने वाले applications स्वाभाविक रूप से accessible होते हैं, वास्तविक उपयोग स्थितियों से मेल नहीं खाती
  • यह अपेक्षा कि graphics, जटिल DOM, या WebGL canvas न होने से screen readers raw ASCII text को आसानी से समझ लेंगे, आधुनिक TUI में टूट जाती है
  • Ink(JS/React), Bubble Tea(Go), tcell जैसे terminal UI frameworks developer experience (DX) को बेहतर बनाने की कोशिश करते हैं, लेकिन दृष्टिबाधित users के लिए और अधिक शत्रुतापूर्ण वातावरण बना सकते हैं
  • accessibility के मामले में आधुनिक TUI कई बार खराब तरह से implement किए गए graphical interface से भी बदतर होते हैं

CLI और TUI के बीच संरचनात्मक अंतर

  • CLI: linear stream

    • CLI stdin/stdout के आधार पर काम करता है; command डालने पर result नीचे जुड़ता है और cursor नीचे चला जाता है
    • output linear और time-ordered रूप में जमा होता है, इसलिए Speakup जैसे kernel-level screen readers के लिए यह उपयुक्त है

  • TUI: 2D grid

    • TUI terminal window को text stream की तरह नहीं, बल्कि ऐसी 2D grid की तरह देखता है जिसमें हर character cell एक pixel की तरह इस्तेमाल होता है
    • समयगत flow को छोड़कर spatial layout को प्राथमिकता देने से यह screen readers के लिए कठिन संरचना बन जाती है

gemini-cli में दिखने वाली समस्याएँ

  • gemini-cli Node.js और Ink framework से बना एक tool है, और ऊपर से यह एक साधारण chat interface जैसा दिखता है
  • अंदर ही अंदर Ink React component tree को terminal grid के हिसाब से ढालने की कोशिश करता है
  • Speakup(Linux) या NVDA(Windows) के साथ इस्तेमाल करने पर application सिर्फ fail नहीं करता, बल्कि screen reader पर लगातार पढ़े जाने वाली चीज़ें उछालता रहता है

  • responsive canvas की तरह व्यवहार करने वाली screen

    • framework screen को responsive canvas की तरह मानता है, इसलिए हर update re-rendering करवाता है
    • जब AI “सोच रहा” होता है, तो timer या spinner update करने के लिए hardware cursor को timer की जगह ले जाया जाता है, नया समय लिखा जाता है, फिर उसे वापस मूल जगह लाया जाता है
    • visual users के लिए यह तुरंत गुजर जाने वाली क्रिया है, लेकिन screen reader users को यह “Responding... Time elapsed 1s... Responding... Time elapsed 2s...” की तरह बार-बार सुनाई दे सकती है
    • cursor status display, spinner, और conversation history के बीच पलभर के लिए घूमता है, और Speakup उस क्षण cursor के नीचे मौजूद content को पढ़ने की कोशिश करता है
    • नतीजतन timer updates और conversation fragments आपस में मिल जाते हैं, जिससे वास्तव में टाइप की जा रही चीज़ पर ध्यान केंद्रित करना मुश्किल हो जाता है

  • NVDA और paste करते समय होने वाली अस्थिरता

    • Windows में NVDA के साथ terminal खोलकर, Linux मशीन पर SSH से जुड़ने के बाद screen session में text paste करने पर NVDA तुरंत crash कर सकता है या system बहुत अस्थिर हो सकता है
    • हर character टाइप करने या text paste करने पर application state बदलती है, और framework तय करता है कि interface को फिर से render करना चाहिए
    • अगर conversation history state में शामिल है, तो framework हजारों lines के text layout को तुरंत फिर से draw या recalculate करने की कोशिश कर सकता है
    • conversation messages जितने ज़्यादा होंगे, यह समस्या उतनी ही अधिक बार होगी
    • dynamic content notifications से बचने के लिए Insert+5 combination भी इस समस्या से नहीं बचा पाता

  • input lag loop

    • Ink जैसे frameworks जब Node.js जैसे single-threaded environment में चलते हैं, तो history बढ़ने के साथ performance गिरावट बढ़ती जाती है
    • बड़े text blocks paste करने पर हजारों lines का diff calculate करना पड़ सकता है
    • system screen को फिर से draw करने का तरीका निकालने में व्यस्त हो जाता है, इसलिए input processing देर से होती है
    • एक key दबाने पर भी character दोबारा दिखने में अधिकतम 10 सेकंड तक लग सकते हैं

पुराने tools क्यों काम करते हैं

  • nano, vim, menuconfig जैसे tools इसलिए उपयोगी नहीं हैं कि वे हमेशा accessibility में परफ़ेक्ट हों
  • असली बात यह है कि ये tools cursor को पूरी तरह छिपा सकते हैं, या cursor position tracking से पैदा होने वाले शोर को कम कर सकते हैं

  • nano और vim: cursor छिपाना

    • nano को --constantshow जैसे cursor position दिखाने वाले option के साथ चलाना, या vim को बिना खास settings के इस्तेमाल करना usability को खराब कर सकता है
    • अगर cursor दिखाई दे रहा हो और tracking चालू हो, तो Speakup character echo की जगह cursor position updates को प्राथमिकता देता है
    • user अगर “a” टाइप करे तो उसे “a” की जगह “Column 2” सुनाई दे सकता है, और “b” टाइप करने पर “Column 3”
    • इन पुराने tools को इस तरह configure किया जा सकता है कि visual cursor या status bar updates दब जाएँ, जिससे screen reader coordinate updates की बजाय character input stream पर निर्भर रह सके
    • आधुनिक frameworks आमतौर पर “no-cursor” या “headless” mode नहीं देते, और मान लेते हैं कि visual cursor अनिवार्य है

  • menuconfig: single-column focus

    • Linux kernel का menuconfig इसलिए काम करता है क्योंकि यह कड़ाई से single-column focus बनाए रखता है
    • borders और titles होने के बावजूद active area एक vertical list ही रहती है, और cursor उसी list में स्थिर रहता है
    • cursor clock update के लिए नीचे-दाएँ और title update के लिए ऊपर-बाएँ नहीं घूमता
    • spatial complexity कम रहने से screen reader अपना रास्ता नहीं खोता

  • Irssi: scroll region का उपयोग

    • Irssi संयोग से accessible नहीं है; यह 20 साल से अधिक समय से custom rendering engine के साथ VT100 scroll region का उपयोग करने वाला chat tool है
    • नया message आने पर यह terminal driver को निर्देश देता है: “row 1 से row 23 तक को scroll region के रूप में define करो”
    • फिर “scroll up” command भेजी जाती है, terminal content को ऊपर खिसका देता है, और उस region के नीचे नए text को draw करता है
    • यह तरीका input line के साथ हस्तक्षेप को न्यूनतम करता है
    • screen के हर character को हाथ से फिर से लिखने की बजाय यह terminal की hardware capabilities पर निर्भर करता है
    • आधुनिक frameworks इन hardware features को नज़रअंदाज़ करके screen state diff calculate कर characters फिर से लिखने का तरीका अपनाते हैं, जो computationally अधिक महँगा और accessibility के लिए शत्रुतापूर्ण है

gemini-cli issues को संभालने की समस्या

  • Google और gemini-cli maintainers देखने में accessibility की परवाह करते लगते हैं, लेकिन repository में महत्वपूर्ण accessibility regressions को छोड़ा हुआ है
  • Issue #3435 और Issue #11305 जैसे accessibility regressions पर न चर्चा है, न roadmap, न fix
  • Issue #1553 इस तरह की accessibility failures को track करने के लिए था, लेकिन यह unresolved रहा और bot ने इसे अपने-आप बंद कर दिया
  • bot ने issue बंद करते समय वही सामान्य संदेश दिया कि काफी समय से activity नहीं हुई और backlog manage करने के लिए इसे बंद किया जा रहा है
  • सिर्फ इसलिए accessibility reports बंद कर देना कि maintainers ने महीनों तक उन्हें नहीं छुआ, सफ़ाई नहीं बल्कि सबूत छिपाने जैसा है
  • इससे यह संकेत जाता है कि अगर किसी bug को काफ़ी देर तक नज़रअंदाज़ करो, तो वह मानो मौजूद ही नहीं रहता, जबकि वास्तविक software दृष्टिबाधित users के लिए अब भी अनुपयोगी बना रहता है
  • project के “Closed Issues” metrics बेहतर दिख सकते हैं, लेकिन accessibility problems हल नहीं होतीं

accessible terminal tools बनाने के लिए निष्कर्ष

  • अगर terminal applications में accessibility सचमुच महत्वपूर्ण है, तो terminal को canvas की तरह संभालने वाले declarative UI frameworks का उपयोग बंद करना होगा
  • “modern” TUI stacks को इस तरह optimize किया गया है कि developers React-जैसा code आसानी से लिख सकें, और इसके बदले machines की efficient text rendering क्षमता की कुर्बानी दी गई है
  • अगर application यह सुनिश्चित नहीं कर सकता कि user cursor छिपा सके, या spinner और timer दिखाने के लिए aggressive re-rendering पर निर्भर है, तो वह एक inaccessible tool बन जाता है
  • दृष्टिबाधित users के लिए ऐसा simple, linear CLI stream कहीं बेहतर है, बजाय उस “smart” TUI के जो lag करता है, लगातार पढ़े जाने वाला content उछालता रहता है, और cursor को पूरी screen पर बिखेर देता है

संबंधित पढ़ाई

2 टिप्पणियां

 
GN⁺ 2026-05-05
Hacker News की राय

  • Claude Code के rendering UI को देखते हुए पहली बार समझ आया कि TUI command-line interface से ज़्यादा DOS या Borland-शैली के UI system के करीब है
    CLAUDE_CODE_NO_FLICKER=1 सेटिंग को देखते समय पता चला कि यह TUI terminal control codes के ज़रिये कई layers को overlap करके दिखाने वाली संरचना पर बना है
    React के लिए Ink terminal implementation भी पढ़ा: https://github.com/vadimdemedes/ink
    यह देखना दिलचस्प था कि यह pixel-based graphics नहीं है, फिर भी पुराने WordPerfect या WordStar जैसा दिखने लगता है, और दृष्टिबाधित users के नज़रिए से usability भी मिलती-जुलती है। हालांकि DOS tools के लिए 80x25 braille pad बाद के screen readers से बेहतर काम करता था, ऐसा याद है

  • आजकल के लोकप्रिय TUI को जितना ज़्यादा देखता हूँ, उतना ही बुरा लगता है। ऐसा लगता है जैसे programming की शुरुआत से जमा हुई सबसे खराब प्रथाएँ सब इकट्ठी करके उन्हें एक भारी, धीमे, संभालने में मुश्किल jelly-जैसे ढेर में लपेट दिया गया हो, जो अपने ही वजन से गिरने वाला हो

    • वे terminal UI कम और terminal के भीतर Windows जैसी graphical UI की नकल करने की कोशिश ज़्यादा लगते हैं
      यह उसी तरह की चीज़ है जैसी उस दौर में DOS पर बनाई जाती थी जब Windows आम नहीं था या पर्याप्त अच्छा नहीं था, इसलिए उनका आपदा होना या उन्हें चलाने वाले terminal की क्षमताओं को समझे बिना बनाया जाना हैरान करने वाली बात नहीं है

  • मुझे हमेशा थोड़ा अजीब लगा कि TUI इतने लोकप्रिय क्यों हैं। terminal की ताकत उसके streaming model में है, और composable utilities graphical UI में कहीं कम देखने को मिलने वाला फ़ायदा हैं
    मैं समझ सकता हूँ कि terminal की सीमाएँ TUI design को सजावट से ज़्यादा tool के उद्देश्य पर केंद्रित कर सकती हैं, लेकिन व्यक्तिगत रूप से मुझे यह बहुत ठोस वजह नहीं लगती

    • Claude Code, OpenCode, Crush जैसी नई लहर के TUI composability या text streaming की वजह से नहीं, बल्कि कई अनुकूल परिस्थितियों के साथ आने का नतीजा ज़्यादा लगते हैं
      Vim/Neovim/tmux/zellij आदि इस्तेमाल करते हुए terminal में ही रहने वाले engineers की एक बड़ी जमात पहले से मौजूद है, और बहुत-सा development work terminal में scripts चलाने के रूप में होता है, इसलिए जितना हो सके उतना काम वहीं ले जाने की मांग है
      macOS और Linux जैसे मुख्य platforms पर package manager के ज़रिये distribution लगभग सुलझ चुका है, लेकिन cross-platform native app distribution अब भी fragmented है
      इस मांग और distribution के फ़ायदों की वजह से Ink for React, Bubble Tea for Go जैसे TUI components काफ़ी बेहतर हो गए हैं, और Electron की छवि धीमे और bloated apps से जुड़ी होने के कारण developers उससे बचते हैं
      आख़िरकार सफल products अक्सर दूसरे रूपों में भी जाते हैं, जैसे Claude Code का Claude Cowork में बदलना और OpenCode का OpenCode Web जोड़ना, लेकिन developer tools की product-market fit को TUI में तेज़ी से test करना आसान है, और दूसरी UI आने के बाद भी बहुत-से users terminal में ही बने रहेंगे
    • vim जैसी बुनियादी चीज़ों के लिए यह ठीक बैठता है, लेकिन लगभग हर दूसरी चीज़ के लिए साधारण command-line tools या web interface बेहतर लगते हैं। इसकी लोकप्रियता का बड़ा हिस्सा शायद इस चाह से आता है कि लोग खुद को 10 terminal windows खोले हुए hacker जैसा महसूस करना चाहते हैं, जबकि असल में वे graphical UI जैसा अनुभव चाहते हैं
    • आज यह पूरी तरह फैशन से बाहर है, लेकिन TN3270 याद आ सकता है। वह streaming से ज़्यादा form-based और keyboard-centric था
      उसे graphical UI में भी आसानी से नकल किया जा सकता था, लेकिन keyboard shortcuts बाद की चीज़ बनकर रह गए
      आज भी ऐसे users मिलते हैं जिन्हें ऐसे पुराने workflows की याद आती है, और वे इसे “पुराना text interface”, यानी TUI, कहकर बताते हैं। ध्यान से सुनो तो वे असल में एक बेहद तेज़, shortcut-केंद्रित flow चाहते हैं। data entry में अहम चीज़ animation नहीं बल्कि speed है
      नए users चमक-दमक पसंद करते हैं, लेकिन अनुभवी लोग उस पर ध्यान नहीं देते
    • TUI ssh पर बिना अतिरिक्त काम के चल जाता है
      terminal की लगाई सीमाओं की वजह से apps आम तौर पर एक जैसे दिखते और एक जैसे चलते हैं। बाहरी दुनिया में user experience standards को, संभव होने के बावजूद, रोज़मर्रा में नज़रअंदाज़ कर दिया जाता है, लेकिन TUI एक तरह से सबसे कम surprise देने वाला sweet spot है
    • TUI की ताकत कुछ जगहों पर है: कम resource usage, mouse पर कम निर्भरता, vi muscle memory से मेल खाने वाली key bindings को ज़्यादा कामों में लागू कर पाना, और ज़्यादा गहरा organization
      TUI tools की वजह से मैं ज़रूरत पड़ने पर अपना ऐसा IDE बना पाया जो दिखाई नहीं देता। guake और yakuake की वजह से उसे छिपाया जा सकता है, और zellij की वजह से projects और tabs के हिसाब से व्यवस्थित किया जा सकता है। आज की तरह कई भूमिकाओं वाले काम के लिए यह बिल्कुल फिट बैठता है
      हालांकि कोई भी इसे polished नहीं कहेगा

  • project maintainer के नज़रिए से बात अलग हो सकती है। project के मालिक और उसे maintain करने वाले लोग issues में Open और Closed के अर्थ तय कर सकते हैं, और users का उनसे सहमत होना ज़रूरी नहीं
    उदाहरण के लिए Open का मतलब “अब तक वर्गीकृत नहीं हुआ” या “इस पर सक्रिय रूप से काम चल रहा है” हो सकता है, और Closed का मतलब “हमने यह ticket देखा, लेकिन अभी टीम का कोई सदस्य इस पर काम नहीं करेगा” हो सकता है
    यानी Closed का मतलब हमेशा “इसे reject कर दिया गया और यह फ़ैसला अंतिम है” नहीं होता; इसका मतलब “यह अभी हमारे काम की सूची में नहीं है” भी हो सकता है। यह सबके लिए सहज न हो, लेकिन अगर इससे project के लोग अपना workload व्यवस्थित कर पाते हैं, तो इसे सही ठहराया जा सकता है

    • gemini-cli कोई volunteer-maintained open source project नहीं है
      Google आम तौर पर accessibility को गंभीरता से लेता है, और अपने ज़्यादातर products के लिए conformance reports भी प्रकाशित करता है: https://belonging.google/accessibility-conformance-reports/

  • मैं इस आकलन से सहमत हूँ। इससे आगे बढ़कर कहूँ तो अगर developers उस CUA, यानी IBM के Common User Access interface standard, का पालन करते और उसे और formalize करते जिससे वे पहले से काफ़ी संतुष्ट थे, तो चीज़ें कहीं आसान होतीं: https://en.wikipedia.org/wiki/IBM_Common_User_Access
    अगर developers अलग-अलग UI configurations के साथ प्रयोग करना चाहते हैं, तो करने दें, लेकिन पीछे एक ऐसा CUA बनाए रखें जिसे मशीन और इंसान दोनों call कर सकें। दुख की बात है कि ergonomics कभी developers की ताकत नहीं रही

  • यह TUI और Windows के बीच का एक अच्छी तरह documented मुद्दा है
    90 के दशक में जब ज़्यादातर SAP systems AS/400 terminals से Windows NT पर गए, तो productivity में बड़ी गिरावट की शिकायतें बहुत थीं
    मैंने SAP में काम नहीं किया, लेकिन मेरी माँ ने किया था, और workflow पूरी तरह tabular और function-key आधारित होने से बदलकर mouse पकड़ने, उसे घुमाने और बहुत click करने वाला हो गया। कई functions में tab navigation और F keys गायब हो गए
    उन्होंने दिखाया था कि ESC ESC F4 F3 TAB TAB से पूरे system में कितनी तेज़ी से चला जा सकता था, और वह असली system भी नहीं बल्कि terminal था
    सार यह है कि Windows-based apps discoverability और नए users के लिए अच्छे हैं, जबकि terminal-based apps तेज़, याददाश्त-आधारित navigation और power users के लिए बेहतर हैं

    • यह किसी खास graphical UI की समस्या है, graphical UI की अवधारणा की नहीं। अच्छे graphical UI frameworks में predictability और keyboard-केंद्रित fast paths पहले से शामिल होने चाहिए, ताकि हर app को यह फ़ैसला फिर से न लेना पड़े
      वास्तव में expert या power users के लिए सफल apps सभी fast paths को ध्यान में रखकर बनाए जाते हैं। Microsoft Ribbon, जिससे लोग अक्सर बेवजह नफ़रत करते हैं, उसका एक उदाहरण है। वह keyboard से चल सकता है, customize किया जा सकता है, और साथ ही discoverable भी है
    • ऐसा कोई कारण नहीं कि वह functionality graphical UI version में बची न रह सके। यह अक्सर user experience design failure होता है, जब system को कभी इस्तेमाल न करने वाले लोग अगला version design करने का निर्देश पा जाते हैं; इसका graphical UI बनाम TUI से बहुत कम लेना-देना है
      graphical UI सिर्फ constraints को ढीला कर देता है, और इसलिए user experience खराब करना और आसान हो जाता है

  • TUI मूल रूप से एक सरल विकल्प होना चाहिए था, लेकिन अब यह terminal की पोशाक पहना हुआ web app बन गया है

    • लेकिन इसमें web की accessibility options नहीं हैं, अच्छा text editing नहीं है, customization options बहुत बुनियादी हैं, और sandbox में चलने के बजाय यह trusted computing environment मांगता है
      यह web app से काफ़ी दूर है, और ज़्यादातर पैमानों पर उससे कहीं बदतर है

  • “text है इसलिए accessible होगा” वाले मिथक की बात करें, तो ऐसा नहीं है। ऐसा मानने वाला कोई नहीं है
    developers ऐसा text documents के बारे में कहते हैं, और शर्तों के साथ grep, cut, ls जैसे single-command terminal apps के बारे में। TUI के बारे में ऐसा कहा गया हो, ऐसा नहीं लगता

  • समस्या declarative UI framework इस्तेमाल करने में नहीं, बल्कि इस बात में है कि इन frameworks के rendering engines accessibility का ख़याल नहीं रखते

    • लेख पढ़ने पर साफ़ दिखता है कि declarative UI भी सही implementation और noise बंद करने के options के साथ संभव है
      लेकिन किसी ने उस पर ध्यान नहीं दिया, और बात बस “terminal है, तो इसे सुंदर बनाते हैं” तक सीमित रह गई
    • क्या terminal में शुरू से ही accessibility support मौजूद है?

  • TUI को बिना window-जैसे elements के फिर से खोजा जाएगा। अभी कम लोग यह समझते हैं, लेकिन यह C64 console की तरह sprite-based हो सकता है। शायद कहीं कोई यह पहले से कर भी रहा हो
    windows और panels को अब विदा किया जा सकता है। शांत text environments 2026 में भी मानव सांस्कृतिक DNA का हिस्सा रहेंगे, और इस medium में अभी बहुत कम खोजबीन हुई है
    आधुनिक web की cognitive aggressiveness मुझे सचमुच उससे भी बड़ा दुःस्वप्न लगती है। images, videos, ads का बिना संदर्भ एक साथ घुला-मिला होना एक बहुत hallucination-जैसा अनुभव बनाता है
 
GN⁺ 2026-05-04
Lobste.rs की राय

  • इस लेख में, कई दूसरे ब्लॉग पोस्टों की तरह, AI-सहायता प्राप्त लेखन की गंध बहुत ज़्यादा आती है
    LLM को इस तरह के शीर्षक पसंद हैं: “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”

    • शीर्षक से ही यह AI से बड़े पैमाने पर बने लेख जैसा लगता है। विषय खुद नया है, इसलिए इसे स्पैम रिपोर्ट करना शायद कुछ ज़्यादा था, लेकिन 1) हर जगह बार-बार दिखने वाली वही शैली अब बर्दाश्त नहीं होती और 2) इससे सामग्री की शुद्धता पर भी शक होने लगता है
      यह एक शानदार ब्लॉग पोस्ट हो सकती थी, लेकिन अगर लगता है कि लेखक ने बस आउटलाइन ChatGPT में डालकर काम खत्म कर दिया, तो इससे पाठक और लेखक दोनों का नुकसान होता है
    • LLM लेखन की सबसे नापसंद विशेषताओं में से एक यह है कि वह “The <जो बिल्कुल स्थापित अवधारणा नहीं है>” जैसी शैली में लिखता है, जिससे वह किसी औपचारिक अवधारणा जैसा दिखने लगता है
      किसी बहुत ही विशेष, एकबारगी समस्या को “क्लासिक” समस्या कहना भी वैसा ही है

  • यह सच में उदास करने वाला है। सार यह है कि Irssi जैसे सुलभ TUI मौजूद हैं, लेकिन आधुनिक TUI framework ऐसी मिसालों को नज़रअंदाज़ करके grid diffing और cursor movement पर निर्भर करते हैं
    screen reader cursor के हिलने पर उस जगह की सामग्री पढ़ते हैं, इसलिए नतीजा पूरी तरह गड़बड़ हो जाता है या बहुत ज़्यादा पढ़कर सुनाने वाला spam पैदा होता है

  • यहाँ दी गई तकनीकी व्याख्या पूरी तरह सही है या नहीं, इस पर संदेह है
    खासकर Ink लंबे समय तक incremental rendering को बिल्कुल support नहीं करता था, और Ink का उपयोग करने वाले ज़्यादातर app अब भी इसे enable नहीं करते। वह incremental rendering भी line-based है, इसलिए यह cursor को असली timer position पर नहीं ले जाता
    Gemini CLI में incremental rendering चालू करने के लिए alternate buffer का उपयोग ज़रूरी है, और built-in screen reader friendly mode चालू होने पर यह disable हो जाता है। संबंधित option का दस्तावेज़ यहाँ है
    जोड़ने की बात यह भी है कि Python का rich/textual, अधिक धीमी और प्रायः single-threaded language पर होने के बावजूद, कई बार Ink से कहीं तेज़ होता है। हज़ारों लाइनों का diff निकालना अनिवार्य रूप से इतना धीमा नहीं होता, और न ही इसमें 10 सेकंड लगने चाहिए
    user experience निराशाजनक और टूटा हुआ है, इस पर संदेह नहीं, लेकिन जो सटीक कारण बताए गए हैं वे LLM hallucination हो सकते हैं या अधूरी जानकारी पर आधारित हो सकते हैं। Ink का incremental rendering, चालू होने पर भी, बताए गए तरीके से काम नहीं करता
    असल में full-screen redraw screen reader को भ्रमित करने की ज़्यादा संभावना रखता है, और line-based redraw से बदलाव से असंबंधित, बेतरतीब टूटे हुए text fragment दोबारा पढ़े जा सकते हैं

  • सिर्फ TUI को दोष देना ठीक नहीं है
    असली समस्या यह है कि लगभग पूरे stack में accessibility support बहुत खराब है
    पहली बात, ज़्यादातर GPU-rendering terminal emulator system-provided accessibility API का बिल्कुल उपयोग नहीं करते। जब text GPU से render होता है, तो accessibility tool उसे “पढ़” नहीं सकते और वह सिर्फ image जैसा दिखता है। Kitty, Alacritty, WezTerm इसी श्रेणी में आते हैं। मेरा terminal Ghostty macOS पर accessibility API से पढ़ा जा सकता है, और iTerm2 तथा Terminal.app भी ऐसा कर सकते हैं
    दूसरी बात, TUI के लिए accessibility जानकारी terminal emulator तक पहुँचाने वाला कोई terminal sequence या standard movement है ही नहीं। terminal cell, run, region के लिए ARIA-जैसी annotation के समकक्ष किसी चीज़ की ज़रूरत है, लेकिन ऐसा कोई प्रयास नहीं है। भले ही TUI cursor को अच्छी तरह संभाले, कई use case में समस्या फिर भी आएगी
    उदाहरण के तौर पर, Ghostty में OSC133 और accessibility API को जोड़कर हर shell prompt, input, command को साधारण text box नहीं बल्कि संरचनात्मक रूप से अर्थपूर्ण element के रूप में उजागर करने का काम किया गया है। इससे पता चलता है कि terminal spec, TUI और terminal emulator—तीनों को साथ में काम करना होगा
    पूरा stack सड़ चुका है, और इसे सच में ठीक करने की कोशिश करने वाले लोग भी लगभग नहीं हैं। मेरे पास भी समय सीमित है, इसलिए मैं बस अपनी पूरी कोशिश कर सकता हूँ, लेकिन यह इतना बड़ा विषय है कि इसमें ecosystem politics तक शामिल है, इसलिए इसे संभालना मुश्किल है
    बोनस के तौर पर, दिलचस्प लेकिन भयानक सच्चाई यह है कि यहाँ AI accessibility सुधारने में मदद भी कर रहा है। बहुत से AI tool accessibility API का उपयोग या दुरुपयोग करके window list पढ़ते हैं और input करते हैं। इसलिए AI use case की वजह से ज़्यादा app अब accessibility integration को कहीं अधिक गंभीरता से लेने लगे हैं

    • terminal सच में छोटा browser बनता जा रहा है

  • Claude Code और gemini-cli के readline-based न होने से मुझे हर दिन गुस्सा आता है
    कुछ मिलती-जुलती keybinding डाली गई हैं, लेकिन परिचित readline shortcut की लंबी tail गायब है
    Anthropic यह मानकर कि “इसे web development जैसा बनाना चाहिए” एक गलती थी, readline से फिर से शुरू कर सकता है
    यह सोचना गलत है कि ऐसे tool बनाने वाले developer के लिए परिचित dev experience, उन tool का उपयोग करने वाले user के लिए परिचित user experience से ज़्यादा महत्वपूर्ण है

    • मेरी समझ में इस समस्या का बड़ा हिस्सा यह है कि Ink असल में rendering backend भर से संतुष्ट है और input widget नहीं देता
      वास्तव में, अच्छी तरह maintain होने वाले चर्चित third-party समाधान भी लगभग नहीं हैं। अगर आपको flexible input box चाहिए, तो आपको शुरू से खुद बनाना पड़ता है
      इसकी तुलना Textual के शानदार Input widget या JS ecosystem की दूसरी library OpenTUI से की जा सकती है
    • क्या readline GNU license के अंतर्गत नहीं है? क्या किसी ने आखिरकार इसका non-GPL version बना लिया?
      मुझे LLM पसंद नहीं हैं, इसलिए UI का खराब होना व्यक्तिगत रूप से मुझे फ़ायदा लगता है, लेकिन readline का उपयोग न करने के पीछे कोई वजह हो सकती है

  • kakoune, helix जैसे terminal editor शायद accessibility मानकों को पार करने में मुश्किल पाएँगे, जब तक वे “cursor छिपाने” जैसी तरकीब न अपनाएँ
    फिर भी, संभावना है कि वे VS Code जितने सुलभ न हों
    VS Code के अलावा कौन-सा सुलभ cross-platform IDE-lite या IDE है? VS Code का धीरे-धीरे अधिक शत्रुतापूर्ण होता रवैया मुझे पसंद नहीं है। JetBrains IDE हो सकता है

    • emacspeak है, जो Emacs के लिए बहुत ही सुलभ interface देता है
      कमी यह है कि Emacs खुद तो cross-platform है, लेकिन TTS की वजह से emacspeak की Linux पर कुछ निर्भरता हो सकती है। या शायद नहीं भी। मैंने इसे Windows पर कभी आज़माया नहीं
    • सबसे पहले यह देखना होगा कि accessibility किसके लिए है। अगर यह बधिर लोगों के लिए है, तो स्थानीय भाषा का text और स्थानीय sign language देनी होगी। अमेरिका में आम तौर पर यह ASL होगी
      अगर यह दृष्टिबाधित लोगों के लिए accessibility है, तो emacspeak या platform के accessibility tool की ज़रूरत होगी
      accessibility एक spectrum है, कोई checkbox नहीं

  • Links में अलग Braille terminal mode है, जो नकली GUI elements को अधिक सरल full-screen menu में बदल देता है और arrow-key navigation को भी line-by-line बना देता है
    एक और दिलचस्प उदाहरण edbrowse है। यह दृष्टिबाधित Karl Dahlke द्वारा बनाया गया text-mode browser है, जो अधिक लोकप्रिय text-mode web browser से अलग TUI का उपयोग नहीं करता, बल्कि ed-style command-line interface का उपयोग करता है

  • अगर यह Ink framework है, तो शायद यही वजह है कि CLI CPU 100% इस्तेमाल करता है, हमेशा के लिए अटक जाता है, और लंबा chat history बार-बार redraw करता रहता है। दुखद है