アクセシブルな名前および説明の算出 1.2

W3C 作業草案

この文書についての詳細
このバージョン:
https://www.w3.org/TR/2026/WD-accname-1.2-20260430/
最新公開バージョン:
https://www.w3.org/TR/accname-1.2/
最新エディターズドラフト:
https://w3c.github.io/accname/
履歴:
https://www.w3.org/standards/history/accname-1.2/
コミット履歴
最新勧告:
https://www.w3.org/TR/accname/
編集者:
Bryan Garaventa (招待専門家)
Melanie Sumner (招待専門家)
以前の編集者:
Michael Cooper (W3C)
Joanmarie Diggs (Igalia, S.L.) (2021年3月まで編集者)
Richard Schwerdtfeger (Knowbility) (2017年10月まで編集者)
Joseph Scheuhammer (Inclusive Design Research Centre、OCAD University) (2017年5月 まで編集者)
James Craig (Apple Inc.) (2016年5月まで編集者)
Andi Snow-Weaver (IBM) (2012年12月まで編集者)
Aaron Leventhal (IBM) (2009年1月まで編集者)
フィードバック:
GitHub w3c/accname (プル リクエスト, 新しい課題, 未解決の課題)

概要

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

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

この文書は、 Accessible Name and Description Computation 1.1 [ACCNAME-1.1] W3C勧告におけるアクセシブルな名前および説明の指針を更新し、最終的に置き換える。 これは、 WAI-ARIA概要で説明される WAI-ARIAスイートの一部である。

この文書の状態

この節は、公開時点におけるこの 文書の状態を説明する。現在のW3C 公開物の一覧およびこの技術レポートの最新改訂版は、 W3C標準および草案 索引で参照できる。

この文書は、Accessible Rich Internet Applications Working Groupにより、 勧告 トラックを用いた作業草案として公開された。

作業草案としての公開は、 W3Cおよびそのメンバーによる承認を意味しない。

これは草案文書であり、いつでも他の文書によって更新、置換、または廃止される可能性がある。 この文書を進行中の作業以外のものとして引用することは適切ではない。

この文書は、 W3C 特許 ポリシーの下で運営されるグループにより作成された。 W3Cは、 そのグループの成果物に関連して行われた特許開示の公開リスト を維持している。そのページには、特許を開示するための 手順も含まれる。ある個人が、 その個人が必須クレームを含むと考える特許について 実際の知識を有する場合、 W3C特許ポリシー第6節に従って その情報を開示しなければならない。

この文書は、 2025年8月18日版W3Cプロセス文書によって管理される。

1. 序論

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

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

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

説明は、アクセシブルなオブジェクトの性質をさらに明確にする短い説明である。名前が十分である場合、 説明を提供することは常に必要というわけではないが、 ユーザーがそのオブジェクトの使用をよりよく理解する助けとなり得る。

アクセシビリティAPIは現在、アクセシブルな名前および説明について、 平坦で構造化されていない文字列をサポートする。したがって、名前/説明の算出結果は平坦な文字列である。

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

2. 重要な用語

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

一部の用語はその場で定義されるが、以下の定義はこの文書全体で使用される。

支援技術

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

  • Webコンテンツを取得してレンダリングするために、ユーザーエージェントが提供するサービスに依存するもの
  • ユーザーエージェントまたはWebコンテンツ自体と、APIの使用を通じて連携するもの、および
  • 障害のある人々によるWebコンテンツとのユーザー対話を容易にするために、ユーザーエージェントが提供するものを超えるサービスを提供するもの

この定義は、他の文書で用いられる定義と異なる場合がある。

この文書の文脈で重要な支援技術の例には、以下が含まれる:

  • レンダリングされたテキストおよび画像の視覚的な可読性を拡大および改善するために用いられる 画面拡大鏡;
  • 合成音声またはリフレッシュ可能な点字ディスプレイを通じて情報を伝えるために最もよく用いられる スクリーンリーダー;
  • テキストを合成音声に変換するために用いられるテキスト読み上げソフトウェア;
  • 音声による制御および音声入力を可能にするために用いられる音声認識ソフトウェア;
  • キーボードを模擬するために用いられる代替入力技術(ヘッドポインター、オンスクリーンキーボード、単一スイッチ、 および呼気/吸気デバイスを含む);
  • マウスによるポインティングおよびクリックを模擬するために用いられる代替ポインティングデバイス。
