6. サポートされるステートおよびプロパティ

compositeウィジェットの現在アクティブな子孫を識別する。

複合ウィジェットがすべての子にフォーカス可能にさせるものに属するオーバーヘッドを減らすために現在のアクティブな子を管理する責任がある場合に、これは使用される。例として、マルチレベルリスト、ツリー、グリッドがある。一部の実装において、ユーザーエージェントは、アクティブな子孫がフォーカスを持つ支援技術に伝えるためにaria-activedescendantを使用できる。著者は、複合ウィジェットのフォーカスされる子孫のaria-activedescendant属性を使用してもよい。たとえば、コンボボックスのテキストボックス子孫に。

著者は、aria-activedescendant属性によって対象にされる要素が、DOM内のコンテナの子孫、またはaria-owns属性によって示されるような論理子孫のいずれかであることを保証すべきである。ユーザーエージェントは、アクティブな子孫がコンテナの子孫であることの検証を期待されない。著者は、フォーカスされる際に現在アクティブな子孫が可視であり視野内にある（またはスクロールすると視野に入る）ことを保証すべきである。

支援技術がaria-relevant属性によって定義される変更通知に基づく変更される領域のすべて、または一部のみを提示するかどうかを示す。関連するaria-relevantを参照のこと。

アクセシビリティーAPIとドキュメントオブジェクトモデル[DOM]の両者は、支援技術が文書の変更された領域を決定するのを可能にするイベントを提供する。

ライブ領域のコンテンツが変更される場合、ユーザーエージェントは、変更された要素を調査し、aria-atomicセットをもつ最初の要素を見つけるために先祖を横断し、以下の場合に対する適切な動作を適用すべきである。

1. 先祖のいずれも明示的にaria-atomicを設定しない場合、aria-atomicがfalseであるのがデフォルトであり、支援技術はユーザーに変更されたノードのみを表示する。
2. aria-atomicが明示的にfalseに設定される場合、支援技術は、先祖チェーンの検索を停止し、ユーザーに変更されたノードのみを表示する。
3. aria-atomicが明示的にtrueに設定される場合、支援技術は、要素の完全なコンテンツを表示する。

aria-atomicがtrueである場合、支援技術は、複数の変更を結合し、一度に全体の変更領域を表示することを選択してもよい。

ユーザー入力を補完する提案が提供されるかどうかを示す。

inlineまたはbothのいずれかに設定したaria-autocomplete属性をもつtextboxに対して、著者は、任意の自動補完テキストが選択されていることを保証すべきであり、その結果ユーザーはテキストボックス上に入力することができる。

コンテンツまたは存在が現在の要素によって制御される要素を識別する。関連するaria-ownsを参照のこと。

たとえば：

• コンテンツツリービューの表は、隣接する文書ペインのコンテンツを制御することができる。
• チェックボックスのグループは、商品価格が表やグラフにライブ追跡されるものを制御することができる。
• タブは、関連するタブパネルの表示を制御する。

オブジェクトを記述する要素を識別する。関連するaria-labelledbyを参照のこと。

aria-labelledby属性は、代替テキストを計算するために、その両方の参照要素でaria-describedbyに似ているが、説明がより詳細な情報を提供することを目的とする場所で、ラベルは、簡潔にすべきである。

要素またはaria-describedbyに参照される要素は、全体の記述から成る。必要に応じて、複数の要素にID参照を含む、またはIDによって参照される要素をもつ要素（たとえば、段落）のセットを囲む。

ユーザーの裁量で、支援技術が文書ソースの順に読み上げの一般的なデフォルトを上書きを可能にする、コンテンツの代替読み上げ順で次の要素を識別する。

aria-flowtoが単一のIDREFを持つ場合、ユーザーの要求に応じて、支援技術は、通常の文書読み込み順序を見合わせ、対象となるオブジェクトまで進むことを可能にする。しかし、aria-flowtoが複数のIDREFSを提供される場合、支援技術はパスの選択肢として参照される要素を提示すべきである。

