Accessible Rich Internet Applications (WAI-ARIA) 1.2 日本語訳

重要かつ通常は時間依存の情報をもつライブリージョンの種類。関連するalertdialogおよびstatusを参照のこと。

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

アラートは断定的なライブリージョンであり、これはそのライブリージョンが支援技術のユーザーのための即時通知を引き起こす手段であることを意味する。オペレーティングシステムが許可する場合、WAI-ARIAアラートが作成されるとき、ユーザーエージェントは、アクセシビリティAPIを通してシステムのアラートイベントを起動すべきである。

著者もユーザーエージェントのいずれもが、アラートが処理されるようにするためにアラートにフォーカスを設定または管理を要求されない。アラートがフォーカスを受け取るために必要とされていないので、著者はアラートを閉じることを、ユーザーに要求すべきではない。著者がフォーカスが伝達されたときのメッセージに移動するためにフォーカスを切望する場合、著者はalertの代わりにalertdialogを使用すべきである。

ロールalertをもつ要素は、assertiveの暗黙のaria-live値を持ち、trueの暗黙のaria-atomic値を持つ。

初期のフォーカスがダイアログ内の要素に行く場所で、警告メッセージを含むダイアログの種類。関連するalertおよびdialogを参照のこと。

アラートダイアログは、ユーザーに警告するメッセージを伝えるために使用される。alertdialogロールは、アラートメッセージとダイアログの残りの部分との両方を含むノードで発生する。コンテンツ著者は、alertdialogが示される間、キーボードとマウスの相互作用がダイアログ内でのみ動作することを保証することによってアラートダイアログをモーダルに確認させるべきである。aria-modalを参照のこと。

alertと異なりalertdialogは、ユーザーからの応答を受信することができる。たとえば、ユーザーが生成されているアラートが理解するのを確認することなどである。アラートダイアログが表示されるとき、著者は、フォームコントロールまたは確認ボタンのような、アラートダイアログ内のアクティブな要素にフォーカスを設定すべきである。ユーザーエージェントは、アラートが作成された場合、意図されるアクセシビリティAPIによって指定されるアラートイベントを提供され、アクセシビリティAPIを通してシステムのアラートイベントを発火すべきである。

著者は、ダイアログで警告メッセージ要素を指すようにalertdialog上のaria-describedbyを使用すべきである。そうでない場合、支援技術は、警告メッセージのコンテンツを決定するために内部の回復機構に頼る。

widgetロールによってサポートされる標準的な相互作用パターンに従わない、キーボードまたはジェスチャーイベントなどの、ユーザー入力を要求する1つ以上のフォーカス可能な要素を含むstructure。

一部のユーザーエージェントおよび支援技術は、上矢印および下矢印キーイベントなどの標準入力イベントが読み取りカーソルを制御するために傍受され使用される、ブラウズモードを持つ。このブラウズモードの動作は、widgetロールを持たない要素がインタラクティブな機能を提供するためのキーボードやジェスチャーイベントの受信や使用しないように防ぐ。

WAI-ARIA widgetロールのいずれかによってサポートされない相互作用モデルをもつ要素を作成する必要がある場合、著者はその要素にロールapplicationを与えてもよい。そして、ユーザーがロールapplication要素にナビゲートする場合、標準入力イベントを傍受する支援技術は、ウェブアプリケーションを通じてほとんどまたはすべての標準入力イベントを通過するモードに切り替えるべきである。

たとえば、プレゼンテーションスライドエディターは、スライド上のテキストボックスや画像要素の位置を変更するために矢印キーを使用する。著者がスライドコンテナーにロールapplication、「スライド エディター」のaria-roledescriptionを与え、そして指示を与えるためにaria-describedbyを使用するので、このような相互作用モデルに対応するWAI-ARIA widgetロールは存在しない。

application要素に含まれるフォーカス可能な要素のみが一部の支援技術のユーザーにアクセシブルであるので、著者は、アクセシブルであるアプリケーションの内側にすべての非装飾な静的テキストまたは画像コンテンツを保証するために次の方法のいずれかを使用しなければならない：

