アクセシブル・リッチ・インターネット・アプリケーション（WAI-ARIA）1.3

重要かつ多くの場合時間的制約のある情報を持つライブリージョンの一種。関連：alertdialog、status。

alertはユーザーに直ちに重要なメッセージを伝えるために使われます。音声警告の場合、alertは聴覚障害者へのアクセシブルな代替を提供します。alert ロールは、アラートメッセージを含む要素に付与します。alertは、statusロールの特殊な形で、原子的なライブリージョンとして処理されます。

alertはアサーティブライブリージョンであり、支援技術ユーザーへ直ちに通知を発生させます。OSが許すなら、ユーザーエージェントはアクセシビリティAPI経由でシステムアラートイベントを推奨（SHOULD）発火すべきです。

alertが処理されるのに、著者やユーザーエージェントがフォーカスを設定・管理する必要はありません。alertはフォーカスを受ける必要がないため、著者はユーザーにalertを閉じることを要求すべきではありません（SHOULD NOT）。もし著者がアラートの伝達時にフォーカスを移したい場合は、alertdialogをalertの代わりに使うべきです（SHOULD）。

alertロールの要素はaria-live値assertiveおよびaria-atomic値trueが暗黙的に設定されます。

ダイアログ内で初期フォーカスが要素に移る、アラートメッセージを含むダイアログの一種。関連：alert、dialog。

alertdialogはユーザーに警告メッセージを伝えるために使われます。alertdialog ロールは、アラートメッセージとダイアログ全体を含むノードに適用します。著者は、alertdialogが表示されている間、キーボードやマウスの操作がそのダイアログ内でのみ有効となるようにして、アラートダイアログをモーダルにすべきです（SHOULD）。aria-modalを参照してください。

alertと異なり、alertdialogはユーザーからの応答を受けることができます。たとえば「通知を理解したか」などの確認入力が想定されます。アラートダイアログを表示した時、著者はダイアログ内のアクティブな要素（フォームコントロールや確認ボタン等）にフォーカスを当てるべきです（SHOULD）。ユーザーエージェントは、意図されたアクセシビリティAPIが指定されていれば、アラート作成時にアクセシビリティAPI経由でシステムアラートイベントを発火すべきです（SHOULD）。

著者はalertdialogでアラートメッセージ要素を参照するためにaria-describedbyを指定すべきです（SHOULD）。指定しない場合、支援技術はアラートメッセージ内容を決定するため内部リカバリ手段を使うことがあります。

1つ以上のフォーカス可能な要素を含み、キーボードやジェスチャ入力等、widgetロールによってサポートされる標準的な操作パターンに従わないユーザー入力が必要なstructure。

一部のユーザーエージェントや支援技術には「ブラウズモード」があり、上下矢印キーなどの標準入力イベントを読取カーソル操作のために奪取します。このブラウズモード動作により、widgetロールを持たない要素は、こうしたキーボード・ジェスチャイベントでの対話ができません。

WAI-ARIAのwidgetロールでは対応できない操作モデルを持つ要素が必要な場合、著者はその要素にapplicationロールを設定してもよい（MAY）です。ユーザーがapplicationロールの要素に入った場合、標準入力イベントを奪取する支援技術は、入力イベントをアプリケーションに直接渡すモードへ移行すべきです（SHOULD）。

例：プレゼンテーションスライドエディターでは、矢印キーでテキストボックスや画像要素の位置を変更します。こうした操作はARIAのwidgetロールで適合するモデルがないため、著者はスライドコンテナにapplicationロール、およびaria-roledescriptionで「スライドエディタ」などの説明、aria-describedbyで説明テキストを指定できます。

一部支援技術ではapplication内のフォーカス可能要素しかユーザーが利用できないため、著者はアプリケーション内の非装飾的な静的テキストや画像コンテンツもアクセシブルとなるよう、以下いずれかの手法を必ず使う必要があります（MUST）：

1. aria-labelledbyまたはaria-describedbyで、内容をフォーカス可能な要素と関連付ける。
2. 内容を、documentまたはarticleロールのついたフォーカス可能な要素内に配置する。
3. フォーカス管理で説明されているように、aria-activedescendantを更新して、フォーカス中内容を含む要素を参照することで、アクセシビリティ子孫のフォーカス管理を行う。

