ARIA の役割とは何ですか?開発者のための実践ガイド

ARIA の役割とは何ですか? ARIA ロールは、87 個の定義値 (WAI-ARIA 1.2 時点) のボキャブラリーであり、要素が * 何か*、HTML タグに関係なく要素がどのように動作するかを支援技術に伝えます。 button、navigation、または dialog のようなロールは、一般的な <div> または <span> を既知のウィジェット タイプに割り当てるため、スクリーン リーダーがそれを正しくアナウンスし、正しいキーボード操作を公開します。

そもそも ARIA ロールが存在する理由

aria ロールとは何かを理解するには、HTML だけでは解決できない構造的な問題を aria ロールが解決することを理解する必要があります。ネイティブ HTML 要素には暗黙的なセマンティクスがあります。つまり、<button> はそれ自体がボタンであることを通知し、フォーカスすることができ、Enter キーとスペースバーに応答し、必要に応じて押された状態を表示します。開発者がカスタム ウィジェット (コンボボックス、タブ パネル、ツリー ビュー) を作成するとき、多くの場合、セマンティクスを含まない <div> と <span> を使用します。 ARIA の役割は、著者が失われた意味を明示的に述べられるようにすることで、このギャップを埋めます。

WAI-ARIA 仕様は、W3C の Accessible Rich Internet Applications Working Group によって維持されています。最初のバージョンである ARIA 1.0 は、2014 年に W3C 勧告になりました。 2017 年に ARIA 1.1 が続き、ARIA 1.2 は 2023 年に推奨ステータスに達しました。改訂ごとに役割、状態、プロパティが追加され、それぞれがキーボードの予期される動作を説明するオーサリング実践ドキュメントにリンクされています。

重要な違いにより、役割が他の 2 つの ARIA カテゴリから区別されます。ロールは「これは何ですか？」に答え、状態とプロパティは「どのような状態にあるのか?」と答えます。そして「それは何と関係があるのですか？」 role="checkbox" はウィジェットのタイプを宣言します。 aria-checked="true" は現在の状態を示します。この 2 つを混同することは、カスタム ウィジェットが壊れる最も一般的な原因の 1 つです。

6 つの役割カテゴリ

ARIA ロールとは何かを理解するには、ARIA 仕様がロールを 6 つのファミリーにグループ化していることを知ると役立ちます。ファミリを理解すると、ロールがサポートする状態とプロパティ、および適用されるキーボード パターンを予測できるようになります。

カテゴリー	目的	代表的なロール
抽象	スーパークラス定義、マークアップでは決して使用されない	widget, input, section
ウィジェット	インタラクティブなコントロール	button, checkbox, slider, tab
文書構造	ページのランドマークと領域	banner, main, navigation, region
ランドマーク	ナビゲート可能なページ領域 (構造のサブセット)	banner, complementary, contentinfo, form
ライブリージョン	動的なコンテンツの変更を通知する	alert, status, log, timer
ウィンドウ	ブラウザまたはアプリケーションのウィンドウ	dialog, alertdialog

抽象ロールは、分類を整理するためにのみ使用されます。作成者はマークアップに「role=“widget”」や「role=“input”」を決して書いてはなりません。その結果、未定義の動作が発生し、検証が失敗します。残りの 5 つのカテゴリは、実際に適用するものです。

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

暗黙の役割と ARIA の最初のルール

各 HTML 要素には、HTML Accessibility API Mapping (AAM) 仕様によって定義された暗黙的な ARIA 関数 (aria ロールとは何かを説明する) があります。 <nav> 要素には暗黙的な role="navigation" があります。 <ul> には暗黙的な role="list" があります。 <h1> から <h6> は role="heading" を持ちます。 <table> には role="table" があります。

ARIA の使用に関する最初の W3C ルールでは、ネイティブ HTML 要素または属性が必要なセマンティクスと動作をすでに伝えている場合は、ARIA で要素を再利用する代わりにそれを使用する、と明確に述べられています。 <button> に role="button" を追加する必要はありません。さらに悪いことに、<div> に role="button" を追加すると、アナウンスは表示されますが、動作は表示されません。フォーカスもキーボードのアクティブ化も、フォームの送信も行われません。

