WAI-ARIA Graphics Module 日本語訳

W3C Recommendation

This version:
https://www.w3.org/TR/2018/REC-graphics-aria-1.0-20181002/
Latest published version:
https://www.w3.org/TR/graphics-aria-1.0/
Latest editor's draft:
https://w3c.github.io/graphics-aria/
Implementation report:
https://w3c.github.io/test-results/graphics-aam/
Previous version:
https://www.w3.org/TR/2018/PR-graphics-aria-1.0-20180626/
Editors:
(Igalia, S.L.)
(W3C)
Former editors:
(IBM Corporation) (until September 2016)
(Knowbility) (until August 2017)
Authors:
(IBM Corporation)
(Knowbility)
(W3C)

出版以来の報告されたエラーや問題に対するエラッタを確認されたい。

翻訳も参照のこと【訳注:これは日本語非公式訳です】。


概要

支援技術は、障害のある人に適切な情報を伝えるために、文書の構造および期待される動作に関するセマンティックな情報を必要とする。この仕様は、ウェブグラフィックに固有の中核となるロールWAI-ARIA 1.1 [WAI-ARIA-1.1]モジュールを定義する。 これらのセマンティクスは、著者がグラフィックの論理構造を支援技術に表現して、グラフィックのアクセシビリティを向上させることを可能にする。 支援技術は、セマンティックなナビゲーションを可能にし、スタイリングとインタラクティブ機能を適応させて、聴衆に最適な体験を提供する。 これらの機能は、HTML [HTML52] およびSVG [SVG2]で定義されたグラフィックおよび文書構造要素を補完する。

この文書は、WAI-ARIA Overviewで説明されているWAI-ARIAスイートの一部と位置付けられている。

この文書の位置付け

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

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

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

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

この文書に関するコメントを歓迎する。public-aria@w3.orgアーカイブ)にメールを送信されたい。

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

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

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

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

1. 導入

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

WAI-ARIAは、ウェブコンテンツおよびアプリケーションのアクセシビリティと相互運用性を改良するためのフレームワークを提供する技術仕様である。これにより、ウェブブラウザーはウェブコンテンツのアクセシビリティセマンティクスをプラットフォーム固有のアクセシビリティAPIにマッピングできる。 これにより、著者がプラットフォームの依存関係を含めて考える必要なく、ネイティブのプラットフォームアプリケーションと同様に、ウェブコンテンツをプラットフォーム支援技術と相互運用可能になる。

この仕様は、グラフィックスをサポートするように設計されたWAI-ARIA [WAI-ARIA-1.1]のモジュール拡張である。この仕様の目的は以下を含む:

この仕様は、すべての構造化グラフィックまたは図で使用される中核となるロールを定義する。 形状やキャンバスなどのグラフィカルなマークアップ要素を記述するために使用できるデフォルトのロールを確立する。 WAI-ARIA属性と組み合わせて、代替テキストを提供し、要素間の関係を示すことにより、多くの図や略図に注釈を付けるためのフレームワークを提供する。 今後の作業では、チャートや地図などのデータが豊富なグラフィックのより詳細な注釈を可能にするためにこのフレームワークを拡張する。

WAI-ARIAの詳細な説明については、WAI-ARIA Introductionとリッチインターネットアプリケーションのアクセシビリティへの適用方法を参照のこと。

1.1 対象読者

この仕様は、グラフィックス固有の要素のロールで構成される、グラフィックス用のWAI-ARIAモジュールを定義する。. この仕様が影響を与える複数の読者は次の通り:

各適合性要件は、要件が適用される読者を示す。

1.2 ユーザーエージェントのサポート