ドキュメント、ページ、またはサイトの独立した構成部分となる合成物からなるページセクション。

articleはランドマークにはなりませんが、入れ子にしてディスカッション構造を形成でき、支援技術はその入れ子構造にも配慮してユーザーの理解を支援できます。articleはフォーラムへの投稿、雑誌や新聞記事、ブログエントリ、ユーザーコメントなど独立した内容全般に利用できます。「独立」とはその内容が単独でも成立する（例：シンジケーション先で利用できる）という意味です。ただし要素自体は祖先との関連を持ち、例えば親body要素の連絡先情報はarticleにも適用されます。articleの入れ子では、子articleが親articleの内容に関するものを表します。たとえば、コメントがブログ記事のarticleの子articleとして表現される場合です。記事の著者、見出し、日付等は入れ子の子articleには適用されません。

ユーザーがarticleロールを持つ要素に移動したとき、多くの支援技術（標準キーボードイベントを処理するもの）は標準キーボードイベントをWebアプリにパスせずドキュメント閲覧モードに切り替えるべきです（SHOULD）。一部の支援技術では、入れ子構造のarticleも階層移動機能として提供されます。

articleがfeed内の場合、著者はaria-posinsetやaria-setsizeの値を指定してもよい（MAY）です。

ページ固有の内容ではなく、主にサイト全体に関連する内容を含むlandmarkです。

サイト指向の内容には、サイトのロゴやスポンサーのアイデンティティ、サイト専用の検索ツールなどが一般的に含まれます。バナーは通常ページの上部に表示され、多くの場合幅いっぱいに広がります。

支援技術は、ユーザーがbannerロールを持つ要素に素早く移動できるようにすべきです（SHOULD）。 ユーザーエージェントは、bannerロールの要素をナビゲーション用のランドマークとして扱うべきです（SHOULD）。 ユーザーエージェントは、ユーザーがbannerロールの要素に素早く移動できるようにしてもよい（MAY）です。

著者は、1ページにつきbannerロールを持つ要素は1つまでにすべきです（SHOULD）。

他の出典から引用されたコンテンツのセクション。

クリックまたは押下時にユーザー操作を開始できる入力。関連：link。

ボタンは主に個別動作のために使われます。ボタンの見た目を標準化するとウィジェットがボタンであることの認知が向上し、ツールバーなどでもよりコンパクトに表示できます。

ボタンは、オプションで属性aria-pressedをサポートします。aria-pressed属性が空でない場合、そのボタンはトグルボタンです。aria-pressedがtrueの時ボタンは「押された」状態、aria-pressedがfalseだと未押下となります。属性が無ければ、単なるコマンドボタンです。

figure、grid、group、radiogroup、table、またはtreegridの名称や説明となる可視コンテンツです。

caption を使う場合、著者は次を満たすべきです（SHOULD）：

• captionは、figure、grid、group、radiogroup、table、またはtreegridの子孫である。
• captionは、grid、group、radiogroup、table、またはtreegridの最初の非generic子孫である。
• captionは、figureの最初または最後の非generic子孫である。

captionが含まれる要素のアクセシブルネームとなる場合、著者はその要素にcaption要素を参照するaria-labelledbyを指定すべきです（SHOULD）。

<div role="radiogroup" aria-labelledby="cap">
   <div role="caption" id="cap">
     お好きなフルーツを選んでください
   </div>
   <!-- ... -->

captionが名前と説明を両方に使われている場合、著者は caption 内の「名前」になる要素を aria-labelledby で、説明となる要素を aria-describedby で参照してもよい（MAY）です。

<div role="table" aria-labelledby="name" aria-describedby="desc">
   <div role="caption">
     <div id="name">大会参加者一覧</div>
     <div id="desc">
       このテーブルは過去4週間で大会に参加した合計人数（500人）を示しています。
     </div>
   </div>
   <!-- ... -->

captionが長い説明文の場合や、説明に理解上重要なセマンティクス要素が含まれている場合、著者はcaption内の「名前」要素をaria-labelledby、説明要素をaria-detailsで参照してもよい（MAY）です。

<div role="figure" aria-labelledby="name" aria-details="details">
  <!-- ここに複雑なデータビジュアライゼーションSVGなど -->
   <div role="caption">
     <div id="name">20XX年度の販売情報</div>
     <div id="details">
       この棒グラフは5年間の販売総額を示します。昨年度の販売情報
       を確認したり、前年情報
       を上に重ねて表示したりできます。
     </div>
   </div>
   <!-- ... -->

