はじめに
このシリーズでは、HTMLに書いた意味がDOM、Accessibility Tree、Platform Accessibility APIを経由して支援技術へ届く仕組みから、Shadow DOMのカプセル化、Fluent UIやTabsterのようなライブラリが担う複雑な操作、そしてaxe-coreやDevTools、スクリーンリーダーがそれぞれ異なる層を検証することまで見てきました。
前回の第5回では、GitHub CopilotなどのAIが、どんな情報やツールにアクセスできるかによってレビューできる範囲が変わることを考えました。今回はシリーズの最終回として、少し視点を引いてみます。
ある機能が完成し、リリース直前にアクセシビリティレビューを行ったとします。そこで、キーボードだけでは操作できない、フォーカスが迷子になる、情報設計が複雑すぎる、操作順序が理解できない、画面に出てくる用語が分かりにくい、といった問題が見つかりました。
ここで、ひとつの問いが浮かびます。
なぜ、aria-labelを追加しても解決しないのでしょうか。
1. 「アクセシビリティ対応をお願いします」が遅すぎる理由
開発現場では、次のような順番になってしまうことがあります。
設計
↓
実装
↓
完成
↓
アクセシビリティ対応
この流れでは、最後のレビューが「画面に名前がない」「コントラストが足りない」といった局所的な確認にとどまらず、画面全体の前提を問い直す場になりがちです。誰が、何を達成するために、どの順番で操作するのか。そこで合意したはずの情報設計や操作モデルそのものに、変更が必要だと分かるからです。
アクセシビリティを「最後に足す機能」と考えると、最後に見つかった問題を、最後の工程だけで直そうとしてしまいます。しかし、WCAG 2.2の達成基準は、特定の技術に依存しない検証可能な成果として定められています。基準を満たすために何をどう設計するかは、画面や技術の選択と切り離せません。
W3CのAccessibility Principlesも、情報を知覚できること、操作できること、理解できること、そして支援技術が情報を解釈できることを、Webアクセシビリティの土台として説明しています。これは属性の有無だけでなく、利用者が目的を達成できる体験全体に関わる問いです。
2. 後付けで直せる問題
もちろん、比較的局所的に修正できる問題もあります。
- 画像の代替テキスト（alt）の漏れ
- フォームコントロールとラベルの関連付け
- カスタムコントロールに必要なroleや状態の不足
- 必須項目やエラーメッセージのプログラム上の関連付け
こうした問題は、マークアップやコンポーネントを適切に直すことで改善できる場合があります。見落としを見つけるために自動テストやチェックリストを使うことも有効です。
ただし、「後から直せる」と「後から直すのが望ましい」は同じではありません。画像が何を伝えるか、入力欄の説明が利用者にとって十分か、エラーがどの項目と結びつくかは、表示する内容やフォームの設計に関係します。実装後に修正できても、設計時に一緒に考えていれば手戻りを減らせたかもしれません。
また、roleを足せば常にアクセシブルになるわけでもありません。標準のHTML要素が持つ意味や操作を使えるなら、まずそれを活かすのが基本です。roleは意味を伝えるための手段であり、操作や見た目、情報の分かりやすさを自動で作ってくれるものではありません。
3. 後付けでは直しにくい問題
アクセシビリティレビューで見つかる問題が、局所的な属性だけとは限りません。
- 情報アーキテクチャ: 必要な情報が画面や階層に散らばり、目的にたどり着けない
- ナビゲーション構造: ページや機能のまとまりが分かりにくく、現在地を見失う
- フォーカス戦略: どこから操作を始め、移動後にどこへ戻るかが決まっていない
- ダイアログやメニュー: 開いた後の操作、閉じた後のフォーカス、キーボードの使い方が曖昧
- 操作モデル: 同じような部品なのに、画面ごとに操作方法が違う
- 業務フロー: 一連の手続きが長く、途中で戻ったり誤りを訂正したりしにくい
- 用語と認知負荷: 内部用語がそのまま表示され、選択肢や覚える情報が多すぎる
これらは実装後でも変更できます。ただ、変更するときには、画面遷移、状態管理、データ構造、テスト、利用者への説明まで見直しが必要になることがあります。「修正できない」というより、aria-labelの追加だけでは修正できず、設計の前提まで戻る必要があるのです。
たとえば、ダイアログを閉じたあとフォーカスがどこへ移るべきかは、ラベルの問題ではありません。ユーザーが元の作業へ戻れるように、ダイアログを開く前の状態と閉じた後の状態をどうつなぐかという設計です。メニューの項目を矢印キーで移動するのか、Tabキーで順にたどるのかも、その部品をどんな操作モデルとして設計したかに関わります。
WAI-ARIA Authoring Practices Guide（APG）のキーボード操作ガイドは、ARIAで作ったウィジェットのキーボード操作はブラウザーが自動で提供するのではなく、作成者が実装する必要があると説明しています。ARIAで名前や役割を伝えても、フォーカス移動や操作順序まで一緒に設計されるわけではありません。
4. このシリーズで見てきたもの
ここまでの各回を振り返ると、すべてが設計の一部だったことが見えてきます。
- 第1回: HTMLから支援技術へ — HTMLに書いた意味が、DOM、Accessibility Tree、Platform Accessibility APIを通って支援技術へ伝わる。どの意味を、どの構造で届けるのかという設計でした。
- 第2回: Shadow DOM — カプセル化されたコンポーネントの内側と外側で、意味や操作の情報をどうつなぐか。境界の設計でした。
- 第3回: Fluent UIやTabster — キーボード操作やフォーカス管理など、部品を組み合わせるだけでは得られない振る舞いをどう支えるか。コンポーネントと操作モデルの設計でした。
- 第4回: 検証 — axe-core、DevTools、キーボード、スクリーンリーダーは、それぞれ違う層を確かめます。何を、どの手段で確かめるかという検証設計でした。
- 第5回: AI — AIは渡されたコードやテスト結果、利用可能なツールの範囲でレビューします。どんな根拠を用意し、どこを人が判断するかという役割分担の設計でした。
シリーズのテーマは違って見えても、共通していたのは「実装後に属性を足す」話ではありませんでした。ユーザーへ意味と操作をどう届けるかを、異なる層から見てきたのだと思います。
5. Fluent UIやReact Ariaはなぜ苦労しているのか
Fluent UI、React Aria、Tabsterのようなライブラリが向き合っているのは、aria-labelの不足だけではありません。特に難しいのは、次のような振る舞いを、予測できる一貫した体験として実装することです。
- フォーカスをどこへ移し、どこへ戻すか
- Tabキーと矢印キーをどう使い分けるか
- ダイアログを開いている間、背景の操作をどう扱うか
- メニューやタブなど複合ウィジェットをどう操作するか
- 状態の変化や操作結果をスクリーンリーダーにどう伝えるか
APGでは、メニュー、タブリスト、グリッドなど複数のフォーカス可能な項目を持つ部品を「複合ウィジェット」として扱い、Tabキーで部品間を移動し、矢印キーなどで部品内を移動する一般的な操作パターンを説明しています。この振る舞いは、ARIAのroleを書くだけでは得られません。
Fluent 2のアクセシビリティガイダンスも、情報の階層を明確にし、予測できるナビゲーションを設計すること、ダイアログのような一時的なUIを閉じたあとにフォーカスを失わせないことを案内しています。コンポーネントライブラリが扱う課題の中心は、属性の数ではなく、利用者が迷わず操作を続けられる一連の振る舞いです。
ライブラリは、その複雑さをすべてのプロダクトで一から実装しなくて済むようにする重要な手段です。一方で、どの情報をまとめるのか、どの操作を優先するのか、ボタンの名前が業務上の意味を表しているかまでは、ライブラリだけでは決められません。
6. AIは設計を肩代わりしてくれるのか
第5回で考えたように、AIはコードレビュー、axe-coreの結果の整理、キーボード操作のテスト生成などで役立ちます。テスト結果から指摘候補をまとめたり、未確認の状態を洗い出したりすることで、チームが検証に使える時間を増やせます。
しかし、コードやテスト結果だけを見て「この説明は利用者に伝わるか」「この順序で手続きを進められるか」「エラーから自力で回復できるか」を確実に判断することはできません。それらは画面の外にある業務知識や、実際に使う人の目的・経験・期待にも関わるからです。
これはAIにできることが少ないという話ではありません。AIには観察や整理、反復を支援してもらい、設計の意図や当事者の経験を踏まえた判断はチームが担う。必要なら、実際に使う人に参加してもらい、そこで得られた気づきを次の設計へ戻す。そうした役割分担が大切です。
7. Accessible by Defaultという考え方
アクセシビリティを最終工程に追加するのではなく、設計の最初から存在している品質として考える。それが Accessible by Default です。
認証画面を作る
↓
実装後にアクセシビリティ対応
×
認証画面を設計する
↓
最初からキーボード操作を考える
スクリーンリーダーで情報を得る方法を考える
エラーを理解し、修正する方法を考える
○
画面を作り始める前に、少なくとも「この画面でユーザーは何を達成するのか」「どんな入力方法で操作できるのか」「エラーが起きたらどう気づき、どう戻れるのか」を一緒に考えておくと、アクセシビリティは後から追加する作業ではなく、画面の振る舞いを決める条件になります。
MicrosoftのInclusive Designは、排除が起きているところに気づき、多様な人から学び、一人のための解決を多くの人へ広げる考え方を示しています。Tools and guidanceには、チームで使える活動カードや設計のためのツールもあります。また、MicrosoftのWindows向けアクセシビリティ設計ドキュメントは、アクセシビリティを製品ライフサイクルの最初から考えるべき品質として扱い、論理的な構造やキーボードフォーカスを設計することを勧めています。
同じ考え方は、特定の技術や会社に限りません。Apple Human Interface GuidelinesのAccessibilityは、直感的で、知覚でき、利用者に合わせて適応できるインターフェースを説明しています。Material Designのアクセシビリティガイダンスにも、設計システムの一部としてアクセシビリティの指針が用意されています。ツールや表現は異なっても、「どのような人が、どのように参加できるか」を設計の段階で問う姿勢は共通しています。
開発者向けのMicrosoft Accessibility Fundamentalsにも、アクセシビリティの原則、コンテンツ、評価とテスト、利用者やコミュニティとの協働が含まれています。こうした学びを、リリース前の一度きりのチェックではなく、チームが設計や実装を続けるための共通言語にしていけます。
もちろん、チェックリストや自動テストは今後も役に立ちます。大切なのは、それを「最後に合格するための関門」に限定せず、設計の途中で違和感を見つけ、よりよい選択をするために使うことです。
8. アクセシビリティは品質か、設計か
アクセシビリティは、間違いなく品質です。キーボードで使えるか、情報が正しく伝わるか、エラーから戻れるかは、リリース前後に検証すべき品質の一部です。
ただ、品質保証工程だけで作れるものではありません。品質保証は、設計と実装で意図したことが保たれているかを確かめ、ずれを見つけるための活動です。利用者の目的に合った情報構造や操作モデルを、検査工程だけから作り出すことはできません。
だから、タイトルへの答えはこうです。
アクセシビリティは品質でもある。けれど、より本質的には設計である。
設計の中にアクセシビリティが含まれていれば、テストはそれを確かめ、ライブラリは実装を支え、AIは確認や修正のサイクルを助けられます。どの手段も、設計の代わりではなく、設計を実現するためのものです。
9. まとめ
アクセシビリティは、DOMの話だけでも、ARIAの話だけでも、チェックツールの話だけでもありません。ユーザーへ意味と操作を届け、目的を達成できるようにするための設計です。
このシリーズで見てきたDOM、Accessibility Tree、Shadow DOM、Fluent UI、Tabster、DevTools、axe-core、Playwright、そしてAIは、すべてその設計を支援するための手段でした。それぞれにできることがあり、それぞれに見えないことがあります。
私たちが本当に設計しているのは、HTMLだけではありません。さまざまな人が、さまざまな方法で参加できるユーザー体験です。
最初の画面設計から、キーボード、スクリーンリーダー、分かりやすい言葉、エラーからの回復を一緒に考える。その小さな選択が、リリース直前の「後付け」を減らし、より多くの人にとって使いやすい体験につながっていきます。