アクセシブルな説明

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

アクセシブルな名前

アクセシブルな名前は、ユーザーインターフェイス要素の名前である。各プラットフォームのアクセシビリティAPIは、アクセシブルな名前 プロパティを提供する。アクセシブルな名前の値は、ユーザーインターフェイス要素の可視の プロパティ(例: ボタン上の可視テキスト)または不可視のプロパティ(例: アイコンを説明する代替テキスト)から 派生する場合がある。関連するアクセシブルな説明を参照。

アクセシブルな名前プロパティの単純な使用は、「OK」ボタンによって説明できる。テキスト 「OK」がアクセシブルな名前である。ボタンがフォーカスを受け取ると、支援 技術はプラットフォームのロール説明をアクセシブルな名前と連結する場合がある。たとえば、 スクリーンリーダーは「push-button OK」または「OK button」と読み上げる場合がある。連結の 順序およびロール説明の具体事項(例: 「button」、「push-button」、 「clickable button」)は、プラットフォームの アクセシビリティAPIまたは支援技術によって決定される。

ツールチップ 属性

デスクトップユーザーエージェントにおけるマウスホバーへの応答などで、ユーザーエージェントがツールチップを生成する結果となる任意のホスト言語属性。

3. 適合性

非規範的とマークされた節に加えて、この仕様におけるすべての作成者向けガイドライン、図、例、および注は 非規範的である。この仕様におけるその他すべては規範的である。

この文書におけるキーワードMAYMUST、およびMUST NOTは、 BCP 14 [RFC2119] [RFC8174] に記述されるとおりに、かつ、ここに示すようにすべて 大文字で現れる場合にのみ、解釈される。

規範的な節は、この仕様に適合する実装のために、作成者、ユーザーエージェント、および支援技術がMUST従う要件を提供する。

非規範的な(参考)節は、この仕様を理解するために有用な情報を提供する。そのような 節には推奨される実践の例が含まれる場合があるが、この仕様に適合するために そのような推奨に従うことは要求されない。

4. 名前および説明

名前および説明の算出の開始点は、DOM要素である。出力は、単一の単語のように単純なものにも、 空白で区切られたトークンの文字列にもなり得る、平坦で構造化されていない 文字列である。例にはSaveおよび Reload from diskが含まれる。

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

author
名前は、aria-labelおよびaria-labelledby 属性のような明示的なマークアップ機能、 またはHTMLにおけるaltもしくはtitle 属性、あるいはSVGにおけるdesc 要素のようなホスト言語のラベル付け機構において、 制作者が提供した値から生成される。
contents
名前は、テキストノードから生成され、 それらは要素に関連付けられる。 これは一部のロールにおいて、 "author"に加えて許可される場合があるが、 "content"は、より高い優先度を持つ"author"機能が提供されない場合にのみ用いられる。優先度は、 テキスト等価物の算出アルゴリズムによって定義される。
prohibited
その要素は名前を持たない。制作者は、その要素に名前を付けるために aria-labelまたは aria-labelledby属性を使用しては MUST NOTならない。

アクセシブルなリッチインターネット アプリケーション(WAI-ARIA)1.2 [WAI-ARIA]仕様は、 制作者からの名前をサポートする ロールコンテンツからの名前を サポートするロールおよび 名前を付けることができない ロールの一覧を提供する。

4.1 名前の算出

ユーザーエージェントは、下記の テキスト等価物の算出という節に概説される規則を用いて、 アクセシブルな名前を算出しなければ MUSTならない。

4.2 説明の算出

次の表は、アクセシブルな説明を算出するために適用できるマークアップの優先順位を提供する。 ユーザーエージェントは、 最後の列で説明されるように、列挙された条件が満たされる表内の最初の適用可能な項目を使用しなければ MUSTならない。ユーザーエージェントは、たとえそのマークアップが空の説明をもたらす場合であっても、 見つかった最初の関連マークアップ以外のいかなるマークアップも使用しては MUST NOTならない:

