Jump to Table of Contents Collapse Sidebar

Accessible Name and Description Computation 1.2日本語訳

W3C Working Draft

More details about this document
This version:
https://www.w3.org/TR/2024/WD-accname-1.2-20240429/
Latest published version:
https://www.w3.org/TR/accname-1.2/
Latest editor's draft:
https://w3c.github.io/accname/
History:
https://www.w3.org/standards/history/accname-1.2/
Commit history
Latest Recommendation:
https://www.w3.org/TR/accname/
Editors:
Bryan Garaventa (Level Access)
Melanie Sumner (Invited Expert)
Former editors:
Michael Cooper (W3C)
Joanmarie Diggs (Igalia, S.L.) (Editor until March 2021)
Richard Schwerdtfeger (Knowbility) (Editor until October 2017)
Joseph Scheuhammer (Inclusive Design Research Centre, OCAD University) (Editor until May 2017)
James Craig (Apple Inc.) (Editor until May 2016)
Andi Snow-Weaver (IBM) (Editor until December 2012)
Aaron Leventhal (IBM) (Editor until January 2009)
Feedback:
GitHub w3c/accname (pull requests, new issue, open issues)

概要

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

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

この文書は、Accessible Name and Description Computation 1.1 [ACCNAME-1.1] W3C Recommendationにおけるアクセシブルな名前および説明のガイダンスを更新し、最終的にはこれに取って代わるものである。この文書は、WAI-ARIA Overviewで説明されているWAI-ARIAスイートの一部と位置付けられている。

この文書の位置付け

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

この文書は、Recommendation trackを使用したWorking DraftとしてAccessible Rich Internet Applications Working Groupによって公開された。

Working Draftとしての公開は、W3Cおよびその会員による承認を意味するものではない。

この文書は草案であり、いつでも更新、他の文書による置き換えや廃止扱いにされうる。進行中の作業以外のものとしてこの文書を引用することは不適切である。

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

この文書は2023年11月3日のW3Cプロセス文書によって管理される。

1. 導入

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

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

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

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

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

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

2. 重要な用語

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

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

支援技術

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

  • ウェブコンテンツを取得してレンダリングするためのユーザーエージェントによって提供されるサービスに依存する
  • APIの使用を通してユーザーエージェントまたはウェブコンテンツ自体と連動し、
  • 障害者によってウェブコンテンツとのユーザーの対話を容易にするためにユーザーエージェントによって提供されるものを超えたサービスを提供する

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

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

  • 拡大してかつレンダリングされたテキストと画像の視覚的な読みやすさを改善するために使用されるスクリーン拡大鏡。
  • 合成音声または点字ディスプレイを通して情報を伝達するために最も頻繁に使用されるスクリーンリーダー。
  • 合成音声にテキストを変換するために使用される音声変換ソフトウェア。
  • 音声制御とディクテーションを可能にするために使用される音声認識ソフトウェア。
  • キーボードをシミュレートするために使用される、(ヘッドポインタ、オンスクリーンキーボード、単一のスイッチ、息操作デバイスを含む)代替入力技術。
  • マウスポインタおよびクリックをシミュレートするために使用される代替ポインティングデバイス。
アクセシブルな説明

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

アクセシブルな名前

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

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

ツールチップ属性

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

3. 適合性

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

キーワードMAYMUSTおよびMUST NOTは、BCP 14 [RFC2119] [RFC8174]で示されるとおりに解釈される。ただし、大文字で表示される場合に限る。

3.1 RFC 2119キーワード

RFC-2119のキーワードは、大文字と太字で表記されている。上に示したキーワードが使用されるが、この形式を共有しない場合キーワードは、RFC 2119の意味で形式的な情報を伝達せず、単なる説明、すなわち、参考情報である。可能な限り、そのような用途は、この使用において回避される。

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

規範的または参考情報としての章の分類は、章全体に適用される。

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

4. 名前および説明

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

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

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

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

4.1 名前計算

ユーザーエージェントは、テキスト等価計算の節で概説される規則を使用して、アクセシブルな名前を計算しなければならない

4.2 説明計算

次の表に、アクセシブルな説明の計算に適用できるマークアップの優先順位を示す。ユーザーエージェントは、最後の列で説明されているように、記載された条件が満たされるテーブルから最初の適用可能なエントリーを使用しなければならない。ユーザーエージェントは、たとえそのマークアップの記述が空であっても、最初に発見された関連するマークアップ以外のマークアップを使用してはならない