冗長性は必ずしも無害であるとは限りません。暗黙的な役割をオーバーライドすると、支援技術が依存するセマンティクスが失われる可能性があります。 <table> 内に role="presentation" を記述すると、テーブル セマンティクスが完全に排除されます。レイアウト テーブルでは意図的に行われる場合もありますが、データ テーブルでは悲惨な結果になります。

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

ロールが状態およびプロパティとどのように相互作用するか

ロールは、サポートする状態とプロパティのコンテナとして機能します。仕様では、どの属性がどのロールに対して有効であるかが定義されており、ブラウザはアクセシビリティ ツリーでサポートされている組み合わせのみを公開します。 aria ロールとは何かを理解すると、role="checkbox" が値 true、false、または mixed の aria-checked をサポートしていることを知るのに役立ちます。 role="slider" は、aria-valuenow、aria-valuemin、aria-valuemax、およびオプションで aria-valuetext をサポートします。 role="combobox" は、aria-expanded、aria-controls、および aria-activedescendant をサポートします。 role="button" に aria-checked を適用することは無意味であり、一部のスクリーン リーダーでは無視されるか、混乱を招く結果が生成されます。

必要なプロパティも重要です。 aria-checked のない role="checkbox" は無効です。状態は必須であり、オプションではありません。 role="slider" に aria-valuenow を指定しないと、ユーザーは現在の値を判断できなくなります。 ARIA 仕様では、これらを「必須の状態とプロパティ」としてラベル付けしており、axe-core や IBM Equal Access Accessibility Checker などの適合性チェッカーは、それらが存在しないことを指摘しています。

役割、アクセシビリティ ツリー、ブラウザのサポート

ブラウザは ARIA 関数をプラットフォーム アクセシビリティ API (Windows では UIA、macOS では AXAPI、Linux では ATK/AT-SPI) に変換し、スクリーン リーダーはこれらの API を使用します。ブラウザーが正しく割り当てていない役割は、実際にはユーザーには見えません。

サポートは機能とブラウザによって異なります。 「ボタン」、「リンク」、「ヘッダー」、「リスト」、「ナビゲーション」などのコア機能は広くサポートされています。新しいロール、またはより特殊なロール (デジタル パブリッシングの WAI-ARIA モジュールの「フィード」、「数学」、「doc-footnote」) のサポートは、サポート状況にばらつきがあります。 role=“switch” は最新のブラウザでサポートされていますが、10 年前に一貫性なく発表されました。

視聴者が実際に使用する組み合わせをテストすることは、依然として重要です。 2 つのスクリーン リーダーは異なるプラットフォーム API を使用し、異なるヒューリスティックを適用するため、Firefox を使用した NVDA で動作するウィジェットは、Safari を使用した VoiceOver では動作が異なる場合があります。

ランドマークの役割とページ構造

ランドマーク ロールを使用すると、スクリーン リーダー ユーザーはページの領域に直接ジャンプできます。 8 つのランドマークの役割は、「バナー」、「補完」、「コンテンツ情報」、「フォーム」、「メイン」、「ナビゲーション」、「リージョン」、および「検索」です。最新の HTML には、ほとんどのネイティブ同等の要素があります。<header> は banner、<footer> は contentinfo、<main> は main、<nav> は navigation、<aside> は complementary、アクセシブルな名前を持つ <form> は form、アクセシブルな名前を持つ <section> は region になります。

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

CSS や JavaScript が失敗した場合でも機能し、ロール/属性の競合のリスクが軽減されるため、ネイティブ要素を使用することをお勧めします。 「search」ランドマークにはネイティブ HTML に相当するものがないため、検索領域としては「role=“search”」が依然として正しい選択です。

よくある間違いは、<main> または <article> 内の <div> に role="banner" を適用することです。ランドマーク ロールは、他の特定のロール内にネストされていない場合にのみランドマークを作成します。 「main」内の「banner」はランドマークとしてまったく表示されません。 DOM 内の場所は、ロール値と同じくらい重要です。 aria の役割とは何なのか疑問に思っている人のために、これらのランドマークは仕様の重要な部分です。

ライブリージョンの役割

