ARIA実践ガイド：ネイティブHTMLとAPGで堅牢なUIを設計する

ARIAを追加しても、クリックしかできないUIはアクセシブルになりません。

ARIAが伝えるのは主に要素の意味と状態であり、キー操作やフォーカス移動は別に実装して確かめる必要があります。

実装は、ネイティブHTMLで土台を作り、不足する意味だけをARIAで補い、最後に実際の操作環境で検証する順序で進めます。

ARIAが担う範囲

ARIAは、HTMLだけでは十分に表現できないユーザーインターフェースの意味、関係、状態を支援技術へ伝えるための仕様です。

たとえば、タブの選択状態、アコーディオンの開閉状態、ダイアログの名前などを伝えられます。

一方で、role='button'を付けても、ブラウザはSpaceキーやEnterキーの処理、フォーカス表示、クリック処理を自動では追加しません。

W3Cの「Using ARIA」も、必要な意味と振る舞いを備えたネイティブHTML要素がある場合は、それを使うよう示しています。

<!-- 意味と基本操作がブラウザから提供される -->
<button type="button">保存</button>

<div role='button'>で同じ見た目を作る方法は、キー操作、フォーカス可能性、無効状態などを実装側で補う必要があるため、保守範囲が広がります。

ARIAの基礎を先に確認したい場合は、関連記事のWAI-ARIAの役割、プロパティ、状態の解説が参考になります。

名前、役割、状態をそろえる

支援技術が操作要素を理解するには、少なくとも「何という要素か」「何をする要素か」「いまどういう状態か」を一貫して伝える必要があります。

アクセシブルネームを可視ラベルと合わせる

アクセシブルネームは、支援技術が要素を識別するときに使う名前です。

可視テキストがあるボタンでは、その文言を名前として使うのが基本です。

アイコンだけのボタンには短い名前が必要ですが、可視ラベルがあるのに別のaria-labelで上書きすると、画面上の文言と読み上げが食い違います。

<button type="button" aria-label="検索">
  <svg aria-hidden="true" focusable="false">…</svg>
</button>

音声操作では画面に見える文言を発話して対象を指定することがあるため、可視ラベルを名前に含めることも確認します。

状態は見た目と同時に更新する

開閉アイコンだけが変わり、aria-expandedが古い値のまま残ると、視覚表示と読み上げが別の状態を伝えてしまいます。

DOMの表示、フォーカス、ARIA属性は一つの処理で更新し、どれか一つだけが取り残されない設計にします。

APGを実装仕様へ落とし込む

APG（ARIA Authoring Practices Guide）は、ARIAを使う代表的なUIパターンについて、期待されるロール、状態、キー操作を整理したW3Cの実践ガイドです。

ただし、APGの利用前の注意事項は、ブラウザと支援技術の組み合わせによる差を踏まえ、対象環境で十分にテストするよう求めています。

APGの例は設計判断の基準であり、そのまま本番へ貼り付ける完成部品ではありません。

アコーディオン

開閉のトリガーにはbuttonを使い、見出しの中に置くと、文書構造と操作対象を同時に伝えられます。

<h3>
  <button type="button" aria-expanded="false" aria-controls="shipping-panel">
    配送について
  </button>
</h3>
<div id="shipping-panel" hidden>
  <p>配送条件の説明</p>
</div>

開くときはaria-expanded='true'へ変更し、パネルのhiddenを外します。

role='region'は常に必要ではなく、各パネルをランドマークとして区別することが読者の移動に役立つ場合に限って検討します。

タブ

タブでは、ページ全体のTab順に入るタブを一つに絞り、矢印キーでタブ間を移動するロービングtabindexを使います。

<div role="tablist" aria-label="設定">
  <button role="tab" aria-selected="true" tabindex="0" aria-controls="general-panel">一般</button>
  <button role="tab" aria-selected="false" tabindex="-1" aria-controls="notice-panel">通知</button>
</div>

APGのタブパターンには、自動アクティベーションと手動アクティベーションの二方式があります。

パネルを遅延なく表示できるなら、フォーカス移動と同時に選択する方式を検討できます。

表示に待ち時間が生じるなら、矢印キーではフォーカスだけを移し、EnterまたはSpaceで選択する方式のほうが移動を妨げにくくなります。

モーダルダイアログ

モーダルダイアログは、開いた後に背景を操作できない状態にし、フォーカスを内部へ移す必要があります。

<dialog aria-labelledby="terms-title">
  <h2 id="terms-title">利用規約</h2>
  <p>確認してほしい内容</p>
  <button type="button">閉じる</button>
</dialog>

ネイティブのdialog要素をshowModal()で開く方法が要件と対象環境に合うなら、独自のdiv role='dialog'よりブラウザの機能を利用できます。

独自実装を選ぶ場合も、APGのモーダルダイアログパターンに沿って、初期フォーカス、内部のTab循環、Escapeでの終了、終了後の論理的な復帰先を設計します。

トグルボタン

同じ操作のオンとオフを切り替えるボタンでは、ラベルを固定し、aria-pressedで押下状態を伝える方法があります。

<button type="button" aria-pressed="false">お気に入り</button>

単独の設定値を表す場面でネイティブのチェックボックスが要件を満たすなら、先にチェックボックスを検討します。

role='switch'を選ぶ場合は、aria-checkedとキー操作を含むスイッチの規約を一式実装します。