優先順位 属性 適用条件 説明の計算方法
1 aria-describedby属性 すべての要素で使用 名前計算 要素上のaria-describedbyで参照され、連結され、スペース文字で区切られたすべてのノード
2 aria-description属性 すべての要素で使用 フラットな文字列として
3 説明計算に参加するホスト言語機能 一意のホスト言語機能は、該当する要素のアクセシブルな名前にまだ使用されていない場合にのみ、要素の説明計算に参加してもよい。この条件を満たすHTML要素については、HTML AAM: Accessible Description Computationを参照。 ホスト言語要素のテキスト等価計算、またはホスト言語属性の文字列値のいずれか。
4 ホスト言語のツールチップ属性または同等の機能(例:HTML title属性)
  • すべての要素
  • このノードのアクセシブルな名前にまだ使用されていない場合にのみ使用する。
フラットな文字列として

4.3 テキスト等価計算

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

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

4.3.1 用語

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

4.3.2 計算ステップ

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

  1. Initialization: root nodeを与えられた要素に、current noderoot nodeに、そしてtotal accumulated textを空文字列("")に設定する。root nodeのロールで名前付けが禁止されている場合、空の文字列("")を返す。
  2. Computation: current nodeのテキストによる代替を計算する。
    1. Hidden Not Referenced: current node非表示かつ存在する場合:
      1. aria-labelledbyまたはaria-describedbyトラバーサルの一部ではなく、そのリレーションによって直接参照されるノードが非表示になっていた場合。
      2. ネイティヴホスト言語のテキストによる代替要素(例:HTMLlabel)または属性トラバーサルの一部でもなく、トラバーサルのルートが非表示になっていた場合。
      空文字列を返す。
      注記

      アクセシブルな名前の計算のために、非表示の広い定義を明確にすることが重要である。

      1. CSSプロパティdisplay:nonevisibility:hiddenvisibility:collapseまたはcontent-visibility:hiddenを持つノード :これらは、「認識できない」および「明示的に非表示」のガイドラインに一致するため、非表示と見なされる。
      2. CSSプロパティopacity:0もしくはfilter:opacity(0%)、または同様のSVGメカニズムを持つノード:非表示とは見なされない。これらの方法で非表示にされたテキストは、選択またはコピーすることができ、ユーザーエージェントはアクセシビリティツリーでそのテキストを公開する。
      3. aria-hidden="true"プロパティを持つノード:非表示と見なされ、「明示的に非表示」のガイドラインに一致する。
      4. 画面外または別のオブジェクトの背後に隠れているノードは、非表示とは見なされない。これらはアクセシビリティツリーで公開され、画面上のオブジェクトに名前を付けることもできる。
      注記

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

    2. LabelledBy: そうでなければ、current nodeが少なくとも1つの有効なIDREFを含むaria-labelledby属性を持ち、かつcurrent nodeがまだ進行中のaria-labelledbyまたはaria-describedbyトラバーサルの一部になっていない場合、そのIDREFを出現順に処理する。
      1. accumulated textを空文字列に設定する。
      2. IDREFごとに:
        1. current nodeをIDREFによって参照されるノードに設定する。
        2. LabelledBy Recursion: 全体のComputationステップで始まるcurrent nodeのテキストによる代替を計算する。resultをそのテキストによる代替に設定する。
        3. スペース文字とresultaccumulated textに追加する。
      3. 空文字列("")でない場合、accumulated textを返す。

      Hidden Not Referencedと組み合わせたLabelledBy Recursionの結果は、aria-labelledbyまたはaria-describedbyによって参照されるノードが非表示の場合、ユーザーエージェントが、サブツリー内のすべてのノードをアクセシブルな名前またアクセシブルな説明の一部として含めなければならないことを意味する。

    3. Embedded Control: そうでなければ、current nodeが別のウィジェットのラベル内に埋め込まれたコントロール(たとえば、aria-labelledbyによって直接参照される任意の要素)であり、ユーザーが埋め込みコントロールの値を調整できる場合、次の方法で埋め込みコントロールを代替テキストの一部として返す:
      1. Textbox: 埋め込みコントロールがロールtextboxを持つ場合、その値を返す。
      2. Combobox/Listbox: 埋め込みコントロールがロールcomboboxまたはlistboxを持つ場合、選択したoptionの代替テキストを返す。
      3. Range: 埋め込みコントロールがロールに役割rangeを持つ場合(たとえば、spinbuttonslider):
        1. aria-valuetextプロパティが存在する場合、その値を返す。
        2. そうでなければ、aria-valuenowプロパティが存在する場合、その値を返す。
        3. そうでなければ、ホスト言語属性によって指定される値を使用する。
    4. AriaLabel: そうでなければ、current nodearia-label属性を持ち、その値が未定義でも、空文字列でも、空白を削除しても空文字列ではない場合:
      1. current nodeのトラバースが再帰によるものであり、かつ、current nodeが埋め込みコントロールである場合、aria-labelを無視してルールEmbedded Controlに飛ぶ。
      2. そうでなければ、aria-labelの値を返す。
    5. Host Language Label: そうでなければ、current nodeのネイティヴマークアップが代替テキストを定義する属性(たとえばalt)または要素(たとえば、HTML labelSVG title)を提供する場合、その代替はホスト言語によって定義されたflat stringの形式で返す。ただし、要素がプレゼンテーショナル(role="presentation" or role="none")とマークされている場合は除く。
      注記
      代替テキストを定義するマークアップの詳細については、HTML-AAMSVG-AAM、またはその他のホスト言語の文書を参照のこと。
      注記

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

    6. Name From Content: そうでなければ、current node'sロールコンテンツ由来の名前を許可する場合、またはcurrent nodearia-labelledbyaria-describedbyによって参照される、もしくはネイティヴホスト言語の代替テキスト要素(たとえばHTMLlabel)である場合、またはネイティヴホスト言語の代替テキストの子孫である場合は、次のようになる:
      1. Name From Content Reset: accumulated textを空文字列に設定する。
      2. Name From Generated Content: current nodeに関連付けられた CSS生成テキストコンテンツを確認して、accumulated textに含める。 CSS ::beforeおよび::after擬似要素[CSS2]は、コンテンツモデルを持つ要素に対してテキストコンテンツを提供できる。
        1. ::before擬似要素の場合、ユーザーエージェントは、スペースなしでCSSテキストコンテンツをcurrent nodeのテキストコンテンツの先頭に追加しなければならない
        2. ::after擬似要素の場合、ユーザーエージェントは、スペースなしでCSSテキストコンテンツをcurrent nodeのテキストコンテンツに追加しなければならない
      3. Determine Child Nodes: current noderendered child nodesを決定する。
        1. current nodeシャドウルートがアタッチされている場合、rendered child nodesシャドウルートの子ノードに設定する。
        2. そうでなければ、current node割り当てられたノードをもつスロットである場合、rendered child nodescurrent node割り当てられたノードに設定する。
        3. そうでなければ、rendered child nodescurrent nodeの子ノードに設定する。
      4. Name From Each Child: current noderendered child nodeごとに:
        1. current noderendered child nodeに設定する。
        2. 全体のComputationステップで始まるcurrent nodeの代替テキストを計算する。resultをその代替テキストに設定する。
        3. resultaccumulated textに追加する。
      5. 空文字列("")でない場合、accumulated textを返す。

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

      注記

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

      注記

      2024年1月18日:ARIA Working Groupは、current nodeCSS display値、ならびにその隣接するノードおよび擬似要素に応じて、スペースの有無にかかわらずテキスト文字列を結合することの実現可能性を検討している。現在進行中の議論はAccName #225にある。

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

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

    10. スペース文字および上記の各ステップのresulttotal accumulated textに追加する。
  3. すべてのステップが完了した後、total accumulated textは、計算を開始した要素アクセシブルな名前またはアクセシブルな説明として使用される。

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

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

