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

重要で、通常は時間的制約がある情報を含むライブリージョンの一種です。関連：alertdialog、status。

alertは、ユーザーにとって即座に重要となるメッセージを伝えるために使用されます。音声警告の場合、alertは聴覚障害者にとってアクセシブルな代替手段となります。alertロールは、アラートメッセージを含む要素に適用します。alertは、statusロールの特殊な形式であり、atomicなライブリージョンとして処理されます。

alertは「アサーティブ」なライブリージョンであり、支援技術利用者に即時通知を引き起こします。オペレーティングシステムが許可する場合、ユーザーエージェントは、WAI-ARIAアラートが作成された際、アクセシビリティAPI経由でシステムアラートイベントをSHOULD発火するべきです。

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

alertロールを持つ要素は、暗黙のaria-live値がassertive、暗黙のaria-atomic値がtrueとなります。

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

alertdialogはユーザーに警告メッセージを伝えるために使用されます。alertdialogロールは、アラートメッセージおよびダイアログ全体を含むノードに設定します。コンテンツ著者は、alertdialog表示時にキーボード・マウス操作がダイアログ内だけで動作するようにして、モーダルにするべきです（SHOULD）。aria-modal参照。

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

著者はalertdialogにaria-describedbyを使って、ダイアログ内のアラートメッセージ要素を参照するべきです（SHOULD）。指定しない場合は、支援技術が内部回復機構によってアラートメッセージ内容を決定することになります。

structureであり、1つ以上のフォーカス可能な要素を含み、widgetロールでサポートされる標準的なインタラクションパターンに従わない、キーボードやジェスチャーなどのユーザー入力を必要とします。

一部のユーザーエージェントや支援技術にはブラウズモードがあり、標準の入力イベント（上下矢印キーなど）を捕捉してリーディングカーソルの制御に使います。このブラウズモード動作は、widgetロールを持たない要素がそうしたキーボードやジェスチャーイベントを受け取ってインタラクティブな機能を提供することを妨げます。

既存のWAI-ARIAwidgetロールでは対応できないインタラクションモデルの要素を作成する場合、著者はその要素にapplicationロールをMAY付与できます。そして、ユーザーがapplicationロールを持つ要素に入った際、標準入力イベントを捕捉する支援技術は、そのほとんどまたはすべての標準入力イベントをウェブアプリケーションにパススルーするモードにSHOULD切り替えるべきです。

例：プレゼンテーションスライドエディタでは、矢印キーでスライド上のテキストボックスや画像要素の位置を変更します。WAI-ARIAwidgetロールに対応するインタラクションモデルがないため、著者はスライドコンテナにapplicationロール、aria-roledescriptionを「Slide Editor」に設定し、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には適用されません。

ユーザーがarticleロールを持つ要素に移動した際、標準キーボードイベントを捕捉する支援技術は、キーボードイベントをウェブアプリケーションにパススルーするのではなく、ドキュメント閲覧モードにSHOULD切り替えるべきです。支援技術は、入れ子article要素階層をユーザーがナビゲートできる機能をMAY提供できます。

articleがfeed文脈にある場合、著者はaria-posinsetやaria-setsize値をMAY指定できます。

主にサイト指向のコンテンツを含むlandmarkです。ページ固有のコンテンツよりもサイト全体に関する内容が中心となります。

サイト指向のコンテンツには、サイトスポンサーのロゴやアイデンティティ、サイト専用の検索ツールなどが含まれることが一般的です。バナーは通常ページの最上部に表示され、ページ幅全体に広がることが多いです。

ユーザーエージェントは、bannerロールを持つ要素をナビゲーション用ランドマークとしてSHOULD扱うべきです。

どのdocumentやapplication内でも、著者はbannerロールを持つ要素を1つだけSHOULDマークすべきです。

他の情報源から引用されたコンテンツのセクションです。

クリックや押下でユーザーの操作をトリガーする入力要素です。関連：link。

ボタンは主に個別のアクションで使われます。ボタンの見た目を標準化することで、ユーザーがウィジェットをボタンとして認識しやすくなり、ツールバーなどでコンパクトな表示も可能となります。

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

可視コンテンツで、figure、table、grid、treegridを命名し、説明も可能です。