captionが説明目的のみで、親要素のアクセシブルネームとなる文字列がない場合はaria-labelやaria-labelledby も利用でき、captionはaria-details経由で説明とみなしてもよい（MAY）です。

<div role="figure" aria-label="販売情報" aria-details="details">
  <!-- ここに複雑なデータビジュアライゼーションSVGなど -->
   <div role="caption" id="details">
     この棒グラフは5年間の販売総額を示します。昨年度の販売情報
     を確認したり、前年情報
     を上に重ねて表示したりできます。
   </div>
   <!-- ... -->

表形式コンテナ内のセル。関連：gridcell。

著者は必ず（MUST）、elementにcell roleを指定した場合は、それがrole rowを持つ要素のアクセシビリティ子要素となるようにしなければなりません。

3つの値（true、false、mixed）を持つチェック可能な入力。

aria-checked属性は、 checkboxがチェック済み（true）、未チェック（false）、または混合（mixed）（チェック・未チェックが混在するグループ）のいずれであるかを示します。多くのチェックボックスはmixed値を使用せず、実質的にはboolean型のチェックボックスです。

内容がコンピュータコード断片であるセクション。

codeロールの主な役割は支援技術に「この内容はコンピュータコード」であり、特別な表現（特に音声合成時）が必要かもしれないことを伝えることです。特にスクリーンリーダー等の音声出力機能では、"-"のような記号も省略せず読み上げるようすべきです（SHOULD）。

列のヘッダー情報を含むセル。

columnheaderは、テーブルやグリッドにおける列ヘッダーとして使用できます。また、円グラフなどでデータ内の同種の関係性を表すためにも使えます。

columnheaderは、その列内のすべてのセルと構造的な関係を持ちます。これはHTMLのth要素（列スコープ付き）と等価です。

著者は必ず（MUST）、elementにcolumnheader roleを付与した場合、それがrowロールを持つ要素のアクセシビリティ子要素になるようにしなければなりません。

aria-selected状態をcolumnheaderに適用しても、該当列のすべてのセルにaria-selectedが自動伝播されることはありません。著者が特定アプリケーションの要件に応じて選択伝播することは可能（MAY）です。

columnheaderロールはインタラクティブなグリッド、非インタラクティブなテーブル両方で使えますが、aria-readonlyやaria-requiredはインタラクティブ要素にのみ適用されます。そのため、著者はtable下のcolumnheaderでaria-requiredやaria-readonlyを使用すべきではありません（SHOULD NOT）し、ユーザーエージェントもgrid下でない限りこれらのプロパティを支援技術へ公開すべきではありません（SHOULD NOT）。

inputが、listboxやgridなど、他の要素を制御し、そのpopupによってユーザーがinputの値を設定するのを支援するものです。

comboboxは、名前付き入力フィールドと補助的なpopup要素による値選択支援機能を統合したものです。 combobox入力は、編集・入力が可能な1行テキストフィールド、または値を表示するのみの要素でもよい（MAY）です。 comboboxがテキスト入力対応かつaria-autocompleteによる自動補完動作を持つときは、著者は必ず（MUST）、comboboxにaria-autocompleteを対応する値で付与してください。

通常、comboboxの初期状態は折りたたみ（collapsed）です。折りたたみ時は、combobox要素本体と、個別の（オプション）popup制御buttonのみが見えます。combobox本体とpopup要素の両方が表示されている状態を展開（expanded）と呼びます。著者は必ず（MUST）、展開時はcomboboxにaria-expandedをtrue、折りたたみ時はfalseと設定してください。

著者は必ず（MUST）、comboboxに関連付けるpopup要素にlistbox、tree、grid、またはdialogロールを付与してください。popupが表示時には必ず（MUST）comboboxのaria-controlsでpopup要素を参照します。

comboboxロールの要素は、暗黙的にaria-haspopup値がlistboxとなります。popup要素のロールがlistbox以外の場合、著者は必ず（MUST）popupに合わせたaria-haspopup値を明示的に指定してください。

