UI オートメーションと Microsoft Active Accessibility

Microsoft Active Accessibility は、アプリケーションをアクセス可能にするための以前のソリューションでした。 Microsoft UI オートメーションは Microsoft Windows の新しいアクセシビリティ モデルであり、その目的は支援技術製品と自動テスト ツールのニーズを解決することです。 UI オートメーションは、多くの点で Active Accessibility よりも強化されています。

このトピックでは、UI オートメーションの主な機能を紹介し、Active Accessibility との違いについて説明します。

プログラミング言語

Active Accessibility は、デュアル インターフェイスをサポートするコンポーネント オブジェクト モデル (COM) に基づいているため、C/C++、Microsoft Visual Basic 6.0、およびスクリプト言語でプログラミングできます。 UI オートメーション (標準コントロールのクライアント側プロバイダー ライブラリを含む) はマネージド コードで記述されており、C# または Visual Basic .NET を使用して UI オートメーション クライアント アプリケーションを実に簡単にプログラムすることができます。 インターフェイスを実装する UI オートメーション プロバイダーは、マネージド コードまたは C/C++ で記述できます。

Windows Presentation Foundation におけるサポート

Windows Presentation Foundation (WPF) は、ユーザー インターフェイスを作成するための新しいモデルです。 WPF の要素には Active Accessibility のネイティブ サポート機能はありませんが、UI オートメーションがサポートされており、これに Active Accessibility クライアントのためのブリッジ サポートが含まれています。 UI オートメーション専用に作成されたクライアントだけが WPF のユーザー補助機能 (テキストに関する豊富なサポートなど) を最大限に利用できます。

サーバーとクライアント

Active Accessibility では、サーバーとクライアントは、主にサーバーによる IAccessible の実装を介して直接通信します。

UI オートメーションでは、サーバー (プロバイダー) とクライアントの間にコア サービスが存在します。 このコア サービスは、プロバイダーによって実装されたインターフェイスを呼び出して、追加のサービス (要素の一意のランタイム識別子の生成など) を提供します。 クライアント アプリケーションはライブラリ関数を使用して UI オートメーション サービスを呼び出します。

UI オートメーション プロバイダーは Active Accessibility クライアントに情報を提供でき、Active Accessibility サーバーは UI オートメーション クライアント アプリケーションに情報を提供できます。 ただし、Active Accessibility は UI オートメーションほど多くの情報を公開しないため、この 2 つのモデルには完全な互換性がありません。

UI 要素

Active Accessibility では UI 要素を IAccessible インターフェイスまたは子識別子として表現します。 2 つの IAccessible ポインターを比較してそれらが同じ要素を参照しているかどうかを判断するのは困難です。

UI オートメーションでは、すべての要素が AutomationElement オブジェクトとして表現されます。 比較は等値演算子または Equals メソッドを使用して行われますが、どちらの方法でも、要素の一意のランタイム識別子が比較されます。

ツリー ビューとナビゲーション

画面上の UI インターフェイス (UI) 要素は、ツリー構造で表すことができます。デスクトップがルートで、その直接の子としてアプリケーション ウィンドウがあり、アプリケーション内の要素がその子孫となります。

Active Accessibility では、エンドユーザーには無関係なオートメーション要素も多数、ツリー内に公開されます。 クライアント アプリケーションは、すべての要素の中から意味のあるものを特定する必要があります。

UI オートメーション クライアント アプリケーションは、フィルタリングしたビューを使用して UI を確認します。 このビューには、必要な要素 (ユーザーに情報を提供したり、対話を可能にしたりする要素) のみが表示されます。 コントロール要素だけが含まれるビューや、コンテンツ要素だけが含まれるビューがあらかじめ定義されています。さらに、アプリケーションでカスタム ビューを定義することもできます。 UI オートメーションは、ユーザーに対して UI を簡単に表せるようにして、ユーザーとアプリケーションの対話を支援します。

Active Accessibility における要素間ナビゲーションは、空間的 (画面上で左にある要素に移動するなど)、論理的 (次のメニュー項目に移動する、ダイアログ ボックスのタブ オーダー内で次の項目に移動するなど)、階層的 (コンテナー内の最初の子に移動する、子からその親に移動するなど) のいずれかです。 子要素が IAccessibleを実装しているオブジェクトであるとは限らないため、階層的ナビゲーションは複雑です。

UI オートメーションでは、すべての UI 要素が、同じ基本機能をサポートする AutomationElement オブジェクトです。 (プロバイダーの観点では、IRawElementProviderSimple から継承されたインターフェイスを実装するオブジェクトです)。ナビゲーションは主に階層的 (親から子、兄弟から次の兄弟) です (兄弟間のナビゲーションは、タブ オーダーに従う場合があるため、論理的要素も持っています)。フィルタリングされたツリー ビューで TreeWalker クラスを使用して、任意の場所からナビゲーションを開始できます。 FindFirst と FindAllを使用して、特定の子または子孫に移動することもできます。たとえば、指定したコントロール パターンがサポートされるダイアログ ボックス内のすべての要素を非常に簡単に取得できます。