優先順位 属性 適用可能な条件 説明の算出にどのように使用されるか
1 aria-describedby 属性 任意の要素で使用 要素上のaria-describedbyにより参照されるすべてのノードに対する名前の算出を、 連結し、空白文字で区切ったもの
2 aria-description 属性 任意の要素で使用 平坦な文字列として
3 説明の計算に参加するホスト言語機能 一意なホスト言語機能は、適用可能な要素のアクセシブルな名前にすでに使用されていない場合にのみ、 要素の説明の算出に参加してよい MAY。この条件を満たす HTML要素については、 HTML AAM: アクセシブルな説明の 算出を参照。 ホスト言語要素のテキスト等価物の算出、または ホスト言語属性の文字列値のいずれか。
4 ホスト言語のツールチップ属性または同等の機能(例: HTMLtitle属性)
  • 任意の要素
  • このノードのアクセシブルな名前にまだ使用されていない場合にのみ使用
平坦な文字列として

4.3 テキスト等価物の算出

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

この算出の目的は、空白で区切られたテキストトークンの平坦な文字列の形式で、 代替提示のための知覚可能なラベルまたは説明を 作成することである。

4.3.1 用語

ルートノード
テキスト代替が求められるDOMノードまたは要素
現在ノード
root nodeのテキスト等価物を算出するために現在たどられているDOMノード。初期状態では、current noderoot nodeであるが、後の段階では root nodeの何らかの子孫、または別の参照されたノードのいずれかである。
レンダリングされた子ノード
ノードは、 シャドウ ルートおよびスロットを考慮したときに、 与えられたノードの子ノードとしてレンダリングされるものである。
平坦な文字列
すべての復帰、改行、タブ、および改ページが単一の空白に置き換えられ、 複数の空白が単一の空白に削減された文字の文字列。その文字列は 文字データのみを含み、いかなるマークアップも含まない。
合計蓄積テキスト
current nodeを含まないところまで算出されたテキスト等価物。
蓄積テキスト
下記で説明されるステップまたは一連のステップで蓄積されたテキスト。それは それらのステップのための一時的な記憶領域である。
結果
下記で説明されるいずれかのステップで算出されたテキスト等価物。
結果を、空白なしで、Xに追加する
  • Xが空の場合、resultをXにコピーする。
  • Xが空でない場合、resultをXの末尾にコピーする。
結果を、空白付きで、Xに追加する
  • Xが空の場合、resultをXにコピーする。
  • Xが空でない場合、Xの末尾に空白を追加し、その空白の後にresultを Xにコピーする。
結果を、空白なしで、Xの前に追加する
  • Xが空の場合、resultをXにコピーする。
  • Xが空でない場合、resultをXの先頭にコピーする。
結果を、空白付きで、Xの前に追加する
  • Xが空の場合、resultをXにコピーする。
  • Xが空でない場合、resultをXの先頭にコピーし、そのコピーの後に空白を追加する。