1つ以上のIDREFSの場合、ユーザーエージェントまたは支援技術は、ユーザーにターゲットとなる要素のいずれかにナビゲーションのオプションを与えるべきである。パス名はaria-flowto属性のターゲット要素の名前によって決定することができる。アクセシビリティーAPIは、名前付けされたパスの関係を提供することができる。

要素がポップアップのコンテキストメニューまたはサブレベルのメニューを持つことを示す。

これは、アクティブ化が条件付きコンテンツを描くことを意味する。通常のツールチップはこのコンテキストでポップアップを考慮しないことに注意する。

ポップアップは一般に、主要ページコンテンツの上部に出現する項目のグループとして視覚的に提供される。

現在の要素を分類する文字列の値を定義する。関連するaria-labelledbyを参照のこと。

aria-labelの目的はaria-labelledbyと同じである。これは、ユーザーにオブジェクトの認識可能な名前を提供する。ラベルをマッピングする最も一般的なアクセシビリティーAPIは、アクセシブルな名前プロパティである。

ラベルテキストが画面上で可視である場合、著者は、aria-labelledbyを使用すべきであり、aria-labelを使用すべきではない。要素の名前が要素のコンテンツからプログラム的に決定することができない事例があってもよく、可視ラベルの提供が所望のユーザー体験でない場合がある。これはブラウザーのツールチップを提示するかもしれないにもかかわらず、ほとんどのホスト言語は、要素に名前を付けるために使用できる属性を提供する（たとえば、HTMLにおけるtitle属性[HTML]）。可視ラベルまたは可視ツールチップが望ましくないケースで、著者は、aria-labelを使用して要素のアクセシブルな名前を設定してもよい。代替テキスト演算により必要に応じて、アクセシブルな名前プロパティを計算する際に、ユーザーエージェントはaria-labelよりaria-labelledbyを優先する。

現在の要素を分類する要素を識別する。関連するaria-labelおよびaria-describedbyを参照のこと。

aria-labelledbyの目的はaria-labelと同じである。これは、ユーザーにオブジェクトの認識可能な名前を提供する。ラベルをマッピングする最も一般的なアクセシビリティーAPIは、アクセシブルな名前プロパティである。

ラベルテキストが画面上で可視である場合、著者はaria-labelledbyを使用すべきであり、aria-labelを使用すべきではない。インターフェイスが画面上で可視ラベルを持つことが不可能である場合のみaria-labelを使用する。代替テキスト演算により必要に応じて、アクセシブルな名前プロパティを計算する際に、ユーザーエージェントはaria-labelよりaria-labelledbyを優先する。

aria-labelledby属性は、代替テキストを計算するために、その両方の参照要素でaria-describedbyに似ているが、説明がより詳細な情報を提供することを目的とする場所で、ラベルは、簡潔にすべきである。

注：アメリカ英語でこのプロパティの期待される綴りは"labeledby"である。しかし、このプロパティがマップされるアクセシビリティーAPI機能には、"labelledby"の綴りを確立している。このプロパティは、慣習に一致し、開発者に対する難しさを最小化するためにそのように綴られる。

構造内の要素の階層レベルを定義する。

これは、ツリー項目、文書内の見出し、ネストされたグリッド、ネストされたtablists、およびコンテナ内に出現するまたは所有権の階層に参加することができる他の構造アイテムに、ツリーの内側で適用することができる。aria-levelの値は1以上の整数である。

レベルは深さとともに増加する。DOMの祖先が正確にレベルを表さない場合、著者は、明示的にaria-level属性を定義すべきである。

この属性は、たとえば、ロールgroupをもつ要素よりもむしろロールtreeitemをもつ要素で、セットの方向内のリーフノードとして動作する要素に適用される。これは、セット内の複数の要素がこの属性に対して同じ値を持ってもよいことを意味する。属性はコンテナに単一の値を提供するためにより少ない反復的になるが、リーフノードにこれを制限することは、属性を使用するための支援技術に対する単一の方法があることを保証する。

