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

重要かつ通常は時間依存の情報をもつライブリージョンの種類。関連する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をもつ要素にすばやくナビゲートできるようにすべきである。ユーザーエージェントは、ナビゲーションランドマークとしてbannerのロールをもつ要素を扱うべきである。ユーザーエージェントは、ユーザーがロールbannerをもつ要素にすばやくナビゲートできるようにしてもよい。

著者は、bannerロールをもつページ上の要素を1つだけマークすべきである。

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

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

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

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

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

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

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

captionがそれを含む要素のアクセシブルな名前を表す場合、著者は、ロールcaptionをもつ要素を参照するために、包含要素にaria-labelledbyを指定すべきである。

<div role="radiogroup" aria-labelledby="cap">
   <div role="caption" id="cap">
     Choose your favorite fruit
   </div>
   <!-- ... -->

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>
   <!-- ... -->

captionが長い形式の説明を表す場合、または説明がその説明を理解する上で重要なセマンティック要素を含む場合、著者は代わりに、包含要素の"名前"を表すcaption内の要素を参照するためにaria-labelledbyを指定し、説明的な内容を含むcaption内の要素を参照するためにaria-detailsを指定してもよい。

<div role="figure" aria-labelledby="name" aria-details="details">
  <!-- figure content here, such as a complex data viz SVG -->
   <div role="caption">
     <div id="name">Sales information for 20XX</div>
     <div id="details">
       This barchart represents the total amount of sales over the course
       of five years. <a href="...">Sales information for last year</a> can
       be reviewed, or you can overlay <button aria-pressed="false">previous year</button>
       information in this graphic.
     </div>
   </div>
   <!-- ... -->

captionが説明のみを含み、その要素のアクセシブルな名前として機能する適切なテキスト文字列が含まれていない場合、aria-labelまたはaria-labelledbyは、アクセシブルな名前を提供するために使用されてもよく、captionは、aria-details経由で参照される説明的な内容としてのみ扱われてもよい。

<div role="figure" aria-label="Sales information" aria-details="details">
  <!-- figure content here, such as a complex data viz SVG -->
   <div role="caption" id="details">
     This barchart represents the total amount of sales over the course
     of five years. <a href="...">Sales information for last year</a> can
     be reviewed, or you can overlay <button aria-pressed="false">previous year</button>
     information in this graphic.
   </div>
   <!-- ... -->

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

著者は、ロールcellをもつ要素が、ロールrowをもつ要素のアクセシビリティの子であることを保証しなければならない。

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

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

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

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

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

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

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

著者は、ロールcolumnheaderをもつ要素が、ロールrowをもつ要素のアクセシビリティの子であることを保証しなければならない。

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 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>

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

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

commandは、オントロジーのために使用される抽象ロールである。著者は、コンテンツにおいてcommmandロールを使用してはならない。

他のコンテンツへの反応を表す内容が含まれているコメント。

コメントは、テキストの短い範囲から、他のコメント、記事全体まで、可視コンテンツに注釈を付けることができる。著者は、コメントとコメントされたコンテンツの間の関係を次のように識別すべきである：

1. コメントが別のcommentへの返信の場合：
   • すべての祖先コメントがDOMで使用できる場合、DOMの子孫要素にする、またはaria-ownsを使用して、各返信commentを返信先のcommentのセマンティックの子孫にする。
   • あるいは、コメントにページ番号が付けられている場合など、すべての祖先コメントがDOMにない場合、aria-levelを介して階層レベルを示してもよい。追加のグループ位置情報は、aria-posinsetおよびaria-setsizeを介して示されてもよい。
2. そうでなければ、コメントがページ内の他のコンテンツに関連している場合：
   • コメント付きコンテンツを含む要素のaria-detailsに、ロールcommentをもつ要素を参照する値を提供する。
   • 同じコメント付きコンテンツに関連するコメントが複数ある場合、個々のコメントを参照するコメント付きコンテンツのaria-detailsに値を指定するか、コメントの親コンテナーを参照するためにaria-detailsを使用するかのいずれかとなる。aria-detailsがcomment要素ではなくコメントを含む要素を参照する場合、著者はgroupまたはregionのロールを参照先のコンテナーに割り当てるべきである。

著者がcomment要素に対してaria-level、aria-posinsetまたはaria-setsizeを明示的に宣言していない場合、ユーザーエージェントは欠落している値を自動的に計算し、それらを支援技術に公開しなければならない。

兄弟または直系の子孫であるメインコンテンツを補完するように設計されたランドマーク。complementaryランドマークのコンテンツは、仮にそれが関連するメインコンテンツから分離されたとしても、意味のあるままであることが期待されるだろう。

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

支援技術は、ユーザーがロールcomplementaryをもつ要素にすばやくナビゲートできるようにすべきである。ユーザーエージェントは、ナビゲーションランドマークとしてcomplementaryのロールをもつ要素を扱うべきである。ユーザーエージェントは、ユーザーがロールcomplementaryをもつ要素にすばやくナビゲートできるようにしてもよい。

ナビゲート可能なアクセシビリティ子孫を含むことができるウィジェット。

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

compositeは、オントロジーのために使用される抽象ロールである。著者は、コンテンツにおいてcompositeロールを使用してはならない。

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

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

支援技術は、ユーザーがロールcontentinfoをもつ要素にすばやくナビゲートできるようにすべきである。ユーザーエージェントは、ナビゲーションランドマークとしてcontentinfoのロールをもつ要素を扱うべきである。ユーザーエージェントは、ユーザーがロールcontentinfoをもつ要素にすばやくナビゲートできるようにしてもよい。

著者は、contentinfoロールをもつページ上の要素を1つだけマークすべきである。

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

著者は、定義されている要素を特定し、その要素に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のスクロール可能なlist。スクロールがarticleにリストの両端に追加または削除されるかもしれない。

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は参照する要素と同じ場所で表示される必要はない。著者は、その名前、説明テキスト、またはその両方を含むことができるcaptionをfigureに提供してもよい。captionが提供され、かつそのcaptionがfigureのコンテンツの説明として機能する場合、著者はaria-detailsを用いてそのcaptionをfigure要素に関連付けるべきである。

作成者は、aria-labelを用いてfigureにアクセシブルな名前を提供するまたは、ページ内の他のテキストを参照し、要素のラベルおよびアクセス可能な名前として機能するためにaria-labelledbyを使用してもよい。

figureをcaptionに関連付ける方法の詳細については、captionロールを参照のこと。

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

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

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

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

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

支援技術は、ユーザーがロールformをもつ要素にすばやくナビゲートできるようにすべきである。ユーザーエージェントは、ロールformおよびアクセシブルな名前をもつ要素を、ナビゲーションのランドマークとして扱うべきである。ユーザーエージェントは、ユーザーがロールformをもつ要素にすばやくナビゲートできるようにしてもよい。

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

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

ロールpresentationをもつ要素と同様に、ロールgenericをもつ要素は、aria-live属性など、その子孫にアクセシブルなステートおよびプロパティの数を制限して提供できる。

しかし、ロールpresentationをもつ要素とは異なり、ユーザーエージェントは、許可されたアクセシビリティ属性が指定されている場合、アクセシビリティAPIのgeneric要素を公開する。ユーザーエージェントは、そのような許可された属性が指定されていない場合、generic要素を無視してもよい。

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

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

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

フォーカスの管理で説明されるように、キーボードアクセシブルであるために、著者は、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の適切な取り扱いは、グループが提供されるコンテキストによって決定される。