1. aria-labelledbyまたはaria-describedbyを使用してフォーカス可能な要素とコンテンツを関連付ける。
2. ロールdocumentまたはarticleを持つフォーカス可能な要素でコンテンツを配置する。
3. フォーカスされたコンテンツを含む要素を参照するためにaria-activedescendantの値を更新し、フォーカスの管理で説明したように所有される要素のフォーカスを管理する。

文書、ページ、またはサイトの独立した部分を形成する文章から成るページのセクション。

記事は、ナビゲーションランドマークではないが、支援技術が次の議論でユーザーを支援するために記事のネスティングに注意を払うことができる場合に議論を形成するためにネストされるかもしれない。記事は、フォーラムの投稿、雑誌や新聞記事、ウェブログ項目、ユーザーが送信したコメント、またはコンテンツの他の独立した項目であるかもしれない。たとえばシンジケーションにおいて、そのコンテンツが孤立することができるという点で、独立である。しかし、要素は依然として要素の祖先に関連する。たとえば、親body要素に適用する連絡先情報は、依然としてなおも記事をカバーする。記事をネストする場合、子記事は、親記事のコンテンツに関連するコンテンツを表す。たとえば、ユーザーが送信したコメントを受け入れるサイト上のウェブログ項目は、ウェブログ項目の記事内にネストされる記事としてコメントを表すかもしれない。著者、見出し、日付、または記事に関連する他の情報は、ネストされた記事に適用されない。

ユーザーがarticleのロールを割り当てられた要素へナビゲートする場合、ウェブアプリケーションを通してキーボードイベントを渡すのとは対照的に、通常は標準のキーボードイベントを横取りする支援技術は、文書閲覧モードに切り替えるべきである。支援技術は、ユーザーが任意のネストされたarticle要素の階層をナビゲートすることを可能にする機能を提供してもよい。

articleがfeedのコンテキスト内にある場合、著者はaria-posinsetおよびaria-setsizeに値を指定してもよい。

ページ固有のコンテンツではなく、ほとんどがサイト指向のコンテンツを含むlandmark。

サイト向けコンテンツは典型的に、ロゴやサイトのスポンサーの識別、およびサイト固有の検索ツールなどを含む。バナーは通常、ページの上部に表示され、典型的に全幅にわたる。

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

任意のdocumentまたはapplicationの中で、著者は、bannerロールをもつ複数の要素をマークすべきでない。

別のソースから引用されたコンテンツのセクション。

クリックまたは押された際にユーザー誘発のアクションを可能にする入力。関連するlinkを参照のこと。

ボタンは、個別のアクションに大部分は使用される。ボタンの外観を標準化することは、ボタンとしてウィジェットの利用者の認識を高め、ツールバーでよりコンパクトな表示が可能になる。

ボタンはオプション属性aria-pressedをサポートする。空でないaria-pressed属性をもつボタンは、トグルボタンである。aria-pressedがtrueである場合にボタンは「押された」ステートにあり、aria-pressedがfalseである場合にボタンは押されていない。属性が存在しない場合、ボタンは単純なコマンドボタンである。

figure、table、gridまたはtreegridに名前を付け、説明する可視コンテンツ。

captionを使用する場合、著者は次のことを保証すべきである：

• captionが figure、table、gridまたはtreegridの直接の子である。
• captionがtable、gridまたはtreegridの最初の子である。
• captionがfigureの最初または最後の子である。

著者は、ロールcaptionをもつ要素を参照するために、親のfigure、table、gridまたはtreegrid上のaria-labelledbyを設定すべきである。しかし、captionが名前とその親の説明の両方として機能するコンテンツを含む場合、著者は代わりに、簡潔な名前が含まれているcaption内の要素を参照するためにaria-labelledbyを設定してもよく、記述的な内容が含まれているcaption内の要素を参照するためにaria-describedbyを設定してもよい。

<div role="table" aria-labelledby="name" aria-describedby="desc">
   <div role="caption">
     <div id="name">Contest Entrants</div>
     <div id="desc">
       This table shows the total number of entrants (500) the
       contest accepted over the past four weeks.
     </div>
   </div>
   <!-- ... -->

テーブルコンテナーにおけるセル。関連するgridcellを参照のこと。

著者は、ロールcellをもつ要素がロールrowをもつ要素で含まれるまたは所有されることを保証しなければならない。

true、false、またはmixedの3つの可能性がある値を持つチェック可能な入力。

