ARIA ロールの例: 完全なガイド

ARIAロールの例は、role属性がインターフェース要素をアクセシビリティツリーにどのようにマッピングするかを示しており、WAI-ARIA 1.2仕様は、widget、document structure、landmark、live region、window、abstractの6つのロールカテゴリを定義し、80以上の具体的なロールをカバーしています。このガイドでは、各カテゴリのすぐにコピーできる実用的な例と、ロールが役立つ場合と積極的に害を及ぼす場合を決定するルールを紹介します。

主なポイント

• ARIAロールは支援技術に項目が何であるかを伝えますが、それ自体では動作、フォーカス、キーボードサポートを追加することはありません。
• ARIAを使用する際の最初のルールは、暗黙のロール、状態、キーボード管理をすでに備えているネイティブHTML要素を優先することです。
• WAI-ARIA 1.2の6つのロールカテゴリは、widget、document structure、landmark、active region、window、summaryであり、抽象ロールはマークアップに決して現れてはなりません。
• ランドマークロールは、既存のXHTML/CSSサイトに追加できる最もコスト効率が高く、リスクが最も低いARIAです。
• ウィジェットロールは、キーボード操作と状態処理のためにほぼ常にJavaScriptマッピングを必要とし、そうでなければプレーンHTMLよりも悪い体験を生み出します。
• 各ロールをスクリーンリーダーと自動チェッカーで検証してください。仕様上有効なロールでも、あなたのコンテンツにとっては間違っている可能性があります。

ARIAロールが実際に何をするか

ARIAロールは、role属性に配置して、アクセシビリティツリー内の要素のセマンティックなアイデンティティを置き換えたり提供したりするトークンです。<div role="button">はスクリーンリーダーに「ボタン」とアナウンスするよう伝えますが、ブラウザは依然としてそれを汎用コンテナとして扱います。つまり、フォーカス可能ではなく、EnterやSpaceに応答せず、無効状態もありません。この宣伝されたセマンティクスと実際の動作の間のギャップが、ARIAの失敗の最も一般的な原因です。これらは、セマンティクスが動作から乖離する可能性があることを示す一般的なaria rolesの例です。

W3CのAccessible Rich Internet Applications Working Groupによって維持されているWAI-ARIA仕様は、ロールだけでなく状態とプロパティも定義しています。ロールは「それは何か」の層であり、aria-expanded、aria-checked、aria-labelのような状態とプロパティは「どのような状態か」の層です。必要な状態を伴わないロールは不完全です — role="checkbox"にはaria-checkedが必要であり、role="combobox"にはaria-expandedと制御されたlistboxが必要です。

ネイティブHTML要素は暗黙のロールを持っています。<button>はbuttonロールに、<nav>はnavigationに、<h1>から<h6>はheadingに、<input type="checkbox">はcheckboxに対応します。ブラウザが自動的にロール、キーボード動作、状態を提供するため、W3CのARIA Authoring Practices Guideに文書化されているARIA使用の最初のルールは、同等の要素が存在する場合は常にネイティブセマンティクスを使用することです。カスタムツリービューや<div>から構築されたタブ付きパネルなど、ネイティブ要素が適さない場合にのみ明示的なロールを探してください。

WAI-ARIAの6つのロールカテゴリ

WAI-ARIA 1.2はロールを6つのカテゴリに整理しており、ロールがどのカテゴリに属するかを知ることで、どれだけのJavaScriptを負うかがわかります。以下は一般的なaria rolesの例です：

カテゴリ	目的	ロールの例	JavaScriptが必要？
Widget	インタラクティブコントロール	button、checkbox、tab、slider、combobox	はい — キーボード + 状態
Document structure	コンテンツの整理	heading、list、listitem、table、article	いいえ
Landmark	ナビゲーション用のページ領域	banner、main、navigation、complementary	いいえ
Live region	動的な更新をアナウンス	alert、status、log、timer	通常は — 更新をトリガーするため
Window	サブウィンドウとダイアログ	dialog、alertdialog	はい — フォーカス管理
Abstract	スーパークラスロール、決して記述しない	widget、input、section、landmark	N/A — 使用しないでください

抽象ロールは分類を整理するためにのみ存在します。HTMLにrole="input"やrole="section"を書くことは検証エラーであり、これらのロールは支援技術に対して定義された動作を持たないため、予測不可能なアナウンスを生成します。

関連: UserWay — 簡単な操作で計画を立てるためのウィジェットを無料で利用できます.

ランドマークロールの例

ランドマークロールは、JavaScriptを必要とせず、すでに持っている領域に直接マッピングされるため、古いXHTML/CSSサイトに追加できる最も安全で最も影響力のあるARIA rolesの例です。典型的なページスケルトン：

<header role="banner">
  <nav role="navigation" aria-label="Principal">
    <ul>...</ul>
  </nav>
</header>
<main role="main">
  <article>...</article>
  <aside role="complementary" aria-label="Artículos relacionados">...</aside>
</main>
<footer role="contentinfo">...</footer>

