A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://momdo.github.io/accname-1.1/ below:

Accessible Name and Description Computation 1.1 日本語訳

この文書は「Accessible Name and Description Computation 1.1(W3C Recommendation2018-12-18)」の日本語訳です。日本語訳は参考情報であって、公式な文書ではありません。また、翻訳に誤りがありえます。

訳者への連絡先、他の仕様の翻訳等については、Wikiを参照ください。

概要

この文書は、ユーザーエージェントがウェブコンテンツ言語からアクセシブルオブジェクト名前および説明をどのように決定するのかを説明する。この情報はアクセシビリティAPIを通じて公開されるため、支援技術はこのオブジェクトを識別し、その名前または説明をユーザーに提示することができる。名前および説明を決定するためのアルゴリズムを文書化することは、異なるアクセシビリティAPI間でこれらのプロパティの相互運用可能な公開を促進し、この情報が著者の意図と一致する方法で表示されるように保証することを促す。

アクセシブルな名前および説明の計算仕様は、複数のコンテンツ技術に適用されるサポートを定義する。これには、汎用のWAI-ARIA [WAI-ARIA]ロールステート、およびプロパティだけでなく、個々のコンテンツ言語に固有の機能によって提供されるアクセシブルな名前および説明も含まれる。

この文書は、WAI-ARIA 1.0 User Agent Implementation Guide [WAI-ARIA-IMPLEMENTATION] W3C勧告のアクセシブルな名前および説明のガイダンスに取って代わる。この文書は、WAI-ARIA Overviewで説明されているWAI-ARIAスイートの一部と位置付けられている。

この文書の位置付け

この節は、公開時点におけるこの文書のステータスについて説明する。他の文書がこの文書に取って代わるかもしれない。W3Cが現在公開しているリストとテクニカルレポートの最新版は、W3C technical reports index at https://www.w3.org/TR/で見つけることができる。

この文書は、Accessible Rich Internet Applications Working GroupによるAccessible Name and Description Computation (Accname) 1.1の W3C Recommendationである。Working Groupは、仕様が実装可能であることを実証するために Accname 1.1実装レポートを作成した。Accname 1.1への変更点の履歴は付録で利用可能である。

この文書にコメントするには、W3C accna GitHubリポジトリーに提出する。これを実行できない場合、public-aria@w3.orgコメントアーカイブ)にメールを送信する。Accname 1.1勧告に寄せられたコメントは、この仕様のバージョンに変更をもたらすことはできないが、エラッタまたはAccnameの将来のバージョンで対処することができる。ワーキンググループは、コメントに正式な回答をすることはないが、ワーキンググループによって行われる将来の仕事は、この文書で寄せられたコメントに対処することができる。技術の進行中の更新は、公開エディターズドラフトで見ることができる。

この文書は、RecommendationとしてAccessible Rich Internet Applications Working Groupによって発行された。

Working Groupの実装レポートを参照されたい。

この文書は、W3Cのメンバー、ソフトウェア開発者、および他のW3Cグループや利害関係者によって検討され、W3C勧告としてディレクターによって承認されている。これは安定した文書であり、規範的仕様として使用されてもよく、他の文書から引用してもよい。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範な開発を促進することである。これはウェブの機能と相互運用性を強化する。

この文書はW3C特許ポリシーの下で活動するグループによって作成された。W3Cは、グループの成果物に関するあらゆる開示特許の公開リストを管理する。ここには、特許開示にあたっての指示も含まれている。特許について十分に知識のある人物が、仕様にEssential Claim(s)が認められると判断した場合は、W3C特許ポリシーの第6章に従い情報を開示する必要がある。

この文書は、2018年2月1日のW3Cプロセス文書によって管理される。

目次
  1. 概要
  2. この文書の位置付け
  3. 1. 導入
  4. 2. 適合性
    1. 2.1 RFC 2119キーワード
    2. 2.2 規範的および参考情報の章
  5. 3. 重要な用語
  6. 4. 名前と説明
    1. 4.1 名前計算
    2. 4.2 説明計算
    3. 4.3 アクセシブルな名前および説明計算
      1. 4.3.1 用語
  7. 5. アクセシブルな名前および説明のマッピング
  8. 6. 付録
    1. 6.1 変更ログ
      1. 6.1.1 直前の公開ワーキングドラフトからの実質的な変更点
      2. 6.1.2 WAI-ARIA 1.0 User Agent Implementation Guide勧告からの他の実質的な変更点
    2. 6.2 謝辞
      1. 6.2.1 発行時点のARIA WGでアクティブな参加者
      2. 6.2.2 その他のARIAの貢献者、コメンター、および以前にアクティブな参加者
      3. 6.2.3 資金提供者の権利
  9. A. 参考文献
    1. A.1 標準情報
    2. A.2 参考文献