もしUIにpopupの表示制御用アイコンがあり、ポインタやタッチイベントで操作できる場合、著者はその要素にbuttonロールを付け、フォーカス可能だがページのTab順には含めず、comboboxの子孫にならないようすべきです（SHOULD）。更に、キーボードでもcomboboxおよびpopup内要素間のフォーカス移動機構を設けるべきです（SHOULD）。例：下矢印キーで入力欄からpopup要素の最初のフォーカス対象に移動など。もしpopupがaria-activedescendantをサポートする場合、実際のフォーカス移動の代わりにcomboboxのaria-activedescendant値で操作でき、popup子孫のどれかがアクティブなら、著者はaria-activedescendantをその子孫要素idにしてもよい（MAY）です。

ユーザーエージェントは必ず（MUST）、comboboxロール要素の値を支援技術に公開してください。comboboxの値は以下のいずれかです：

• combobox要素が値を持つホスト言語要素（例：HTMLのinput要素）の場合、その要素の値がcomboboxの値となります。
• それ以外の場合、comboboxの値はその子孫要素から決まり、buttonの名前算出方法と同様に決定します。

    <label id="tag_label" for="tag_combo">Tag</label>
  <input type="text" id="tag_combo"
      role="combobox" aria-autocomplete="list"
      aria-haspopup="listbox" aria-expanded="true"
      aria-controls="popup_listbox" aria-activedescendant="selected_option">
<ul role="listbox" id="popup_listbox" aria-labelledby="tag_label">
   <li role="option">Zebra</li>
   <li role="option" id="selected_option">Zoom</li>
</ul>

comboboxの実装は機能・挙動が多様であり、著者が考慮すべき点が多くあります。設計パターン詳細はWAI-ARIAオーサリングプラクティスをご参照ください。

アクションは実行するが入力データは受け取らないウィジェット型。

commandは抽象ロールであり、オントロジー用です。著者は絶対に（MUST NOT）内容にcommandロールを使用しないでください。

コメントは他の内容に対する反応・意見を表す内容です。

コメントは小さなテキスト片から他のコメント、記事全体まで様々な可視コンテンツに注釈できます。著者はコメントとその対象コンテンツとの関係を下記のように明示すべきです（SHOULD）：

1. コメントが他のcommentへの返信の場合：
   • すべての先祖コメントがDOM上にあるなら、返信となるcommentを返信先commentの論理的子孫（DOMの子要素化やaria-ownsで関連付け）にしてください。
   • また、すべての先祖コメントがDOM上にない（ページ分割等）場合は、階層レベルはaria-levelで、リスト内位置はaria-posinsetおよびaria-setsizeで指定してもよい（MAY）です。
2. その他、コメントがページ内他の内容に関連する場合：
   • コメント対象要素にaria-detailsで該当comment要素を参照すべきです（SHOULD）。
   • 同じ対象に複数コメントがあるなら、それぞれ個別のcommentをaria-detailsで参照するか、親コンテナをまとめてaria-detailsで参照してください。コンテナ（comment複数格納要素）を参照する場合、著者はgroupやregionロールを必ずつけてください（SHOULD）。

著者がcomment要素にaria-level、aria-posinset、aria-setsizeいずれも明示しない場合は、ユーザーエージェントは必ず（MUST）値を自動算出し支援技術へ公開します。

主コンテンツの兄弟または直下に配置し主コンテンツを補足するよう設計されたlandmarkです。関連する主コンテンツと分離しても意味が保たれる補助領域です。

このロールを使う内容例として、ポータルの場合は上映時間、現在の天気、関連記事、注目株価など様々です。補助コンテンツが主コンテンツから完全に独立できる場合は、より一般的なロールを用いるのが適切です。

支援技術は、ユーザーがcomplementaryロール要素に素早く移動できるようすべきです（SHOULD）。 ユーザーエージェントは、complementaryロール要素をナビゲーション用ランドマークとして扱うべきです（SHOULD）。 ユーザーエージェントは、これら要素への移動支援を提供してもよい（MAY）です。

ウィジェットのひとつで、ナビゲーション可能なアクセシビリティ子孫を含むことができます。

著者は、複合ウィジェットがWebページ内の広域ナビゲーションで一つのナビゲーション停止点として存在するよう推奨します（SHOULD）。複合ウィジェットにフォーカスが入った後は、ユーザーがその複合要素内のelement、つまりアクセシビリティ子孫に移動できる独立したナビゲーション手段を用意すべきです（SHOULD）。