各マーカーロールはネイティブ要素に対応します — bannerはトップレベルの<header>に、mainは<main>に、navigationは<nav>に、complementaryは<aside>に、contentinfoは<footer>に。ネイティブ要素を使用する場合、ロールは暗黙的であり、繰り返すべきではありません。明示的なrole属性がその価値を発揮するのは、変更できない<div>マークアップに行き詰まっている場合のみであり、これは古いテンプレートやCMS出力でよくあります。

ここで2つの注意点があります。第一に、banner、main、contentinfoはページごとに1回だけ出現する必要があります。複数のmainランドマークはナビゲーションを妨害します。第二に、同じタイプの複数のランドマークが存在する場合 — 例えば3つの<nav>要素 — それぞれに別々のaria-labelを付けて、スクリーンリーダーユーザーがランドマークリストでそれらを区別できるようにしてください。ラベルなしのnavは兄弟と同じように宣伝され、目的が果たされません。

一見の価値があります: AudioEye — Accesibilidad gestionada: 人間性の見直しと自動化の組み合わせ.

ウィジェットロールの例

ウィジェットロールは、ARIAが強力かつ危険になる場所です。各ウィジェットロールには暗黙の契約があります：特定のキーボードキー、特定の状態、特定のフォーカス動作。ARIA Authoring Practices Guideは各パターンの完全版を公開しています。これらのaria rolesの例は、関連する複雑さを示しています。

例えばトグルボタンは、オン/オフ状態を伝えるためにaria-pressedが必要です：

<button type="button" aria-pressed="false" id="mute">
  Silenciar
</button>

<button>要素はロール、フォーカス、Enter/Space処理を提供し、JavaScriptはaria-pressedを"false"と"true"の間で切り替えるだけです。これはARIA使用の理想的な形です — ネイティブ要素、最小限のARIA、小さなスクリプト。

<div>から構築されたカスタムタブインターフェースは逆のケースです。コンテナにrole="tablist"、各タブにrole="tab"、各パネルにrole="tabpanel"、アクティブなタブにaria-selected、タブをパネルにリンクするaria-controls、タブ間の矢印キーナビゲーションが必要です。これらのいずれかを逃すと、ウィジェットはタブとして宣伝されますが、静的テキストのように動作します。同じことがrole="slider"（aria-valuenow、aria-valuemin、aria-valuemaxと矢印キーが必要）、role="combobox"（aria-expandedと制御されたlistboxが必要）、role="tree"（aria-expandedと完全な矢印キー走査が必要）にも当てはまります。

有用な決定ルール：仕事をしてくれるネイティブ要素 — <button>、<input type="checkbox">、<select>、<details> — がある場合は、それを使用してウィジェットロールを完全に無視してください。カスタムウィジェットロールは真に新しいコントロールのために取っておき、出荷前に完全なキーボードパターンを実装するJavaScriptを予算に組み込んでください。

ドキュメント構造とライブリージョンの例

ドキュメント構造ロールは、ネイティブ要素が利用できない場合にコンテンツの関係を記述します。これらのaria rolesの例には、見出しとして機能するスタイル付き<div>の古典的な救済策であるaria-levelを伴うrole="heading"が含まれます：

関連: IAAP CPACC / WAS Certification — La certificación que acredita tu experiencia en accesibilidad.

<div role="heading" aria-level="2">Novedades del mes</div>

ここではaria-level属性が必須です — レベルなしのheadingロールはランクなしでアナウンスされ、ドキュメントのアウトラインを壊します。同様に、role="list"とrole="listitem"は、list-style: noneやflexコンテナなどのCSSが一部のブラウザでリストセマンティクスを削除した場合にそれを復元し、role="table"、role="row"、role="columnheader"、role="cell"は<div>マークアップからデータテーブルを再構築します。実際には、実際の<ul>、<ol>、<table>要素に再構築する方が、構造ロールの完全なセットを維持するよりもほとんど常に手間が少なくて済みます。

ライブリージョンロールは、ページをリロードせずに変化するコンテンツをアナウンスします。role="alert"はスクリーンリーダーを即座に中断し、エラーメッセージや緊急通知に対応します。role="status"は丁寧に待機し、「Guardado」のような確認に適しています。role="log"はチャットやアクティビティフィードに適合します。role="timer"はカウントダウンに対応します。重要な詳細は、ライブリージョンコンテナがコンテンツが変化する前にDOMに存在しなければならないことです — role="alert"とそのテキストを持つ新しい要素を同時に注入すると、監視されるリージョンが存在しなかったため、アナウンスが生成されないことがよくあります。ページロード時に空の<div role="status">を作成し、後でそのテキストを更新してください。

一般的なARIAロールの間違い

冗長なロールがリストのトップです。<button role="button">や<nav role="navigation">のようなこれらのaria rolesの例は、何も追加せずマークアップを乱雑にします。暗黙のロールがすでに存在します。開発者が<h2>にrole="heading"を追加する場合にも同じ冗長性が現れます。

ショッピングの場合: accessiBe — 48 時間で IA が WCAG に最高の瞬間をもたらす.