1. 導入

この章は非規範的である。

ユーザーエージェントはDOM [DOM]から情報を取得し、アクセシブルなオブジェクトで構成されるアクセシビリティツリーと呼ばれる並列構造を作成する。アクセシブルなオブジェクトは、そのロールステート、およびプロパティに関する情報を提供する。一例は、ロールがmenuitemであり、現在haspopupプロパティを持つenabled状態にあり、それがサブメニューにつながることを示す、アクセシブルなオブジェクトである。

この文書で説明されるアクセシブルなオブジェクトの2つのプロパティは、そのアクセシブルな名前およびアクセシブルな説明である。名前は、オブジェクトの目的に関する情報を提供する短いラベルである。メニュー項目のアクセシブルな名前の例はNewであり、メニュー項目が新しい文書、ウィンドウなどを作成するために提供することを意味する。

説明は、アクセシブルなオブジェクトの性質をさらに明確にする短い説明である。名前が十分である場合に説明を提供する必要は必ずしもないが、ユーザーがオブジェクトの使用法をよりよく理解するのに役立つ。

アクセシビリティAPIは現在、アクセシブルな名前および説明のためのフラットな非構造化文字列をサポートしている。名前/説明の計算結果は、フラットな文字列である。

用語"アクセシブルな名前"および"アクセシブルな説明"は、それらがアクセシビリティAPIによって公開されているアクセシブルなオブジェクトのプロパティであることを強調するために使用されている。しかし、それらは、以後単に"名前"および"説明"とたびたび呼ばれる。

2. 適合性

非規範的とマークとしてマークされる章と同様に、この仕様のすべてのオーサリングガイドライン、図、例、およびノートは非規範的である。この仕様における他のすべては規範的である。

キーワードは、[RFC2119]で示されるとおりに解釈されなければならない

2.1 RFC 2119キーワード

RFC 2119のキーワードは、(原文で)大文字で整形されかつclass="rfc2119"をもつstrong要素で包まれる。上に示したキーワードが使用されるが、この形式を共有しない場合キーワードは、RFC 2119の意味で形式的な情報を伝達せず、単なる説明、すなわち、参考情報である。可能な限り、そのような用途は、この使用において回避される。

2.2 規範的および参考情報の章

ある章規範的または非規範的(参考情報である)であるかかどうかの指示は、節を含む章全体に適用される。

参考情報の章は、この仕様を理解するのに有益な情報を提供する。そのような章は、推奨されるプラクティスの例を含むかもしれないが、この仕様に準拠するためにそのような推奨に従うことを必要としない。

3. 重要な用語

一部の用語は適当な位置に定義されるが、以下の定義は、この文書全体で使用される。

アクセシビリティAPI

オペレーティングシステムおよびその他のプラットフォームは、支援技術オブジェクトおよびイベントに関する情報を公開する一連のインターフェイスを提供する。支援技術は、情報を取得し、それらのウィジェットと対話するためにこれらのインターフェイスを使用する。アクセシビリティAPIの例は、Microsoft Active Accessibility [MSAA]、Microsoft User Interface Automation [UI-AUTOMATION]、MSAA with UIA Express [UIA-EXPRESS]、Mac OS X Accessibility Protocol [AXAPI]、Linux/Unix Accessibility Toolkit [ATK]およびAssistive Technology Service Provider Interface [AT-SPI]、ならびにIAccessible2 [IAccessible2]である。

アクセシビリティツリー

ユーザーインターフェイス(UI)の構造を表すアクセシブルなオブジェクトのツリー。アクセシビリティツリーの各ノードは、アクセシビリティAPIを介して公開されるようなUIにおける要素を表す。例えば、プッシュボタン、チェックボックス、またはコンテナなど。

アクセシブルな説明

アクセシブルな説明は、インターフェイス要素に関連する、アクセシブルな名前を補完する追加情報を提供する。アクセシブルな説明は、視覚的に知覚されるかもしれないし、されないかもしれない。