checkboxのaria-checked属性は、入力がチェックされる（true）、チェックされない（false）かどうかを示し、またはチェックされるおよびチェックされない値の混合物（mixed）を持つ要素のグループを表す。多くのチェックボックスはmixed値を使用せず、よって事実上真偽チェックボックスである。

コンテンツがコンピューターコードの断片を表すセクション。

codeロールの主な目的は、コンテンツがコンピューターコードであるため、特に合成音声に関して特別な提示が必要になる可能性があることを支援技術に伝えることである。より具体的には、コンテンツのテキスト読み上げの提示を提供するスクリーンリーダーおよびその他のツールは、一般的な記号（"-"など）が確実に話されるように、完全な句読記号の冗長性を優先すべきである。

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

columnheaderは、テーブルまたはグリッドの列見出しとして使用することができる。これはまた、データ内の類似関係を示す円グラフで使用することもできる。

ColumnHeaderは、対応する列における見出しとすべてのセルとの間の関係を確立する。これは、列の範囲をもつHTML th要素と構造的に等価である。

著者は、ロールrowをもつ要素に含まれる、または所有されるロールcolumnheaderをもつ要素を保証しなければならない。

columnheader上のaria-selectedの適用は、ユーザーエージェントに対応する列におけるすべてのセルにaria-selectedステートを自動的に伝搬させてはならない。著者は、特定の用途に応じてこの方法で選択の伝搬を選択してもよい。

columnheaderロールはインタラクティブなグリッドと非インタラクティブなテーブルの両方で使用することができる一方で、aria-readonlyおよびaria-requiredの用途はインタラクティブな要素にのみ適用可能である。したがって、著者はtableから伝わるcolumnheaderにおいてaria-requiredまたはaria-readonlyを使用すべきでなく、かつcolumnheaderがgridから伝わらない限り、ユーザーエージェントは支援技術にいずれかのプロパティを公開すべきでない。

listboxやgridなどの、ユーザーがinputの値を設定するのを助けるために動的にポップアップすることができる、別の要素を制御するinput。

comboboxは、補助的なポップアップ要素を介して値の選択を支援するための能力をもつ名前付けされた入力フィールドを機能的に兼ね備えている。comboboxは、編集または入力をサポートする単一行のテキストフィールド、またはcomboboxの現在の値を表示のみをする要素のいずれであってもよい。comboboxがaria-autocompleteで記載されるようにテキスト入力をサポートして自動補完の動作を提供する場合、著者は提供される動作に対応する値にcombobox要素上でaria-autocompleteを設定しなければならない。

一般に、comboboxの初期状態は折りたたみである。折りたたみ状態では、combobox要素とオプションのポップアップコントロールbuttonのみが表示される。comboboxは、その現在の値を示すcombobox要素とその関連するポップアップ要素の両方が表示されている場合に展開すると呼ぶ。著者は、要素が展開された場合にロールcomboboxをもつ要素でtrueにaria-expandedを、および要素が折りたたまれた場合にfalseに設定しなければならない。

著者は、comboboxに関連付けられたポップアップ要素がlistbox、tree、gridまたはdialogのロールを持つことを保障しなければならない。著者は、combobox要素のaria-controlsを、comboboxポップアップ要素を参照する値に設定しなければならない。

ロールcomboboxをもつ要素は、listboxの暗黙のaria-haspopup値を持つ。comboboxのポップアップ要素がlistbox,以外のロールを持つ場合、著者はそのポップアップのロールに対応するaria-haspopupの値を指定しなければならない。

ユーザーインターフェイスがポインターおよびタッチイベントを介してポップアップの可視性を制御できる追加のアイコンを含む場合、著者は、要素にロールbuttonがあり、フォーカス可能であるがページのTabシーケンスに含まれていないこと、およびロールcomboboxをもつ要素の子孫ではことを保証すべきである。さらに、キーボードでアクセスできるようにするために、著者は、combobox要素とポップアップに含まれる要素との間でフォーカスを移動するためのキーボードメカニズムを提供すべきである。たとえば、1つの一般的な規則は、Down Arrowがポップアップ要素の最初のフォーカス可能な子孫への入力からフォーカスを移動することである。ポップアップ要素がaria-activedescendantをサポートする場合、フォーカスを移動する代わりに、そのようなキーボードメカニズムは、combobox要素のaria-activedescendantの値を制御することができる。ポップアップ要素の子孫がアクティブである場合、フォーカスがcombobox要素上に残っている間、著者は、ポップアップ内のアクティブな要素を参照する値にcomboboxのaria-activedescendantを設定してもよい。

