6. 利用可能な状態（states）とプロパティ（properties）

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が単一のID参照をもつ場合、この属性は支援技術が、ユーザーの要求に応じて、通常の文書読み込み順序を見合わせ、指定対象のオブジェクトまで進むことを可能にします。しかし、aria-flowtoが複数のID参照を伴って指定された場合には、支援技術はパスの選択肢として参照された要素を提示するべきです。

1つまたはそれ以上のID参照の場合、ブラウザーまたは支援技術は、指定対象要素のいずれにもそこへ移動する選択オプションをユーザーに与えるべきです。パス名は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の値の代わりの値をレンダリングすべきである。