4.3.2 算出手順

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

  1. 初期化: root nodeを与えられた 要素に、current noderoot nodeに、total accumulated textを空文字列("")に設定する。 root nodeのロールが名前付けを禁止する場合、空文字列("")を返す。
  2. 算出: current nodeのテキスト代替を算出する:
    1. 参照されていない非表示: current node非表示 であり、かつ:
      1. aria-labelledbyまたは aria-describedbyの探索の一部ではない場合。 ここで、その関係により直接参照されるノードが非表示であったものとする。
      2. かつ、ネイティブホスト言語のテキスト代替要素(例: HTMLにおけるlabel)または 属性 の探索の一部でもない場合。ここで、その探索のルートが非表示であったものとする。
      空文字列を返す。

      アクセシブルな名前の計算の目的における、非表示の広い定義を明確にすることは重要である:

      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-describedbyを使用することにより、 非表示テキストを アクセシブルな 名前またはアクセシブルな説明の一部として 含めることができる。

    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探索: 算出ステップ全体から開始して、 current nodeの テキスト代替を算出する。resultをそのテキスト代替に設定する。
        3. 空白文字および resultaccumulated textに追加する。
      3. accumulated textが 空文字列("")でない場合、それを返す。

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

    3. 埋め込みコントロール: そうでない場合で、 current nodeが別のウィジェットのラベル (例: aria-labelledbyにより直接参照される任意の要素)内に埋め込まれたコントロールであり、 ユーザーがその埋め込みコントロールの値を調整できる場合、次の方法で、 埋め込みコントロールをテキスト代替の一部として返す:
      1. Textbox: 埋め込みコントロールが textboxロールを持つ場合、その 値を返す。
      2. Combobox/Listbox: 埋め込みコントロールがcomboboxまたはlistboxロールを持つ場合、 選択されたoptionのテキスト代替を返す。
      3. Range: 埋め込みコントロールがrangeロールを持つ場合 (例: spinbuttonまたは slider):
        1. aria-valuetextプロパティが存在する場合、その値を返す。
        2. そうでない場合で、 aria-valuenowプロパティが存在する場合、その値を返す。
        3. そうでない場合、ホスト言語属性によって指定される値を使用する。
    4. AriaLabel: そうでない場合で、current nodeslot要素ではなく、 かつ未定義でなく、空文字列でもなく、空白をトリムした場合にも 空文字列でない値を持つaria-label 属性を持つ場合:
      1. current nodeの探索がName From Contentの子孫 ノード再帰によるものであり、かつ current nodeが埋め込みコントロールである場合、aria-labelを無視し、 規則埋め込みコントロールへ進む。
      2. そうでない場合、aria-labelの値を返す。
    5. ホスト言語ラベル: そうでない場合で、 current nodeのネイティブマークアップがテキスト代替を定義する 属性(例: alt)または要素(例: HTMLlabelまたはSVGtitle)を提供する場合、 ホスト言語によって定義される flat stringの形式でその代替を返す(例: HTML-AAM)。ただし、 current nodeが提示的(role="presentation" またはrole="none"alt="")として公開される場合を除く。
      重要! ネイティブHTML要素のアクセシブルな名前は、 ホスト言語によって異なる方法で計算される場合がある。詳細については、 HTML-AAMを確認すること。

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

    6. コンテンツからの名前: そうでない場合で、 current nodeロールコンテンツからの 名前を許可する場合、またはcurrent nodearia-labelledbyaria-describedbyにより参照される場合、または ネイティブホスト言語のテキスト代替要素(例: HTMLにおけるlabel)である場合、または ネイティブホスト言語のテキスト代替要素の子孫である場合:
      1. コンテンツからの名前のリセット: accumulated textを空文字列に設定する。
      2. 生成コンテンツからの名前: current nodeに関連付けられた CSS生成テキストコンテンツを確認し、それを accumulated textに含める。 CSS::before および::after疑似要素 [CSS2] は、コンテンツモデルを持つ要素に対して、 ::marker 疑似要素に加えて、テキストコンテンツを提供できる。
        1. ::marker疑似要素について、ユーザーエージェントは、 current node::markerをサポートする場合、 CSSテキストコンテンツを、空白なしで、 current nodeのテキストコンテンツの前に追加しなければ MUSTならない。
        2. ::before疑似要素について、ユーザーエージェントCSSテキストコンテンツを、空白なしで、 current nodeのテキストコンテンツの前に追加しなければ MUSTならない。
        3. ::after疑似要素について、ユーザーエージェントCSSテキストコンテンツを、空白なしで、 current nodeのテキストコンテンツに追加しなければ MUSTならない。
      3. 子ノードの決定: current noderendered child nodesを決定する:
        1. current nodeシャドウ ルートが付随している場合、rendered child nodesシャドウ ルートの子ノードに設定する。
        2. そうでない場合で、current nodeslotであり、割り当てられた ノードを持つ場合、rendered child nodescurrent node割り当てられた ノードに設定する。
        3. そうでない場合、 rendered child nodescurrent nodeの子ノードに設定する。
      4. 各子からの名前: current nodeの各 rendered child nodeについて:
        1. current noderendered child nodeに設定する。
        2. 算出ステップ全体から開始して、 current nodeのテキスト代替を算出する。 resultをそのテキスト代替に設定する。
        3. resultaccumulated textに追加する。
      5. accumulated textが 空文字列("")でない場合、それを返す。

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

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

      2024年1月18日: ARIA作業部会は、 current node、ならびにその隣接ノードおよび疑似要素の CSS display値に応じて、 テキスト文字列を空白ありまたは空白なしで結合する実現可能性を検討している。 進行中の議論はAccName #225にある。

    7. テキストノード: そうでない場合で、current nodeテキストノードである場合、 そのテキスト内容を返す。
    8. 再帰的なコンテンツからの名前: そうでない場合で、 current nodeが、 アクセシブルな名前またはアクセシブルな 説明が算出されている要素の子孫であり、かつ子孫を含む場合、 コンテンツからの名前のリセットへ進む。
    9. ツールチップ: そうでない場合で、current nodeツールチップ属性を持つ場合、 その値を返す。

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

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

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

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