このモジュールは、WAI-ARIA [WAI-ARIA-1.1].で定義される一般的なユーザーエージェントサポートの原則に従う。ここで定義されたロールは、アクセシビリティAPIに公開される情報以外のユーザーエージェントによる動作の変更を必要としない。しかし、ここで定義されているセマンティクスは、ユーザーエージェントが読者に提示する一般的なユーザーインターフェイスを強化する機能を提供する。たとえば、ユーザーエージェントは、グラフィック環境に適した代替キーボードナビゲーションを提供したり、ユーザーがより大きな文書からグラフィックのコピーを抽出したりできるようにする。

1.3 WAI-ARIAとホスト言語の相互進化

WAI-ARIAグラフィックスモジュールは、WAI-ARIA [WAI-ARIA-1.1]で定義されるWAI-ARIAとホスト言語の相互進化のモデルに従う。これは、HTML [HTML52]、SVG [SVG2]、EPUBのような言語をサポートするものの中でセマンティックスを補強するためのもの、または明示的にARIAのサポートを含まない他のマークアップベースの言語で、アクセシビリティ拡張技術として使用される。WAI-ARIAロールは、著者がスタイルとスクリプトを通して新しいタイプのオブジェクトを作成するとき、または文書の意味ではなく視覚的な外観を記述するマークアップ言語を使用するときに、支援技術のセマンティクスを明確にする。

マークアップ言語はこれらのセマンティクスの一部をネイティブで提供する場合があるが、WAI-ARIAグラフィックスモジュールによって提供されるセマンティクスの永続的なニーズがあることが予想される。一部のホスト言語は、ユーザーインターフェイス以外の機能のセマンティックスを作成するために存在する。たとえば、SVGはオブジェクトが表すだろうユーザーインターフェイスコンポーネントでなく、グラフィカルオブジェクトの生成物の背後にあるセマンティックスを表現する。このようなホスト言語は、設計上、この仕様のすべての機能に対応するネイティヴセマンティックスを提供しないかもしれない。これらのホスト言語では、セマンティック情報を追加するための長期的なアプローチとして、WAI-ARIAグラフィックスモジュールを採用できる。

1.4 オーサリングプラクティス

1.4.1 オーサリングツール

WAI-ARIAおよびグラフィックスWAI-ARIAロールステートおよびプロパティの定義における要件の多くは、コードを検証するために使用される他の品質管理プロセスと同様に、開発プロセスの間に自動的にチェックできる。 グラフィックスを作成している著者を支援するために、これらのツールは、DOMからのグラフィックスWAI-ARIAロールのセマンティック構造をこの仕様で定義されているものと比較し、エラーを著者に通知するか、単にその構造を適用するテンプレートを作成できる。

1.4.2 プラクティスおよびツールのテスト

インタラクティブコンテンツのアクセシビリティは、静的なチェックだけで確認できない。インタラクティブコンテンツの開発者は、ウィジェットやアプリケーションにデバイスに依存しないアクセスのためにテストすべきであり、ユーザーと情報交換中にすべてのコンテンツと変更へのアクセシビリティAPIへのアクセスを確認すべきである。

1.5 支援技術

アクセシビリティセマンティックスへのプログラムアクセスが支援技術に不可欠である。詳細については、WAI-ARIA [WAI-ARIA-1.1]の支援技術のセクションを参照のこと。

特にグラフィックスのロールについては、支援技術の2つのカテゴリーが特に関連しているが、ニーズは異なる。

ロールの説明は、そのロールをもつ要素のどの機能が意味的に重要であると見なされ、可能な場合はいつでも読者に伝えるべきであることを示唆する。

2. 適合性

この仕様の主な内容は規範的であり、適合表明に影響を与える要件を定義する。入門資料、付録、"非規範的"と記されている章および節、図、例、および注釈は参考情報である(非規範的)。非規範的な資料は、ガイドラインの解釈に役立つ助言情報を提供するが、適合表明に影響を及ぼす要件は作成しない。