captionを使用する際、著者は以下をSHOULD確実にすべきです：

• captionがfigure、table、grid、またはtreegridの直下の子要素であること。
• captionがtable、grid、treegridの最初の子要素であること。
• captionがfigureの最初または最後の子要素であること。

著者は、親要素のfigure、table、grid、treegridにaria-labelledbyを設定し、captionロールを持つ要素を参照するべきです（SHOULD）。ただし、captionの中に親の名前と説明が含まれる場合は、著者はaria-labelledbyでcaption内の簡潔な名前要素を参照し、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>
   <!-- ... -->

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

roleがcellの要素は、rowロールを持つ要素内または所有されている必要があります（MUST）。

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

checkboxのaria-checked属性は、入力がチェックされている（true）、未チェック（false）、またはグループ内にチェックと未チェックが混在している（mixed）かを示します。多くのチェックボックスはmixed値を使わず、事実上ブール型チェックボックスとなります。

内容がコンピューターコード断片を表すセクションです。

codeロールの主な目的は、支援技術に対して内容がコンピューターコードであることを知らせ、特に合成音声による提示方法に特別な配慮が必要である場合があることを伝えることです。特に、スクリーンリーダーやテキスト読み上げツールは、一般記号（例：「-」など）が確実に読み上げられるよう、句読点の詳細な読み上げをSHOULD優先するべきです。

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

columnheaderは、テーブルやグリッドで列ヘッダーとして使用できます。円グラフなどでデータの関係を示す用途でも使えます。

columnheaderは対応する列内のすべてのセルとの関係を確立します。これはHTML th要素（列スコープ）と構造的に同等です。

roleがcolumnheaderの要素は、rowロールの要素内または所有されている必要があります（MUST）。

aria-selected状態をcolumnheaderに適用しても、ユーザーエージェントが対応する列内のすべてのセルにaria-selected状態を自動的に伝搬してはなりません（MUST NOT）。著者が必要に応じてこの伝搬を行うことはMAYです。

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

inputであり、listboxやgridなどを制御し、inputの値設定を補助するためにダイナミックにポップアップすることができる要素です。

comboboxは、名前付き入力欄と補助ポップアップ要素による値選択補助を機能的に組み合わせたものです。 comboboxの入力フィールドは編集や入力可能な単一行テキスト欄でもよいし、現在値のみ表示する要素でもかまいません。 comboboxがテキスト入力をサポートし、aria-autocompleteで定義されたオートコンプリート挙動を提供する場合、著者はcombobox要素に提供する挙動に応じたaria-autocomplete値をMUST設定する必要があります。

通常、comboboxの初期状態は折りたたみ（collapsed）です。 折りたたみ状態では、combobox要素と独立した（任意の）ポップアップコントロールbuttonのみが表示されます。 comboboxが展開（expanded）状態の場合、現在値を表示するcombobox要素と関連ポップアップ要素が両方表示されます。 著者は、comboboxが展開時はaria-expandedをtrueに、折りたたみ時はfalseにMUST設定する必要があります。

著者は、comboboxと関連付けるポップアップ要素にlistbox、tree、grid、dialogのいずれかのロールをMUST設定する必要があります。 combobox要素には、ポップアップ要素を参照する値をaria-controlsでMUST設定する必要があります。

comboboxロールを持つ要素は、暗黙のaria-haspopup値がlistboxとなります。 もしポップアップ要素のロールがlistbox以外の場合は、そのポップアップのロールに対応したaria-haspopup値を著者がMUST指定する必要があります。

UIにポインターやタッチ操作でポップアップの表示可否を制御する専用アイコンが含まれる場合、その要素にはbuttonロールを付与し、フォーカス可能だがTab順には含めず、combobox要素の子孫にしないことがSHOULD推奨されます。 また、キーボードでもcombobox要素とポップアップ内の要素間を移動できる仕組みをSHOULD著者が提供すべきです。 例えば、一般的な慣例としてDown Arrowで入力欄からポップアップ内の最初のフォーカス可能要素に移動できます。 ポップアップ要素がaria-activedescendantをサポートする場合は、フォーカス移動の代わりにcombobox要素のaria-activedescendant値を制御することもできます。 ポップアップ内の子孫がアクティブな場合、著者はcombobox要素のaria-activedescendant値をポップアップ内のアクティブ要素参照値に設定してもMAYです（フォーカスはcombobox要素上に保持）。