アクセシブルな名前

アクセシブルな名前は、ユーザーインターフェイス要素の名前である。各プラットフォームのアクセシビリティAPIは、アクセシブルな名前プロパティを提供する。アクセシブルな名前の値は、可視(たとえば、ボタンの可視テキスト)またはユーザーインターフェイス要素の不可視(たとえば、アイコンを説明する代替テキスト)プロパティから得られるかもしれない。関連するアクセシブルな記述を参照のこと。

アクセシブルな名前プロパティに対する簡単な用法は、"OK"ボタンによって説明することができる。テキスト"OK"は、アクセシブルな名前である。ボタンがフォーカスを受け取る場合、支援技術は、アクセシブル名前をもつプラットフォームのロールの説明を連結できる。たとえば、スクリーンリーダーは、"押しボタンOK"または"OKボタン"を話すことができる。連結の順序および役割の説明の詳細(たとえば"ボタン"、"押しボタン"、"クリック可能ボタン")は、プラットフォームアクセシビリティAPIまたは支援技術によって決定される。

アクセシブルなオブジェクト

アクセシビリティAPIアクセシビリティツリーにおけるノード。アクセシビリティオブジェクトは、支援技術による用途に対する、さまざまなステートプロパティおよびイベントを公開する。一般にマークアップ言語(HTMLやSVGなど)のコンテキストにおいて、特にWAI-ARIAにおいて、マークアップ要素およびその属性は、アクセシブルなオブジェクトとして表される。

支援技術

ハードウェアおよび/またはソフトウェアは:

この定義は他の文書で使用したものと異なるかもしれない。

この文書のコンテキストにおいて重要である支援技術の例としては次のものを含む:

属性

この仕様において、属性は、マークアップ言語における属性として使用される。属性は、要素によって表されるオブジェクトステートおよびプロパティに関する情報を提供するために要素に追加される構造的特徴である。

クラス

類似の特性を共有する一連のインスタンスオブジェクト

要素

この仕様において、要素は、マークアップ言語における要素として使用される。要素は、オブジェクトに対するデータプロファイルを含むマークアップ言語における構成要素である。

イベント

コンピュータシステムにおける他のオブジェクトにオブジェクトステートで個別の変化を通信するために使用されるプログラムのメッセージ。ウェブページへのユーザー入力は、相互作用を記述する抽象イベントを介して一般的に媒介され、ドキュメントオブジェクトのステートの変化の通知を提供することができる。一部のプログラミング言語において、イベントは、通知としてより一般的には知られる。

非表示

要素すべてのユーザーに可視、知覚可能またはインタラクティブでないことを示す。要素またはいずれかのその祖先要素がレンダリングされないか明示的に隠される場合、要素は非表示と考えられる。

参考情報

情報目的で提供されかつ適合のために必須でないコンテンツ。適合するために必要なコンテンツは、規範的と呼ばれる。

ノード

DOMツリーまたはアクセシビリティツリーにおけるオブジェクトの基本型。DOMノードは、他の型の中で、要素またはテキストノードとしてさらに指定される。アクセシビリティツリーのノードは、アクセシブルなオブジェクトである。

規範的

適合のために要求されるもの。対照的に、参考情報または"非規範"として識別されるコンテンツは、適合のために必須でない。

オブジェクト

ユーザーインターフェイスのコンテキストで、1つ以上の要素によってマークアップ言語で表現され、ユーザーエージェントによってレンダリングされる、知覚的ユーザーエクスペリエンスの項目。

プログラミングのコンテキストで、1つ以上のクラスおよび同様のオブジェクトの一般的な特性を定義するインターフェイスのインスタンス。アクセシビリティAPIにおけるオブジェクトは、1つ以上のDOMオブジェクトを表すことができる。アクセシビリティAPIは、DOMインターフェイスと区別されるインターフェイスを定義している。
知覚可能

ユーザーが感じることができる方法でユーザーに提示可能なもの。この文書における参照はWCAG 2.1原則1:コンテンツは知覚可能でなければならないに関連する。[WCAG20]

プロパティ

指定されたオブジェクトの性質に不可欠である、またはオブジェクトに関連付けられたデータ値を表す属性。プロパティの変化は、オブジェクトの意味または見栄えに著しい影響を与えるかもしれない。特定のプロパティ(たとえば、aria-multiline)は、ステートを変更する可能性がより低いが、変更差分の周期は原則でないことに注意する。aria-activedescendantaria-valuenow、およびaria-valuetextのような少数のプロパティは、頻繁に変更することが期待される。ステート対プロパティの明確化を参照のこと。