ユーザーエージェントは、ロールcomboboxをもつ要素の値を支援技術に公開しなければならない。comboboxの値は、次のいずれかで表される：

• combobox要素が、HTML input要素などの値を提供するホスト言語要素である場合、コンボボックスの値はその要素の値である。
• そうでなければ、comboboxの値はその子孫要素によって表され、その子孫コンテンツからbuttonの名前を計算するために使用されるのと同じメソッドを使用して決定できる。

    <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">
   <li role="option">Zebra</li>
   <li role="option" id="selected_option">Zoom</li>
</ul>

コンボボックスの実装の機能および挙動は大きく異なる。その結果として、多くの重要なオーサリング考慮事項が存在する。コンボボックスの設計パターンの実装に関する詳細については、WAI-ARIA Authoring Practicesを参照のこと。

アクションを実行するが入力データを受信しないウィジェットのフォーム。

DOM階層における同様のレベルでメインコンテンツを補完するように設計されるが、メインコンテンツから分離しても意味があるままとなる、landmark。

このロールを適切に持つコンテンツのさまざまな種類が存在する。たとえば、ポータルの場合に、これは含まれるが、視聴時間、現在の天気、関連記事、または注目の株に限定されるものではない。包含されるコンテンツを示す補完的なロールは、主要コンテンツに関連する。相補的なコンテンツが主要コンテンツから完全に分離可能である場合、より一般的なロールを使用することが適切だろう。

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

ナビゲーション可能な子孫または所有される子を含むことができるウィジェット。

著者は、複合ウィジェットがウェブページのより大きなナビゲーションシステム内の単一のナビゲーションストップとして存在することを確認すべきである。複合ウィジェットがフォーカスを一度持つと、著者は、子孫または複合要素の所有される子である要素にナビゲートするためにユーザーに対する独立したナビゲーション機構を提供すべきである。

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

ページのこの領域に含まれる情報の例は、著作権やプライバシーステートメントへのリンクである。

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

任意のdocumentまたはapplicationの中で、著者は、contentinfoロールをもつ複数の要素をマークすべきでない。

用語または概念の定義。関連するtermを参照のこと。

著者は、その要素にtermのロールを与え、かつaria-labelledby属性とともにその要素を参照するまたは、ロールtermをもつ要素をロールdefinitionをもつ要素の子孫にすることによって定義されている要素を識別すべきである。

削除には、削除済みとしてマークされているコンテンツ、または削除が提案されているコンテンツが含まれる。関連するinsertionを参照のこと。

削除は一般に、コンテンツの2つのバージョン間の違いを示すため、または複数のユーザーがコンテンツを修正しているシナリオで削除を提案されたコンテンツを指定するかのいずれかのために使用される。

ウェブアプリケーションの主要ウィンドウの子孫ウィンドウであるダイアログ。HTMLページに対して、主要アプリケーションウィンドウはウェブコンテンツ全体である。たとえばbody要素。

ダイアログはほとんどの場合、情報への入力または応答をユーザーに促すために使用される。ワークフローを中断するように設計されたダイアログは、通常モーダルである。関連するalertdialogを参照のこと。

著者は、aria-labelまたはaria-labelledby属性に対処することができる、ダイアログに対するアクセシブルな名前を提供しなければならない。

著者は、すべてのダイアログ（モーダルと非モーダルの両方）が少なくとも1つのフォーカス可能な子孫要素を持つことを保証すべきである。ダイアログが表示される場合に、著者は、モーダルダイアログ内の要素にフォーカスすべきであり、かつ著者は、モーダルダイアログのフォーカスを管理すべきである。

[ARIA 1.2で非推奨]静的な目次など、グループのメンバーへの参照のリスト。

directoryは、リンクされているかどうかにかかわらず、静的な目次である。これは、ネストされたリストを含む、リストで構築された目次を含む。しかし、動的な目次は、代わりにtreeロールを使用するかもしれない。

支援技術のユーザーが読み取りモードで閲覧することを望むかもしれないコンテンツを含む要素。