規範的な章は、ユーザエージェントがこの仕様に適合するために実装に対し従わなければならない要件を提供する。この文書の規範部分におけるキーワードMUSTMUST NOTREQUIREDSHALLSHALL NOTSHOULDRECOMMENDEDMAYOPTIONALは、Keywords for use in RFCs to indicate requirement levels [RFC2119]で示されるとおりに解釈される。RFC 2119のキーワードは、(原文で)大文字で整形されかつclass="rfc2119"をもつ要素で包まれる。上に示したキーワードが使用されるが、この形式を共有しない場合キーワードは、RFC 2119の意味で形式的な情報を伝達せず、単なる説明、すなわち、参考情報である。可能な限り、そのような用途は、この使用において回避される。

規範的な章は、著者、ユーザーエージェント、および支援技術がこの仕様に準拠するように実装するために従わなければならない要件を規定する。

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

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].である。

支援技術

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

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

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

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

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

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

クラス

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

要素

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

イベント

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

参考情報

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

規範的

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

オブジェクト

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

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

クラスの特徴の説明およびどのようにクラスが互いに関連するか。

プロパティ

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

ロール

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

セマンティックス

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

ステート

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

タクソノミー

階層においてクラスがスーパークラスのプロパティを継承する、どのようにさまざまなクラスの特性が互いに関係するかの階層的な定義。タクソノミーは、オントロジーの形式的な定義の一部を構成することができる。

ユーザーエージェント

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

ウィジェット

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

4. グラフィックロール

このセクションでは、WAI-ARIAロールタクソノミーへの追加を定義し、すべてのロールの特性とプロパティについて説明する。このモジュールで提供されるフィールドの説明については、ARIAロールを参照のこと。

著者は、支援技術に提示される内容に影響を与えたり、ロールおよびプロパティの使用を通じてナビゲーションに影響を与えたりすることができる。これには、要素にセマンティックの重要性がないとマークする機能が含まれる。グラフィックの場合、すべての要素を提示およびナビゲートすると、グラフィックの理解および使用が難しくなる場合が多くある。

著者は、ロールnone またはpresentationを割り当てることにより、文書のセマンティック表現(アクセシビリティツリー)から除外する要素をマークしてもよい。このロールをもつ要素は、あたかもその子またはテキストコンテンツが親要素に直接含まれているかのように、支援技術によって透過的に処理されるべきである。さらに、imggraphics-symbol,などの特定のロールは、親要素に割り当てるとき、すべての子DOM構造がアクセシビリティツリーから省略される。これは、ロール特性表の「子のプレゼンテーション」値で示される。最後に、グラフィック言語のネイティブセマンティクスでは、セマンティックデータがアタッチされていないDOM構造をデフォルトで無視することもある。 SVGの場合、これは Accessibility API Mappings仕様 [SVG-AAM-1.0]で定義される。

すべての場合において、プレゼンテーションと見なされるためには、要素はインタラクティブであってはならず、アクセシブルなプロパティまたは代替テキストを割り当てられてはならない。インタラクティブ要素またはWAI-ARIAステートおよびプロパティをもつ要素については、ロールnoneまたはpresentationは無視される。

4.1 ロールの定義

以下は、この仕様で定義されるWAI-ARIAロールのアルファベット順のリストである。これらは通常、WAI-ARIAで定義された他のロールと組み合わせて使用され、ドキュメント内のグラフィックやリッチインターネットアプリケーションに注釈を付ける[WAI-ARIA-1.1]。

graphics-document
コンテンツの視覚的な外観またはレイアウトが意味を伝えるdocumentの型。
graphics-object
セマンティックな意味をもつ個別のオブジェクトまたはサブコンポーネントを表すgraphics-documentのセクション。 グラフィカルオブジェクト自体に、ネストされたサブコンポーネントがあってもよい。
graphics-symbol
単純な意味またはカテゴリーを伝えるために使用されるグラフィックオブジェクト。ここで、意味は特定の視覚的外観よりも重要である。チャートや地図など、より大きな構造化グラフィックのコンポーネントであってもよい。 シンボル自体は分割不能なオブジェクトである。子はプレゼンテーション的となる。