ユーザーエージェントは、comboboxロールを持つ要素の値を支援技術にMUST公開する必要があります。 comboboxの値は以下のいずれかで表されます：

• combobox要素が、値を持つhost言語要素（HTML inputなど）の場合は、その要素の値。
• それ以外の場合は、descendant要素の内容で表され、buttonの名前計算方法と同様に決定されます。

    <label for="tag_combo">タグ</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">
   <li role="option">ゼブラ</li>
   <li role="option" id="selected_option">ズーム</li>
</ul>

comboboxの実装は機能・動作が多岐にわたるため、著者には多くの重要な考慮事項があります。詳細はWAI-ARIAオーサリング実践でcomboboxデザインパターンの実装詳細を参照してください。

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

landmarkであり、DOM階層上で主コンテンツと同じ階層に配置されつつ、主コンテンツから分離されても意味が成立するように設計されています。

このロールに適したコンテンツは様々です。例としてポータルサイトでは、上映時間、現在の天気、関連記事、注目株などが該当します。complementaryロールは、含まれる内容が主コンテンツに関連していることを示します。もしcomplementary内容が主コンテンツから完全に分離可能なら、より一般的なロールを使うことが適切かもしれません。

ユーザーエージェントは、complementaryロールを持つ要素をナビゲーション用ランドマークとしてSHOULD扱うべきです。

ウィジェットであり、ナビゲーション可能な子孫や所有する子要素を含むことができます。

著者は、複合ウィジェットがウェブページ全体のナビゲーションシステム内で単一のナビゲーションストップとなるようSHOULD配慮すべきです。複合ウィジェットにフォーカスが当たった後は、著者はその子孫や所有子要素へ個別にナビゲーションできる仕組みをSHOULD用意すべきです。

親文書に関する情報を含むlandmarkです。

この領域には、著作権情報やプライバシー声明へのリンクなどの情報が含まれることが一般的です。

ユーザーエージェントは、contentinfoロールを持つ要素をナビゲーション用ランドマークとしてSHOULD扱うべきです。

どのdocumentやapplication内でも、著者はcontentinfoロールを持つ要素を1つだけSHOULDマークすべきです。

用語や概念の定義です。関連：term。

著者は、定義する要素にtermロールを付与し、aria-labelledby属性で参照するか、termロールの要素をdefinitionロールの要素の子孫にすることで定義対象を示すべきです（SHOULD）。

削除には、削除された内容や削除が提案されている内容が含まれます。関連：insertion。

deletionは通常、2つのバージョン間の差分をマークしたり、複数人でコンテンツを修正する場面で削除提案を示すために使われます。

ダイアログはウェブアプリケーションの主要ウィンドウの子ウィンドウです。HTMLページの場合、主要アプリケーションウィンドウは文書全体（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ロールとtabindex0を付与します。スクリーンリーダーユーザーがTabキーでdocument要素にフォーカスすると、そのテキストをリーディングカーソルで読むことができます。

1文字以上の強調された文字。関連：strong。

emphasisロールの目的は、内容を強調またはストレスを与えることです。意味に影響しないタイポグラフィの変更を伝えるためのものではありません。著者は、emphasisロールが無い場合に意味が変わる場合のみSHOULDこのロールを使用すべきです。

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

スクロール可能なlistで、articleが含まれます。スクロール操作によりarticleがリストの両端に追加・削除されることがあります。

feedは、ドキュメント閲覧モードを備えた支援技術（スクリーンリーダー等）が、リッチなコンテンツのストリームをリーディングカーソルで読み・スクロールできるようにします。コンテンツが無限に読み込まれ続ける場合もあり、ユーザーが読むにつれて新しいコンテンツが追加されます。feed内で、支援技術はユーザーのリーディングカーソル移動をウェブアプリケーションに通知するため、ユーザーエージェントのフォーカスを移動します。その結果、アプリケーションは新しいコンテンツの追加や表示位置の調整ができます。また、feedは著者が追加・削除を通知できるため、支援技術がリーディングビューを妨げずパフォーマンスも維持しやすくなります。