aria ロールとは何かを考えると、ライブリージョンロールは、焦点を変更することなくコンテンツの変更を通知します。 4 つのライブ領域関数は、「アラート」、「ステータス」、「ログ」、「タイマー」と、より一般的な「マーキー」です。それぞれは暗黙的に aria-live 値を持ちます。実際には、「alert」と「log」はそれぞれ「assertive」と「polite」を意味し、「status」は「polite」を意味します。

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

「アラート」と「ステータス」のどちらを選択するかは、実際の結果を伴う設計上の決定です。 「アラート」はスクリーン リーダーが読み取っているものをすべて停止します。これはエラーや緊急の通知に適していますが、過度に使用すると有害です。 「ステータス」は一時停止を待ちます。一時停止は進行状況メッセージと確認テキストと同時に表示されます。

コンテンツが変更される前に、ライブ リージョンが DOM 内に存在している必要があります。 role="alert" 要素とそのテキストを同時に挿入すると、変更時にリージョンが存在しなかったため、アナウンスが行われないことがよくあります。信頼できるパターンは、ページの読み込み時に空のライブ領域をレンダリングし、後でそのテキスト コンテンツを更新することです。

ARIA ロールを使用しない場合

ARIA を使用する際の 2 番目のルールは、本当に必要な場合を除き、作成者はネイティブ セマンティクスを変更すべきではないということです。 5 番目のルールは、すべてのインタラクティブ要素は、その機能に関係なく、キーボードからアクセスでき、フォーカス可能でなければならないと規定しています。

ロールを追加しても動作は追加されません。 <div> に role="button" を指定すると、フォーカスに失敗し、入力やスペースバーに応答せず、フォームを送信できなくなります。 tabindex="0"、入力とスペースのキーストローク ハンドラー、および多くの場合「ロールに適した」状態管理を追加する必要があります。この時点で、実際の「」を使用すると、必要なコードとエラーが少なくなります。

一部の役割は、誤って適用すると実際に有害になります。 role="presentation" および role="none" は、要素からセマンティクスを削除し、実装によってはその必要な子孫からもセマンティクスを削除します。 「role=“application”」を適用すると、スクリーン リーダーがキーストロークのインターセプトを停止するモードに切り替わります。これにより、カスタム キーボード処理が不完全な場合にユーザーが罠にかかる可能性があります。

役割を選択するための意思決定フレームワーク

短いシーケンスを実行すると、ほとんどの ARIA ロール エラーを防ぐことができます。 ARIA ロールとは何か、およびその使用方法を理解するには、次の手順に従います。

1. ウィジェットまたは領域を特定します。 要素の実際の名前を分かりやすい言葉で指定します。
2. ネイティブ HTML と同等のものを確認します。 HTML-AAM マッピングを調べます。 <button>、<select>、<details>、または <dialog> が適合する場合は、それを使用してください。
3. 適合するネイティブ要素がない場合は、最も近い ARIA ロールを選択します。 それが現在の仕様に存在し、抽象的ではないことを確認します。
4. 必要な状態とプロパティを追加します。 ロールの定義で必須の属性を確認します。
5. キーボード操作パターンを実装します。 ウィジェット タイプについては、「WAI-ARIA オーサリング プラクティス ガイド」に従ってください。
6. 少なくとも 2 つのスクリーン リーダーとブラウザの組み合わせを使用してテストします。 アナウンス、状態、キーボード フローを確認します。

ステップ 3 ～ 6 では、ほとんどのカスタム ウィジェット エラーが発生します。ステップ 5 でキーボード パターンをスキップすると、正しくアドバタイズするものの操作不能なウィジェットが作成されます。これはおそらく ARIA をまったく使用しないよりも悪いです。

テストおよび検証ツール

自動ツールは、無効なロール値、必要なプロパティの欠落、それらをサポートしていない要素に適用されているロールなどの構造エラーを検出します。 axe-core は、多くのブラウザ拡張機能の背後にあるエンジンであり、ARIA ルールの定義されたサブセットをチェックします。 IBM Equal Access アクセシビリティ チェッカーと W3C 独自の Nu HTML チェッカーでも、ロールの不正使用が示されています。

自動化ツールでは、ロールが正しいアナウンスを生成するかどうか、またはキーボード操作が機能するかどうかを検証できません。 NVDA と Firefox、JAWS と Chrome、または VoiceOver と Safari を使用した手動テストは引き続き必要です。 Accessibility Insights for Web 拡張機能は、自動チェックと、キーボードとスクリーン リーダーの検証を含むガイド付き手動評価を組み合わせたものです。

