この技術でできること
- スクリーンリーダー（音声読み上げソフト）を使う視覚障害者でも、 意味を理解して迷わず操作できるUI を提供できる
- マウスを使わずキーボード（Tabキー等）だけでも、 すべての機能（モーダル、ドロップダウン含む）にアクセス できるようになる
- クローラー（Googleなどの検索エンジン）がページ内容を正確に解析でき、 結果としてSEOも向上 する
例 : トグルスイッチをデザインした時、「見た目だけスイッチに似せた div タグとCSS」で実装すると、スクリーンリーダーにはただの「文字がない箱」と認識されます。エンジニアが正しい button 要素を使い、aria-pressed="true/false" などの属性を適切に実装（セマンティックHTMLとARIAの活用）することで、マシンはそれが「今はONになっている切り替えボタン」だと正しくユーザーに読み上げることができます。
なぜ難しいか
ブラウザが「間違った（標準に準拠していない）コード」を書いても、 見た目上はなんとなく動いて表示してしまう からです。
エンジニアが <div> タグにJavaScriptでクリック判定とカーソル変更スタイル（cursor: pointer）をあてれば、見た目は完全に「ボタン」になります。健常なユーザーも普通にクリックできます。しかし、それは「見えている人」や「マウスを使える人」だけの話であり、目に見えない「システム側からの解釈」は完全に欠落しています。表面的な見た目を急いで再現することに囚われると、構造の品質（セマンティクス）が犠牲になります。
実装でUXに効くポイント
1. セマンティックHTML（意味のある構造のマークアップ）
見出しには h1 h2、区切りには section、ナビは nav、ボタンは button と、役割に合ったタグを厳密に使います。
- たったこれだけで、多くのアクセシビリティツールは自動的にフォーカス位置を調整し、意味をユーザーに伝えてくれます。
2. フォーカス制御（キーボード操作の担保）
Tabキーを押してフォーカス（選択状態）が移動した際、「いまどこにいるか」の輪郭線（アウトライン）を消さずにデザインに馴染ませて表示します。
- さらに「モーダルを開いたらフォーカスをモーダル内に閉じ込める」「閉じたら元のボタンにフォーカスを戻す」といった、キーボードユーザーが迷子にならないための見えない動線設計（フォーカストラップ等）が必要です。
3. WAI-ARIAによる「状態」の翻訳
セマンティックHTMLだけでは表現しきれない複雑なUI（カルーセルや、開閉するカスタムセレクトボックス等）に対して、「これは今開いている（aria-expanded）」、「これは必須項目だ（aria-required）」という情報を付与する属性群（HTMLだけで足りない状態情報を機械に伝えるもの）です。
- これにより、コードとスクリーンリーダーの間に橋が架かり、複雑な非同期UIの現在状態が音で伝わります。
やりすぎ / 足りなすぎ（トレードオフ）
状況例: ARIA属性の過剰な付与
Before（悪い例） :
「アクセシビリティを完璧にしたい」と考えたエンジニアが、すべての div 要素に role="button" や aria-label="クリックしてください" などを過剰に書き込む。
結果 : スクリーンリーダーの読み上げ情報がノイズだらけになり（「クリックしてくださいボタン、クリックしてくださいボタン…」）、本当に伝えたい機能が埋もれてかえって使えなくなる（WCAG：Webアクセシビリティの国際的なガイドライン の第一ルール「No ARIA is better than bad ARIA」違反）。
After（現実的な落とし所） :
無理に装飾的なカスタムUIをARIAで補強するのではなく、まずはHTML標準タグ（ネイティブの <button> や <dialog>）を使って書き直す。
代替手段への配慮 : デザイン側も、「どうしても標準タグで実現できない特殊な見た目のUI」をあきらめ、システムが自然に持つコンポーネントの挙動にデザインを歩み寄らせる。
運用で崩れるポイントと衝突（デザイナー × エンジニア）
❌ 「フォーカスの青い枠線がデザインに合わないから、CSSで全部消して」
デザイナーの視点 : ボタンをクリックした後に残る太い輪郭線（デフォルトの outline）が、ブランドの美しい世界観を壊している。フォーカス枠は全部 outline: none で隠すべきだ。（品質＝ビジュアルの美しさとノイズのなさ）
エンジニアの視点 : デフォルトの輪郭線を消すと、キーボードで操作しているユーザーが「自分が今どこを選択しているか」完全に失い、プロダクトが操作不能になる。消すのは明らかなアクセシビリティ違反だ。（品質＝あらゆるユーザーへの機能到達性）
なぜ衝突するか（品質の定義差） : デザイナーは「マウスやタッチ前提の視覚面」を優先し、エンジニア（a11y意識の高いエンジニア）は「キーボードユーザーの生存線」を守ろうとするためです。
どう合意するか :
- フォーカスリングを「単に消す」のではなく「ブランドカラーに合わせた美しい見せ方のフォーカス（
:focus-visible等の活用）」をシステムデザインとして定義し直す。 - デザイナー自身がTabキーだけでサイトを巡回し、フォーカス状態がないことの絶望感を体験する。
実践チェックリスト
最低ライン（Must）
[ ] デザイン上で「キーボードフォーカスされている状態（Focus表示）」のスタイルを定義している
[ ] 意味のあるボタンやリンクを、見た目重視のために不適切なHTMLタグ（div 等）で実装させていない
[ ] フォームの入力エラー等が、色（「赤くなります」等）だけでなくテキストでも伝わるよう設計している
理想ライン（Better）
[ ] 「スクリーンリーダーでこのUIをどう読み上げるべきか（aria-label）」をFigma等に申し送りしている [ ] 複雑なオリジナルUIを作る場合、最初からキーボードでの操作手順（Tab移動や矢印キーの挙動）を設計に含めている
関連技術
前提となる技術
- コンポーネント設計 — コンポーネントを綺麗に分割することが、アクセシビリティ担保の始まり
次に学ぶ技術
- テスト戦略 — アクセシビリティは人力だけでなく、多くの部分をLighthouse等の自動テストで検知・保証できる
まとめ
- この技術の本質 : 視覚情報だけに依存せず、機械（ブラウザ・支援技術）を通して情報の意味を正しく伝達する構造
- UXへの影響 : 障害の有無に関わらず、あらゆる環境（屋外の眩しい光、通信制限、音声環境等）での快適な体験を担保する
- 実務での判断軸 : 「Figmaで作ったこの美しいUIは、画面を見ずにキーボードのTabキーと音声だけで操作できるか？」
- 次に学ぶべき技術 : テスト戦略（この品質をどうやって落ちないように仕組み化するかを学ぶ）
目的別のおすすめ :