UI オートメーション プロバイダーの概要
Microsoft UI オートメーション プロバイダーは、アクセシビリティ クライアント アプリケーションが 要素に関する情報を取得してその機能を呼び出すことができるように、アプリケーションの UI の要素を公開するソフトウェア オブジェクトです。 一般に、UI 内の各コントロールまたはその他の個別の要素にはプロバイダーがあります。
Microsoft には、Microsoft Win32、Windows フォーム、Windows Presentation Foundation (WPF) で提供される標準コントロールごとにプロバイダーが含まれています。 つまり、標準コントロールはUI オートメーションクライアントに自動的に公開されます。標準コントロールのアクセシビリティ インターフェイスを実装する必要はありません。
アプリケーションにカスタム コントロールが含まれている場合は、それらのコントロールのUI オートメーション プロバイダーを実装して、アクセシビリティ クライアント アプリケーションからアクセスできるようにする必要があります。 また、プロバイダーを含まないサード パーティのコントロールにプロバイダーを実装する必要もあります。 プロバイダーを実装するには、UI オートメーション プロバイダー インターフェイスとコントロール パターン インターフェイスを実装します。
このトピックでは、コントロール開発者がUI オートメーション プロバイダーを実装する方法の概要について説明します。 これには、次のセクションが含まれます。
プロバイダーの種類
UI オートメーション プロバイダーは、サーバー側プロバイダーとクライアント側 (またはプロキシ) プロバイダーの 2 つのカテゴリに分類されます。
サーバー側プロバイダーは、関連するUI オートメーション プロバイダー インターフェイスの独自のネイティブ実装を含むカスタム コントロールなどのオブジェクトです。 サーバー側プロバイダーは、プロバイダー インターフェイスの実装をクライアントから要求するUI オートメーション コアに公開することで、プロセス境界を越えてクライアント アプリケーションと通信します。 サーバー側プロバイダーの詳細については、「Server-Side UI オートメーション プロバイダーの実装」を参照してください。
クライアント側プロバイダー (プロキシ) は、コントロールの代わりにプロバイダー インターフェイスUI オートメーション実装するオブジェクトであり、独自の完全なプロバイダー実装は含まれません。 プロキシがない場合、このようなコントロールはUI オートメーションに対してほとんど不透明であり、コントロールの場所など、ウィンドウ ハンドル (HWND) から使用できる基本情報のみを提供できます。 通常、プロキシ プロバイダーは、Windows メッセージを送受信することで、プロセス境界を越えてアプリケーションと通信します。 詳細については、「Client-Side (プロキシ) UI オートメーション プロバイダーの実装」を参照してください。
UI オートメーション プロバイダーの概念
ここでは、UI オートメーション プロバイダーを実装するために理解しておく必要があるいくつかの重要な概念について簡単に説明します。
要素
UI オートメーション要素は、UI オートメーション クライアントに表示される UI (通常はウィンドウまたはコントロール) の一部です。 例として、アプリケーション ウィンドウ、ペイン、ボタン、ツールヒント、リスト ボックス、およびリスト項目が含まれています。
UI オートメーション要素は、ツリーとしてクライアントに公開されます。 UI オートメーションは、要素間を移動してツリーを構成します。 ナビゲーションは、各要素のプロバイダーによって有効になります。 各要素は、独自の親要素、その兄弟要素、およびその最初と最後の子要素を指すことができます。
クライアントは、次の表で説明するように、3 つのプリンシパル ビューでUI オートメーション ツリーを表示できます。
| 表示 | 説明 |
|---|---|
| 列ビュー | すべての要素が含まれます。 |
| コントロール ビュー | コントロールである要素が含まれます。 |
| コンテンツ ビュー | ユーザーに情報を伝達するコントロール要素が含まれます。 |
コンテンツ要素またはコントロール要素としての要素の定義はプロバイダー実装で行う必要があります。 コントロール要素はコンテンツ要素であることもないこともありますが、コンテンツ要素はすべてコントロール要素です。
ツリーのクライアント ビューの詳細については、「ツリーの概要UI オートメーション」を参照してください。
フレームワーク
フレームワークは、画面のある領域で子コントロール、ヒット テスト、およびレンダリングを管理するコンポーネントです。 たとえば、HWND と呼ばれる Win32 ウィンドウは、メニュー バー、ステータス バー、ボタンなど、複数のUI オートメーション要素を含むフレームワークとして機能できます。
リスト ボックスやツリー ビュー コントロールなどの Win32 コンテナー コントロールは、子項目をレンダリングしてヒット テストを実行するための独自のコードが含まれているため、フレームワークと見なされます。 これに対し、WPF リスト ボックスはフレームワークではありません。レンダリングとヒット テストは、含まれているウィンドウによって処理されるためです。
アプリケーション内の UI はさまざまなフレームワークで構成することができます。 たとえば、アプリケーションの HWND に動的 HTML (DHTML) が含まれている場合、 HWND にコンボ ボックスなどのコンポーネントを含めることができます。
fragments
特定のフレームワークからの要素の完全なサブツリーをフラグメントと呼びます。 サブツリーのルート ノードにある要素はフラグメント ルートと呼ばれます。 フラグメント ルートには親はありませんが、他のフレームワーク (通常は Win32 ウィンドウ (HWND) 内でホストされます。
Hosts
すべてのフラグメントのルート ノードは、要素 (通常は Win32 ウィンドウ (HWND) でホストされている必要があります。 例外は、他の要素でホストされないデスクトップです。 カスタム コントロールのホストはコントロール自体の HWND であり、アプリケーション ウィンドウや最上位のコントロールのグループを含む可能性があるその他のウィンドウではありません。
フラグメントのホストは、UI オートメーション サービスを提供するうえで重要な役割を果たします。 このホストがフラグメント ルートへの移動を可能にし、いくつかの既定のプロパティを提供するため、カスタム プロバイダーはそれらを実装する必要がありません。
関連トピック
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示