必要な状態の欠落が2番目です。aria-checkedなしのrole="checkbox"、aria-valuenowなしのrole="slider"、aria-expandedなしのrole="combobox"はすべて、ユーザーを誤導する不完全なアナウンスを生成します。仕様は各ロールに必要な状態とプロパティをリストしており、自動チェッカーはそれらの欠落をフラグします。

間違った要素へのロールの誤用が3番目です。<a href>にrole="button"を付けるとリンクセマンティクスが上書きされ、新しいタブで開くなどの期待される動作が壊れます。フォーカス可能な要素にrole="presentation"やrole="none"を付けると、そのセマンティクスが削除されながらタブオーダーに残り、アナウンスされたアイデンティティのないフォーカス可能な要素が作成されます。そしてrole="widget"やrole="input"のような抽象ロールの使用は常にエラーです。

最後に、ARIAロールは壊れたDOMを修正できません。自身のrole="tab"内にネストされたrole="tabpanel"は、どれだけ属性を追加しても無意味なツリーを生成します。まず構造を修正し、その上にARIAを重ねてください。

ARIAロールのテスト方法

ARIAロールのテストには複数の方法が必要です。自動ツールは有効性エラーを検出しますが、セマンティックな不一致は検出しません。アクセシビリティチェッカー — axe DevTools、WAVE、Lighthouse — から始めて、マークアップ内の無効なロール、欠落した必須属性、抽象ロールを検出してください。これらのツールは高速で、機械的なエラーを検出します。

次にスクリーンリーダーパスを行います。WindowsでのFirefoxとNVDA、ChromeとJAWS、macOSでのSafariとVoiceOverはそれぞれアクセシビリティツリーを異なる方法で公開し、1つで正しくアナウンスされるロールが別のものではそうでない場合があります。ランドマークと見出しでナビゲートして、構造ロールが期待されるアウトラインを生成することを確認し、すべてのウィジェットをタブ移動して、アナウンスされたロール、状態、キーボード動作が一致することを検証してください。

ChromeまたはFirefox DevToolsでアクセシビリティツリーを直接検査してください。「Accessibility」パネルは任意の要素の計算されたロールと名前を表示します。これは、あなたが書いたロールとブラウザが実際に公開するロールの間のギャップを明らかにします — 親によって上書きされたり完全に無視されたりするロールを検出する最速の方法です。

出典と参考文献

• WAI-ARIA — Wikipedia: Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA)は、World Wide Web Consortium (W3C)によって公開された技術仕様であり…

よくある質問

ARIAロールとは何で、どのように機能しますか？

ARIAロールは、アクセシビリティツリー内の要素のアイデンティティを定義するrole属性の値であり、スクリーンリーダーがそれを正しくアナウンスできるようにします。それらはセマンティクスのみを変更し、外観、フォーカス、キーボード動作は変更しません。WAI-ARIA 1.2仕様は6つのロールカテゴリと80以上の具体的なロールを定義し、それぞれに必要な状態とプロパティがあります。

ネイティブHTMLの代わりにARIAロールをいつ使用すべきですか？

必要なセマンティクスを提供するネイティブHTML要素がない場合にのみARIAロールを使用してください。<button>、<nav>、<input type="checkbox">のようなネイティブ要素は、暗黙のロールに加えて組み込みのキーボードサポートと状態管理を備えています。ARIA使用の最初のルールはネイティブセマンティクスを優先し、再構築できないカスタムウィジェットやレガシーマークアップにのみ明示的なロールを追加することです。

ARIAロールとARIA属性の違いは何ですか？

ARIAロールは「この項目は何か」に答え、aria-expanded、aria-checked、aria-labelのようなARIA属性は「どのような状態か」または「何と呼ばれているか」に答えます。ロールとその必須属性は連携して機能します：aria rolesの例として、role="checkbox"はaria-checkedなしでは不完全であり、role="combobox"にはaria-expandedと制御されたlistboxが必要です。

ARIAロールは任意のHTML要素に使用できますか？

ARIAロールはほとんどの要素に適用できますが、一部の組み合わせは無効または有害です。widgetやinputのような抽象ロールは決して記述すべきではありません。リンクのロールをrole="button"に変更すると、リンクの期待される動作が壊れ、フォーカス可能な要素にrole="presentation"を付けると、そのセマンティクスが削除されながらタブオーダーに残ります。

ARIAロールはJavaScriptなしで機能しますか？

ドキュメント構造とランドマークの役割はセマンティクスを変更するだけであるため、JavaScript がなくても機能します。 「tab」、「slider」、「combobox」などのウィジェットの役割には、キーボード操作の実装と状態の更新に JavaScript が必要です。JavaScript がないと、要素はそれ自体をコントロールとして宣言しますが、コントロールのように動作せず、これは単純な HTML よりも悪くなります。

自分の ARIA ロールが正しいかどうかを確認するにはどうすればよいですか?

自動テストと手動テストを組み合わせます。 axe DevTools、WAVE、または Lighthouse を実行して無効なロールと不足している必須属性を検出し、NVDA、JAWS、および VoiceOver でテストしてアナウンスとキーボードの動作を確認します。 Chrome および Firefox DevTools の [アクセシビリティ] パネルには、計算されたロールが表示され、ブラウザーがオーバーライドまたは無視するロールが明らかになります。