ユーザーエージェントのフォーカスがdocumentのロールを割り当てられた要素に移動する場合、静的なコンテンツを閲覧するための読み取りモードを持つ支援技術は、読み取りに切り替えて、読み取りカーソルを制御するために、上または下矢印キーボードイベントなどの、標準入力イベントを傍受してもよい。

読み取りモードを持つ支援技術はwidgetまたはapplicationロールのいずれかを持つものを除くすべての要素に適したデフォルトモードになるので、documentロールが支援技術の動作を変更する便利な唯一の状況は、ロールdocumentをもつ要素がwidgetまたはapplicationのフォーカス可能な子要素となる場合である。たとえば、いくつかの静的なリッチテキストが含まれるapplication要素を考えると、著者はロールdocumentをテキストを含む要素に適用することができ、0のtabindexを与えることができる。スクリーンリーダーのユーザーがTabキーを押してdocument要素にフォーカスを置く場合、ユーザーはスクリーンリーダーの読み取りカーソルをもつテキストを読むことができる。

1つ以上の強調される文字。関連するstrongを参照のこと。

emphasisロールの目的は、コンテンツをアクセントを付けるまたは強調することである。コンテンツの意味に影響を与えない印刷上の提示の変更を伝えるためではない。著者は、そのロール不在がコンテンツの意味を変える場合にのみemphasisロールを使用すべきである。

emphasisロールは重要性を伝えることを意図しない。その目的には、strongロールがより適切である。

スクロールがarticleにリストのいずれかの端に追加させるまたは端から削除させるかもしれない場所でarticleのスクロール可能なlist。

feedは、ユーザーが読むようにより多くのコンテンツを読み込むことによって無限にスクロールし続けるかもしれないリッチコンテンツのストリームを介して読み込みとスクロールの両方をするためのカーソル読み込みブラウズモードを使用することを、スクリーンリーダーなどの文書閲覧モードを持つ支援技術のユーザーにできるようにする。feedにおいて、支援技術は、ユーザーエージェントのフォーカスを移動することによってユーザーの読み取りカーソルの動きの信号とともにウェブアプリケーションを提供し、ユーザーがページを閲覧するときにアプリケーションが新しいコンテンツを追加したり、視覚的にコンテンツを配置したりすることを可能にする。feedはまた、支援技術が読み取りの混乱またはパフォーマンスの低下をすることなく、より確実に読み取り表示を更新できるように追加および削除が発生する場合に、著者に支援技術を告知させる。

たとえば、各articleがテキスト、リンク、画像と同様に共有やコメントのためのウィジェットをもつニュース記事を含む場所で、ニュース記事のストリームを提示するためにfeedを使用することができる。スクリーンリーダーのユーザーは、各ニュース記事を読み取って対話し、記事から記事へスクリーンリーダーの読み取りカーソルを移動するので、必要に応じて各記事は、表示にスクロールし、そして新しい記事は読み込まれる。

feedは、子がロールarticleを持つコンテナー要素である。articlesがfeedの片方または両方の端に追加または削除される場合、著者は、変更が作成される前にfeed要素上でaria-busyをtrueに設定し、変更が完了した後にこれをfalseに設定すべきである。著者は、feedの真ん中でarticlesを挿入または削除を避けるべきである。この要件は、支援技術がfeed内で読み取りカーソルを移動するためにユーザーコマンドと同時に発生するfeedコンテンツにおける変化に正常に対応するのを助ける。

著者は、ユーザーエージェントのフォーカスがarticleまたはその子孫要素のいずれかで設定される場合に、フォーカス可能なfeedで各articleを作成し、アプリケーションがビューにarticleをスクロールすることを保証すべきである。たとえば、HTMLで、各article要素は、-1または0のいずれかのtabindex値を持つべきである。

支援技術の読み取りカーソルがarticleから別のものに移動する場合、支援技術は、読み取りカーソルを含むarticleにユーザーエージェントのフォーカスを設定すべきである。読み取りカーソルがarticle内部のフォーカス可能な要素に到着する場合、支援技術は、articleを含んでいるフォーカスを設定する代わりにその要素にフォーカスを設定してもよい。