6. 付録

6.1 変更ログ

6.1.1 直前の公開ワーキングドラフトからの実質的な変更点

  • 27-June-2019: Add statement allowing for the possibility of naming being prohibited on the root node. Note: This change in and of itself has no implementation impact, but it allows other specifications to optionally prohibit naming for a top-level element. Furthermore, even if this prohibition is made within a specification, that prohibition will not have any impact on calculating name from contents.

6.2 謝辞

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

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

6.2.1 発行時点のARIA WGでアクティブな参加者

  • Irfan Ali (Educational Testing Service)
  • CB Averitt (Deque Systems, Inc)
  • Sina Bahram (Invited Expert)
  • Shirisha Balusani (Invited Expert)
  • Amelia Bellamy-Royds (Invited Expert)
  • Curt Bellew (Oracle Corporation)
  • Alex Bernier (Association BrailleNet)
  • Zoë Bijl (Invited Expert)
  • Jorge Blazquez Alonso (IBM Corporation)
  • Alice Boxhall (Google LLC)
  • Matthew Brennan (Facebook)
  • Kim Bunge (TPGi)
  • Shari Butler (Pearson plc)
  • Tammy Campoverde (UnitedHealth Group)
  • David Caro (Wikimedia Foundation)
  • Timothy Cole (University of Illinois at Urbana-Champaign)
  • Dominic Cooney (Facebook)
  • Michael Cooper (W3C Staff)
  • James Craig (Apple Inc.)
  • Jory Cunningham (Salesforce)
  • Jes Daigle (Bocoup)
  • Joanmarie Diggs (Igalia)
  • Jason Duan (IBM Corporation)
  • Isaac Durazo (Bocoup)
  • Howard Edwards (Bocoup)
  • Steve Faulkner (TPGi)
  • Reinaldo Ferraz (NIC.br)
  • Alexander Flenniken (Bocoup)
  • Bryan Garaventa (Level Access)
  • Matt Garrish (DAISY Consortium)
  • Jaunita George (Navy Federal Credit Union)
  • Raghavendra Giriyappa (IBM Corporation)
  • Michael Goddard (Bocoup)
  • Glen Gordon (TPGi)
  • Jon Gunderson (University of Illinois at Urbana-Champaign)
  • Markku Hakkinen (Educational Testing Service)
  • Sarah Higley (Microsoft Corporation)
  • Hans Hillen (TPGi)
  • Isabel Holdsworth (TPGi)
  • Stanley Hon (Microsoft Corporation)
  • Nicholas Hoyt (University of Illinois at Urbana-Champaign)
  • Shilpi Kapoor (BarrierBreak Technologies)
  • Matthew King (Facebook)
  • Greta Krafsig (The Washington Post)
  • Peter Krautzberger (Invited Expert)
  • JaEun Jemma Ku (University of Illinois at Urbana-Champaign)
  • Lori Lane (University of Illinois at Urbana-Champaign)
  • Charles LaPierre (Benetech)
  • Gez Lemon (TPGi)
  • Aaron Leventhal (Google LLC)
  • Brian Liu Xu (Microsoft Corporation)
  • David MacDonald (Invited Expert)
  • Carolyn MacLeod (IBM Corporation)
  • Daniel Marques (WIRIS Science)
  • Dominic Mazzoni (Google LLC)
  • Mark McCarthy (University of Illinois at Urbana-Champaign)
  • Jan McSorley (Pearson plc)
  • Erika Miguel (Bocoup)
  • Sheila Moussavi (Bocoup)
  • Rich Noah (Bocoup)
  • James Nurthen (Adobe)
  • Scott O'Hara (Microsoft Corporation)
  • Achraf Othman (MADA Center)
  • Vijaya Gowri Perumal (Newgen Knowledgeworks)
  • Christos Petrou (Centre for Inclusive Design)
  • Simon Pieters (Bocoup)
  • Ian Pouncey (TetraLogical Services Ltd)
  • Ruoxi Ran (W3C Staff)
  • Adrian Roselli (TPGi)
  • Janina Sajka (Invited Expert, The Linux Foundation)
  • Stefan Schnabel (SAP SE)
  • Harris Schneiderman (Deque Systems, Inc.)
  • Lisa Seeman-Kestenbaum (Invited Expert)
  • Boaz Sender (Bocoup)
  • Cynthia Shelly (Google LLC)
  • Tzviya Siegman (Wiley)
  • Sharon Snider (IBM Corporation)
  • Neil Soiffer (Invited Expert)
  • Volker Sorge (Invited Expert)
  • Francis Storr (Intel Corporation)
  • Melanie Sumner (Invited Expert)
  • Alexander Surkov (Igalia)
  • William Tennis (Navy Federal Credit Union)
  • Seth Thompson (Bocoup)
  • Scott Vinkle (Shopify)
  • Can Wang (Zhejiang University)
  • Wei Wang (Zhejiang University)
  • Léonie Watson (TetraLogical Services Ltd)
  • Jason White (Educational Testing Service)
  • Jan Williams (TPGi)
  • Evan Yamanishi (W. W. Norton)
  • Benjamin Young (Wiley)
  • Valerie Young (Bocoup)
  • Marco Zehe (Mozilla Foundation)