ロール

種類の主な指標。このセマンティックな関連付けはツールが存在してもよく、その種類の他のオブジェクトに関するユーザーの期待と一致する方法でオブジェクトとの相互作用をサポートしてもよい。

セマンティックス

コンピューターが要素および属性などのオブジェクトの表現を処理し、かつさまざまな人間がオブジェクトの一貫した理解を相互に達成するような方法でオブジェクトを確実に表現できるような方法で定義される、人間によって理解されるようなものの意味。

ステート

ステートは、ユーザーのふるまいまたは自動化プロセスに応じて変更することができるオブジェクトの特性を表現する動的なプロパティである。ステートは、オブジェクトの本質的な性質に影響を与えないが、オブジェクトまたはユーザーインタラクションの可能性に関連したデータを表す。プロパティに対するステートの明確化を参照のこと。

テキストノード

属性または要素のテキストコンテンツを表すDOMノードの型。テキストノードは子ノードを持たない。

ツールチップ属性

デスクトップユーザーエージェントのマウスホバーに応答してなど、ユーザーエージェントにツールチップの生成をもたらすホスト言語の属性。

ユーザーエージェント

ウェブコンテンツとのエンドユーザーのやりとりを引き出し、レンダリングしかつ容易にする任意のソフトウェア。この定義は他の文書で使用したものと異なるかもしれない。

ウィジェット

ユーザーが対話することができる個別のユーザーインターフェイスオブジェクト。ウィジェットは、1つの値または操作(たとえば、ボックスやメニュー項目をチェックする)を持つ単純なオブジェクトから、多数の管理されたサブオブジェクト(たとえば、ツリーやグリッド)を含む複雑なオブジェクト​へと多岐にわたる。

4. 名前と説明

名前および説明計算の出発点はDOM要素である。その出力はフラットであり、とても単純な1つの単語となりうる構造化されていない文字列、すなわちスペースで区切られたトークンの文字列である。例としては、SaveReload from diskがある。

重要な因子は要素ロールである。これは、どのコンテンツが名前文字列に寄与するかを決定する。ロールはnameFrom RDFプロパティを持ち、次の2つの値を取りうる:

著者
名前は、aria-labelおよびaria-labelledby属性などの明示的なマークアップ機能、またはHTMLのaltもしくはtitle属性、SVGのdesc要素などのホスト言語のラベル付けメカニズムで著者によって提供される値から生成される。
コンテンツ
名前は、要素に関連付けられるテキストノードから生成される。これは、一部のロールの"著者"に加えて、許可されてもよいが、"コンテンツ"は、より高い優先順位の"著者"機能が提供されない場合にのみ、使用される。優先順位はアクセシブルな名前および説明計算アルゴリズムによって定義される。

Accessible Rich Internet Applications (WAI-ARIA) 1.1 [WAI-ARIA]仕様は、著者由来の名前およびコンテンツ由来の名前をサポートするロールのリストを提供している。

4.1 名前計算

ユーザーエージェントは、下記のアクセシブルな名前および説明の計算の節で概説される規則を使用して、アクセシブルな名前を計算しなければならない

4.2 説明計算

aria-describedbyが存在する場合、ユーザエージェントは、現在の要素のaria-describeby属性によって参照される要素のテキストによる代替を連結することによってアクセシブルな説明を計算しなければならない。参照される要素のテキストによる代替は、アクセシブルな名前および説明の計算の節で概説される複数の方法を使用して計算される。

4.3 アクセシブルな名前および説明計算

アクセシブルな名前および説明の計算は、アクセシブルな名前アクセシブルな説明の両方を生成するために使用される。複数の異なる種類の要素ノード、およびマークアップの組み合わせに対して提供される異なる規則が存在する。適切な場合、テキストによる代替は、要素内に含まれるすべての関連コンテンツから構築される。これは、テキスト自身が参照する自身の子またはノードからテキストを検索するための規則の完全なセットを使用して、再帰的なステップ2Bおよび2Fを経て達成される。

計算の目的は、スペースで区切られたテキストトークンのフラットな文字列の形式で、代替プレゼンテーション用の知覚可能なラベルまたは説明を作成することである。