支援技術の読み取りカーソルをもつ別のarticleにスクロールする機能は、ページ内の別のarticleの存在に依存するため、著者は、ユーザーエージェントのフォーカスが読み込まれたarticlesのセットのどちらかの端でarticleに達する前に、追加のarticlesを読み込もうと試みるべきである。また、著者は、buttonのような、ユーザーに読み込まれているより多くのarticlesを要求させる要素を含む読み込まれた一連のarticlesのどちらかまたは両方の端にarticleを含めてもよい。

簡単なラベルを提供することに加えて、ユーザーがarticleによってナビゲートする場合に、著者は、ラベルの後で話す要素へスクリーンリーダーに示唆するためにfeedにおいてaria-describedbyをarticle 要素に適用されてもよい。スクリーンリーダーは、著者が記述の外から残っている、埋め込まれたインタラクションウィジェットなどの、反復またはほとんどない重要な要素を無視することをユーザーに有効にする、articleでナビゲートするとき、ラベルとアクセシブルな説明の両方を話すことによってfeedコンテンツをすばやくスキャンする方法を著者に提供してもよい。

著者は、articleのナビゲーション機能を提供する支援技術を利用しないユーザーがfeedをナビゲートするためにキーボードを使用できるように、feedにおけるarticle間でフォーカスを移動するためのキーボードコマンドを提供すべきである。

feedで利用可能な記事の数が静的である場合、著者はそのfeedにおけるarticle要素にaria-setsizeを指定してもよい。しかし、合計数が非常に大きい、不定、または頻繁に変更する場合、著者は、セットの不明なサイズを通信するためにaria-setsizeを-1に設定してもよい。

フィードの設計パターンの実装に関する詳細についてはWAI-ARIA Authoring Practicesを参照のこと。

グラフィカルな文書、画像、コード断片、またはテキスト例を通常含むコンテンツの知覚可能なsection。figureの一部は、ユーザー移動可能であってもよい。

著者は、主要テキストからfigureへの参照を提供すべきであるが、figureは参照する要素と同じ場所で表示される必要はない。著者は、aria-describedbyを使用するキャプションとしての機能を果たすテキストを参照してもよい。著者は、aria-labelを使用してラベルを提供してもよく、aria-labelledbyを使用してラベルとして機能を果たすテキストを参照してもよい。

支援技術は、ユーザーがすばやく図にナビゲートできるようにすべきである。メインストリームのユーザーエージェントは、ユーザーがすぐに図にナビゲートできるようにしてもよい。

全体として、フォームを作成するために組み合わせるアイテムおよびオブジェクトのコレクションを含むlandmark領域。関連するsearchを参照のこと。

フォームは、ホスト言語のフォームコントロール、スクリプト化コントロール、およびハイパーリンクのミックスを含むかもしれない。著者は、可能な限りフォームコントロールを作成するためにネイティヴホスト言語のセマンティックスを使用することに注意する。フォームの目的が検索条件を送信することである場合、著者は汎用のformロールの代わりにsearchロールを使用すべきである。

著者は、フォームの目的を説明する簡潔なラベルをロールformとともに各要素に付与しなければならない。可視ラベルが存在する場合、著者は、aria-labelledbyをもつ可視ラベルを参照すべきである。著者は、可能な限り、見出しの内側にラベルを含むべきである。見出しは、標準のホスト言語の見出し要素のインスタンスまたはロールheadingをもつ要素のインスタンスであってもよい。

著者がonsubmitイベントをトリガーしない（たとえば、フォーム要素の値を変更するユーザーによってトリガーされるフォーム送信）ユーザーアクションに基づくフォーム送信をするスクリプトを使用する場合、著者は、行動の事前通知をユーザーに提供すべきである。

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

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

genericロールは、ホスト言語（HTML divやspanなど）の一般的な要素の暗黙的なロールとして使用することを目的としているため、主にユーザーエージェントの実装者向けである。著者は、コンテンツにおいてこのロールを使用すべきでない。著者は、presentationまたはnoneを使用して、暗黙的なアクセシビリティセマンティックスを削除する、または名前付きコンテナー内の子孫を意味的にグループ化するためにgroupなどのセマンティックコンテナーロールを使用してもよい。