6.2.2 資金提供者

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

A. 参考文献

A.1 標準情報

[CORE-AAM-1.2]
Core Accessibility API Mappings 1.2. Valerie Young; Alexander Surkov; Michael Cooper. W3C. 2 November 2023. W3C Candidate Recommendation. URL: https://www.w3.org/TR/core-aam-1.2/
[CSS2]
Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. Bert Bos; Tantek Çelik; Ian Hickson; Håkon Wium Lie. W3C. 7 June 2011. W3C Recommendation. URL: https://www.w3.org/TR/CSS21/
[DOM]
DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/
[html-aam-1.0]
HTML Accessibility API Mappings 1.0. Scott O'Hara. W3C. 18 April 2024. W3C Working Draft. URL: https://www.w3.org/TR/html-aam-1.0/
[infra]
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[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/

A.2 参考文献

[ACCNAME-1.1]
Accessible Name and Description Computation 1.1. Joanmarie Diggs; Bryan Garaventa; Michael Cooper. W3C. 18 December 2018. W3C Recommendation. URL: https://www.w3.org/TR/accname-1.1/
[wai-aria-1.2]
Accessible Rich Internet Applications (WAI-ARIA) 1.2. Joanmarie Diggs; James Nurthen; Michael Cooper; Carolyn MacLeod. W3C. 6 June 2023. W3C Recommendation. URL: https://www.w3.org/TR/wai-aria-1.2/