DOMの祖先が正確にレベルを表す場合、ユーザーエージェントは、文書構造から項目のレベルを計算することができる。文書構造またはaria-ownsから算出することができない場合に、この属性はレベルの明示的指示を提供するために使用できる。レベルの自動計算に対するユーザーエージェントのサポートは異なるかもしれない。著者は、この属性が必要かどうかを判断するためにユーザーエージェントおよび支援技術を試験すべきである。著者がレベルを計算するためにユーザーエージェントに対して意図する場合、著者は、この属性を省略すべきである。

注：treegridについて、aria-levelは、ロールgridcellをもつ要素でなく、ロールrowをもつ要素でサポートされる。一見すると、これはtreeitem要素上のaria-levelのアプリケーションと矛盾するように見えるかもしれないが、gridcellが各rowの水平方向内でリーフノードであるのに対して、gridの垂直方向内のリーフノードとしてそのrowの動作で一貫している。レベルは行内のセルのセットでサポートされないので、aria-level属性はロールrowをもつ要素に適用される。

要素が更新されることを示し、ユーザーエージェントの更新の種類、支援技術の種類を説明し、ユーザーがライブ領域から期待することができる。

この属性の値は、重要度で表現される。領域がpoliteとして指定される場合、支援技術はユーザーに更新に通知するが、一般に現在のタスクを中断せず、更新が低い優先度を取る。領域がassertiveとして指定される場合、支援技術はすぐにユーザーに通知し、かつ潜在的に前の更新の音声キューをクリアすることができる。Live Region Properties and How to Use Themを参照のこと（[ARIA-PRACTICES]、5.2.1節）。

ポライトネスレベルは、本質的に更新のための順序付けメカニズムであり、ユーザーエージェントまたは支援技術に強い提案として供給する。値は、ユーザーエージェント、支援技術、またはユーザーによって上書きされるかもしれない。たとえば、支援技術は変更がキー入力やマウスのクリックに反応して発生したと判断できる場合、たとえaria-live属性の値が異なって明言する場合であっても、支援技術はすぐにその変更を提示することができる。

別のユーザーが異なるニーズを持つので、一般に定義されたベースラインからの一定のポライトネスレベルをもつライブ領域へユーザーの支援技術の応答を微調整するのはユーザー次第である。ユーザーがキューと中断に制御をふるうことができるように、支援技術は、増減する粒度のレベルを実装することを選択できる。

プロパティが更新を送信する必要があるオブジェクトに設定されない場合、ポライトネスレベルは、aria-live属性を設定する最も近い祖先の値である。

aria-live属性は、ライブ領域に変更の提示の順序に対する主要な決定である。aria-live属性が祖先チェーンに設定されない場合（たとえば、log変更はデフォルトでpoliteである）、実装はまた、ロールでポライトネスのデフォルトのレベルを考慮する。assertiveである項目は、politeな項目の直後に表示される。ユーザーエージェントまたは支援技術は、断定的な変化が発生する際にキューに入れられた変更をクリアするために選択してもよい。（たとえば、断定的な領域における変更は、すべての現在キューの変更を削除するかもしれない）

テキストボックスが複数行の入力または単一行のみを受け入れるかどうかを示す。

注：ほとんどのユーザーエージェントの実装において、ENTERキーまたはRETURNキーのデフォルトの動作は、HTMLで、単一行と複数行のテキストフィールドとの間で異なる。ユーザーが単一行の<input type="text">要素にフォーカスを持つ場合、キーストロークは通常、フォームを送信する。ユーザーが複数行の<textarea>要素にフォーカスを持つ場合、キーストロークは改行を挿入する。WAI-ARIA textboxロールは、aria-multiline属性をもつボックスのこれらの種類を区別する。よって著者は、フィールドを設計する際にこの区別を意識することを勧める。

ユーザーが現在の選択可能な子孫から複数の項目を選択できることを示す。

著者は、選択した子孫がtrueに設定されるaria-selected属性を持ち、選択可能な子孫がfalseに設定されるaria-selected属性を持つことを保証すべきである。著者は選択可能でない子孫上のaria-selected属性を使用すべきでない。