ロールpresentationをもつ要素と同様に、ロールgenericをもつ要素は、aria-live属性など、その子孫にアクセシブルなステートおよびプロパティの数を制限して提供できる。しかし、ロールpresentationをもつ要素とは異なり、generic要素はアクセシビリティAPIで公開されるため、支援技術はレイアウトや境界などの特定のプロパティを収集できる。

方向矢印キーのような、グリッドで一部またはすべてのセルが2次元のナビゲーションのメソッドを使用することでフォーカス可能となる、1つ以上のセルをもつ1つ以上の行のコレクションを含む複合widget。

gridロールは、特定の視覚、たとえば、表、プレゼンテーションを意味するものではない。これは、要素間の関係を記述する。これは、チェックボックスまたはナビゲーションリンクのコレクションをグループ化するような単純な目的、またはフル機能のスプレッドシートアプリケーションの作成のような複雑な目的のために使用されてもよい。

gridのセル要素は、ロールgridcellを持つ。著者は、gridcellロールの代わりにrowheaderかcolumnheaderロールのいずれかを使用することで行または列ヘッダーとしてセルを指定してもよい。著者は、ロールgridcell、columnheaderまたはrowheader を持つ要素が、順番にロールrowgroupまたはgridをもつ要素に所有される、ロールrowをもつ要素によって所有されることを保証しなければならない。

フォーカスの管理で説明されるように、キーボードアクセシブルであるために、著者は、gridの子孫のフォーカスを管理すべきである。ユーザーがキーボードでgridコンテンツをナビゲートしている場合、著者は、次のようにフォーカスを設定すべきである：

• gridcell が、checkbox、button、またはlinkのような、フォーカスを受け取る際に矢印キーが押されることを消費しない単一のインタラクティブなwidgetを含む場合、著者は、そのセルに含まれるインタラクティブな要素にフォーカスを設定してもよい。これは、含まれるウィジェットが直接操作可能にすることを可能にする。
• そうでなければ、著者は、フォーカスを受信する要素がgridcell、rowheader、またはcolumnheader要素であることを保証すべきである。

著者は、フォーカス可能なセルが次のいずれかが含まれる場合に、そのフォーカス可能なセルの内側に含まれるコンテンツにユーザーがナビゲートして対話することを可能にする相互作用または編集モードに変更するためのメカニズムを提供すべきである。

• 操作するための矢印キーを要求するウィジェット、たとえば、comboboxまたはradiogroup
• 複数のインタラクティブな要素
• 編集可能なコンテンツ

たとえば、スプレッドシート内のセルがcomboboxまたは編集可能なテキストを含む場合、Enterキーは、そのセルが方向矢印キーが含まれているcomboboxまたはtextboxを操作するために使用することができるようなフォーカスを持つ場合、セル間相互作用または編集モードをアクティブにするために使用されるかもしれない。実装に応じて、もう一度Enter、Tabは、Escape、または別のキーを押すことで、アプリケーションとグリッドナビゲーションモードとを切り替えてもよい。

著者は、ユーザーが編集することができた式の結果を表示するには、gridcellを使用してもよい。たとえば、スプレッドシートアプリケーションにおいて、textboxが編集可能な状態で式を含むgridcellに出現する場合に、ユーザーが編集のためにgridcellをアクティブにするまで、gridcell は式から算出した値を示してもよい。

aria-readonlyがロールgridをもつ要素に設定される場合、ユーザーエージェントは、gridに所有されるすべてのgridcell要素に値を伝播し、アクセシビリティAPIに値を公開しなければならない。著者は、個々のgridcell要素のためにaria-readonlyの伝播値を上書きしてもよい。

フォーカス可能なgridcell要素のコンテンツが編集可能でない場合、セルコンテンツの編集機能を提供するgridにおいて、著者は、gridcell要素上のaria-readonlyにtrueを設定してもよい。しかし、aria-readonly,の値は、gridまたは個々のセルに指定されたかどうかを、セルに含まれるコンテンツが編集可能であるかどうかのみを示す。これは、grid自身をナビゲートまたは操作するための機能の利用可能性を示すものではない。

aria-readonly の未指定値はgridまたは<gridcellに編集可能なコンテンツが含まれていることを意味しない。たとえば、gridが、日付ピッカーで日付を表すlink要素のコレクションのような、編集可能でない要素のコレクションを提示する場合、著者がaria-readonlyに値を指定することは必須ではない。