compositeは抽象ロールであり、オントロジー用です。著者はcompositeロールをコンテンツで使用してはなりません（MUST NOT）。

親ドキュメントに関する情報を含むlandmarkです。

この領域に含まれる情報例として、著作権やプライバシーステートメントへのリンクなどがあります。

支援技術は、ユーザーがcontentinfoロールの要素に素早く移動できるようすべきです（SHOULD）。 ユーザーエージェントはcontentinfoロール要素をナビゲーション用ランドマークとして扱うべきです（SHOULD）。 ユーザーエージェントはユーザーがcontentinfoロール要素に素早く移動できるようしてもよい（MAY）です。

著者は1ページにつきcontentinfoロールを持つ要素は1つまでにすべきです（SHOULD）。

用語または概念の定義です。関連：term。

著者は、定義対象となるelementを特定し、その要素にtermロールを付与しなければなりません（MUST）。

definitionロールをフォームコントロールのようなインタラクティブ要素に使用すると、支援技術利用者がその要素を操作できなくなるおそれがあるため、著者は使用すべきではありません（SHOULD NOT）。

deletionは、削除された内容・削除提案中の内容、あるいは付随する内容の文脈で無関係になった内容を表します。関連：insertion。

deletionは通常、2つのコンテンツバージョンの差分マークや、複数人で編集しているときに削除提案候補を示すために使われます。

ダイアログは、ウェブアプリケーションの主要ウィンドウの子ウィンドウです。HTMLページの場合、主要なアプリケーションウィンドウはWebドキュメント全体、つまりbody要素です。

ダイアログは主にユーザーに入力や応答を促すために使われます。作業の流れを中断させるダイアログは通常モーダルです。関連：alertdialog

著者は必ず（MUST）ダイアログにアクセシブルネームを付与しなければなりません。これはaria-labelやaria-labelledby属性で実現できます。

著者は、すべてのダイアログ（モーダル・非モーダル共）に少なくとも1つのフォーカス可能な子孫要素があるよう推奨します（SHOULD）。モーダルダイアログが表示された時には、要素にフォーカスを当て、そのフォーカス管理も推奨します（SHOULD）。

【ARIA 1.2 で非推奨】グループメンバーへの参照リスト（例：静的な目次）。

directoryは、リンク付き／リンクなしの静的な目次です。リストや入れ子リストで作られた目次も含みます。動的な目次にはtreeロールの利用が考えられます。

要素であり、その内容を支援技術利用者がリーディングモードで閲覧することを想定しています。

ユーザーエージェントのフォーカスがdocumentロールを持つ要素へ移動した時、静的コンテンツ閲覧用のリーディングモードを備えた支援技術は、そのモードへ切り替えてもよい（MAY）です。また、上下キー入力などの標準イベントを読取カーソル操作用に奪取します。

リーディングモード対応の支援技術は、widgetやapplicationロール以外の要素はすべてデフォルトでリーディングモード扱いにするため、documentロールが支援技術の動作切り替えで有効になるのは、そのdocumentロールがwidgetまたはapplicationロール要素のフォーカス可能な子要素の場合のみです。例として、application要素内にある静的リッチテキスト要素にdocumentロールを付与し、tabindexを0にすることで、スクリーンリーダーユーザーがTabキー操作でdocument要素へフォーカスを移したときに、そのリーディングカーソルでテキストを読めるようにできます。

1つ以上の強調文字。関連：strong。

emphasisロールの目的は意味的な強調・ストレスを伝えることです。単に表記上の変化だけで意味が変わらない場合には使いません。emphasisロールを使わないことで内容の意味が変わる場合だけ使うべきです（SHOULD）。

emphasisロールは重要性自体を伝えるものではありません。重要性にはstrongロールの使用がより適切です。

スクロール可能なlistで、articlesがリストの両端で追加または削除される場合があります。

feedは、ドキュメント閲覧モードを持つ支援技術のユーザー、例えばスクリーンリーダーが、読み取りカーソルでリッチなコンテンツのストリームを読んだりスクロールしたりできるようにします。このストリームは、ユーザーが読むにつれて無限にスクロールできるよう次々にコンテンツを読み込めます。feed内では、支援技術がユーザーの読み取りカーソル移動をWebアプリケーションに通知するため、ユーザーエージェントのフォーカスを移動させ、アプリケーションが新しいコンテンツの追加や可視位置の調整を行うことを可能にします。feedはまた、著者が追加・削除が発生していることを支援技術に知らせることで、読み取りやパフォーマンスを損なわず最新の表示に更新できるようにします。