graphics-document (ロール)

コンテンツの視覚的な外観またはレイアウトが意味を伝えるdocumentの型。

他のdocument型と同様に、graphics-documentロールは、関連情報を含むページの領域のルート要素に適用され、ユーザーの主要なインタラクションモードは、アプリケーションを制御するよりもむしろ、文書を閲覧することが期待される。このロールをもつ要素は、文書ファイルのルート要素、またはその中にネストされた構造のルート要素であってもよい。

graphics-documentは、次のように同様の役割と区別される場合がある:

  • 他の文書と比較して、graphics-documentは、その視覚的(通常は2次元)提示のセマンティックの重要性によって区別される。ユーザーエージェントおよび支援技術は、グラフィックのナビゲーションをサポートするときにこれを考慮すべきである。文書を再フォーマットまたはスタイル変更するアクセシビリティ技術は、セマンティックなロールとそのコンテンツの関係とを一致させる方法を除いて、graphics-documentのレイアウトを変更すべきでない

  • imgと比較すると、graphics-documentは、コンテンツの構造化された性質によって区別される。その子要素にはセマンティックな意味があり、リンクまたはその他のインタラクティブなウィジェットを含んでもよい。

  • graphics-objectに比べて、graphics-documentは自己完結型である。その意味は、周囲のコンテンツから分離されても持続する。graphics-documentロールをもつ要素は、子コンテンツの解釈のスコープおよびコンテキストを定義する。

一般に、著者は、チャート、地図、ダイアグラム、テクニカルドローイング、ブループリント、説明用グラフィックスなどの構造化グラフィックスに対してgraphics-documentロールを使用すべきである。しかし、1つの大きなグラフィックが意味を犠牲にすることなく安全に再配置できる個別の領域を持つ場合、それらの各領域は、個別のgraphics-documentとなるべきである。代替ロール(figureなど)を使用して、それらをグループ化してもよい。 1つのgraphics-documentがもう1つのgraphics-document内にネストされもよい。たとえば、地図に埋め込まれた棒グラフまたはチャートパネルのマトリックスはロールgraphics-documentを持つべきである。ネストされたドキュメントはカプセル化を提供する。内側および外側のグラフィックのコンポーネント間のナビゲーションは明示的であるべきである。

ARIA 1.0仕様に基づくユーザーエージェントおよび支援技術をサポートするために、著者は、documentロールをrole="graphics-document document"の形式でフォールバック値として含めたいことがある。

将来の仕様では、特別なセマンティック構造を持つ特定の型のグラフィカルドキュメントに対して、より具体的なロールを定義する可能性がある。 これらのより具体的なロールは、graphics-documentのサブクラスになるだろう。

特性:
特性
スーパークラスロール: document
関連する概念:
継承されるステートおよびプロパティ:
名前の由来: 著者
アクセシブルな名前要求: True
子のプレゼンテーション: False

graphics-object (role)

セマンティックな意味をもつ個別のオブジェクトまたはサブコンポーネントを表すgraphics-documentのセクション。 グラフィカルオブジェクト自体に、ネストされたサブコンポーネントがあってもよい。

切断されたオブジェクトのコレクションを表すコンテナ要素には、代わりにgroupまたはlistロールを与えるべきである。 セマンティックな意味を持たず、祖先から提供されたセマンティックコンテキストを変更しないグループ化要素(たとえば、スタイリングまたはレイアウトにのみ使用されるdivまたはSVG g)には、ロールを付与すべきでない。 ロールの欠如は、ロールnoneまたはpresentationで明示的に示されてもよい。

graphics-documentとは異なり、graphics-objectは自己完結型である必要はなく、ナビゲーションへの新しいコンテキストを確立しない。 しかし、ユーザーエージェントおよび支援技術は、ユーザー、特に非視覚的ユーザーが、ネストされたリストと同様に、オブジェクトのネストされた構造を階層的にナビゲートする方法を提供すべきである

