GUIは完全なキーボード操作に対応できるべき

キーボードアクセシビリティは、一般的なアクセシビリティと同様に、しばしば無視されたり完全に忘れられたりするものの一つです。面白いことに、前者は通常後者から派生するものです。

責任の一端は人気のあるUIフレームワーク（またはそのようなものを避けることを選んだ開発者）の肩にあります。古いフレームワークはこれをかなり簡単にする傾向があります。例えば、Cocoa/AppKit（MacネイティブUIフレームワーク）では、ほぼ視覚的に全体のUIを適切なキーボードナビゲーションに配線することができます（主にコントロール間でnextKeyViewアウトレットを接続して、タブフォーカスを通る論理的なチェーンを生成するだけです）。キーショートカットの定義も簡単です。コマンドのメニュー項目を追加し、対応するショートカットを設定するだけです（これにより、ユーザーはシステム設定で自由にショートカットを再バインドできます）。

残念ながら、そのような設計は新しいフレームワークでは好まれなくなりました。新しい好ましいスタイルは、開発者がどの部分を埋めるかを選択するワイヤーフレームであり、多くの場合、最も基本的なものだけが採用されます。

パワーユーザーエクスペリエンスは、一般的なユーザーエクスペリエンスと同じではありません。すべての開発者ツールがキーボード駆動であるべきという主張をしたいなら、どうぞご自由に。しかし、ほとんどの人はキーボード駆動のGUIの学習曲線を受け入れる気はなく、それはそれで構いません。強制すべきではありません。

HNがすべてのユーザーがArch Linuxの効率重視の完璧主義者ハッカーであるかのように振る舞うのは、痛々しいほど気取っています。

（これは意図したよりも厳しい言い方になってしまいました。すみません。Arch Linuxの人々は大好きです。ただ、平均的なユーザーにサービスを提供することは、パワーユーザーのための完璧なツールを作ることと同じくらい立派だと思います。）

しかし、GUIがキーボード駆動であるとはどういう意味でしょうか？

明白な方法は、すべてのアクションに単にショートカットを割り当てることです。

私の反論は、それは本当にキーボード駆動ではなく、単にキーボード互換であるということです。発見可能性の問題があります。現在のベストプラクティスは、ボタンのショートカットをツールチップ、メニュー項目、または別のショートカットを押したときに表示することのようです。

私は、ボタンはキーボードとは根本的に不一致だと思います。キーボード駆動のUIにはボタンがあるべきではありません。

問題は、CLIやTUIのような真にキーボード駆動のUIは発見可能性がひどく、それがマウス駆動のUIがそもそも存在する理由です。では、マウスでクリックするのと同じくらい直感的なキーボード駆動のUIを持つことはできるでしょうか？

最後にCRUDアプリを作ったとき（たぶん24年前くらい）、私はこれをやろうと心に決めました。給与計算の人々がターミナルモードのVAX VMSアプリケーションを、コマンドラインの技術に精通したUnix管理者が顔を赤らめるほどの速さと器用さで操作しているのを見て、「そうか、90年代のポイントアンドクリックGUIはすべて間違っていたんだ。仕事でシステムを頻繁に使う必要がある人々は、発見可能性と引き換えに器用さを失うような簡単な学習曲線よりも、学習曲線の後に速度、快適さ、器用さを得る方を好むだろう」と思いました。

それはウェブアプリフレームワークでしたが…すべてのブラウジング/リスト画面には行IDとフォーカスされたテキストボックスが含まれており、行IDを入力してEnterを押すと選択できました。すべてのアクションボタンには、どのCtrl+Shiftホットキーがトリガーされるかを示す下線がありました。すべての編集画面は最初の編集可能なテキストボックスにフォーカスがデフォルト設定され、マウスは実際には必要ありませんでした。最後に、読み込み時間は75msを目標に最適化されました。

面白いことに、ユーザーフィードバックは「キーボード操作はかなり良いですが、もっと速くしてください」というものでした。