著者は、フォーカス可能なgridcellがaria-selected属性をもつアクションの対象として選択可能であることを示してもよい。gridが複数のgridcellを選択すること可能である場合、著者は、ロールgridをもつ要素でaria-multiselectable をtrueに設定すべきである。

WAI-ARIAはホスト言語の要素を増強することができるため、gridは、HTMLのtable要素などのネイティヴテーブルの要素および属性を再利用することができる。たとえば、著者がHTMLのtable要素にgridロールを適用する場合、ユーザーエージェントが自動的に適切な変換を行うため、著者は子孫のHTML trおよびtd要素にロールをrowおよびgridcellを適用する必要はない。著者がネイティヴホスト言語テーブル要素を再利用しかつ複数の行または列にまたがるgridcell要素を必要とする場合、著者は、WAI-ARIA aria-rowspanまたはaria-colspanプロパティの代わりに適切なホスト言語属性を適用すべきである。

グリッドの設計パターンの実装に関する詳細については、WAI-ARIA Authoring Practicesを参照のこと。

gridまたはtreegrid内のcell。

gridcellは、フォーカス可能、編集可能、または選択可能であってもよい。gridcellは、機能的関係のアプリケーションを扱うためにaria-controlsのような関係を持ってもよい。

著者がgridcellに行ヘッダー、列ヘッダー、またはその両方を持たせ、かつ関連する見出しがDOM構造から決定することができない場合、著者は、gridcellのaria-describedbyを適用しロールrowheaderまたはcolumnheaderをもつ要素を参照することによってどのヘッダーセルがgridcellに関連しているかを明示的に示すべきである。

treegridにおいて、著者はaria-expanded属性を使用することで拡張可能としてgridcellを定義してもよい。 aria-expanded 属性が提供される場合、個々のセルにのみ適用される。拡張することもできるコンテナーrowに対する代理ではない。gridcell上にこの属性を提供するための主なユースケースは、ピボットテーブルの動作である。

著者は、ロールgridcellをもつ要素が、ロールrowをもつ要素で含まれるまたは所有されることを保証しなければならない。

支援技術によってページサマリーまたは目次に含まれることを意図されないユーザーインターフェイスオブジェクトのセット。

ページサマリーまたは目次に含まれるユーザーインターフェイスオブジェクトのグループ化したregionと対比する。

著者は、階層内の兄弟のコレクションを形成するツリーウィジェットにおける子のような、ウィジェットにおける項目の論理的な集合を形成するためにgroupを使用すべきである。しかし、groupがlistboxのコンテキストで使用される場合、著者は、その子をoption要素に制限しなければならない。したがって、著者および支援技術によるgroupの適切な取り扱いは、グループが提供されるコンテキストによって決定される。

著者は、group要素をネストしてもよい。セクションがウェブページの目次に含まれることを保証するのに十分大きい場合、著者は、セクションにregionのロールまたは標準ランドマークロールを割り当てるべきである。

ページのセクションに対する見出し。

headingのロールをもつ要素が論理的なアウトラインに編成されることを保証するために、著者は適切な入れ子レベルを示すためにaria-level属性を使用しなければならない。

画像を形成する要素のコレクションのコンテナー。

imgは、一緒に見た場合に1枚の画像の印象を与える複数の画像ファイルだけでなく、キャプションおよび説明テキストを含めることができる。imgは、描画オブジェクトのコレクションによって形成されているかどうかに関わりなく、文書内の1つのグラフィックを表す。imgのロールをもつ要素を認識可能にするために、著者はaria-labelまたはaria-labelledby属性を使用してラベルを提供しなければならない。

ユーザー入力を許可するウィジェットの一般的な種類。

挿入には、追加済みとしてマークされているコンテンツ、または追加が提案されているコンテンツが含まれる。関連するdeletionを参照のこと。

挿入は一般に、コンテンツの2つのバージョン間の違いを示すため、または複数のユーザーがコンテンツを修正しているシナリオで追加を提案されたコンテンツを指定するかのいずれかのために使用される。

特定の、著者が指定した目的に関連し、ユーザーが容易にセクションにナビゲートできてページの要約に記載させることを望むだろう、十分に重要なコンテンツを含む知覚可能なsection。そのようなページの概要は、ユーザーエージェントまたは支援技術によって動的に生成することがある。