4.3.1 用語
ルートノード(Root node)
テキストによる代替が検索されるDOMノードまたは要素
カレントノード(Current node)
root nodeのテキスト同等物を計算するために現に横断したDOMノード。最初は、current noderoot nodeであるが、後の段階では、root nodeの子孫か、別の参照されるノードのいずれかになる。
フラットな文字列(Flat string)
すべてのキャリッジリターン、改行、タブ、およびフォームフィードが単一のスペースに置き換えられ、かつ複数のスペースが単一のスペースにまとめられる文字の文字列。この文字列は文字データのみを含む。マークアップは含まれない。
総累積テキスト(Total accumulated text)
これまでに計算されたテキスト同等物。ただし、current nodeを含めない。
累積テキスト(Accumulated text)
下記のステップまたはステップのシーケンスで累積されたテキスト。これは、下記のステップの一時的なストレージである。
結果(Result)
テキスト同等物は、次に説明するいずれかの手順で計算される。
スペースなしで結果をXに追加する(Append the result, without a space, to X)
スペース付きで結果をXに追加する(Append the result, with a space, to X)
スペースなしで結果をXの先頭に追加する(Prepend result, without a space, to X)
スペース付きで結果をXの先頭に追加する(Prepend the result, with a space, to X)

与えられた要素に対するテキストによる代替は、次のように計算される:

  1. 初期化する:root nodeを与えられた要素に、current noderoot nodeに、そしてtotal accumulated textを空文字列("")に設定する。
  2. current nodeのテキストによる代替を計算する:
    1. current node非表示であり、かつaria-labelledbyまたはaria-describebyによって直接参照されない場合、もしくはネイティヴホスト言語のテキストによる代替要素(HTMLのlabelなど)または属性によって直接参照されない場合、空文字列を返す。 コメント:

      デフォルトでは、支援技術は非表示情報を中継しないが、著者はそれを明示的に上書きし、aria-labelledbyまたはaria-describebyを使用することによって、アクセシブルな名前またはアクセシブルな説明の一部として非表示テキストを含めることができる。

    2. そうでなければ:
      • 名前を計算して、current nodeが少なくとも1つの妥当なIDREFを含むaria-labelledby属性を持ち、かつcurrent nodeがまだaria-labelledbyトラバーサルの一部でない場合、そのIDREFを発生順に処理する:
      • または、説明を計算して、current nodeが少なくとも1つの妥当なIDREFを含むaria-describedby属性を持ち、かつcurrent nodeがまだaria-describedbyトラバーサルの一部でない場合、そのIDREFを発生順に処理する:
        1. accumulated textを空文字列に設定する。
        2. IDREFごとに:
          1. current nodeをIDREFによって参照されるノードに設定する。
          2. ステップ2から始めて、current nodeのテキストによる代替を計算する。result結果をそのテキストによる代替に設定する。
          3. スペース付きでresultaccumulated textに追加する。
        3. accumulated textを返す。
      例:

      次の例は、「…かつcurrent nodeがまだaria-labelledbyトラバーサルの一部でない…」という句の意味を示している。

      • element1アクセシブルな名前は"hello"である。これは、そのaria-labelledbyの最初のトラバースであり、element3につながるためである。
      • element2アクセシブルな名前を持たない。計算は、element1につながるaria-labelledbyの最初のトラバースを含むが、element1aria-labelledbyはその後は続かない。
      <element1 id="el1" aria-labelledby="el3" />
      <element2 id="el2" aria-labelledby="el1" />
      <element3 id="el3"> hello </element3>
    3. そうでなければ、名前を計算する場合、およびcurrent nodeが空文字列でなく、空白を除去したときに空文字列でもないaria-label属性を持つ場合:
      • current nodeのトラバースが再帰によるものであり、かつcurrent nodeがステップ2Eで定義されている埋め込みコントロールである場合、aria-labelを無視してルール2Eにスキップする。
      • そうでなければ、aria-labelの値を返す。
      例:

      次の例は、ノードが自分自身を参照するaria-labelledbyを持つときの、aria-labelledbyaria-labelの相互作用を示している。<span role="button">要素は、それぞれ"Delete Documentation.pdf"と"Delete HolidayLetter.pdf"というアクセシブルな名前を持つ。

      <h1>Files</h1>
      <ul>
        <li>
          <a id="file_row1" href="./files/Documentation.pdf">Documentation.pdf</a>
          <span role="button" tabindex="0" id="del_row1" aria-label="Delete" aria-labelledby="del_row1 file_row1"></span>
        </li>
        <li>
          <a id="file_row2" href="./files/HolidayLetter.pdf">HolidayLetter.pdf</a>
          <span role="button" tabindex="0" id="del_row2" aria-label="Delete" aria-labelledby="del_row2 file_row2"></span>
        </li>
      </ul>
    4. そうでなければ、current nodeのネイティヴマークアップがテキストによる代替を定義する属性titleなど)または要素(HTML labelなど)を提供する場合、要素がプレゼンテーションとしてマークされない限り(role="presentation"またはrole="none")、ホスト言語によって定義されたflat stringの形式でその代替を返す。 コメント:

      たとえば、HTMLにおいて、img要素のalt属性はテキストによる代替文字列を定義し、label要素は参照されるフォーム要素のテキストを提供する。SVG2において、desc要素およびtitle要素は、それらの親要素の説明を提供する。

    5. そうでなければ、埋め込みコントロールの値を調整できる場所で、current nodeが別のwidgetのラベル内に埋め込みコントロール(HTMLのlabel要素、またはaria-labelledbyによって直接参照される要素など)である場合、次の方法でテキストによる代替の一部として埋め込みコントロールを含める:
      • 埋め込みコントロールがロールtextboxを持つ場合、その値を返す。
      • 埋め込みコントロールがロールメニューbuttonを持つ場合、ボタンのテキストによる代替を返す。
      • 埋め込みコントロールがロールcomboboxまたはlistboxを持つ場合、選択したoptionのテキストによる代替を返す。
      • 埋め込みコントロールがロールrangeを持つ場合(spinbuttonsliderなど):
        • aria-valuetextプロパティが存在する場合、その値を返す。
        • そうでなければ、aria-valuenowプロパティが存在する場合、その値を返す。
        • そうでなければ、ホスト言語属性によって指定される値を使用する。
      例:

      テキスト入力フィールドを含むチェックボックスラベルについて考えてみよう:"Flash the screen [input] times"。ユーザーが埋め込みテキストボックスに"5"を入力した場合、完全なラベルは"Flash the screen 5 times"となる。

      <div role="checkbox" aria-checked="false">Flash the screen <span role="textbox" aria-multiline="false"> 5 </span> times</div>
    6. そうでなければ、current nodeロールコンテンツ由来の名前を許可する場合、またはcurrent nodearia-labelledbyもしくはaria-describebyによって参照される、もしくはネイティヴホスト言語のテキストによる代替要素(HTMLのラベルなど)である場合、またはネイティヴホスト言語のテキストによる代替要素の子孫である場合:
      1. accumulated textを空文字列に設定する。
      2. current nodeに関連付けられているCSSで生成されたテキストコンテンツを確認し、それをaccumulated textに含める。CSS :beforeおよび:after擬似要素[CSS2]は、コンテンツモデルを持つ要素にテキストコンテンツを提供することができる。
        • :before擬似要素の場合、ユーザーエージェントは、スペースなしでCSSテキストコンテンツをcurrent nodeのテキストコンテンツの先頭に追加しなければならない
        • :after擬似要素の場合、ユーザーエージェントは、スペースなしでCSSテキストコンテンツをcurrent nodeのテキストコンテンツに追加しなければならない
      3. current nodeのそれぞれの子ノードに対して:
        1. current nodeを子ノードに設定する。
        2. ステップ2から始めて、current nodeのテキストによる代替を計算する。result結果をそのテキストによる代替に設定する。
        3. resultaccumulated textに追加する。
      4. accumulated textを返す。

      重要:サブツリーの各nodeは一度だけ調べられる。テキストが子孫から収集されたが、いくつかの子孫ノードで別のIDREFによって参照される場合、その2回目以降の参照は行われない。これは、無限ループを避けるために行われる。

      コメント:

      このステップは子ノード自体にも適用でき、これは計算が再帰的であり、かつcurrent nodeのサブツリー内のすべての要素から収集されるテキストをもたらすことを意味する。しかし、任意の与えられたの子孫nodeのテキストによる代替は、上記のステップBからDで説明したより高い先行するマークアップに由来することがある。ここで"Namefrom: author"属性は、サブツリー全体のテキストによる代替を提供する。

    7. そうでなければ、current nodeテキストノードである場合、そのテキストのコンテンツを返す。
    8. そうでなければ、current nodeアクセシブルな名前またはアクセシブルな説明が計算されている要素の子孫であり、かつ子孫を含む場合、2F.iに進む。
    9. そうでなければ、current nodeツールチップ属性を持つ場合、その値を返す。 コメント:

      ツールチップ属性は、サブツリーのコンテンツを含めて他に何も結果を提供できない場合にのみ、使用される。

    スペース付きで上記の各ステップのresulttotal accumulated textに追加する。