6. 付録

6.1 変更履歴

6.1.1 前回の公開作業草案以降の実質的な変更

  • 2019年6月27日: ルートノード上で名前付けが禁止される可能性を許容する記述を追加。 注: この変更自体には実装上の影響はないが、他の仕様がトップレベル要素に対して名前付けを任意に禁止できるようにする。 さらに、この禁止が仕様内で行われたとしても、その禁止は コンテンツからの名前の計算にはいかなる影響も与えない。

6.2 謝辞

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

以下の人々がこの文書の開発に貢献した。

6.2.1 公開時点のARIA WG参加者

  • Rahim Abdi (Apple Inc.)
  • NAVYA AGARWAL (Adobe)
  • Joey Arhar (Google LLC)
  • Benjamin Beaudry (Microsoft Corporation)
  • Curt Bellew (Oracle Corporation)
  • Zoë Bijl (W3C Invited Experts)
  • Gautier Chomel (EDRLab)
  • Aleksandar Cindrikj (Netcetera)
  • Keith Cirkel (Mozilla Foundation)
  • Daniel Clark (Microsoft Corporation)
  • Sydney Coleman (Google LLC)
  • James Craig (Apple Inc.)
  • Chris Cuellar (Bocoup)
  • Diego Della Rossa (UsableNet)
  • Joanmarie Diggs (Igalia)
  • Tamsin Ewing (W3C)
  • Mayuri Faldu (Navy Federal Credit Union)
  • Betsy Fanning (PDF Association)
  • Steve Faulkner (TetraLogical Services Ltd)
  • Patrick Foster (axes4 GmbH)
  • Jane Fulton (Cisco)
  • Bryan Garaventa (W3C Invited Experts)
  • Matt Garrish (DAISY Consortium)
  • Doug Geoffray (Microsoft Corporation)
  • Ariella Gilmore (IBM Corporation)
  • Taylore Givens (Microsoft Corporation)
  • David Grogan (Google LLC)
  • Shirisha Gubba (Google LLC)
  • Jon Gunderson (University of Illinois)
  • Oliver Habersetzer (SAP SE)
  • Sunny Hardasani (Adobe)
  • Matthew Hardy (Adobe)
  • Chris Harrelson (Google LLC)
  • Sarah Higley (Microsoft Corporation)
  • Hans Hillen (TPGi)
  • Isabel Holdsworth (TPGi)
  • Stanley Hon (Microsoft Corporation)
  • Michael Jackson (Microsoft Corporation)
  • Jilin Jiang (Ant Group Co., Ltd.)
  • Duff Johnson (PDF Association)
  • Summer Jones (Thomson Reuters Corp.)
  • Yuki Kamahori (Cybozu)
  • William Kilian (Kilian Codes LLC)
  • Matthew King (Meta)
  • Zachary Kinsey (TargetStream Technologies)
  • Daisuke Kobayashi (Cybozu)
  • Peter Krautzberger (krautzource UG)
  • Nina Krauß (SAP SE)
  • JaEun Jemma Ku (University of Illinois)
  • Joe Lamyman (TetraLogical Services Ltd)
  • Christopher Land (Oracle Corporation)
  • Charles LaPierre (Benetech)
  • Patrick Lauke (TetraLogical Services Ltd)
  • Philip Lazarevic (Level Access)
  • Leo Lee (Microsoft Corporation)
  • Brett Lewis (TPGi)
  • Alison Maher (Microsoft Corporation)
  • Gurpreet Kaur Mangera (Rakuten Group, Inc.)
  • Mark McCarthy (University of Illinois)
  • Eduardo Meza Etienne (Navy Federal Credit Union)
  • Clay Miller (Microsoft Corporation)
  • Hirotaka Minamida (Cybozu)
  • Daniel Montalvo (W3C)
  • Baldino Morelli (UsableNet)
  • Jacques Newman (Microsoft Corporation)
  • James Nurthen (Evinced Inc.)
  • Scott O'Hara (Microsoft Corporation)
  • Lola Odelola (W3C Invited Experts)
  • Neil Osman (Evinced Inc.)
  • Yusuke Oyama (Cybozu)
  • Adam Page (Hilton)
  • Michael Pennisi (Bocoup)
  • Giacomo Petri (UsableNet)
  • Noah Praskins (TPGi)
  • Lucas Radaelli (Google LLC)
  • Paul Rayius (PDFix-US)
  • Mark Rogers (Powermapper Software)
  • Priti Rohra (BarrierBreak Solutions Private Limited)
  • Adrian Roselli (W3C Invited Experts)
  • Marco Sabidussi (UsableNet)
  • Trisha Salas (Level Access)
  • Stefan Schnabel (SAP SE)
  • Harris Schneiderman (Deque Systems, Inc.)
  • Raymond Schwartz (Navy Federal Credit Union)
  • Davis Shaver (The Washington Post)
  • Cynthia Shelly (W3C Invited Experts)
  • Tzviya Siegman (W3C)
  • Avneesh Singh (DAISY Consortium)
  • Michael[tm] Smith (sideshowbarker) (W3C)
  • Francis Storr (Intel Corporation)
  • Nobukiyo Sugisaki (Cybozu)
  • Melanie Sumner (IBM Corporation)
  • Alexander Surkov (Igalia)
  • James Teh (Mozilla Foundation)
  • Roman Toda (Foxit software)
  • David Tseng (Google LLC)
  • Cybozu W3C (Cybozu)
  • Jan Williams (TPGi)
  • Peter Wyatt (PDF Association)
  • Valerie Young (Igalia)