例えば、feedをニュース記事のストリーム表示に使うことができます。各articleはテキスト、リンク、画像、コメント、シェアやコメント用ウィジェットを含むニュースを表示します。スクリーンリーダーユーザーが各ストーリーを読んだり操作し、読みカーソルを次のストーリーに動かすと、そのストーリーが画面に現れ、必要に応じて新しいストーリーが追加で読み込まれます。

feedは、その子にarticleロールを持つ要素を持つコンテナ要素です。feedの両端でarticlesの追加・削除が行われる際には、著者は変更前にfeed要素のaria-busyをtrueにし、変更完了後にfalseに戻すべきです（SHOULD）。また、feedの途中でarticlesの挿入・削除は避けるべきです（SHOULD）。これにより、支援技術がユーザーの読み取りカーソル移動と同時発生する変更にうまく対処できます。

著者はfeed内の各articleをフォーカス可能とし、アプリケーションはarticleやその子孫要素にuser agentのフォーカスが当たったときに、そのarticleを画面にスクロールインするようにすべきです（SHOULD）。例えばHTMLでは、各article要素にtabindex属性で-1や0を設定します。

支援技術の読みカーソルが1つのarticleから別のarticleに移る際、支援技術はその読み取りカーソルのあるarticle自体にuser agentのフォーカスを合わせるべきです（SHOULD）。ただし、読みカーソルがarticle内のフォーカス可能な要素にいる場合は、代わりにその要素へフォーカスしてもよい（MAY）です。

支援技術の読みカーソルで別のarticleにスクロールするにはページ内に次のarticleが必要なため、著者はユーザーエージェントのフォーカスが端のarticleに届く前に追加のarticlesのさらなる読み込みを試みるべきです（SHOULD）。もしくは端にbutton要素など「さらに読み込む」仕組みを含むarticleを配置してもよい（MAY）です。

簡単なラベル提供に加えて、著者はfeed内のarticle要素にaria-describedbyを指定することで、スクリーンリーダーがラベルのあとに何を読み上げるか調整してもよい（MAY）です。スクリーンリーダーはfeedコンテンツをラベル＋アクセシブルな説明の両方で読みあげて概要把握を促し、ウィジェット等繰り返しや重要度の低い要素は省略できます。

著者は、支援技術によるarticleナビゲーション機能を持たないユーザーでもキーボードでfeed内のarticlesを移動できるよう、フォーカス移動のキーボードコマンドを用意すべきです（SHOULD）。

feed内の記事数が固定の場合、著者はそのfeed内article要素でaria-setsizeを指定してもよい（MAY）です。ただし非常に多い・未定・頻繁に変化する場合は、aria-setsizeを-1で「不明」と表現してもよい（MAY）です。

デザインパターンの詳細はWAI-ARIAオーサリングプラクティスを参照してください。

知覚できるsectionのひとつで、通常グラフィカルドキュメント、画像、メディアプレイヤー、コードスニペット、例文などを含みます。figureのパーツはユーザーがナビゲーションしてもよい（MAY）です。

著者はfigureを主文から参照できるようすべきです（SHOULD）が、figure自体の表示位置は参照先と同じ位置である必要はありません。著者はfigureにcaptionロール（名称・説明もしくは両方）を付与してもよい（MAY）です。captionを提示し、それがfigureの内容説明となる場合には、aria-detailsでfigureと関連付けすべきです（SHOULD）。

著者はfigureにaria-labelでアクセシブルネームを持たせたり、aria-labelledbyで他のテキストを参照して要素のラベルやアクセシブルネームにしてもよい（MAY）です。

figureとそのcaptionとの関連付けについてはcaptionロールを参照してください。

支援技術はユーザーが素早くfigureに移動できるようすべきです（SHOULD）。ユーザーエージェントも同様の機能を提供してもよい（MAY）です。

アイテムやオブジェクトの集合を包含し、それらが合わさってフォームを構成するlandmark領域。関連：search。

フォームにはホスト言語のフォームコントロール、スクリプト制御要素、ハイパーリンクなどが混在できます。ただし可能な限りネイティブのホスト言語セマンティクスでフォームコントロールを作成することが推奨されます。入力目的が検索の場合、formロールではなくsearchロールの使用が望ましい（SHOULD）です。