すべてのステップが完了した後、total accumulated textは、計算を開始した要素アクセシブルな名前またはアクセシブルな説明として使用される。

5. アクセシブルな名前および説明のマッピング

labelled-by/label-forおよびdescribed-by/description-forなどの関係を含む、名前および説明のアクセシビリティAPIマッピングに関する情報は、Core Accessibility API Mappings specification [CORE-AAM-1.1]に記載されている。aria-labelaria-labelledby、およびaria-describedbyのマッピングテーブルエントリーを参照のこと。

6. 付録 6.1 変更ログ 6.1.1 直前の公開ワーキングドラフトからの実質的な変更点 C.1 WAI-ARIA 1.0 User Agent Implementation Guide勧告からの他の実質的な変更点 6.2 謝辞

この章は非規範的である。

次の人は、この文書の開発に貢献した。

6.2.1 発行時点のARIA WGでアクティブな参加者 6.2.2 その他のARIAの貢献者、コメンター、および以前にアクティブな参加者 6.2.3 資金提供者の権利

この出版物は、契約番号ED-OSE-10-C-0067のもとで米国教育省・障害者リハビリテーション研究所(NIDILRR)の政府資金によって一部賄われている。この出版物の内容は、必ずしも米国教育省の見解や政策を反映するものではなく、また商品名、商用製品、組織の言及は米国政府による支持を意味するものではない。