注：リストおよび木は、ユーザーに一度に複数の項目の選択を可能にするかもしれないロールの例である。

要素および向きが水平または垂直であるかどうかを示す。

DOM階層が関係を表すために使用することができないDOM要素間の、可視的、機能的、またはコンテキストの親子関係を定義するために要素を識別する。関連するaria-controlsを参照のこと。

aria-owns属性の値は、IDによって文書における1つ以上の要素を参照するIDREFSのスペース区切りのリストである。aria-ownsを追加する理由は、DOMから推測する他の方法では不可能である支援技術に親子コンテキストの関係を公開することである。

著者は、DOM階層の代替としてaria-ownsを使用すべきでない。関係がDOMで表現される場合、aria-ownsを使用してはならない。著者は、要素のIDがいつでも複数の他の要素のaria-owns属性で指定されないことを保証しなければならない。言い換えれば、要素は、1つの明示的な所有者のみを持つことができる。

リスト項目またはツリー項目の現在のセットにおける要素の数または位置を定義する。セットにおけるすべての要素がDOMに存在する場合は必要ない。関連するaria-setsizeを参照のこと。

セットにおけるすべての項目が文書構造に存在する場合、ユーザーエージェントが自動的に各項目のセットサイズおよび位置を計算することができるため、この属性を設定する必要はない。しかし、セットの一部だけが与えられた瞬間に文書構造に存在する場合、このプロパティは、要素の位置の明確な表示を提供するために必要とされる。

次の例は、16のセットで5から8の項目を示す。

<h2 id="label_fruit"> Available Fruit </h2>
<ul role="listbox" aria-labelledby="label_fruit">
  <li role="option" aria-setsize="16" aria-posinset="5"> apples </li>
  <li role="option" aria-setsize="16" aria-posinset="6"> bananas </li>
  <li role="option" aria-setsize="16" aria-posinset="7"> cantaloupes </li>
  <li role="option" aria-setsize="16" aria-posinset="8"> dates </li>
</ul>

著者は、1以上かつセットのサイズ以下の整数をaria-posinsetに値を設定しなければならない。著者は、aria-setsizeと同時にaria-posinsetを使用すべきである。

要素は編集可能でないが、他の方法で動作可能であることを示す。関連するaria-disabledを参照のこと。

これは、ユーザーは読むことができるが、ウィジェットの値を設定できないことを意味する。読み取り専用の要素は、ユーザーに関連し、アプリケーションの著者は、要素または要素のフォーカス可能な子孫にナビゲーションを制限すべきでない。要素の値をコピーするなどの他のアクションはまたサポートされる。これは、アプリケーションが子孫へのユーザーナビゲーションを許可しないかもしれない、無効要素とは対照的である。

例は以下を含む：

• 定数を表すフォーム要素。
• スプレッドシートのグリッドにおける行または列見出し。
• ショッピングカートの合計のような計算結果。

支援技術がライブ領域内で受信する通知（追加、削除など）をユーザーエージェントが変更するものを示す。関連するaria-atomicを参照のこと。

属性は、次の値のスペースで区切りリストとして表現される：additions、removals、textまたは包括的な値all。

単にプレゼンテーション的なものとは対照的に、これは、重要なセマンティック的な変化を説明するために使用される。たとえば、ログの上部から除去されたノードは、単に他のエントリーに対して場所を作成する目的のために除去され、そのノードの除去は意味を持たない。しかし、バディリストの場合、バディ名の除去は、もはやオンラインでないことを示す、そしてこれは意味のあるイベントである。その場合aria-relevantはallに設定される。aria-relevant属性が提供されない場合、デフォルト値、追加のテキスト、テキストの修正表示およびノードの追加は関連するが、ノード削除は無関係である。

注：removalsまたはallのaria-relevant値は、控えめに使用される。チャットルームを退出するバディのような、コンテンツの除去が重要な変更を表す場合、支援技術は、コンテンツの除去を告知のみを必要とする。