6.2.2 実現を支援した資金提供者

この公開物は、米国教育省、国立障害・自立生活・リハビリテーション研究所(NIDILRR)からの 米国連邦資金により、当初は契約番号ED-OSE-10-C-0067の下で、その後契約番号HHSP23301500054Cの下で、 現在はHHS75P00120P00168の下で、一部資金提供を受けている。この公開物の内容は、必ずしも 米国教育省の見解または方針を反映するものではなく、また商号、商用 製品、または組織への言及が米国政府による承認を意味するものでもない。

A. 参考文献

A.1 規範的参考文献

[CORE-AAM-1.2]
Core Accessibility API Mappings 1.2. Valerie Young; Cynthia Shelly. W3C. 2026年4月24日. CRD. 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. 2011年6月7日. W3C勧告. URL: https://www.w3.org/TR/CSS2/
[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; Rahim Abdi. W3C. 2026年4月24日. W3C作業草案. 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]
RFCにおける要件レベルを示すために用いる キーワード. S. Bradner. IETF. 1997年3月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
RFC 2119キーワードにおける大文字と小文字の曖昧性. B. Leiba. IETF. 2017年5月. 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. 2017年12月14日. W3C勧告. 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. 2018年12月18日. W3C 勧告. 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. 2023年6月6日. W3C勧告. URL: https://www.w3.org/TR/wai-aria-1.2/