コンボボックス

コンボボックスは、入力欄と候補ポップアップを一つの操作として扱う複合ウィジェットです。

<label for="city">都市</label>
<input id="city" role="combobox" aria-autocomplete="list" aria-expanded="false" aria-controls="city-list">
<ul id="city-list" role="listbox" hidden>
  <li id="city-tokyo" role="option">東京</li>
</ul>

このマークアップだけでは完成しません。

APGのコンボボックスパターンを基に、候補の表示条件、矢印キーによる移動、Enterでの確定、Escapeでの終了、入力欄の編集キーを壊さない処理を追加します。

aria-activedescendantを使う方式ではDOMフォーカスを入力欄に保ち、値には現在の候補IDだけを設定します。

複雑なカスタムUI全体の設計と検証は、関連記事のアクセシブルなカスタムコンポーネントの実装とテスト手順でも確認できます。

避けたいARIAの使い方

role='menu'自体がWebサイトで常に誤りという意味ではありません。

デスクトップアプリ型のメニューバーとして矢印キーを含む操作規約を実装する場合には選択肢になりますが、一般的なグローバルナビゲーションへ見た目だけで付けるのは避けます。

ネイティブHTMLへ置き換える例

クリックイベントだけを持つdivのナビゲーションは、リンクの意味も標準のキーボード操作も備えていません。

<!-- 置き換え前 -->
<div class="item" onclick="go('/pricing')">価格</div>

<!-- 置き換え後 -->
<nav aria-label="主なナビゲーション">
  <ul>
    <li><a href="/pricing">価格</a></li>
    <li><a href="/docs">ドキュメント</a></li>
  </ul>
</nav>

置き換え後はリンクの意味と基本的なキーボード操作をブラウザから得られますが、それだけでページ全体のアクセシビリティ適合が保証されるわけではありません。

フォーカス表示、リンク文言、読み順、コントラスト、拡大時の表示などは別に確認します。

デザインシステムに残す実装仕様

コンポーネントの見た目だけを共通化しても、名前、状態、キー操作が実装者ごとに異なれば、利用者の操作体験は安定しません。

各コンポーネントの仕様には次の項目を対応づけて記録します。

• ネイティブ要素：最初に選ぶHTML要素と、カスタム実装が必要になる条件。
• 名前：可視ラベル、補助説明、ラベルを参照するID。
• 役割と状態：暗黙の役割、追加するARIA、初期値、更新条件。
• キー操作：Tab、矢印キー、Enter、Space、Escape、Home、Endのうち必要な操作。
• フォーカス管理：初期位置、移動順、閉じた後の復帰先、削除後の移動先。
• 視覚表示：フォーカス、選択、無効、エラーを色だけに依存せず区別する方法。
• 受け入れテスト：対象ブラウザ、キーボード、スクリーンリーダーで確認する手順。

設計から運用までの扱いは、関連記事のWebアクセシビリティを実務に組み込むチェックポイントにも整理しています。

短時間で行う手動テスト

1. Tab順：ページの先頭から主要な操作へ論理的な順序で移動できるか。
2. フォーカス表示：現在位置を視覚的に追え、固定ヘッダーなどで隠れないか。
3. 標準操作：ボタンをEnterとSpaceで操作でき、リンクをEnterで開けるか。
4. 複合UI：タブ、アコーディオン、ダイアログ、コンボボックスが定めたキー操作で動くか。
5. 状態同期：見た目、DOMの表示、フォーカス、ARIA属性が同じ状態を示すか。
6. 読み上げ：見出し、ランドマーク、ラベル、エラー、状態通知が目的に合う順序と量で伝わるか。
7. 終了経路：ダイアログやポップアップを閉じられ、操作を始めた位置か次の論理的な位置へ戻れるか。

キーボードでの確認を詳しく進める場合は、関連記事のキーボード操作とフォーカス表示の確認方法が役立ちます。

WCAG 2.2との関係

ARIAとAPGは、UIの意味や操作を設計する手掛かりですが、それだけでWCAGへの適合を判定するものではありません。

WCAG 2.2は、Webコンテンツ全体を対象とする検証可能な達成基準を定めています。

W3Cは更新や方針策定でWCAG 2.2を使うことを勧めていますが、案件で適用すべき規格、法令、調達条件は別に確認します。

WCAG 2.1からの変更は、関連記事のWCAG 2.2で追加された達成基準の実務解説で確認できます。

実装判断のまとめ

1. 要件を満たすネイティブHTML要素を探す。
2. 不足する名前、役割、関係、状態だけをARIAで補う。
3. 選んだパターンのキー操作とフォーカス管理を仕様にする。
4. 視覚表示とARIA属性を同じ処理で更新する。
5. 対象ブラウザと支援技術で手動テストし、結果を受け入れ基準へ残す。

少ないARIAを目標にする理由は、コード量を減らすためだけではありません。

ブラウザが備える意味と操作を生かし、独自実装で負う約束を必要な範囲に限定するためです。

参照した一次資料

• W3C「Using ARIA」
• WAI-ARIA APG「Read Me First」
• WAI-ARIA APG「Accordion Pattern」
• WAI-ARIA APG「Tabs Pattern」
• WAI-ARIA APG「Dialog Modal Pattern」
• WAI-ARIA APG「Combobox Pattern」
• W3C「Web Content Accessibility Guidelines 2.2」