A. 参考文献 A.1 標準情報
[AT-SPI]
Assistive Technology Service Provider Interface. The GNOME Project. URL: https://developer.gnome.org/libatspi/stable/
[ATK]
ATK - Accessibility Toolkit. The GNOME Project. URL: https://developer.gnome.org/atk/stable/
[AXAPI]
The NSAccessibility Protocol for macOS. Apple, Inc. URL: https://developer.apple.com/documentation/appkit/nsaccessibility
[CORE-AAM-1.1]
Core Accessibility API Mappings 1.1. Joanmarie Diggs; Joseph Scheuhammer; Richard Schwerdtfeger; Michael Cooper; Andi Snow-Weaver; Aaron Leventhal. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/core-aam-1.1/
[CSS2]
Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. Bert Bos; Tantek Çelik; Ian Hickson; Håkon Wium Lie et al. W3C. 7 June 2011. W3C Recommendation. URL: https://www.w3.org/TR/CSS2/
[IAccessible2]
IAccessible2. Linux Foundation. URL: https://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2
[MSAA]
Microsoft Active Accessibility (MSAA) 2.0. Microsoft Corporation. URL: https://msdn.microsoft.com/en-us/library/ms697707.aspx
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[UI-AUTOMATION]
UI Automation. Microsoft Corporation. URL: https://msdn.microsoft.com/en-us/library/ee684009%28v=vs.85%29.aspx
[UIA-EXPRESS]
The IAccessibleEx Interface. Microsoft Corporation. URL: https://msdn.microsoft.com/en-us/library/windows/desktop/dd561898%28v=vs.85%29.aspx
[WAI-ARIA]
Accessible Rich Internet Applications (WAI-ARIA) 1.1. Joanmarie Diggs; Shane McCarron; Michael Cooper; Richard Schwerdtfeger; James Craig. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/wai-aria-1.1/
[WAI-ARIA-IMPLEMENTATION]
WAI-ARIA 1.0 User Agent Implementation Guide. Joseph Scheuhammer; Michael Cooper. W3C. 20 March 2014. W3C Recommendation. URL: https://www.w3.org/TR/wai-aria-implementation/
[WCAG21]
Web Content Accessibility Guidelines (WCAG) 2.1. Andrew Kirkpatrick; Joshue O Connor; Alastair Campbell; Michael Cooper. W3C. 5 June 2018. W3C Recommendation. URL: https://www.w3.org/TR/WCAG21/
A.2 参考文献
[DOM]
DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3