私がクロームだと思っていたものが、ユーザーが不幸にならないために重要だったのです。

同意しますが、キーボードで使えるだけでは不十分だと思います。なぜなら、ショートカットは発見して覚えるのが難しいことが多いからです。理想は、良いTUIのように、GUIがキーボードでナビゲートする方法の明白なヒントを画面上に表示することだと思います。

一般的なプラットフォーム（ウェブを含む！）向けに、これを念頭に置いて設計され、一般的なアクションの一般的なショートカットについて意見を持ち、標準化できるようなGUIフレームワークがあると本当に素晴らしいでしょう。

著者は優れた点を指摘しています。TUIを持つためだけに作られた貧弱なターミナルUIが多すぎます。これらはしばしば十分に構築されておらず、効果的/生産的であるための十分な思考が欠けています。

しかし、GUIアプリのより広いトレンドは、キーボードユーザーに生産性を提供することではなく、市場シェアをターゲットにすることでした。80年代と90年代、PhotoshopやIllustratorなどは、プロフェッショナルが強力なキーボードショートカットの配列を使用して非常に効率的に作業できるようにすることに焦点を当てたため、今日のパワーハウスになりました。2026年、ソフトウェア企業がKPI炎上で瀕死の状態であり、魅力的なサブスクリプションモデルを作成して顧客を引き込むことで製品管理を評価しているとき、キーボードユーザーに実際に生産性を提供することへの注意はしばしば後回しにされています。モバイルアプリにはキーボードショートカットがなく、デスクトップアプリはますます狭い「エッジケース」として扱われ、モバイルデバイスで利用可能な数十億人に対して、わずか数億人のターゲットユーザーしかいません。キーボードショートカットの力を活用してGUIを高度に生産的で、キーボードから包括的に使用可能にすることで価値を提供することに真剣に取り組む人々にとって、これは機会です。すべての欠点にもかかわらず、MicrosoftはVSCodeでこれを正しく行いました。

> 実際、多くのGUIフレームワークのアプリケーションガイドラインは、GUIアプリケーション開発者に明示的に奨励しています

代わりに、ユーザーが開発者を迂回できるように（少なくとも）フレームワーク一貫性のある方法でエンジニアリングされるべきです。なぜなら、開発者が集合的に「キーボードに精通」する時が来ることは決してないからです。

最近、拡張QWERTY MIDIコントローラーアプリを作ったときに啓示を受けました。そのアプリは、修飾キーが押されたときを含むすべてのキーの状態と機能を常に表示します。

これはソフトウェアを設計する素晴らしい方法だと思いました。キーボードショートカットをすぐに知ることができるからです。なぜなら、すでにそれらを見ているからです。私は、QWERTY MIDIキーボードコントローラー（ハンマースプーン上に構築）のために構築したものを、あらゆる種類のアプリのための単なる汎用インターフェースにしようと取り組んでいます。

最終目標がキーボードショートカットを介してアプリをナビゲートして制御することなら、それをGUI自体の設計に組み込んでみてはどうでしょうか？

私のプロジェクトに興味があれば：https://github.com/mattdanielmurphy/qwerty-midi-hammerspoon

完全に同意しますが、これは主に「オタク」のものだと思います。私は個人用Linuxでi3を使用し、仕事用Macでaerospaceを使用しています。ブラウザではvimium、他のアプリではNeru（Neruと同様のことを行う）を使用しています。最近、Electronアプリ用のユーザースクリプトを作成する方法を見つけ、それ以来、どこでもvimium風の拡張機能（Teamsなど）を追加しています。

これがデフォルトであればいいのにと思いますが、同時にUIをナビゲートするためのより標準的なものがあればいいのにと思います。だからこそ、vimiumや他の同様の拡張機能が本当に好きです。それは、ウェブサイトごとに誰かのナビゲーションのアイデアを学ぶのではなく、viのロジックをウェブサイト全体に適用しているからです。