この記事の途中に、以下の記事の引用を含んでいます。
What’s in a Button?
たかがボタン、と思ったら大間違い──本質を問う鋭い指摘
この記事が語っているのは、一見シンプルに見える「ボタン」というUI要素に潜む、設計・実装・アクセシビリティの基本と落とし穴です。
筆者（Brent Royal-Gordon氏）は、GUI制作の細部にこだわる現場目線から、「ボタン」一つすら、思った以上に多くの要件や配慮が必要だと説きます。
全体のトーンはやや辛口ですが、だからこそ表層だけの「とりあえず動くボタン」を量産しがちな開発者に対して、目からウロコの気づきを投げかけてくれる記事です。
「見た目」ではなく、「体験」に本質あり ── 著者の問題提起
まず著者は、GUI（グラフィカル・ユーザー・インターフェース）の基本要件に人々が無自覚であることを、辛辣にこう表現しています。
“being a GUI has some basic requirements and ‘draws to the screen’ is not the interesting one. The bar is about 20cm off the floor but everyone forgets to jump.”
要するに、「画面に表示される」だけではGUIとしては最低限どころか、本質的な要件に届いていないこと、そしてそれがまるで最低地上高のバーにすら届いていないのに多くの人が「ジャンプする」ことすら忘れている、と比喩的に言っているのです。
また、実験的にHTML/CSSでボタンUIをゼロから作る中で、クリックしたときにダイアログを出すように実装しますが、指摘したいのは技術的なベストプラクティスではなく「どのような配慮・工夫が求められるか」である、と述べています。
試行錯誤！実際に「ちゃんとしたボタン」を作ろうとすると何が起きる？
1. マウスでクリックできても、指じゃ反応しない!?
たとえば、著者は次のような問題点を指摘しています。
“I made it work if you click the button with a cursor, but not if you tap it with a finger.”
ここで言いたいのは、PCのマウス操作で動くものも、スマートフォンやタブレットの指タップにはそのまま対応しない、という問題です。
Web開発などでありがちですが、「clickイベント」だけでなく「touchイベント」にも配慮せよ、という気づきです。
2. ドラッグキャンセル（押して離す前に指をずらしたらキャンセル）は？
さらに、「ドラッグキャンセル」（pointer cancellation）の実装についても、単純にmousedownやmouseupイベントを追うだけでは実現できません。
“This behavior can’t be provided with only one of ‘mouse down on my UI element’ and ‘mouse up on my UI element’; you need both, or some higher-level operation.”
最先端のWebブラウザなどでは「clickイベント」一発で全部まとめて面倒をみてくれるものの、「自作」でUIをゼロから組もうとすると往々にしてこういった細かい落とし穴にはまります。
3. キーボード操作・アクセシビリティ対応は？
続いてはキーボードナビゲーション。
“desktop OSs let you tab between all the interactable items in a window — not just form fields, but everything you might need to interact with.”
つまり、マウスを使わずTab／Shift+Tabなどで全ての操作可能UIを巡回できること。
これを担保しないボタン設計は、実質的に多くのキーボードユーザーや障害者ユーザーを排除します。
また、フォーカス時にはリング表示（outline）などの視覚的補助も必須。
加えてスクリーンリーダーでも伝わるラベルづけがされているか、といった点も見落とせません。
実際、
“We used an icon with no alt text, so the user has no idea what this button does…label / ‘accessibility label’ to be different from the displayed text”
のように、アイコンだけのボタンでは、視覚障害者には意味が伝わらないことを指摘しています。
4. キーボード・ショートカットの世界
また、実はシステムの多くのボタンは、メニューと同様にAltやCmdなどのキーと連携したショートカット操作が可能です。
とくにパワーユーザーはReturn、Esc、Ctrl+Deleteなど、ショートカットで瞬時に操作することが習慣化している場合も多いです。
システム提供の「標準UI部品」には40年分の知恵が詰まっている
ここまで実装要素ごとの問題点ばかり挙げてきましたが、著者はこうも断言します。
“We don’t need to do any of this. We can start with a system-provided button: And then customize it to do our own drawing. […] We and the web browser agree that it’s a button, and we get most of what we discussed for free. ”
つまり、OSやフレームワークが用意した「標準のボタン」を使えば、Accessibilityからキーボード操作、ドラッグキャンセルやVoiceOver対応まで「最初からセット」になっている。
そこに上書き（カスタマイズ）して見た目や一部の挙動にだけ個性を加えればよい、というのです。
著者は繰り返し、「独自UI要素をゼロから作ることには、膨大な作り込みや検証が必要」という現実を指摘しています。
これには、アクセシビリティ専門家やUI設計歴の長い現場エンジニアの多くが共感することでしょう。
また、次のような根本的な示唆も述べています。
“we, as an industry, have had 40 years to establish what desktop GUIs are like, over 30 to establish what web pages are like, and nearly 20 to establish what mobile GUIs are like. […] you might not even know what you’re omitting when you diverge from conventions. Which translates to people being frustrated with your app or web page, or in the worst case not being able to use it at all.”
開発者が「自分がたまたま気づいたことだけ」「自分の手元で動けばOK」と思っていると、ともすればマイノリティの利用者や状況への配慮が完全に抜け落ち、ユーザー体験の大きな毀損or排除につながると警鐘を鳴らしています。
本当に使われるアプリ／サービスを作りたいなら、何を意識すべきか？
この記事を受けて私が強く感じたのは、
「UIパーツを“動けばいい”では絶対に設計してはいけない」
という価値観の重要性です。
たとえば小さな個人開発プロジェクトでよく陥りがちなのが、「他のページからコピペしたボタン実装」を流用し続け、アクセシビリティ対応も見た目優先も二の次になるパターンです。
その結果、「色弱の人には判断できない配色」「画面リーダーで操作不能」「実はスマホでタップが効かない」…といった地雷がそのままリリースされてしまうのです。
筆者が最後に述べている
“the lesson is simple: if you want to customize a UI element, start with a standard one and change how it draws, rather than building one up from scratch and trying to match the system in every little way.”
は、まさにここ数年のフロントエンド開発における不文律のような金言です。
UIフレームワークが進化した現在でも、標準ボタンを「ちゃんと」使うことで得られる恩恵（標準化されたアクセシビリティ、利用者習慣との整合性、将来的な保守容易性）は、何よりも無視できないものです。
【結論】「独自要素を積み上げるより、標準を賢く使え」という示唆
ボタン一つ、されどボタン。
この記事は、日頃シンプルなUIパーツだと思われがちな「ボタン」も、深く考察すればユーザー体験全体に通ずる重要な設計課題が詰まっている、と示してくれました。
現代のWeb開発やアプリ開発において
– 「〇〇さんには見えているけど、□□さんには見えていない（伝わらない）UI」
– 「（開発者が）気づけない破壊的欠陥を、数十年の間に積み上がった“標準UI”ならカバーできる」
– 「独自実装で完璧に振る舞わせる苦労を選ぶより、“最初から賢くサボる”」
という価値観は、エンジニアだけでなくプロダクト全体のチームに浸透すべきものだと強く思います。
そして、たとえ標準部品に寄りかかっても「なぜそう作られているか」「欠落しうる要素は何か」には常に想像力を働かせてほしい、ともいえるでしょう。
本記事を一読した皆さんには、ぜひ
– UIの設計実装では「ゼロから組み上げるより、標準から始めて賢く拡張」
– ユーザー数や多様性（障害者、高齢者、環境依存…）を前提に「本質的体験」を忘れない
という2つのポイントを、ぜひ心の隅に留めてほしいと思います。
categories:[technology]
コメント