著者は必ず（MUST）各formロール要素にフォームの用途を簡潔に説明するラベルを付加しなければなりません。可視ラベルがある場合はaria-labelledbyで参照すべきです（SHOULD）。また可能なら、そのラベルを見出し要素内に配置すべきです（SHOULD）。この見出しは標準ホスト言語のheading要素でも、headingロール要素でもよい（MAY）です。

著者がスクリプトでonsubmitイベント以外のユーザー操作（例：要素値変更など）でフォーム送信する場合は、必ず（SHOULD）事前にユーザーへ通知してください。

支援技術はユーザーがformロール要素に素早く移動できるようすべきです（SHOULD）。ユーザーエージェントは、formロールかつアクセシブルネームを持つ要素をナビゲーション用ランドマークとして扱うべきです（SHOULD）。ユーザーエージェントはformロール要素へ素早く移動できる支援を提供してもよい（MAY）です。

自身にはセマンティックな意味を持たない、名前のないコンテナ要素。

genericロールはホスト言語の暗黙的ロール（例：HTMLのdivやspan）向けで、主にユーザーエージェント実装者向けです。著者はコンテンツで本ロールを用いるべきではありません（SHOULD NOT）。代わりに、暗黙のアクセシビリティセマンティクスを除去したい場合はpresentationまたはnone、名前付きコンテナで子孫を意味的にグループ化する場合はgroupなどを使うこともできます（MAY）。

presentationロールの要素と同様に、genericロールの要素も、その子孫に対してaria-live属性などごく一部のアクセシブル状態・プロパティを付与可能です。

ただし、presentationロールと異なり、許可されたアクセシビリティ属性が指定されている場合はユーザーエージェントはgeneric要素もアクセシビリティAPIに公開します。許可された属性が無い場合はスキップしてもよい（MAY）です。

複合型のwidgetで、1つ以上の行（row）に1つ以上のセルが含まれ、そのグリッド内の一部または全てのセルに、方向キーなど二次元ナビゲーションによりフォーカスできるものです。

gridロールは特定の視覚的（例：表形式など）な表示を示しません。これは関係性を要素間で定義します。単にチェックボックスやナビゲーションリンク集のグルーピングから、機能豊富なスプレッドシートアプリケーションまで幅広い用途に利用できます。

gridのセル要素にはgridcellロールが付きます。著者は任意で（MAY） rowheaderまたはcolumnheaderロールを用い、行・列ヘッダーセルを宣言できます。著者は必ず（MUST）、gridcell・columnheader・rowheaderロールの要素がrowロール要素のアクセシビリティ子要素となること、さらにそれらがrowgroupまたはgridのアクセシビリティ子要素となることを保証してください。

キーボード操作可能とするために、著者はgridの子孫のフォーカス管理をフォーカス管理のとおり推奨（SHOULD）します。ユーザーがキーボードでgrid内容をナビゲートする際は、著者は以下のようにフォーカスを設定推奨（SHOULD）します：

• gridcellの中身が、フォーカス時に矢印キーを消費しないインタラクティブなwidget（例：checkbox、button、link）1つのみの場合、そのウィジェット自体へ任意で（MAY）フォーカスを当て直接操作可能とできます。
• それ以外の場合は、推奨（SHOULD）として、フォーカスを受け取る要素がgridcell・rowheader・columnheaderとなるようにしてください。

さらに、フォーカス可能なセルの中に以下が含まれている場合、著者はそれら内部内容へのナビゲーションやインタラクション（編集）モードに切り替える機構を推奨（SHOULD）します：

• 矢印キーで操作するウィジェット（例：comboboxやradiogroup）
• 複数のインタラクティブ要素
• 編集可能な内容

たとえばスプレッドシートのセルにcomboboxや編集用テキストがある場合、Enterキーでセルの編集・操作モードへ切替し、方向キーで内部のcomboboxやtextboxを操作できます。もう一度Enter、Tab、Escape等で元のグリッドナビゲーションモードに戻す実装も可能です。

著者は任意で（MAY）gridcellを数式結果表示用に使い、ユーザーが編集可能にしてもかまいません。たとえばスプレッドシートで、数式計算結果を表示し、編集モード時のみtextboxを現れるようにできます。