注：指定された値の1つが'removals'または'all'である場合、テキストの除去は適切に考慮されるべきである。たとえば、デフォルトのaria-relevant値をもつライブ領域において'foo'から'bar'へのテキストの変更のために、テキスト追加（ 'bar'）は話されるが、テキスト除去（'foo'）話されない。

aria-relevantは、ライブ領域のオプションの属性である。これは支援技術に提案するが、支援技術はすべての関連する種類の変更を提示する必要はない。

アクセシビリティーAPIとDocument Object Model Level 2 Events [DOM]の両者は、支援技術に文書の変更された領域を決定することを可能にするためにイベントを提供する。

aria-relevantが定義されない場合、要素の値は定義される値をもつ最も近い祖先から継承される。値はトークンリストであるが、継承された値は追加式ではない。子孫要素に供給される値は、祖先要素から継承された値をすべて完全に上書きする。

テキストの変更がrelevantとして表記される場合、ユーザーエージェントは、あたかもアクセシブルな名前がコンテンツから（nameFrom: contents）決定されたかのように、ライブ領域の代替テキストの計算に影響を与える任意の子孫ノード変更を監視しなければならない。たとえば、含まれる画像のHTML alt属性が変更された場合、テキストの変更はトリガーされる。しかし、たとえそのノードがライブ領域に含まれる要素によって参照された（aria-labelledby経由）としても、ライブ領域外のノードへのテキストの変更があった場合、変更はトリガーされない。

フォームが送信される前に要素でユーザー入力が要求されることを示す。

ユーザーがアドレスフィールドに記入する必要がある場合、著者は、フィールドのaria-required属性をtrueに設定する必要がある。

注：要素が要求されるという事実は多くの場合、視覚的に提示される（たとえばウィジェットの後に記号やシンボルなど）。aria-required属性の使用は、著者に要素が要求されることを支援技術に明示的に伝えることを可能にする。

厳密に等価なネイティヴ属性が利用可能である場合を除き、ホスト言語は、著者にユーザーによって入力または選択を必要とするホスト言語フォーム要素上のaria-required属性の使用を可能にすべきである。

リスト項目またはツリー項目の現在のセット内の項目の数を定義する。セットにおけるすべての要素がDOMに存在する場合は必要ない。関連するaria-posinsetを参照のこと。

このプロパティは、セットのメンバーを収集するコンテナ要素ではなく、セットのメンバーにマークされる。要素を言及することでユーザーを方向づけることは、"Yのうち項目X"であり、支援技術は、aria-posinset属性に等しいXおよびaria-setsize属性に等しいYを使用する。

セットにおけるすべての項目が文書構造に存在する場合、ユーザーエージェントが自動的に各項目のセットサイズおよび位置を計算することができるため、この属性を設定する必要はない。しかし、セットの一部だけが与えられた瞬間に文書構造に存在する場合（文書サイズを削減するために）、このプロパティは、セットの大きさの明確な表示を提供するために必要とされる。

次の例は、16のセットで5から8の項目を示す。

<h2 id="label_fruit"> Available Fruit </h2>
<ul role="listbox" aria-labelledby="label_fruit">
  <li role="option" aria-setsize="16" aria-posinset="5"> apples </li>
  <li role="option" aria-setsize="16" aria-posinset="6"> bananas </li>
  <li role="option" aria-setsize="16" aria-posinset="7"> cantaloupes </li>
  <li role="option" aria-setsize="16" aria-posinset="8"> dates </li>
</ul>

著者は、aria-posinsetと連携してaria-setsizeを使用すべきである。

テーブルまたはグリッド内の項目が昇順または降順にソートされるかどうかを示す。

著者は、テーブル見出しまたはグリッド見出しにこのプロパティを適用すべきである。プロパティが提供されない場合、定義されるソート順は一切存在しない。各テーブルまたはグリッドのために、著者は、一度に1見出しのみaria-sortを適用すべきである。

