ハクソク

世界を動かす技術を、日本語で。

テキストモードの誤解：現代のTUIがアクセシビリティにとって悪夢である理由

10時間前原文(xogium.me)

概要

  • ターミナルアプリは自動的にアクセシブルになるという誤解の指摘
  • TUI（Text User Interface）が視覚障害者にとって大きな障壁となる実態
  • CLIとTUIの構造的違いとそのアクセシビリティへの影響
  • 具体例や既存ツールの比較による問題点の分析
  • 改善策と開発者への提言

ターミナル＝アクセシブルという神話

  • 視覚障害者対応としてターミナルアプリが十分だという誤解
  • グラフィックや複雑なDOMがないからといって、必ずしもスクリーンリーダーで読めるわけではない現実
  • Ink（JS/React）、Bubble Tea（Go）、tcellなどのモダンTUIフレームワークがアクセシビリティを悪化させる傾向

構造的欠陥：ストリームとグリッド

  • CLIはストリーム型：標準入出力に沿った直線的・時系列的な表示
    • Speakupのようなカーネルレベルのスクリーンリーダーに理想的
  • TUIはグリッド型：2Dグリッド上に空間的に配置
    • 時間的流れを捨て、座標ベースの情報提示へ
    • スクリーンリーダーが混乱しやすい構造

gemini-cliの実例と問題点

  • gemini-cli（Ink使用）のチャットUIで発生する問題

    • 画面全体の再描画が頻発し、スクリーンリーダーがスパム状態
    • カーソル移動やタイマー更新で、断片的な情報が読み上げられる
    • ユーザー入力が混線し、何を入力しているのか把握困難

  • Windows（NVDA）での障害：

    • SSH接続やテキスト貼り付け時に即座にクラッシュやシステム不安定化
    • 状態変化ごとに全履歴再描画、履歴が多いほど負荷増大
    • insert+5（動的変化の読み上げ抑制）でも回避不可

パフォーマンス劣化とラグ

  • Inkなどのシングルスレッド環境で履歴増加時の大幅な遅延
    • 大量テキスト貼り付けで数秒単位のラグ
    • 入力反応が極端に遅くなる現象

既存ツールとの比較：なぜnano、vim、menuconfigは許容されるか

  • nanoやvimではカーソル非表示設定が可能

    • カーソル追従をオフにしなければスクリーンリーダーが座標情報ばかり読み上げる
    • 視覚的ノイズ抑制で文字入力の読み上げが可能に
    • モダンフレームワークにはno-cursor/headlessモードがほぼ未実装

  • menuconfigは単一カラム集中型

    • 縦リストにカーソルを固定し、空間的混乱を最小化
    • IrssiはVT100スクロール領域活用で履歴と入力行の干渉を抑制
      • ハードウェア機能を利用し、全画面書き換えを避ける
      • 現代的フレームワークは画面全体のdiff・再描画を選択しがち

アクセシビリティ問題の放置と無視

  • Googleやgemini-cliメンテナによるアクセシビリティ課題の放置
    • Issue #3435, #11305などが議論もなく放置
    • Issue #1553は自動Botでクローズ、「古いから閉じます」という形式的対応
    • 未解決のままクローズ＝証拠隠し・実害放置

結論・開発者への提言

  • ターミナル向けアプリ開発時は、TUIフレームワークの安易な利用を再考
  • カーソル非表示やシンプルなストリーム表示が本質的なアクセシビリティ向上
  • スピナーやタイマーの頻繁な再描画に依存する設計は避けるべき
  • 視覚障害者にとっては、単純なCLIストリームの方が遥かに優れている

Hackerたちの意見