ARIA 1.0仕様に基づくユーザーエージェントおよび支援技術をサポートするために、著者は、groupロールをrole="graphics-object group"の形式でフォールバック値として含めたいことがある。

特性:
特性
スーパークラスロール: group
関連する概念:
継承されるステートおよびプロパティ:
名前の由来:
  • 著者
  • コンテンツ
アクセシブルな名前要求: False
子のプレゼンテーション: False

graphics-symbol (role)

単純な意味またはカテゴリーを伝えるために使用されるグラフィックオブジェクト。ここで、意味は特定の視覚的外観よりも重要である。チャートや地図など、より大きな構造化グラフィックのコンポーネントであってもよい。 シンボル自体は分割不能なオブジェクトである。子はプレゼンテーション的となる。

構造化シンボリック言語の一部として使用する場合、aria-roledescriptionプロパティ(ARIA 1.1 [WAI-ARIA-1.1]で導入)を使用して、シンボルの特定のインスタンスの名前および説明とは別にシンボル型に名前を付けることができる。

ARIA 1.0仕様に基づくユーザーエージェントおよび支援技術をサポートするために、要素のデフォルトのセマンティックロールにまだなっていない場合、著者は、imgロールをrole="graphics-symbol img"の形式でフォールバック値として含めたいことがある。

特性:
特性
スーパークラスロール: img
関連する概念:
継承されるステートおよびプロパティ:
名前の由来: 著者
アクセシブルな名前要求: True
子のプレゼンテーション: True

4.2 グラフィックへの他のロール

ARIA 1.1 [WAI-ARIA-1.1]で定義される次の中核となるARIAロールはまた、グラフィックスの注釈に関連している:

次の例は、文書でimgfigure、およびgraphics-documentの適切な使用法を示す。

5. ステートおよびプロパティ

WAI-ARIAは、さまざまなOSプラットフォーム上のプラットフォームの<a3>アクセシビリティAPIをサポートするために使用されるステートおよびプロパティ一式を提供する。支援技術は、公開されたユーザーエージェントのDOMを通して、またはプラットフォームのアクセシビリティAPIへのマッピングを通して、この情報にアクセスしてもよい。ロールと組み合わせる場合、ユーザーエージェントは、いつでもユーザーに伝えるためのユーザーインターフェイス情報を支援技術に提供することができる。ステートまたはプロパティの変化は、支援技術に通知をもたらす。これは、変更が発生したことをユーザーに通知するかもしれない。

A. 変更ログ

The full commit history to WAI-ARIA Graphics Module 1.0 is available.

A.1 Substantive changes since the last public working draft

A.2 Other substantive changes since the First Public Working Draft

B. 謝辞

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

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

B.1 発行時点のSVGアクセシビリティタスクフォースでアクティブな参加者

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

B.3 資金提供者の権利

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

C. 参考文献

C.1 規範規格

[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
[WAI-ARIA-1.1]
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/

C.2 参考文献

[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/
[HTML52]
HTML 5.2. Steve Faulkner; Arron Eicholz; Travis Leithead; Alex Danilo; Sangwhan Moon. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/html52/
[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
[SVG-AAM-1.0]
SVG Accessibility API Mappings. Amelia Bellamy-Royds; Ian Pouncey. W3C. 10 May 2018. W3C Working Draft. URL: https://www.w3.org/TR/svg-aam-1.0/
[SVG2]
Scalable Vector Graphics (SVG) 2. Amelia Bellamy-Royds; Bogdan Brinza; Chris Lilley; Dirk Schulze; David Storey; Eric Willigers. W3C. 7 August 2018. W3C Candidate Recommendation. URL: https://www.w3.org/TR/SVG2/
[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
[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/