例：feedはニュース記事ストリーム表示に使えます。各articleには本文、リンク、画像、コメントおよびシェア・コメント用ウィジェットなどが含まれます。スクリーンリーダーユーザーが記事間を移動しながら読むと、各記事が表示され、必要に応じて新しい記事が読み込まれます。

feedは、子要素がarticleロールを持つコンテナ要素です。feedの両端でarticleが追加・削除される場合、著者は変更前にfeed要素のaria-busyをtrueに、変更後にfalseにSHOULD設定すべきです。また、feedの中央でarticleを追加・削除するのは避けるべきです（SHOULD）。これにより、支援技術は、ユーザーのリーディングカーソル操作と同時に発生するfeed変更にもスムーズに対応できます。

著者は、feed内の各articleをフォーカス可能にし、ユーザーエージェントのフォーカスがarticleまたはその子孫要素に移動した際、アプリケーションがそのarticleを表示領域にスクロールすることをSHOULD確保すべきです。例：HTMLでは、各article要素のtabindex値を-1または0にします。

支援技術のリーディングカーソルがあるarticleから別のarticleに移動した場合、支援技術はリーディングカーソルがあるarticleにユーザーエージェントのフォーカスをSHOULD移動させます。リーディングカーソルがarticle内のフォーカス可能要素に着地した場合、支援技術はその要素へのフォーカス移動をMAY選択できます。

支援技術のリーディングカーソルで他のarticleにスクロールできるかは、ページ内に別のarticleが存在するかに依存します。著者は、フォーカスがリスト両端のarticleに到達する前に追加読み込みをSHOULD試みるべきです。あるいは、リスト両端に追加読み込み用のbutton等を含めてもMAYです。

ラベルの他に、著者はaria-describedbyをfeed内のarticle要素にMAY設定し、スクリーンリーダーでラベルの後に読み上げる要素を示唆できます。スクリーンリーダーは、ラベルとアクセシブル記述を組み合わせて素早く内容を把握できる機能をMAY提供します。これにより、著者が記述から除外した繰り返しや重要度の低い要素（埋め込みウィジェット等）をユーザーが無視できます。

著者は、feed内のarticle間でキーボード操作によるフォーカス移動コマンドをSHOULD提供すべきです。これにより、支援技術による記事ナビゲーション機能を使わないユーザーもキーボードでfeedを操作できます。

供給される記事数が固定の場合、著者はfeed内のarticle要素にaria-setsizeをMAY指定できます。全体数が極めて多い・不定・頻繁に変動する場合は、aria-setsizeに-1を指定し、不明な集合サイズを伝えても構いません（MAY）。

詳細はWAI-ARIAオーサリング実践でfeedデザインパターンの実装を参照してください。

知覚可能なsectionであり、通常はグラフィカルドキュメント、画像、コード断片、サンプルテキストなどを含みます。figureの各部分はユーザーがナビゲートできるMAY場合があります。

著者は、figureを主文から参照することをSHOULD推奨しますが、figureは参照要素と同じ場所に表示する必要はありません。キャプションとして機能するテキストをaria-describedbyで参照してもMAYです。ラベルはaria-labelで設定したり、ラベルとして機能するテキストをaria-labelledbyで参照してもMAYです。

支援技術はユーザーがfigureに素早く移動できるようにするべきです（SHOULD）。主流のユーザーエージェントも素早くfigureに移動できるようにしてもMAYです。

landmark領域であり、アイテムやオブジェクトの集合を含み、それらが全体としてフォームを構成します。関連：search。

フォームには、ホスト言語のフォームコントロール、スクリプト制御、ハイパーリンクなどが混在する場合があります。フォームコントロールは可能な限りホスト言語のネイティブセマンティクスを使うことが推奨されます。フォームの目的が検索条件の送信なら、汎用formロールではなくsearchロールをSHOULD使うべきです。

著者は、formロールを持つ各要素に、フォームの目的を簡潔に説明するラベルをMUST付与する必要があります。可視ラベルがある場合は、aria-labelledbyで参照することをSHOULD推奨します。ラベルは可能な限り見出し内に含めることをSHOULD推奨します。見出しはホスト言語の標準要素でも、headingロールの要素でもMAYです。