aria-readonlyがgridロール要素に指定されている場合、ユーザーエージェントは必ず（MUST）、そのgrid配下の全てのgridcellアクセシビリティ子孫へ値を伝播し、アクセシビリティAPIで公開してください。著者は個々のgridcellでこの値を上書きしてもよい（MAY）です。

セル編集機能のあるgridで、フォーカス可能なgridcellが編集不可のとき、著者はそのgridcellにaria-readonlyをtrueとしてもよい（MAY）です。ただしaria-readonlyの値は、そのセル内内容が編集可能か否かのみを表し、grid自体のナビゲーションや操作可否を示すものではありません。

aria-readonlyを指定しなかった場合でも、そのgridやgridcellに編集可能内容が含まれることを意味するものではありません。例えば、gridで編集できない要素（例：日付ピッカーの日付を示すlink集）を表示する場合はaria-readonly値指定は不要です。

著者は、フォーカス可能なgridcellにアクション対象としての選択機能を持たせる場合、aria-selected属性を用いてもよい（MAY）です。複数のgridcellを選択できるgridの場合、著者は推奨（SHOULD）としてgrid要素にaria-multiselectableをtrueとしてください。

WAI-ARIAはホスト言語要素を拡張できるため、gridは例えばHTMLのtableなど、ネイティブ要素・属性も再利用できます。たとえば著者がHTMLのtableにgridロールを付けた場合、子孫のtr・tdに個別でrow・gridcellロールを付ける必要はなく、ユーザーエージェントが自動的に適切に対応します。ネイティブテーブル要素の行・列の結合を表す場合は、WAI-ARIAのaria-rowspanやaria-colspanプロパティではなく、ホスト言語の標準属性（例：HTMLのrowspan/colspan）を使うことを推奨します（SHOULD）。

グリッドパターン実装の詳細はWAI-ARIA オーサリングプラクティスをご覧ください。

gridやtreegrid内のcellです。

gridcellはフォーカス可能、編集可能、選択可能です。gridcellはアプリケーションで必要な機能的関係を持たせるため、関係性（例：aria-controls）を持つこともできます。

著者がgridcellに行ヘッダー・列ヘッダーまたはその両方を持たせたいものの、該当ヘッダーがDOM構造では明示できない場合は、推奨（SHOULD）として、どのヘッダーセルが関連するかをgridcellのaria-describedbyで明示し、該当rowheaderやcolumnheaderロール要素を参照してください。

treegrid内では、著者は任意で（MAY） gridcellにaria-expanded属性を利用して展開可能セルとできます。aria-expanded属性が付与されている場合、それは個々のセルだけに適用され、親のrowには影響しません。主な用途はピボットテーブルのような挙動です。

著者は必ず（MUST）、roleがgridcellの要素を、rowロール要素のアクセシビリティ子要素にしなければなりません。

ページ要約や目次に支援技術によって含まれる想定がないUIオブジェクトの集まりです。

この点で、region（ページ要約や目次に含まれることを意図したグルーピング）と対比されます。

著者は推奨（SHOULD）として、ツリーウィジェットの兄弟ノードのコレクションのように、widget内部の論理的なまとまりとしてgroupを使います。ただし、たとえばlistbox内でgroupを使う場合、その子要素はoption要素に限る必須（MUST）という文脈依存の要件があります。よって、groupの適切な実装は、その利用される文脈で決まります。

著者は任意で（MAY） group要素を入れ子にできます。セクションがウェブページの目次に載る程度に重要なときは、著者は推奨（SHOULD）としてregionや標準ランドマークロールを付与してください。

ページのセクションの見出しです。

headingロールの要素を論理的アウトラインに整理するため、著者は必ず（MUST） aria-level属性で適切なネストレベルを示してください。

画像を構成する要素の集合のコンテナです。類義語はimgです。

画像を構成する要素の集合のコンテナです。類義語はimageです。

imgはキャプションや説明文、複数画像ファイル（まとめて1つの画像として見えるもの）を含められます。imgは、図形オブジェクトの集合で構成されているかどうかを問わず、文書中の単一のグラフィックを表します。imgロールをもつ要素が知覚可能であるためには、著者は必ず（MUST）その要素にアクセシブルネームを付与しなければなりません。これはaria-labelやaria-labelledby属性で実現できます。