UI オートメーションにおけるナビゲーションは、Active Accessibility の場合より一貫性があります。 ドロップダウン リストやポップアップ ウィンドウなど、Active Accessibility ツリーに 2 回表示される要素がありますが、このような要素からナビゲーションすると、予期しない結果が生じる可能性があります。 実際には、rebar コントロールに対して Active Accessibility を正しく実装することは不可能です。 UI オートメーションでは親の再指定や位置変更が可能なため、ウィンドウの所有関係による階層にかかわらず、要素をツリー内の任意の場所に配置できます。

役割とコントロール型

Active Accessibility は、accRole プロパティ (IAccessible::get_actRole) を使用して、ROLE_SYSTEM_SLIDER や ROLE_SYSTEM_MENUITEM などの UI 内の要素の役割の記述を取得します。 要素の役割は、要素の機能を表す主要な鍵になります。 コントロールとの対話は、 IAccessible::accSelect や IAccessible::accDoDefaultActionなどの固定のメソッドを使用して実現されます。 クライアント アプリケーションと UI の間の対話は、IAccessible を通して実行できる範囲に限定されます。

これに対して、UI オートメーションでは、要素のコントロール型 (ControlType プロパティで記述) と、それに期待される機能とが大きく分離されています。 機能は、特殊なインターフェイスの実装を通じてプロバイダーによってサポートされる、コントロール パターンによって決定されます。 複数のコントロール パターンを組み合わせると、特定の UI 要素がサポートする機能をすべて記述することができます。 プロバイダーによっては、ある 1 つの特定のコントロール パターンをサポートしなければならないものがあります。たとえば、チェック ボックスのプロバイダーは Toggle コントロール パターンをサポートする必要があります。 また、コントロール パターンのセットを 1 つ以上サポートしなければならないものもあります。たとえば、ボタンは、Toggle と Invoke のいずれかをサポートする必要があります。 さらに、コントロール パターンをまったくサポートしないものもあります。たとえば、移動もサイズ変更もドッキングもできないペインには、コントロール パターンはありません。

UI オートメーションは、Custom プロパティによって識別され、LocalizedControlTypeProperty プロパティによって記述可能なカスタム コントロールをサポートします。

次の表に、Active Accessibility の役割と UI オートメーションのコントロール型のマッピングを示します。

さまざまなコントロール型の詳細については、「 UI Automation Control Types」を参照してください。

状態とプロパティ

Active Accessibility では、要素は一般的なプロパティのセットをサポートします。一部のプロパティ (accState など) は、要素の役割に応じてまったく異なる内容を記述する必要があります。 サーバーは、プロパティを返す IAccessible のメソッドをすべて (要素に無関係なものも含む) 実装する必要があります。

UI オートメーションでは、さらに多くのプロパティが定義されており、その一部は Active Accessibility での状態に対応します。 すべての要素に共通するものもあれば、コントロール型とコントロール パターンに固有のものもあります。 プロパティは一意の識別子によって識別され、ほとんどのプロパティは単一のメソッド ( GetCurrentPropertyValue または GetCachedPropertyValue) を使用して取得できます。 多くのプロパティは、 Current プロパティ アクセサーおよび Cached プロパティ アクセサーからも容易に取得できます。

UI オートメーション プロバイダーは、無関係なプロパティを実装する必要はなく、サポートしていないプロパティに対しては単に null 値を返すことができます。 また、UI オートメーションのコア サービスは、一部のプロパティを既定のウィンドウ プロバイダーから取得できます。これらは、プロバイダーによって明示的に実装されたプロパティと 1 つにまとめられます。

UI オートメーションでは、多くのプロパティをサポートすることに加えて、単一のプロセス間呼び出しで複数のプロパティを取得できるので、パフォーマンスが向上します。

次の表に、2 つのモデルのプロパティ間の対応を示します。

次の表に、UI オートメーション プロパティと Active Accessibility の状態定数との対応を示します。

次は、ほとんどの Active Accessibility コントロール サーバーで実装されていなかったか、UI オートメーションに対応するものがない状態を示します。

UI オートメーションのプロパティ識別子の完全な一覧については、「UI オートメーション プロパティの概要」を参照してください。

events

UI オートメーションのイベント機構は、Active Accessibility とは異なり、Windows のイベント ルーティング (ウィンドウ ハンドルと密接に関連する) に依存せず、クライアント アプリケーションでフックを設定する必要もありません。 イベントのサブスクリプションは、特定のイベントに対してだけでなく、ツリーの特定の部分を対象とするように細かく調整できます。 プロバイダーも、リッスンされているイベントを追跡して、イベントの生成を細かく調整できます。

イベントを生成した要素をクライアントで取得することも簡単です。このような要素は、イベント コールバックに直接渡されるからです。 クライアントがイベントをサブスクライブしているときにキャッシュ要求がアクティブであった場合は、自動的に要素のプロパティがプリフェッチされます。

次の表に、Active Accessibility の WinEvent と UI オートメーションのイベントとの対応を示します。

セキュリティ

IAccessible をカスタマイズするシナリオでは、基本 IAccessible をラップしてからこれに対する呼び出しを行うという要件が生じることがあります。 このことは、セキュリティに影響を及ぼします。部分信頼コンポーネントにコード パスを中継させてはならないからです。

UI オートメーション モデルでは、プロバイダーが他のプロバイダー コードを呼び出す必要がありません。 必要な集約はすべて UI オートメーション コア サービスが行います。

関連項目

• UI オートメーションの基礎