範囲ウィジェットに対する最大許容値を定義する。

このプロパティによって定義される、最大値まで増加させることができる任意の値で開始できる範囲ウィジェットは、到達する。

最小値および最大値を宣言することは、代替デバイスに矢印キーを再動作させる、現在値を検証する、または単にユーザーに範囲の大きさ知らせることを可能にする。aria-valuenowが既知の最大値および最小値を持つ場合、著者はaria-valuemaxおよびaria-valueminに対してプロパティを提供すべきである。著者は、aria-valuemaxの値がaria-valueminの値以上であることを保証しなければならない。

範囲ウィジェットに対する最小許容値を定義する。

このプロパティによって定義される、最小値まで減少させることができる任意の値で開始できる範囲ウィジェットは、到達する。

最小値および最大値を宣言することは、代替デバイスに矢印キーを再動作させる、現在値を検証する、または単にユーザーに範囲の大きさ知らせることを可能にする。aria-valuenowが既知の最大値および最小値を持つ場合、著者はaria-valuemaxおよびaria-valueminに対してプロパティを提供すべきである。

著者は、aria-valueminの値がaria-valuemaxの値以下であることを保証しなければならない。

範囲ウィジェットに対する現在値を定義する。関連するaria-valuetextを参照のこと。

このプロパティは、たとえば、スライダーやプログレスバーなどの範囲ウィジェットで使用される。

現在値が既知でない（たとえば、不確定な進捗バー）場合、著者はaria-valuenow属性を設定すべきでない。aria-valuenow属性が存在しない場合、いかなる情報も現在値について示されない。aria-valuenowが既知の最大値および最小値を持つ場合、著者はaria-valuemaxおよびaria-valueminに対してプロパティを提供すべきである。

aria-valuenowの値は10進数である。範囲が数値のセットである場合、aria-valuenowは、この値のいずれかである。たとえば、範囲が[0, 1]である場合、有効なaria-valuenowは0.5である。-2.5または1.1のような、範囲外の値は無効である。

progressbar要素およびscrollbar要素の場合、支援技術は、両方が定義される場合はaria-valueminからaria-valuemaxまでの範囲上の位置として算出される、パーセントとしてユーザーに値をレンダリングするべきであり、そうでなければ、パーセントインジケータをもつ実際値をレンダリングすべきである。ロールsliderおよびspinbuttonをもつ要素の場合、支援技術は、ユーザーに実際値をレンダリングすべきである。

レンダリングされる値が数値として正確に表すことができない場合、著者は、範囲の現在値のユーザーフレンドリーな表現を提供するためにaria-valuenowと併せてaria-valuetext属性を使用すべきである。たとえば、スライダーはsmall、medium、largeの値をレンダリングしているかもしれない。この場合、aria-valuenowの値は、値空間における各値の位置を示す、1から3までの範囲をとるだろうが、aria-valuetextは、small、medium、またはlargeの文字列のいずれかになる。

注：aria-valuetextが指定される場合、支援技術は、aria-valuenowの値を代わりにレンダリングする。

範囲ウィジェットに対するaria-valuenowの人間可読な代替テキストを定義する。

このプロパティは、たとえば、スライダーやプログレスバーなどの範囲ウィジェットで使用される。

aria-valuetext属性が設定される場合、その値が不明である場合を除き、著者はaria-valuenow属性も設定すべきである（たとえば、不確定なprogressbar上）。

レンダリングされる値が意味のある数値として表すことができない場合、著者はaria-valuetext属性のみを設定すべきである。たとえば、スライダーはsmall、medium、largeの値をレンダリングしているかもしれない。この場合、aria-valuenowの値は、値空間における各値の位置を示す、1から3までの範囲をとるだろうが、aria-valuetextは、small、medium、またはlargeの文字列のいずれかになる。aria-valuetextが指定される場合、支援技術は、aria-valuenowの値の代わりの値をレンダリングすべきである。

aria-valuetextが指定される場合、支援技術は、aria-valuenowの値の代わりの値をレンダリングすべきである。