著者がスクリプトでフォーム送信を行い、通常onsubmitイベントが発火しないユーザー操作（例：フォーム要素値変更で送信）を使う場合は、事前にユーザーに挙動を通知することをSHOULD推奨します。

ユーザーエージェントは、formロールを持つ要素をナビゲーション用ランドマークとしてSHOULD扱うべきです。

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

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

presentationロールを持つ要素と同様に、generic要素もaria-live属性など子孫に対して限定的なアクセシブル状態・プロパティを提供できます。しかし、presentationと異なり、generic要素はアクセシビリティAPIに公開されるため、支援技術はレイアウトや境界などの情報を取得できます。

複合型widgetであり、1つ以上の行と1つ以上のセルを含み、グリッド内の一部またはすべてのセルが方向キーなどの二次元ナビゲーションによってフォーカス可能です。

gridロールは特定の視覚的（例：表形式）な表示を意味しません。これは要素間の関係を記述します。チェックボックスのグループやナビゲーションリンクのグループなど簡単な用途から、本格的な表計算アプリのような複雑な用途まで使えます。

gridのセル要素はgridcellロールを持ちます。著者はセルを行・列ヘッダーとしてrowheaderやcolumnheaderロールにしてもMAYです。著者はgridcell、columnheader、rowheaderロールを持つ要素が必ずrowロールを持つ要素に所有され、その行要素がrowgroupまたはgridに所有されるようMUST保証してください。

キーボードアクセシブルにするため、著者はフォーカス管理に従いgrid子孫のフォーカスをSHOULD管理すべきです。キーボードでグリッドを操作する際、著者は以下の通りフォーカスを設定すべきです：

• gridcellが、フォーカス時に方向キーを消費しない単一のインタラクティブwidget（例：checkbox、button、link）を含む場合、著者はそのインタラクティブ要素に直接フォーカスしてもMAYです。これによりウィジェットを直接操作できます。
• それ以外の場合、フォーカスを受ける要素はgridcell、rowheader、columnheader要素であることをSHOULD保証してください。

フォーカス可能セル内に下記が含まれる場合、著者はインタラクションや編集モードへの切り替え手段をSHOULD提供すべきです：

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

例：スプレッドシートのセルにcomboboxや編集可能テキストがある場合、セルにフォーカス時にEnterキーで編集/インタラクションモードに入り、方向キーで内包ウィジェットを操作できるようにします。実装によっては、再度EnterやTab、Escape等でグリッドナビゲーションモードに戻すことができます。

著者はgridcellで計算式の結果を表示し、ユーザーが編集可能にしてもMAYです。例えば、表計算アプリでgridcellに計算値を表示し、編集時はtextboxが現れるようにできます。

gridロール要素にaria-readonly属性を設定した場合、ユーザーエージェントはMUSTその値を所有するすべてのgridcell要素に伝播し、アクセシビリティAPIで値を公開します。著者は個別のgridcell要素で伝播値を上書きしてもMAYです。

グリッドがセル内容の編集機能を持つ場合、フォーカス可能なgridcellが編集不可なら、そのgridcell要素にaria-readonlyをtrueで設定してもMAYです。なお、aria-readonly値はセル内容が編集可能かのみを示し、グリッド自体の操作可否は示しません。

aria-readonly値が未指定でも、グリッドやgridcellが編集可能な内容を持つとは限りません。例：グリッドが編集不可の日付リンク一覧を表示する場合、aria-readonly値を指定する必要はありません。

著者はフォーカス可能なgridcellをアクション対象として選択可能にする場合、aria-selected属性で示してもMAYです。複数選択可能な場合は、grid要素にaria-multiselectableをtrueでSHOULD設定してください。

WAI-ARIAはホスト言語要素の機能を拡張できるので、グリッドはネイティブのテーブル要素（例：HTML table）を再利用できます。例えば、HTML table要素にgridロールを付与すれば、trやtd要素にrowやgridcellロールを個別付与する必要はありません。ネイティブテーブル要素でセルの行・列跨ぎ指定が必要な場合は、WAI-ARIAのaria-rowspanやaria-colspanではなく、ホスト言語の属性を使うべきです（SHOULD）。

