適合レベル
A
※各レベルについては適合レベルとはをご覧ください
概要
独自に作成したUIコンポーネントには、WAI-ARIAを用いて役割や状態を明示し、キーボード操作を可能にする。
具体的な実装方法
4.1.2 A
1. ⭕️良い例
可能な限り、標準のHTMLコントロールを使用します。カスタムコンポーネントを作成する場合は、WAI-ARIAを用いて名前、役割、値を明示的に指定します。
ポイント
- 役割 (Role):
role属性でコンポーネントの種類を指定します（例:role="button"）。 - 名前 (Name):
<label>要素の関連付け、aria-label、aria-labelledbyなどで名前を提供します。 - 値 (Value):
aria-checked、aria-selected、aria-valuenowなどのARIAステート（状態）プロパティで値や状態を示します。
実装例 (HTML)
<!-- 良い例: 標準的なHTML要素を使用 -->
<button onclick="doSomething()">保存する</button>
<!-- 良い例: ARIAを使用してカスタムボタンを実装 -->
<div role="button" tabindex="0" onclick="doSomething()" onkeydown="handleKeyDown(event)">
保存する
</div>
<!-- 良い例: ARIAを使用してカスタムチェックボックスを実装 -->
<div role="checkbox" aria-checked="false" tabindex="0" onclick="toggleCheckbox(this)">
<img src="unchecked.png" alt=""> 同意する
</div>2. ❌悪い例
<div>や<span>にonclickイベントのみを設定:<div>にクリックイベントを設定しただけでは、それは単なるクリックできる<div>であり、ボタンとしての役割や名前が支援技術に伝わりません。- ARIAの役割や状態が欠落: カスタムコンポーネントに
role属性がない、または状態が変化してもaria-checkedなどの値が更新されない。
なぜ問題なのか
これらの実装では、コンポーネントの「名前」「役割」「値」というアクセシビリティAPIに必要な情報が欠落しているため、支援技術はそれを解釈できません。
改善策
- まずは標準のHTMLコントロールで実装できないか検討します。
- カスタムコンポーネントを実装する場合は、必ず
role属性で役割を定義し、tabindex="0"でフォーカス可能にします。さらに、aria-*属性を用いて名前と状態を管理します。
3. プラットフォーム別の実装
Webページでは、HTMLとWAI-ARIAを組み合わせて実装します。
4. 特殊なケースへの対応
- フレーム (
<iframe>):<iframe>要素には、そのフレームの内容を説明する`title`属性を指定することで、アクセシブルな「名前」を提供する必要があります。
確認観点
4.1.2 A
1. 定量的な基準の担保
自動チェックツールでの確認
- LighthouseやAxeは、ARIAの役割や必須属性の欠落、不適切な使用などを検出するのに非常に有効です。「ARIA roles are valid」や「Elements have accessible names」などの項目を確認します。
チェックリストの達成度
2. 定性的な基準の担保
レビュー
- コードレビューにおいて、カスタムUIコンポーネントがARIAの仕様に従って正しく実装されているかを確認します。
専門家による監査
- アクセシビリティ専門家が、ブラウザのアクセシビリティツリー（開発者ツールで確認可能）を調査し、各コンポーネントの名前、役割、値が正しく公開されているかを検証します。
- 実際にスクリーンリーダーを使い、コンポーネントが意図通りに読み上げられ、操作できるかをテストします。