ARIA 仕様自体、WAI-ARIA オーサリング プラクティス ガイド、および HTML-AAM マッピング ドキュメントは、aria ロールとは何かについての信頼できる参考資料です。 MDN Web Docs ARIA Reference は、各ロールの仕様を参照する、厳選された便利な二次ソースです。

重要なポイント

• ARIA ロールは要素が何であるかを宣言します。 WAI-ARIA 1.2 では 6 つのカテゴリに 87 の役割が定義されており、抽象的な役割がマークアップに現れることはありません。
• ネイティブ HTML 要素には暗黙的なロールと組み込みの動作があるため、ARIA を使用するときの最初のルールは、それらを「div」と「role」よりも優先することです。
• ロールには、サポートされている状態とプロパティが必要です。 aria-checked のない role="checkbox" は無効であり、使用できません。
• 役割を追加しても、キーボードの動作やフォーカス機能が追加されることはありません。これらは個別に実装してテストする必要があります。
• ランドマーク ロールとライブ リージョン ロールには、機能するかどうかを決定する場所とタイミングのルールがあります。
• 自動チェックツールは構造上のエラーのみを検出します。さまざまなブラウザの組み合わせに対するスクリーン リーダーのテストは依然として必要です。

ARIA の役割とは何かを理解するには、これらの役割が支援技術の要素の目的を定義していることを思い出してください。

出典と詳細情報

• WAI-ARIA — Wikipedia: Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) は、World Wide Web Consortium (W3C) によって発行された技術仕様です。

よくある質問

ARIA の役割を簡単に言うと何ですか?

ARIA ロールは、要素が何を表すかを支援技術に伝えるために HTML 要素に付けるラベルです。 <div role="button"> は、一般的なテキストではなくボタンとしてアナウンスされます。ロールは、基礎となるタグが提供しない意味を提供しますが、それ自体で動作、フォーカス処理、またはキーボード サポートを追加することはありません。

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

ロールは要素のタイプを記述し、属性はその状態、値、または関係を記述します。 role="slider" はスライダーを識別します。 aria-valuenow="50" は現在の位置を報告し、aria-labelledby はそのラベルを指します。ロールと属性は一緒に使用され、各ロールはサポートする属性を定義します。

ARIA ロールはいくつありますか?

WAI-ARIA 1.2 では、抽象、ウィジェット、ドキュメント構造、ランドマーク、ライブ領域、ウィンドウの 6 つのカテゴリにグループ化された 87 のロールが定義されています。 widget や inputのような抽象的な役割は、仕様の内部分類のためにのみ存在し、HTML では決して記述すべきではありません。この数は仕様が改訂されるたびに増加します。

セマンティック HTML の代わりに ARIA ロールを使用する必要がありますか?

いいえ。ARIA 使用の最初のルールは、必要なセマンティクスと動作を備えたネイティブ HTML 要素が存在する場合は常にネイティブ HTML 要素を優先するというものです。 <div role="button"> ではなく <button> を使用し、<div role="navigation"> ではなく <nav> を使用します。 ARIA ロールは、適切なネイティブ要素が存在しない場合のフォールバックです。

ARIA ロールはすべてのブラウザーとスクリーン リーダーで機能しますか?

button、link、heading、navigationなどのコア ロールは、最新のブラウザーやスクリーン リーダーで確実にサポートされています。デジタル パブリッシング モジュールの役割を含む、新しい役割やより特殊な役割は、サポート状況が異なります。ユーザーが使用する特定のブラウザとスクリーン リーダーの組み合わせでテストすることによってのみ、確信を得ることができます。

ARIA ロールを追加するとアクセシビリティが損なわれる可能性がありますか?

はい。暗黙的なロールをオーバーライドすると、role="presentation"がデータ テーブルに適用される場合など、有用なセマンティクスが失われる可能性があります。カスタム キーボード処理が不完全な場合、role="application"を適用するとユーザーがブロックされる可能性があります。ネイティブ要素での冗長なロールにより、不要なノイズが発生し、場合によっては矛盾したアナウンスが発生することがあります。