詳細はWAI-ARIAオーサリング実践でグリッドデザインパターンの実装を参照してください。

gridまたはtreegrid内のcellです。

gridcellはフォーカス可能・編集可能・選択可能です。gridcellはaria-controlsなどの関係属性を持ち、機能的な関連付けができます。

行ヘッダー・列ヘッダーを持たせたい場合、DOM構造から該当ヘッダーが判別できない場合は、著者はgridcellにaria-describedbyを用い、rowheaderやcolumnheaderロールの要素を参照するべきです（SHOULD）。

treegrid内では、著者はgridcellにaria-expanded属性を付与し展開可能にしてもMAYです。aria-expanded属性は個々のセルにのみ適用され、行コンテナの展開制御にはなりません。主な用途はピボットテーブル動作です。

gridcellロールの要素は、rowロールの要素内または所有されている必要があります（MUST）。

ページ要約や目次（支援技術による）に含める意図のないUIオブジェクトの集合。

regionは、目次に含めるUIオブジェクトのグループです。groupはこれと対照的です。

著者は、groupを使ってウィジェット内で論理的なアイテム集団をSHOULD形成すべきです（例：ツリーウィジェットで兄弟ノードの集団）。ただし、groupがlistbox内にある場合は、子要素をoptionに限定することをMUSTです。そのため、groupの適切な扱いは文脈依存です。

著者はgroup要素を入れ子にしてもMAYです。もしその区分がページ目次に含めるほど重要なら、regionロールや標準ランドマークロールをSHOULD指定してください。

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

headingロールの要素が論理的なアウトラインになるよう、著者はaria-level属性で適切な階層レベルをMUST指定する必要があります。

画像を構成する要素の集まりを収容するコンテナ。

imgはキャプションや説明文、複数の画像ファイルも含み、全体で1つの画像として知覚されます。imgは、複数の描画オブジェクトで構成される場合も、文書内の単一グラフィックを表します。imgロール要素が知覚可能となるためには、著者がaria-labelまたはaria-labelledby属性でラベルをMUST提供する必要があります。

ユーザー入力を受け付ける汎用タイプのウィジェット。

挿入には、追加された内容や追加が提案されている内容が含まれます。関連：deletion。

insertionは通常、2つのバージョン間の差分をマークしたり、複数人でコンテンツを修正する場面で追加提案を示すために使われます。

特定の著者指定の目的に関連し、知覚可能なsectionであり、ユーザーが容易にそのセクションに移動したり、ページ要約に表示されることが望まれるほど重要な内容を含みます。こうしたページ要約は、ユーザーエージェントや支援技術により動的に生成される場合があります。

著者はlandmarkロールのサブクラスロールを割り当て、必要に応じて簡潔な説明ラベルを付与することでコンテンツの目的を指定します。

landmarkロールのサブクラスロールを持つ要素はランドマーク領域またはナビゲーションランドマーク領域と呼ばれます。 支援技術は、ユーザーがランドマーク領域に素早く移動できるようにするべきです（SHOULD）。主流のユーザーエージェントもランドマーク領域への素早い移動を可能にしてもMAYです。

内部または外部リソースへのインタラクティブな参照で、アクティブ化するとユーザーエージェントがそのリソースへ移動します。関連：button。

ホスト言語のネイティブリンク（例：HTMLのhref属性付きアンカー）なら、リンクをアクティブ化するとユーザーエージェントがリソースへ移動します。シミュレートリンクの場合、ウェブアプリ著者がナビゲーション管理を担当します。

listitem要素を含むsectionです。関連：listbox。

リストは、子要素のroleがlistitemである要素を含みます。

ユーザーが選択肢リストから1つ以上の項目を選択できるウィジェットです。関連：combobox、list。

リスト内の項目は静的で、通常のHTML select要素と異なり画像も含めることができます。リストボックスは、子要素のroleがoption、またはgroupロールを持ち、その中にoptionロールを持つ子要素がある場合も含みます。

キーボードアクセシブルにするには、著者はすべてのlistboxインスタンスでoption子孫のフォーカス管理をSHOULD行うべきです。詳細はフォーカス管理参照。

listboxロールを持つ要素は、暗黙のaria-orientation値がverticalとなります。