ハクソク

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

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

2026年5月4日原文(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を実行するのはめっちゃ簡単なんだよね。人が後ろを通るとき、すごくカッコよく見えるし。

Hacker Newsで議論の続きを見る