宣言型UIフレームワークを使うこと自体が問題じゃなくて、これらのフレームワークが出力するレンダリングエンジンがアクセシビリティを考慮してないのが問題だと思う。
└
ターミナルにはアクセシビリティサポートってあるの？
└
記事から明らかだと思うけど、宣言的UIは正しく実装すればできるし、ノイズを無効にするオプションも必要だよね。明らかに、誰もそのことを考えていなかったみたい。「ターミナルを作るけど、見た目を良くする」って感じだった。
> 現実は違う。ほとんどの現代のテキストユーザーインターフェース（TUI）は、悪くコーディングされたグラフィカルインターフェースよりもアクセシビリティに対して敵対的なことが多い。Claude CodeのレンダリングUIが、TUIがコマンドラインインターフェースというよりはDOSやBorlandのUIシステムに近いことに気づいた最初の場所だった。CLAUDE_CODE_NO_FLICKER=1の設定をいじってるときに、このTUIが何なのかを理解したんだ。ターミナルコードで重なって表示されるレイヤーの集まりなんだよね。ReactのInk Terminal実装を読んでみたんだけど、昔のWordperfectやWordstarみたいに見えるのが面白い。視覚障害者にとっての使いやすさはほぼ同じだけど、DOSツール用のブレイルパッド（80x25）は、後に出てきたすべてのスクリーンリーダーよりもずっと使いやすかったのを覚えてる。
TUIはシンプルな選択肢になるはずだったのに、今やターミナルのコスチュームを着たウェブアプリになっちゃった。
└
...ウェブのアクセシビリティオプションがなくて、良いテキスト編集もなく、非常に基本的なカスタマイズオプションしかなく、サンドボックスで動くのではなく信頼できるコンピュートを要求する... ウェブアプリからは遠く、ほとんどの面でずっと劣ってる。
TUIの人気にはずっと不思議を感じてる。私にとって、ターミナルの力はストリーミングモデルにある。コンポーザブルユーティリティはGUIではあまり一般的じゃないからね。ターミナルの制約がTUIのデザインをツールの目的にもっと集中させることは理解できるけど、それがそんなに魅力的なポイントだとは思わない。
└
vimみたいな基本的なものには問題なく動くけど、他のほとんどのことには普通のCLIツールかウェブインターフェースの方がいいな。多くの人気は、10個のターミナルウィンドウを使ってハッカー気分を味わいたい人たちから来てると思うけど、実際にはGUIみたいな体験を求めてるんじゃないかな。
└
コマンドラインシェルには、プログラム間でテキストをパイプできる利点があるよね。TUIはコマンドラインシェルから実行できるし。だから、ターミナルに近いところで作業しながら、GUIの利点（例えば、発見性）を得られるんだ。もし「コマンドを実行して、コマンドを編集して、また実行する」なら、コマンドを実行しているターミナルから編集するのが合理的だと思う。（対照的に、VSCodeみたいなツールでは、ターミナルが画面の一部を占めることが多くて、フルスクリーンに切り替えることはあまりないと思う。そして、開発者は大きなモニターが必要だと言うんだよね。）それに、キーボード操作のプログラムはGUIよりもTUIの方が一般的な気がする。例えば、magitやlazygit、lazydocker、k9sとかね。
└
リモートサーバーやVM、コンテナで作業する時にはすごく便利だよ。Xフォワーディングよりもずっと便利で堅牢だし。
└
コンテナやサンドボックスで簡単に実行できるから好きだな。
└
私にとっては、主にターミナルにいる便利さかな。住んでる場所だし、SSH経由で使えるし、通常のブラウザベースのUIではキーボードの使い勝手が後回しにされがちだけど、TUIはその点を考慮して作られてるからね。他のGUIの選択肢は、ブラウザ（サンドボックス、明らかに、個人用の小さなツールには向かない）、ネイティブ（TUIやブラウザ、Electronに比べて簡単ではない）、それかElectronみたいなもの（無理無理笑）を探してるわけじゃないけど、でも新しいペインを開いてlazygitを実行するのはめっちゃ簡単なんだよね。人が後ろを通るとき、すごくカッコよく見えるし。
└
1) TUIはSSH経由で特別な手順なしに動く。2) ターミナルによって課せられる制約が、すべてのアプリをほぼ同じように見せたり動かしたりする。外の世界では、UXのために発展した基準が、できるからという理由で日常的に無視されてる。TUIは言ってみれば、驚きが最小限になる最適な状態にあるんだ。
└
Claude CodeやOpenCode、Crushなどの新しい波のTUIについては、コンポーザビリティやテキストストリーミングの話じゃないんだ。基本的にはいくつかの追い風の組み合わせだね。1. ターミナルで作業するエンジニアのコミュニティがすでに大きめに存在してる（Vim/Neovim/tmux/zellijなどのユーザー）。多くのエンジニアリングタスクはターミナルでスクリプトを実行することで達成されるから、そこでできるだけ多くの作業を移すのは理にかなってる。これにより、ターミナルで動く開発ツールにアプローチできるユーザーがいる。2. その人たちが気にするプラットフォーム、つまりmacOSとLinuxの間でのクロスプラットフォーム配布は、パッケージマネージャーのおかげでほぼ解決済み。クロスプラットフォームのネイティブアプリの配布は、せいぜい断片的。3. 現代のTUIを構築するのがずっと簡単になったのは、上記の需要と配布の勝利のおかげで、ビルディングブロックに対する需要が高まって、Ink for ReactやBubble Tea for Goなどの良い選択肢がたくさん生まれたから。4. デスクトップGUIに対する開発者の一般的な嫌悪感：Electron。正当な理由があるかどうかは別として、遅くて膨れ上がったアプリケーションと結びつけられている。Electronを使わない場合、クロスプラットフォームの何かを作るのは、TUIアプリをサクッと出すよりもずっと難しい問題になる。成功した製品は最終的にそのギャップを越えるようで、Claude CodeがClaude Coworkを生み出したり、OpenCodeがOpenCode Webを追加したりする。でも、TUIを使った開発ツールで市場適合性をテストするのは、もっと簡単で早い。あなたのユーザーの多くは、他のものを立ち上げた後もそこに留まるだろうね。
└
開発者としての私の経験（シンプルさを好む）：- デフォルトはCLI - GUIが必要だけどローカルシステムにアクセスできない場合：ウェブ - ローカルシステムにアクセスできる（制限された）GUIが必要な場合：TUI - それ以外の場合は、ローカルウェブサーバーを立ち上げるか、他に何も機能しないならGUIツールキットを使う。
└
今は完全に時代遅れだけど、TN3270を思い出してみて。ストリーミングではなく、フォームベースでキーボード主導だった。これをGUIで簡単に模倣できるけど、キーボードショートカットは後回しにされがち。今でもその古いワークフローを懐かしむユーザーに会うことがある。でも彼らはそれを「古いテキストインターフェース」、つまりTUIとして表現する。彼らの話を聞くと、彼らが求めているのは超高速でショートカット駆動のものだとわかる。データ入力をしていると、スピードが大事で、アニメーションなんていらない。初心者は目を引くものが好きだけど、ベテランはもう気にしなくなってる。
└
>「TUIの人気にはずっと不思議に思ってた。俺にとって、ターミナルの力はストリーミングモデルにあるんだ。Emacsとか、Vimとか、Muttとか、Borlandの古いIDEとか使ったことある？ターミナルの力は、どこでも使えることや、リモートシステムへの簡単な接続、そしてTUIアプリにもあるような無駄なGUIのごちゃごちゃがないことにもあるんだ。」
これらのトレンディなTUIを調べれば調べるほど、状況は悪化するばかりだ。まるで開発者たちがプログラミングの黎明期からの最悪のプラクティスをすべて集めて、一つの扱いにくい、重すぎて、性能も低いゼラチン状の塊にまとめ上げたみたい。
└
それはターミナルUIじゃないよ。ターミナルでWindows（などの）GUIを持っているかのように見せかけようとした試みだね。Windowsが一般的じゃなかったり、十分良くなかった頃にDOS用に作られたものと同じだ。だから、失敗しているのは驚かないよ。実行しているターミナルの能力を理解せずに作られたものだし。
この評価には同意するな。さらに、開発者が満足度の高いCUA（IBMの共通ユーザーアクセス）インターフェース標準を守って、それをさらに整備すれば、もっと楽になると思う。もし開発者がいろんなUI設定を試したいなら、やらせてあげればいいけど、機械と人間の両方が呼び出せるCUAをバックグラウンドに置いておくのがいいよね。（残念ながら、エルゴノミクスは開発者にとって強みではないけど。）
これはよく知られた問題だよね、TUIとウィンドウの違い。90年代にほとんどのSAPシステムがAS/400ターミナルからWindows NTに切り替わった時、人々は生産性が大幅に低下したって報告してた。私はSAPで働いたことはないけど、母がやってた。基本的に、彼女は完全に表形式で、ファンクションキーを使ったワークフローから、マウスを持って動き回ってクリックするスタイルに変わったんだ（タブやFキーは多くの機能で失われた）。彼女はESC ESC F4 F3 TAB TABで、システム全体を超高速で移動できる方法を見せてくれたんだ。しかも、これはターミナルであって、実際のシステムじゃない！要するに、Windowsベースのアプリケーションは発見性や新しいユーザーに最適で、ターミナルベースのアプリケーションは速く、記憶に基づくナビゲーションやパワーユーザーに向いているってことだね。
└
それは特定のGUIの問題であって、GUIという概念の問題じゃないよ。良いGUIフレームワークは、予測可能性やキーボード操作の速いパスを考慮して作られるべきで、デフォルトでこれを含めておくべきなんだ。そうすれば、各アプリごとにこれらの決定をする必要がなくなるから。実際、プロフェッショナルやパワーユーザー向けの成功したアプリケーションは、速いパスを意識して作られているよ。Microsoftのリボンも、理由はわからないけど結構嫌われているけど、キーボード操作ができてカスタマイズ可能で、同時に発見性もある例だよね。
TUIアプリケーションのアクセシビリティをテストするためのおすすめはありますか？記事ではspeakupが言及されていますが、私の理解では、それを使うにはハードウェアシンセサイザーが必要です。それに加えてorcaも使えるのでしょうか？
TUIのハッカー美学、特にコーディングエージェント周りは否定できないし、ほとんどのシェル（リモートでも）で動かせるのはいいよね。でもUXは？もし目的が、これらのエージェントが生成するコードの一行も読まないことなら、それがポイントかもしれないけど、そういう場合は問題ない - プロンプトを入力して、祈るだけ。読んだり変更したりする必要がある場合は、ある種のIDEが必要になる。TUIでワークフローを構築できないとは言わないけど、たくさんの人がそうしてる。でも、フルデスクトップアプリケーションほど良くて柔軟ではないんだ。
>「神話的なこと、テキストだからアクセス可能だ。」 視覚がある開発者の間には、持続的な誤解がある：アプリケーションがターミナルで動いているなら、それは本質的にアクセス可能だ。違う、誰もそんなこと信じてない。開発者はテキストドキュメントについてはそう言うけど、それはまったく別の話で、ターミナルの単一コマンドアプリ（grepやcut、lsなど）については条件付きで言う。TUIについては誰もそんなこと言わない。