JP2006526183A - ユーザインタフェースオートメーションフレームワークのクラスおよびインタフェース - Google Patents

Abstract

ユーザインタフェース情報をクライアントに提供する方法およびシステムが記載されている。本方法およびシステムは、アクセシビリティシステムを通じてクライアントにユーザインタフェース情報を提供するアプリケーションプログラムインタフェースのセットを実装する。アクセシビリティシステムは、プロバイダ側からクライアント側へユーザインタフェース情報を転送するメカニズムと、ユーザインタフェース情報を選択的に公開する論理ツリーを含む。アプリケーションプログラムインタフェースシステムは、クライアントがユーザインタフェース情報を取得することを支援するクライアント側アプリケーションプログラムインタフェースを含む。クライアント側アプリケーションプログラムインタフェースは、オートメーションクラス、論理要素クラス、raw要素クラス、コントロールパターンクラス、および入力クラスを含む。プロバイダ側アプリケーションプログラムインタフェースは、プロバイダオートメーションクラス、プロバイダオートメーションインタフェース、raw要素インタフェース、およびコントロールパターンプロバイダインタフェースを含む。

Description

本発明は、ユーザインタフェース情報を収集する支援テクノロジ、自動化テスト等の製品、およびこれらの製品とユーザインタフェース情報とのインタラクションの分野に関する。

［発明の背景］
学習、通信および、コンピュータソフトウェアに含まれコンピュータソフトウェアにより提示される情報へのアクセスの領域で支援を必要とするコンピュータユーザを助けるために、支援テクノロジ（ＡＴ）製品が存在する。このような製品は、コンピュータインタフェースに関連する情報を必要とする。同様に、既存の自動化テスト製品およびユーザインタフェースコマンドユーティリティもまた、ユーザインタフェースに関する情報を必要とする。現在、これらの製品には、ユーザインタフェース（ＵＩ）情報の十分なソースがない。これらの３種の製品（クライアント）は、以下のことができるためには他から必要なサポートを得なければならない：（１）アプリケーションのユーザインタフェースに関する情報を収集すること、（２）ＵＩを構築するために使用されるテクノロジにかかわらずＵＩ要素をプログラムで発見しそれに問い合わせること、（３）キーボードおよびポインタ入力を生成すること、ならびに（４）いかなるタイプの動作や機能が現在利用可能であるかを理解すること。これらのすべての能力をＡＴ製品に与える単一のテクノロジは現在利用可能でなく市販されていない。また、現在のＡＴ製品は、すべてのグラフィカルオペレーティングシステム（ＯＳ）テクノロジと常に互換性があるわけではなく、冗長な通知や紛らわしい通知を集中化された形でフィルタリング（選別）および調整をすることができない。もう１つの欠点として、現在のオートメーションおよびアクセシビリティのインフラストラクチャ（インフラ基盤）は拡張可能でないため、新しい機能を追加するにはＯＳレベルの変更を必要とする。

また、現在、アプリケーションのユーザインタフェースに関する情報を収集するには、ＡＴ製品は、ユーザについての情報を得るためにアプリケーション固有のコードを書かなければならない。このアプリケーション固有コードを書くプロセスは時間がかかり、継続的な保守を必要とする。現在のオートメーションインフラストラクチャは、冗長なイベント通知や紛らわしいイベント通知を一貫性のある形でフィルタリングおよび調整することもできない。したがって、イベントコンシューマ（イベント需要者）は、独力で情報をフィルタリングする必要がある。

現在のシステムによれば、ＡＴ製品は、次の３つの精度レベルでイベント通知を要求することができる：（１）デスクトップ上のあらゆるもの、（２）特定のプロセス（例えばワードプロセッサのオープン）において、または（３）特定プロセス（複数のオブジェクトがそのプロセス内で作業を行う）内のあるスレッドにおいて。現在、クライアントは、イベントを受け取る時、そのイベントが発生した特定のウィンドウのウィンドウハンドルと、そのイベントがどこで発生したかを示す他の情報ビットとを受け取る。クライアントは、イベントに関連するＵＩオブジェクトを取得するためにクロスプロセスコールを行うことができる。このオブジェクトを用いて、クライアントは、そのオブジェクトに関する情報を求めるための追加的なクロスプロセスコールを行うことができる。クライアントが５個の情報を必要とする場合、クライアントは、クロスプロセスコールを５回行わなければならない。クロスプロセスコールは非常に遅いため、現在のアクセシビリティインフラストラクチャを用いてＵＩ情報を収集することのパフォーマンスコストは高い。この種の周知のシナリオ（筋書き）が図１１に示されている。サーバアプリケーション１２がイベント６を発火（fire）させる。カーネル１４は、どのクライアントに通知しなければならないかを判断し、関心のあるクライアント１０にイベント通知１８を送る。クライアント１０は、プロセス境界２を越えてサーバアプリケーション１２に対して、イベント通知１８に関連するオブジェクトを求める要求１６を行う。サーバアプリケーション１２がオブジェクト２０を返すと、クライアント１０は、イベントを発火させたＵＩコントロールに関する情報を求める要求１６の送信を開始することができる。サーバアプリケーション１２は、プロセス境界２を越えてクライアント１０へ、要求された情報２０を返す。

現在のもう１つの選択肢によれば、クライアントコードが、プロセス内にダイナミックリンクライブラリ（．ＤＬＬ）としてロードされることが可能である。この選択肢はいくつかの欠点を有する。第１に、クライアントコードをプロセスにロードするためにシステムからの協力を必要とする。第２に、いったんクライアントコードがアプリケーションのプロセスにロードされると、それが収集する情報を制限することが困難であるため、セキュリティの問題が生じる。第３に、クライアントにとって有効な技法であるためには、それがシステム上のあらゆるプロセスにロードされなければならない。最適には、信頼できるクライアントのみが別のアプリケーションのプロセスにロードされるべきである。

また、クライアントがどのようなイベント通知を受け取ることを希望しているかを指定する能力をクライアントに与えるシステムが必要である。周知のシステムでは、クライアントは、いくつかのクロスプロセスコールを行ってから、その情報を分析して、イベントに関心があるかどうかを判断しなければならないことがある。このイベントフィルタリングをより高いパフォーマンスで実行することが可能であって、新しいシステムやアプリケーションイベントをサポートするために容易に更新可能なメカニズムが必要である。また、セキュリティの問題を軽減するために、信頼できるコンポーネントのみを使用するシステムが必要である。

現在、ユーザインタフェースに関する情報を求める際に、ＡＴ製品は、特定のＵＩフレームワークを原産とするツリーにアクセスする必要がある。したがって、複数のＵＩフレームワークに対するユーザインタフェース情報を伝達するには複数のツリーが必要である。これらの異なるツリーは、エンドユーザによって操作される可視ＵＩコントロールを管理する非表示コンテナオブジェクトのように、ユーザにとって関心のない、または可視でない情報を含むことがある。したがって、ユーザにとって関心のあるノードのみを有する単一の統一されたツリーが必要とされている。

ＡＴ製品、自動化テストツール、およびコマンドユーティリティのニーズに応える解決法が必要とされている。その解決法は、すべてのグラフィカルＯＳテクノロジによって使用可能であるべきであり、すべての形態のＵＩおよびＵＩコンポーネントがアクセス可能となるようにすべきである。

［発明の概要］
本発明は、ユーザインタフェース情報をクライアントに提供する方法およびコンピュータアプリケーションに関する。本発明の一態様によれば、ユーザインタフェース情報をクライアントに提供するアクセシビリティシステムにおいて使用するためのツールのシステムが提供される。アクセシビリティシステムは、クライアント側およびプロバイダ側を含む。ツールのシステムは、ユーザインタフェース情報を求めるためのクライアントオートメーションクラスを含むクライアント側オートメーションツールを含む。クライアントオートメーションクラスは、イベント登録ツールおよび論理要素発見ツールを含む。ツールのセットは、さらに、ユーザインタフェース情報をクライアントに提供するプロバイダ側オートメーションツールを含む。プロバイダ側オートメーションツールは、イベント情報をクライアントに提供するツールを有するオートメーションプロバイダクラスを含む。

もう１つの態様によれば、クライアント側ツールのセットは、プロバイダ側からのユーザインタフェースイベント情報を求めるためのクライアントオートメーションクラスを含むクライアント側オートメーションメカニズムと、論理ツリー内のユーザインタフェース要素を表現する論理要素クラスを含むクライアント側論理要素メカニズムを含んでもよい。

さらにもう１つの態様によれば、プロバイダツールは、クライアントにイベント通知を提供するツールを含むプロバイダ側オートメーションクラスと、ユーザインタフェースプロパティを公開するプロバイダ側オートメーションインタフェースを含む。プロバイダ側ツールは、さらに、特定の関係要素に関連する情報を返すraw(生、未加工)要素インタフェースと、特定の要素に関連しないイベントおよび機能を管理するraw要素コンテクストインタフェースを含む。

もう１つの態様によれば、本発明は、アクセシビリティシステムを通じてクライアントにユーザインタフェース情報を提供するアプリケーションプログラムインタフェースシステムを含む。アクセシビリティシステムは、プロバイダ側からクライアント側へユーザインタフェース情報を転送するメカニズムと、ユーザインタフェース情報を選択的に公開する論理ツリーを含む。アプリケーションプログラムインタフェースシステムは、クライアントがユーザインタフェース情報を取得することを支援するクライアント側アプリケーションプログラムインタフェースを含む。クライアント側アプリケーションプログラムインタフェースは、オートメーションクラス、論理要素クラス、raw要素クラス、コントロールパターンクラス、および入力クラスを含む。プロバイダ側アプリケーションプログラムインタフェースは、プロバイダオートメーションクラス、プロバイダオートメーションインタフェース、raw要素インタフェース、およびコントロールパターンプロバイダインタフェースを含む。

もう１つの態様によれば、本発明は、アクセシビリティシステムを通じてクライアントにユーザインタフェース情報を提供するコンピュータ実施方法を含む。本方法は、クライアントがユーザインタフェース情報を取得することを支援するクライアント側アプリケーションプログラムインタフェースを提供する。ここで、クライアント側アプリケーションプログラムインタフェースは、オートメーションクラス、論理要素クラス、raw要素クラス、コントロールパターンクラス、および入力クラスを含む。本方法は、さらに、クライアント要求に応答するプロバイダ側アプリケーションプログラムインタフェースを提供することを含む。プロバイダ側アプリケーションプログラムインタフェースは、プロバイダオートメーションクラス、プロバイダオートメーションインタフェース、raw要素インタフェース、およびコントロールパターンプロバイダインタフェースを含む。

さらにもう１つの態様によれば、本発明は、アクセシビリティシステムを通じてクライアントにユーザインタフェース情報を提供するコンピュータ実施方法を含む。本方法は、選択されたイベントハンドラを用いてクライアントオートメーションクラスに対してユーザインタフェース情報を要求すること、およびプロバイダが対応するイベント発生メソッドを用いてユーザインタフェースイベント通知を提供する方法を含む。

本発明のさらなる利点および新規な特徴は、以下の説明に記載され、部分的には以下の記載を検討すれば当業者には明らかとなるか、または本発明の実施から分かるであろう。

本発明は、添付図面を参照して以下に詳細に記載される。

［発明の詳細な説明］
例示的なオペレーティング環境
図１は、本発明が実施され得る好適なコンピューティングシステム環境１００の一例を示している。コンピューティングシステム環境１００は、好適なコンピューティング環境の一例に過ぎず、本発明の用途または機能の範囲に関するいかなる限定を示唆することも意図していない。また、コンピューティング環境１００は、例示的オペレーティング環境１００に示されるいかなるコンポーネントまたはその組合せに関するいかなる従属性または要件を有するとも解釈されてはならない。

本発明は、コンピュータにより実行されるプログラムモジュール等のコンピュータ実行可能命令との一般的関連で記述され得る。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データストラクチャ（structure:構造、構造体）等を含む。さらに、当業者には理解されるように、本発明は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサ方式の、またはプログラム可能な消費者電子機器(家電製品)、ミニコンピュータ、メインフレームコンピュータ等の他のコンピュータシステム構成を用いて実施されてもよい。本発明は、通信ネットワークを通じてリンクされるリモート処理デバイスによりタスクが実行される分散コンピューティング環境で実施されてもよい。分散コンピューティング環境では、プログラムモジュールが、メモリ記憶デバイスを含むローカルおよびリモートの両方のコンピュータ記憶媒体に配置されてもよい。

図１を参照すると、本発明を実施する例示的システム１００は、コンピュータ１１０の形態の汎用コンピューティングデバイスを含む。コンピュータ１１０は、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを含む種々のシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１を含む。

コンピュータ１１０は通常、さまざまなコンピュータ可読媒体を含む。例として、限定ではないが、コンピュータ可読媒体にはコンピュータ記憶媒体および通信媒体が含まれ得る。システムメモリ１３０は、読み出し専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２のような揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。起動中等にコンピュータ１１０内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）が通常ＲＯＭ１３１に格納される。ＲＡＭ１３２は通常、処理ユニット１２０から直接アクセス可能な、および／または処理ユニット１２０が現在作用しているデータおよび／またはプログラムモジュールを含む。例として、限定ではないが、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示している。

コンピュータ１１０はまた、他のリムーバブル（取り外し可能）／非リムーバブル、揮発性／不揮発性のコンピュータ記憶媒体を含んでもよい。単なる例として、図１は、非リムーバブル不揮発性磁気媒体の読み書きを行うハードディスクドライブ１４１、リムーバブル不揮発性磁気ディスク１５２の読み書きを行う磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭ等の光媒体のようなリムーバブル不揮発性光ディスク１５６の読み書きを行う光ディスクドライブ１５５を示している。例示的オペレーティング環境で使用可能な他のリムーバブル／非リムーバブル、揮発性／不揮発性のコンピュータ記憶媒体としては、以下のものには限定されないが、磁気テープカセット、フラッシュメモリカード、ディジタル多用途ディスク、ディジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭ等がある。ハードディスクドライブ１４１は通常、インタフェース１４０のような非リムーバブルメモリインタフェースを通じてシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通常、インタフェース１５０のようなリムーバブルメモリインタフェースによりシステムバス１２１に接続される。

前述し図１に示したドライブおよびそれらに関連するコンピュータ記憶媒体は、コンピュータ１１０のためのコンピュータ可読命令、データストラクチャ、プログラムモジュールおよびその他のデータの格納を行う。例えば図１において、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するように示されている。なお、これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じでも異なってもよいことに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、少なくともそれらが別のコピーであることを示すためにここでは異なる番号が与えられている。ユーザは、キーボード１６２、および一般にマウス、トラックボールまたはタッチパッドと呼ばれるポインティングデバイス１６１のような入力デバイスを通じてコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）としては、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ等があり得る。これらおよび他の入力デバイスは、システムバスに結合したユーザ入力インタフェース１６０を通じて処理ユニット１２０に接続されることが多いが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）のような他のインタフェースおよびバスストラクチャにより接続されてもよい。モニタ１９１または他のタイプの表示デバイスもまた、ビデオインタフェース１９０のようなインタフェースを通じてシステムバス１２１に接続される。モニタに加えて、コンピュータはスピーカ１９７およびプリンタ１９６のような他の周辺出力デバイスを含んでもよく、これらは出力周辺インタフェース１９５を通じて接続され得る。

本発明におけるコンピュータ１１０は、リモートコンピュータ１８０のような１つまたは複数のリモートコンピュータへの論理コネクションを用いたネットワーク環境で動作し得る。リモートコンピュータ１８０は、パーソナルコンピュータであってよく、通常、コンピュータ１１０に関して前述した要素の多くまたはすべてを含む。ただし、メモリ記憶デバイス１８１のみが図１には示されている。図１に示す論理コネクションは、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含んでもよい。

ＬＡＮネットワーキング環境で使用される場合、コンピュータ１１０はネットワークインタフェースすなわちアダプタ１７０を通じてＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ１１０は通常、インターネットのようなＷＡＮ１７３を通じて通信を確立するためのモデム１７２等の手段を含む。モデム１７２は、内蔵でも外付けでもよいが、ユーザ入力インタフェース１６０等の適切なメカニズムを通じてシステムバス１２１に接続され得る。ネットワーク環境では、コンピュータ１１０に関して図示したプログラムモジュールまたはその部分は、リモートメモリ記憶デバイスに格納されてもよい。例として、限定ではないが、図１は、リモートアプリケーションプログラム１８５がメモリデバイス１８１上に存在するように示している。理解されるように、図示したネットワークコネクションは例示であり、コンピュータ間に通信リンクを確立する他の手段を使用してもよい。

コンピュータ１１０の多くの他の内部コンポーネントは示されていないが、当業者には理解されるように、このようなコンポーネントおよびその相互接続は周知である。したがって、コンピュータ１１０の内部構成に関するさらなる詳細は、本発明との関連では開示する必要はない。

アクセシビリティシステムの構成
図２に示すように、アクセシビリティシステム２００は、クライアント環境３００およびサーバ環境４００と相互作用する。アクセシビリティシステム２００は、図１に関して前述したコンピュータ環境１００において実施されてもよい。アクセシビリティシステム２００は、クライアント３００とのインタラクションを容易にするクライアント側アクセシビリティインタフェース２２０と、サーバ側４００とのインタラクションを容易にするサーバ側アクセシビリティインタフェース２３０と、アクセシビリティシステムコア２０１を含む。本発明のアクセシビリティシステム２００は、プログラムでユーザインタフェース（ＵＩ）にアクセスするためのクライアント側ＡＰＩ３１０およびプロバイダ側ＡＰＩ４４０を含む新規なアプリケーションプログラムインタフェース（ＡＰＩ）を提供する。アクセシビリティシステム２００により、アプリケーションは、自分自身および使用するコンポーネントをアクセス可能にすることができる。

クライアント環境３００は、好ましくは、支援テクノロジ（ＡＴ）製品または自動化ＵＩテストツールを含む。サーバ側４００は、図２に示すようなさまざまな異なるテクノロジを実施することができる。サーバシステム４１０は、アダプタ４１２およびコア４１４を含み、これらは第１のタイプのＵＩに見出され得る。サーバシステム４２０は、プロキシ（代理）コンポーネント４２２およびコントロール４２４を含む。これらは、米国ワシントン州Redmondの本願特許出願人から市販されているMicrosoft Operating System製品で利用可能なＷｉｎ３２ ＵＩのような、第２のタイプのＵＩに見出され得る。サーバシステム４３０は、アダプタ４３２および内部ＯＭ４３４を含む。これらは別の第３のタイプのＵＩに見出され得る。

図３に示すように、アクセシビリティシステム２００に含まれるイベントメカニズム２１０は、クライアント環境３００およびサーバ環境４００とのインタラクションを容易にするＵＩオートメーションクライアント２０２およびＵＩオートメーションサーバ２０４に頼る。ＵＩオートメーションクライアント２０２およびＵＩオートメーションサーバ２０４は、本発明のイベントメカニズム２１０に関連して以下でさらに詳細に説明される。本発明のアクセシビリティシステム２００は、クライアント（ＡＴ製品）３００に以下の能力を与える：（１）アプリケーションのユーザインタフェースに関する情報を収集すること、（２）ＵＩを構築するために使用されるテクノロジにかかわらずＵＩ要素をプログラムで発見しそれに問い合わせること、（３）キーボードおよびポインタ入力を生成すること、ならびに（４）いかなるタイプの動作や機能が現在利用可能であるかを理解すること。アクセシビリティシステム２００により、アプリケーションは、自分自身および自分のコンポーネントをアクセス可能にすることができる。図２および図３に示す構成は、アクセシビリティシステム２００の以下のようないくつかの主要な側面を可能にする：（１）論理ＵＩツリー、（２）コントロールパターン、（３）イベントメカニズム、（４）プロパティ、ならびに（５）クライアント側およびサーバ側ＡＰＩ。これらのすべてについて、以下でさらに説明する。

ＵＩアクセス論理ツリー２２２
アクセシビリティシステム２００の不可欠なコンポーネントとして論理ツリー２２２がある。その一例を図４（Ｄ）に示す。ツリー２２２は、クライアント側アクセシビリティインタフェース２２０に含まれる。

論理ツリー２２２は、ＵＩ要素の基盤となるストラクチャ（structure:構造、構造体）階層のフィルタリングされたビューであり、コントロールやアプリケーションの開発者が実装しなければならない別個のツリーではない。その代わりに、論理ツリー２２２は、いくつかの明確なプロパティを備える。これらは、関心のある(interesting)ものも関心のない(uninteresting)ものも含めて、ストラクチャ要素が論理ツリー２２２に公開されるべきかどうかを示す。アクセシビリティシステムコア２０１は、この情報を用いて、フィルタリングされたＵＩ論理ツリー２２２を生成し、そのＵＩ論理ツリー２２２がＡＴ製品またはテストスクリプトに提示される。

論理ツリー２２２は、要素のツリーであり、各要素は、コントロール、コントロール内の項目、またはグルーピングストラクチャを表現する。グルーピングストラクチャとしては、ダイアログ、ペイン（pane:ウインドウ枠）、またはフレームがあり得る。論理ツリー２２２のストラクチャは、ユーザによって認識される通りに（たとえコントロールが実際には異なる基盤ストラクチャを用いて実装されていても）アプリケーションのＵＩを表現すべきである。ツリーは、長い時間にわたり安定であるべきである。アプリケーションがユーザにとって同じように見える限り、たとえそのアプリケーションの舞台裏の実装の詳細が変化しても、そのアプリケーションを表現する論理ツリー２２２は同一のままにとどまるべきである。ストラクチャ上および実装上の理由で存在するネイティブ要素（例えば、MicrosoftのＯＳ製品におけるシェルの「ShDocView」ウィンドウ）は、ユーザがそれを認識しないので、このツリーに現れるべきでない。

論理ツリー２２２は、クライアントにとって同じようになるように複数の異なるプロセスを統合することが可能な複数のフラグメントから構築された単一のツリーである。論理ツリー２２２によればバルク検索が可能であり、プロパティのリストに対する値を取得することができる。ユーザが通常の場合に、値を求めてクロスプロセスコールを呼び出す時までに、アクセシビリティシステム２００は論理ツリー２２２を使用することによりその値をフェッチ（取得）しているであろう。

論理ツリー２２２は、周知のシステムの場合のように１ステップで構築されるのでなく、rawツリーを構築するのに使用しるフラグメントから構築される。図５に示すように、３つの主要な手続きが論理ツリー２２２を構築する。手続き７２において、アクセシビリティシステム２００が、基盤テクノロジのネイティブ要素を配置し、図４（Ａ）に示すネイティブツリーに到達する。手続き７４において、アクセシビリティシステム２００がネイティブ要素を結合して、図４（Ｂ）に示すようなrawツリー２０を形成する。最後に手続き７６において、図４（Ｄ）に示すようにrawツリー２０内の関心のないコンポーネントを隠蔽することによって、論理ツリー２２２が得られる。

図４（Ａ）は、２つのネイティブツリー１０および１４を示している。これらは、Ｗｉｎ３２ ＵＩ等の利用可能なＵＩのような基盤テクノロジのネイティブ要素から構築される。ネイティブツリー１０は、親ノード１１と、互いに種々の関係を有する複数の子孫１２を含む。同様に、ネイティブツリー１４は、複数の子ノード１６を有する親ノード１５を含む。子ノード１６は、互いの兄弟として記述することもできる。

図４（Ｂ）に示すように、ネイティブツリー１０および１４を結合してrawツリー２０を形成することができる。rawツリー２０は、２個の子ノード２２および３０を有する親ノード２１を含む。子ノード２２は子孫２３〜２９を有し、子ノード３０は子孫３１〜３３を有する。このrawツリー２０は、ネイティブツリー１０および１４の結合であり、ネイティブツリー１０のノードがノード２２〜２９となり、ネイティブツリー１４のノードがノード３０〜３３となっている。

図４（Ｃ）および図４（Ｄ）に大まかに示す方法により、rawツリー２０は論理ツリー２２２に変換される。rawツリー２０から論理ツリー２２２に移るため、開発者はrawツリーにヒントを挿入することができる。開発者は、rawツリー２０内のノードに「自分自身を隠蔽する」や「自分自身と子を隠蔽する」や「ノードの子を隠蔽する」などとマークすることができる。また、開発者は、ノードを横へ移動したり、ノードを子の前に置いたりすることもできる。rawツリー２０内のこれらの「ヒント」および修正は、論理ツリー２２２を形成するために使用される。例えば、図４（Ｃ）において、開発者は、ブロック４０および４１で示すように、rawツリー２０のノード２４〜２６および３３をuninteresting（関心なし）としてマークしている。通常、ユーザにとって可視とならない要素を含むノードはuninterestingとしてマークされる。可視ＵＩに関連するノードは通常、interesting（関心あり）とみなされ、ＡＴクライアント３００によって使用される論理ツリー２２２に含められる。図４（Ｄ）に示すように、uninterestingとしてマークされたノードは論理ツリー２２２に含まれない。

アクセシビリティシステム２００は、論理ツリー２２２を用いて、イベントに関する情報、システムの状態、オブジェクトの位置およびコントロールに関する情報を見つける。周知のシステムは、それらのシステムのツリー内を調べる能力を有していない。論理ツリー２２２は、クライアント３００の選好（preference）に基づいてナビゲート可能であり、使用されるサーバ側アプリケーションにかかわらず情報を提供することができる。

論理ツリー２２２は、ＵＩの論理表現である単一の統合されたツリーであり、クライアント３００にとって関心のある要素のみを含む形状に形成される。したがって、ＡＴ製品がＵＩ要素のストラクチャ階層をフィルタリングし、エンドユーザに提示されるモデルを推測しようとすることを余儀なくさせる代わりに、論理ツリー２２２は、エンドユーザに提示されるストラクチャに綿密にマッピングされる階層を提示する。これは、ユーザに対してＵＩを記述するＡＴ製品のタスクを大幅に簡略化し、ユーザがアプリケーションと相互作用するのを助ける。

この論理ＵＩツリー２２２はアクセシビリティシステム２００の基本的な部分であるので、アクセシビリティシステム２００の他のすべてのコンポーネントは、論理ツリー２２２で働くように設計される。例えば、図６は、非常に簡単なストラクチャを有するように見える簡単なダイアログボックス６０を示している。しかし、現在利用可能なアクセシビリティテクノロジを通して見ると、このダイアログボックス６０のストラクチャは驚くほど複雑である。このダイアログボックス６０には、ＡＴ製品がエンドユーザにとって意味のあるオブジェクトを発見するためにフィルタリングしなければならないオブジェクトが２６４個含まれる。アクセシビリティシステム２００および論理ＵＩツリー２２２に対するそのサポートを用いると、このダイアログボックス６０を所有する開発者は、少数のプロパティをセットすることにより、図６に示す以下のストラクチャをＡＴ製品３００に提示することができる。

図６に示すように、「実行(Run)」ダイアログの場合、開発者は、フライングウィンドウグラフィック６２と、６３の「開きたいプログラム、フォルダ、ドキュメント、またはインターネットリソースの名前を入力してください(Type the name of program, folder, document, or internet resource and windows will open it for you)」をinterestingとして示すことができる。また、開発者は、ノートパッド(notepad)、ワード(word)、電卓(calculator)等を含むコンボボックス６４、ならびにＯＫ６５、キャンセル(cancel)６６および閲覧(browse)６７の各ボタンをinterestingとして示すこともできる。これは、それらの要素階層にタグ付けするための低コストのメカニズムを開発者に提供することにより、ＵＩアクセシビリティシステム２００を通じてそれらのアプリケーションのＵＩの論理表現を生成する。図示の各特徴は、論理ツリー２２２内のそれぞれの他のノードに対して指定された関係を有するノードによって表現することができる。この論理表現は、テストチームおよびＡＴ製品すなわちクライアント３００に直接的利益を提供する。

ユーザにとって最終的に関心があるのは論理ツリー２２２であるが、raw要素ツリー２０もまたいくつかの重要な機能を提供する。論理ツリー２２２はユーザが関係し得る要素のみを含むが、raw要素ツリー２０は、２２のように、基盤フレームワークの実装ストラクチャを表現するノードを含む。例えばＷｉｎ３２ ＵＩフラグメントの場合、このツリーは、ＨＷＮＤを表現するノードを含むであろう。いくつかの点で、raw要素ツリー２０は、論理要素ツリー２２２と基盤フレームワーク自身のネイティブ要素ツリーとの間の「中間点」である。raw要素ツリー２０は、論理要素ツリー２２２を構築するための基礎として使用されるとともに、ネイティブ要素が最初にシステムに接続される場所である。

raw要素ツリー２０は、デバッグおよびテストのために使用されることも可能である。raw要素ツリー２０は、問題のある特定のノードがどこにあるかを指摘または記述するのに有用である。基礎raw要素ノードに関する機能としては、raw要素ツリー内をナビゲートするメソッド、対応する論理要素（もしそれが存在すれば）にジャンプするメソッド、この要素に対する「デバッグ文字列」（例えばＨＷＮＤノードに対する「HWND 0x483FE」）を含むプロパティ、および他の「舞台裏インフラストラクチャ」メソッドがある。これらの他のメソッドは、ヒットテストおよび位置判定、イベント、ならびにフレームワークが容易に提供可能な公開プロパティ（例えば、focused、enabled）をイネーブルする。

raw要素ツリー２０は、種々のレンダリングエンジンからの要素を表現するノード２２〜３３を含む。raw要素ツリーは、アクセシビリティシステム２００に自分自身を接続するためのレンダリングエンジンの開始点として使用され、ネイティブ要素（例えばＷｉｎ３２からのＨＷＮＤ）を統合された論理ツリー２２２に適応させるライトウェイト（軽量）アダプタオブジェクトから構築される。raw要素ツリーは、さらに、あるテクノロジが別のテクノロジをホスティング（hosting）するホスティング移行を処理するためにも使用される。raw要素ツリー２０は、論理ツリー２２２が構築される基礎であるので、論理ツリー２２２が完全かつ連結であることをチェックするために使用可能であるとともに、行方不明(unaccounted-for)の要素をチェックするために使用可能である。raw要素ツリー２０は、さらに、以下のような他のインフラストラクチャ的タスクのために使用されてもよい：基本要素ＩＤを提供すること、ならびにフレームワークが提供する基本的な要素プロパティ（例えば、focused、enabled、およびlocation）を提供すること。

raw要素ツリー２０は、ＡＴ製品すなわちクライアント３００の主たる情報源ではなく、論理ナビゲーションには使用されず、エンドユーザには公開されない。また、raw要素ツリー２０は、ツリー内の要素の位置を捕捉して、それが将来のある時点で返されるように使用することもできない。論理要素ツリー２２２がこれらすべての機能を実行する。

raw要素ツリー２０は通常、表現されている論理要素を知ることなしに、基盤となるレンダリングテクノロジのraw要素（HWND、Element）から機械的に構築することができる。したがって、raw要素ツリー２０は、論理ツリー２２２内で不明になったraw要素を探すために使用することができる。raw要素ツリー２０は、ノードの位置の「スタックダンプ（stack-dump）」的記述を捕捉することができるので、有用なデバッグ・診断ツールである。さらに、周知のシステムのツリーは、コード固有の基準に基づいており、多様なテクノロジにおける実装が困難である。本発明の手法は、一般的で抽象的な「raw要素」タイプを使用する。これは、任意の基盤レンダリングテクノロジによって、またはそのために、実装可能である。

raw要素ツリーを取得するためには、raw要素ルートを呼び出すことでデスクトップ要素が得られる。これは、その親がＮＵＬＬであること、およびすべての他のノードがそれを最終的祖先として有することを確かめることにより確認される。他の要素を取得するためには、指定された点からraw要素を取得するメソッドを呼び出すことにより、正しいスクリーン座標を用いた要素が返される。raw要素ツリーを取得した後、raw要素ツリーは、要素（親、兄弟および子）をチェックすることにより、チェック・確認することができる。

動作において、クライアント３００は、親(parent)、次の兄弟(next sibling)、前の兄弟(previous sibling)、最初の子(first child)、最後の子(last child)等のような関係を用いてraw要素ツリー２０内をナビゲートすることができる。そして、クライアント３００は、raw要素から、論理ツリー２２２内の対応する論理要素へジャンプすることができる。

イベントメカニズム
クライアント３００は、イベントの通知を継続して受けたい場合、図３に示されているようなＵＩオートメーションクライアント２０２を通じて登録を行い、情報を取得することができる。クライアント３００は、受け取りたいオブジェクト情報、その情報の行き先、および受け取りたいプロパティのリストを指定する。クライアント要求はＵＩオートメーションクライアント２０２に送られる。ＵＩオートメーションクライアント２０２は、デスクトップ上のプロセスを監視することができる。ＵＩオートメーションサーバ２０４は、どのクライアント３００がリスン（listening:待機、要求を待つ）中であるかを追跡し、ＵＩオートメーションクライアント２０２に戻る方法を知っている。ＵＩオートメーションクライアント２０２はクライアントの関心をＵＩエンジン２０６に知らせるので、ＵＩエンジン２０６は、いつＵＩオートメーションサーバ２０４にイベントを伝えるべきかを知っている。ＵＩエンジンは、クライアントの知らせ（アドバイス）を利用する必要はなく、その代わりに、ＵＩオートメーションサーバ２０４にイベントを常に通知すること、またはクライアントがイベントをリスン中である場合に限りＵＩオートメーションサーバに通知することを選択してもよい。アドバイスは、クライアントがイベントをリスン中である場合に限りＵＩエンジンがＵＩオートメーションサーバ通知をオンにしたい場合に有益である。これによりＵＩエンジンは、ＵＩの速度の低下を回避し、他の点では不要なコードモジュールのロードを回避する。

次に、ＵＩエンジン２０６は、ＵＩイベントをＵＩオートメーションサーバ２０４に通知する。ＵＩオートメーションサーバ２０４は、要求された論理要素をクライアント３００に返し、クライアント３００が要求したイベントのプロパティを含む情報をクライアント３００に送る。ＵＩオートメーションサーバ２０４は、いかなる情報がクライアント要求のスコープ内にあるかを判断し、情報が関心のあるものの場合に限り論理要素を形成する。論理要素を形成することとしては、クライアントがイベントを処理する際に使用することを示したプロパティのセットをＵＩオートメーションサーバ側でプリフェッチ（先取り）することがある。例えば、ＵＩオートメーションサーバ２０４は、コンボボックスに対する論理要素を発見することができる。スコープ（有効範囲、作用域）は、コンボボックスまたはその子となるであろう。クライアント３００は、登録段階中のスコープを規定するための子／親／依存関係を要求することができる。

ＵＩオートメーションサーバ２０４は、情報が要求されたスコープ内にあるかどうかを判定した後、論理要素を構築する。ＵＩオートメーションクライアント２０２は、ＵＩオートメーションサーバ２０４から要求情報を受け取るターゲットアプリケーションと通信すること、およびオブジェクトをクライアント３００の適切な空間に転送することによって、クライアント３００にサービスする。

ＵＩオートメーションサーバ２０４は、クライアント３００がイベント通知を受け取るように登録をする時に作成される。例として、ＵＩエンジン２０６がMicrosoft Wordワードプロセッサアプリケーションを実行中であるとする。クライアント３００はnameプロパティ変更に登録しているとする。クライアントの登録により、ＵＩオートメーションサーバ２０４が作成される。また、クライアントの登録は、ＵＩエンジン２０６に対して、ＵＩオートメーションサーバ２０４へのnameプロパティの通知を開始するよう知らせる。ＵＩエンジン２０６はスコープ情報を取得しない。ＵＩエンジン２０６は、サーバ側のＡＰＩの１つを呼び出す。ＵＩエンジン２０６は、（１）どのプロパティが変化したか、（２）プロパティの新しい値、および（３）場合によっては古い値、を指定する。ＵＩオートメーションサーバ２０４は、クライアント３００にとって関心のあるイベントに基づいて作成されるので、イベント、プロパティ、クライアント、および関心のあるスコープを知っており、したがって、作成される論理要素にクライアント３００が関心があるかどうかを知っている。複数のクライアント３００が、同じイベントに対して特定のＵＩオートメーションサーバ２０４に登録し、返される論理要素とともにプロパティがバルクフェッチされるように求めている場合、ＵＩオートメーションサーバ２０４がクライアント３００にイベントを返送する時には、各クライアント３００は、論理要素とともに返される要求したバルクフェッチプロパティの合併(union)を取得する。

リスン中の各クライアント３００に対して、ＵＩオートメーションサーバ２０４は、イベントに関連する論理要素をクライアントに渡してクライアント３００に通知する。ＵＩオートメーションサーバ２０４は、ただ１つの論理要素を作成する。これは現在のテクノロジに対する改善である。現在のテクノロジでは、各クライアント３００が、イベントのソースであるオブジェクトの各自のコピーを求めることが要求される。

クライアントがイベントに対して登録する時にＵＩエンジン２０６がＵＩオートメーションクライアントのアドバイスを利用しない場合、ＵＩエンジン２０６は、リスン中のアクセシビリティクライアント３００があるかどうかをＵＩオートメーションサーバ２０４に問い合わせることが可能であり、いずれもリスン中でない場合、情報を作成してそれをＵＩオートメーションサーバ２０４に送る作業を回避することができる。例えば、スクリーンリーダがクライアント３００であり、情報の行き先、イベントを受け取るべきフォーカス変更オブジェクト、および関心のある特定のプロパティのリストを指定しているとする。ＵＩエンジン２０６はアドバイスを受け、イベントをＵＩオートメーションサーバ２０４へ送るべきことを知っている。ＵＩエンジン２０６は、フォーカス変更を検出すると、ＵＩオートメーションサーバ２０４に通知する。ＵＩオートメーションサーバ２０４は、周知のインタフェースに変換し、イベントおよびオブジェクトをＵＩオートメーションクライアント２０２に送る。ＵＩオートメーションクライアント２０２は、オブジェクトをクライアント３００上の適切な空間に転送する。

上記のコンポーネントは、イベントのためのカーネル内の中央リポジトリ（repository）を除去することによって、周知のシステムを改善している。代わりに、ＵＩオートメーションサーバ２０４は、実行中のコンテクストに関する情報を得ることに関心のあるすべてのクライアント３００を知っている。また、カーネルリポジトリの除去は、より多くのピアツーピア(peer-to-peer)インタラクションを作り出す。というのは、ＵＩオートメーションサーバ２０４は、従来カーネルで実行された機能を遂行するからである。本発明のアクセシビリティシステム２００は、フィルタリングがＵＩオートメーションサーバ２０４を用いてサーバ側で遂行されるようにして、クライアント３００が知りたいことを指定する能力をクライアント３００に与える。

図７は、イベント登録および通知メソッドに関与する手続きを示すフローチャートである。ステップ８０で、クライアント３００がイベント通知を要求する。ステップ８２で、ＵＩオートメーションクライアント２０２が要求をＵＩオートメーションサーバ２０４へ送信する。ステップ８４で、ＵＩオートメーションクライアントは、通知を希望していることをＵＩエンジン２０６に知らせる。ステップ８６で、ＵＩオートメーションサーバ２０４は、ＵＩエンジン２０６から通知を受け取る。ステップ８８で、ＵＩオートメーションサーバ２０４は、受け取った情報をフィルタリングする。ステップ９０で、受け取った情報がユーザにとって関心のないものであることが分かった場合、ステップ９２で、ＵＩオートメーションサーバ２０４は、その情報を捨て、引き続き通知を待つ。他方、ステップ９０で、情報が関心のあるものであることが分かった場合、ステップ９４で、ＵＩオートメーションサーバ２０４は、論理要素を作成し、それをＵＩオートメーションクライアント２０２へ送る。ステップ９６で、ＵＩオートメーションクライアント２０２は、受け取った情報をクライアント３００上の適切な場所に置く。

アクセシビリティシステム２００のイベントメカニズム２１０によれば、クライアント３００は、ＵＩにおけるプロパティ変更、コントロールのストラクチャにおけるツリー変更、マルチメディアイベント、および関連情報についてイベント通知を受け取るように登録することが可能となる。これらの能力がなければ、クライアント３００は、情報、ストラクチャ、または状態が変化したかどうかを知るために、システム内のすべてのＵＩ要素を継続的にポーリングしなければならない。また、アクセシビリティシステム２００のイベントメカニズム２１０によれば、クライアント３００は、プロセス外のイベントを受け取ること、プロパティ集（プロパティコレクション)がイベント通知とともに返されるように要求すること、および複数の要素に関するイベントに対する登録をすることが可能となる。

イベントメカニズム２１０は、ＡＴ製品またはテストアプリケーションがイベントに対して登録を行うために使用するインタフェース、ＡＴ製品がイベント通知を受け取るために使用されるオブジェクトに対して実装するインタフェース、およびコントロール実装者（制御メーカー）がＵＩイベントをイベントエンジンに通知するために使用するインタフェースを公開する。イベントメカニズム２１０は、ＵＩをレンダリングするために使用されるＵＩエンジンとは独立にＡＴ製品およびテストアプリケーションがイベントを受け取ることを可能にするとともに、ＡＴ製品およびテストアプリケーションが基盤テクノロジにかかわらずトップレベルのアプリケーションウィンドウおよびフォーカスを追跡することを可能にする。

該当する場合には、イベントは、アプリケーションの論理要素ツリー２２２からの論理要素に関連づけられる。論理要素が該当しない場合、イベントは、イベントのソースを表現する、人間が読める文字列等の周知のオブジェクトに関連づけられる。イベントメカニズム２１０は、イベント登録中に、ユーザが与えた選好に基づいてフィルタリングを行う。イベント関連データを作成してそれをクロスプロセスでクライアントに送る前に、クライアントのフィルタリング選好をサーバで使用することによって、イベントメカニズム２１０は、クロスプロセスコールの数を削減することによりプロセス外パフォーマンスを本質的に改善する。イベントメカニズム２１０は、イベント登録中に、イベントに対して関心のある論理要素のプロパティを指定する方法を提供する。これがクロスプロセスコールの数をさらに削減する。イベントメカニズム２１０は、オペレーティングシステム（ＯＳ）の重大な変更を必要とせずに拡張可能である。イベントメカニズム２１０は、マネージド(managed)コードを用いて実装されてもよいが、アンマネージド(unmanaged)アプリケーションがＣＯＭインターオペラビリティを通じてそれにアクセスすることも可能である。

イベントメカニズム２１０によれば、クライアントは多数のタイプのイベントの通知を受け続けることができる。イベントのタイプの１つにトップレベルウィンドウイベントがある。トップレベルウィンドウイベントは、メニューおよびコンボボックスのドロップダウン等の、デスクトップを親とする機能に関連するイベントを含む。もう１つのタイプのイベントとして、フォーカスイベントがある。クライアント３００は、フォーカスを追跡するメソッドをしばしば必要とする。さらなるイベントのタイプとして、プロパティ変更イベントおよび論理ストラクチャ変更イベントがある。プロパティ変更イベントは、論理要素のプロパティが変更される時に発火する。論理ストラクチャ変更イベントは、論理要素ツリーストラクチャが変更される時に発火する。

イベントは、コントロールパターンから発火させることも可能である。コントロールパターンから発火するイベントは拡張可能でなければならないので、これらのイベントはＧＵＩＤによって識別される。登録時には任意のＧＵＩＤ値が受け入れられる。任意の新しいコントロールパターンに対して、それがドキュメント化するイベントは一意のＧＵＩＤでなければならない。ＡＴ製品は、新しいコントロールパターンイベントをリスンするように修正されなければならないことがある。また、リスナは、これらのイベントを探索することができなければならない。例えば、管理されたテストでは、これらのイベントを、特定のアプリケーションまたはアプリケーション内のコントロールに制限したいかもしれない。コントロールパターンはソースが何であるかを定義し、イベントコンシューマは、ソース要素およびイベント引数オブジェクトの使用法を知るために、ドキュメンテーションのその部分を参照することが必要となる。

もう１つのタイプのイベントとしてマルチメディアイベントがある。マルチメディアとしては、サウンド、ビデオ、およびアニメーションがあり得る。メソッドは、マルチメディアイベントをサポートし、「停止」、「一時停止」、「早送り」、「巻戻し」、および「消音」等のアクションをクライアントに通知する。シンプルサウンドイベントは、マルチメディアイベントとは別個に扱われてもよい。シンプルサウンドイベントは、そのサウンド自体以外の何らかのイベントをユーザに伝えるために存在する単純な短時間のサウンドを表す。シンプルサウンドイベントとしては、新着メールの到着時に再生されるサウンド、ラップトップのバッテリが低下した時に発生されるサウンド、またはメッセージボックスがIconExclamation（アイコン感嘆符）タイプで表示される時に再生されるサウンドがあり得る。

もう１つのタイプのイベントとしてソフトフォーカスイベントがある。ソフトフォーカスイベントは、デスクトップに現れるがバックグラウンドに常駐する。ソフトフォーカスイベントの例としては、通知エリアに「新規更新が利用可能です」と示すバルーン（balloon）ヘルプウィンドウ、フォーカスを獲得したいバックグラウンドアプリケーションのためのタスクバー内の点滅アイコン、および印刷の開始・終了時に通知トレイ(tray)で出現・消滅するプリンタアイコンがある。これらのイベントは、他のイベントカテゴリと多少重複するように思われるかもしれない（マルチメディアはソフトフォーカスと同様にアニメーションイベントを含み得る）。しかし、イベントは、それがどのように伝えられるかではなく、それが何をユーザに伝えるかに基づいて分類される。

クライアント側ＡＰＩ３１０およびプロバイダ側ＡＰＩ４４０は、上記で列挙したイベントのタイプをサポートするイベント通知のメソッドを提供する。これらのメソッドについて、図８〜図１０に関連して以下でさらに説明する。

コントロールパターン
アクセシビリティモデルは、特定のＵＩ要素またはコントロールによってサポートされる機能を分類および公開する独自の手法を提供する。アクセシビリティモデルは、従来技術のように機能を特定のコントロールタイプ（例えば、ボタン、エディットボックス、またはリストボックス）に関連づけるのではなく、それぞれがＵＩ動作の一側面(一態様)を定義する共通コントロールパターンのセットを定義する。これらのパターンは互いに独立であるので、特定のＵＩ要素によってサポートされる機能の完全なセットを記述するように結合することができる。

例えば、アクセシビリティシステム２００は、Buttonのようなクラス名によって要素を記述する代わりに、呼出し可能なコントロールパターンをサポートするものとして要素を記述する。コントロールパターンは、要素によってサポートされるストラクチャ、プロパティ、イベント、およびメソッドを定義する。したがって、これらのパターンは、クライアントがコントロールの動作を問い合わせることを可能にするだけでなく、クライアントが特定のパターンのために設計されたインタフェースを使用することによってコントロールをプログラムで操作することも可能にする。例えば、SelectionContainerパターンは、選択された項目に対して問合せを行うメソッド、特定の項目の選択もしくは選択解除を行うメソッド、またはコントロールが単一もしくは複数の選択モードをサポートしているかどうかを判定するメソッドを提供する。

アクセシビリティシステム３００に対して現在定義されているコントロールパターンとしては、（１）Selection Container（セレクションコンテナ）、（２）Hierarchy（階層）、（３）Invokable（呼出し可能）、（４）Simple Grid（単純グリッド）、（５）Text（テキスト）、（６）Value（値）、（７）Represents Object（オブジェクト表現）、（８）Scrollable（スクロール可能）、（９）Sortable（ソート可能）、（１０）Drawing（描画）、および（１１）Other Container（他のコンテナ）がある。

この技法によれば、コントロール開発者は、新しいタイプのコントロールを実装しながら、しかもその動作をＡＴ製品およびテストスクリプトに公開するための明確な手法を有することができる。新しいタイプの動作を導入する場合、必要な機能を表すように新しいコントロールパターンを定義することができる。

こうして、支援テクノロジ製品およびテストスクリプトは、各ＵＩコントロールではなく各パターンを扱う方法を理解するように書くことができる。コントロールクラスに比べてコントロールパターンの数ははるかに少ないため、この技法は、必要なコードを最小限にする。また、この手法は、新しいコントロールについて（それが周知のコントロールパターンをサポートする限り）効果的に問い合わせて操作することができる、よりフレキシブルなアーキテクチャを促進する。

次の表は、共通コントロールおよびそれがサポートするパターンのいくつかの例を与える。

共通コントロールパターンに関連する機能を公開するために、より具体的なインタフェースが使用される。これらのパターンの例としては、（１）セレクション管理コンテナ、（２）グリッド配置コンテナ、（３）値を含むＵＩ要素、（４）オブジェクト（ファイル、電子メール等）を表すアイコン、および（５）呼び出され得るＵＩ要素がある。一般的に、これらのパターンは特定のコントロールに緊密に結びついておらず、異なるコントロールが同じパターンを実装してもよい。例えば、リストボックス、コンボボックス、およびツリービューはすべて、「セレクション管理コンテナ」パターンを実装する。コントロールには、適宜複数のパターンを実装するものがあってもよい。セレクショングリッドは、「グリッド配置コンテナ」パターンおよび「セレクション管理コンテナ」パターンの両方を実装する。

従来のアプリケーションの場合のように、単一の「ロール(role)」プロパティはない。代わりに、２つの別個のメカニズムが使用される。コントロールパターンが、コントロールの利用可能な機能を決定し、人間が読めるローカライズ可能な（localizable）プロパティが、「ボタン」、「リストボックス」等のようにユーザが理解可能なコントロールタイプ名を提供する。

システムＡＰＩ
図８は、本発明の一実施形態におけるクライアント側ＡＰＩ３０５の詳細を示している。クライアント側ＡＰＩ３０５は、コアクラス３１０のセットを含み得る。コアクラス３１０は、１つまたは複数のオートメーションクラス３１２、論理要素クラス３１４、およびraw要素クラス３１６を含み得る。クライアント側ＡＰＩ３０５は、さらに、１つまたは複数のコントロールパターンクラス３２０、入力クラス３４０、および補助クラス３５０を含み得る。これら各タイプのクラスについて以下でさらに説明する。

クライアントオートメーションクラス３１２は、クライアント３００に対するＵＩオートメーションメソッドを提供する。クライアントオートメーションクラス３１２は、いかなるＵＩ要素にも固有でないメソッドを含む。クライアントオートメーションクラス３１２は、ポイント、ウィンドウハンドル、またはデスクトップルート要素から論理要素またはraw要素を取得するメソッドを提供することができる。クライアントオートメーションクラス３１２は、さらに、論理要素に基づく入力基準を求めるメソッドを提供することができる。また、クライアントオートメーションクラス３１２は、好ましくは、イベント通知の登録および登録解除を行うメソッドも含む。また、オートメーションクラス３１２は、好ましくは、プロキシ(proxy)ＤＬＬをロードするヘルパ(helper)関数、プロパティおよびコントロールパターンのローカライズ名を取得するヘルパ関数、ならびに要素比較を実行するヘルパ関数も提供する。また、クライアントオートメーションクラス３１２は、クライアント３００がイベントをリスンするためのメソッドも含む。オートメーションクラス３１２によって提供されるいくつかのメソッドを次の表にまとめる。

動作において、クライアント３００がアプリケーションに関するユーザに対する情報を取得する必要がある場合、クライアント３００は、押下するボタンを探索し、そのボタン上のテキストを確認する。クライアント３００は、上記の表２に示される論理要素を見つけるメソッド（FindLogicalElement）のようなメソッドを呼び出してもよい。クライアント側ＡＰＩ３０５は、クライアント側インタフェース２２０の論理ツリー２２２内の位置を基準とする値を返す（return）。論理ツリー２２２を通じて、アクセシビリティシステム２００は、使用中のアプリケーションにかかわらず、ＵＩの抽象的ビューをクライアント３００に与える。抽象モデルとしては、ストラクチャ、プロパティ、イベントや、リストボックス、ボタン等のＵＩコンポーネントが互いに共有していることが期待できる機能がある。

クライアント側ＡＰＩ３０５は、さらに、論理要素クラス３１４を含み得る。論理要素クラス３１４は、要素の共通プロパティを取得するためのフィールド、メソッドおよびプロパティを提供し得る。上記のように、論理要素は、境界長方形、フォーカス、イネーブル、クリッカブルポイント、ランタイムおよび永続(persistent)識別子、ならびに名前のような、論理ツリー２２２内のＵＩ要素を表現する。また、論理要素クラス３１４は、最初の子、最後の子、次の兄弟、および親のような要素間をナビゲートするためのツールも提供し得る。また、論理要素クラス３１４は、要素の特定のパターンを取得するツール、または要素によってサポートされるすべてのパターンを取得するツールも提供し得る。論理要素クラス３１４は、論理要素ツリー２２２内の要素に対して使用されるフィールド、プロパティ、およびメソッドを含む。

クライアント側ＡＰＩ３０５は、さらに、raw要素クラス３１６を含み得る。raw要素クラス３１６は、raw要素ツリー内を移動するための同様の技法を提供する。raw要素クラス３１６は、raw要素ツリー内の要素にアクセスするために使用されるフィールド、プロパティおよびメソッドを含む。

クライアント側ＡＰＩ３０５は、さらに、入力クラス３４０を含む。入力クラス３４０は、マウス、キーボードおよびその他のタイプの入力をシミュレートするために使用可能である。入力クラス３４０によれば、キーボード、ペンおよびマウスのような入力メソッドによるプログラム入力が可能となる。例示的な入力クラスを次の表に示す。

クライアント側ＡＰＩ３０５は、さらに、ＵＩオートメーションコントロールパターンクラス３２０を含む。ＵＩオートメーションコントロールパターンクラス３２０は、論理要素によって公開された特定の機能へのプログラムでのアクセスのためのフィールド、プロパティおよびメソッドを公開することができる。ＵＩオートメーションコントロールパターンクラス３２０は、ユーザがＵＩアクセシビリティシステム２００において定義されるコントロールパターンと相互作用するのを助ける。例えば、アプリケーションウィンドウパターン(application window pattern)メソッドは、アプリケーションをプログラムで扱うための機能を公開する。この機能は、子ウィンドウの配置やアプリケーション内のツールバー、メニュー、スクロールバー、およびシステムメニューを表す論理要素の位置判定を可能にし得る。

コントロールパターンクラス３２０は、アプリケーションウィンドウパターン（ApplicationWindowPattern）クラスを含み得る。ApplicationWindowPatternクラスは、トップレベルアプリケーションウィンドウに通常関連する動作および情報を公開する。クライアント３００は、このクラスを用いて、アプリケーションのマルチドキュメントインタフェース（ＭＤＩ）子(children)を並べて表示(tile)または重ねて表示(cascade)すること、タスクバー上のそのボタンを見つけること、およびツールバーやメニューのようなそのユーザインタフェースの周知のセクションを位置判定することができる。次の表は、本発明の一実施形態のApplicationWindowPatternクラスを示している。

また、コントロールパターンクラス３２０は、要素のコンテンツを表示または非表示にするためのメカニズムを提供する、要素の展開および折りたたみを行うクラス（ExpandCollapsePattern）も含み得る。ExpandCollapsePatternクラスは、ExpandCollapseパターンに対するラッパークラスとして作用する。ExpandCollapsePatternクラスは、展開（表示）または折りたたみ（非表示）が可能なコンテンツを操作するためにクライアント３００によって使用されるフィールド、プロパティおよびメソッドを含む。次の表は、ExpandCollapsePatternクラスの一実施形態を示している。

また、コントロールパターンクラス３２０は、クライアント３００が、発見された項目がグリッドの一部であるかどうかを迅速に判定することを可能にするグリッドアイテムパターン（GridItemPattern）クラスも含み得る。項目がグリッドの一部である場合、GridItemPatternクラスは、その項目が行／列の座標および範囲に関してグリッド内のどこにあるかを判定するのを助ける。GridItemPatternクラスは、好ましくは、グリッド内のセルの機能を公開するコントロールを操作するためにクライアント３００によって使用されるフィールド、プロパティおよびメソッドを含む。次の表は、本発明の一実施形態によるGridItemPatternクラスを示している。

また、コントロールパターンクラス３２０は、TreeViewコントロール内の要素のように互いに階層関係を有する要素を表現する階層項目パターン（HierarchyItemPattern）クラスも含み得る。HierarchyItemPatternクラスは、論理ツリー２２２内でのＵＩ要素の関係とは独立に、ＵＩ要素間の階層関係を公開するコントロールを操作するためにオートメーションクライアント３００によって使用されるフィールド、プロパティおよびメソッドを含む。次の表は、本発明の一実施形態によるHierarchyItemPatternクラスを示している。

また、コントロールパターンクラス３２０は、関連する単一の明瞭なアクションを有するオブジェクトを表現する呼出しパターン（InvokePattern）クラスも含み得る。関連するＵＩコンポーネントの例としては、プッシュボタン、ハイパーリンク、メニュー項目、ラジオボタン、およびチェックボックスがある。InvokePatternクラスは、呼び出された時に単一の明瞭なアクションを発生させる要素を操作するためにオートメーションクライアント３００によって使用されるフィールド、プロパティおよびメソッドを含む。次の表は、本発明の一実施形態による例示的なInvokePatternクラスを示している。

また、コントロールパターンクラス３２０は、マルチビューパターン要素に対するラッパークラス（wrapper class）として働くマルチビューパターン（MultipleViewPattern）クラスも含み得る。マルチビューパターン要素は、１つの情報セットの複数の表現の間で切替可能な要素である。MultipleViewPatternクラスは、同じ情報セットの複数の表現の間で切替を行うための機能を有する要素を操作するためにオートメーションクライアント３００によって使用されるフィールド、プロパティおよびメソッドを含む。次の表は、本発明の一実施形態によるMultipleViewPatternクラスを示している。

コントロールパターンクラス３２０は、さらに、有限範囲内の値を管理するコントロールの能力を反映する、関連するプロパティのセットを公開するレンジバリューパターン（RangeValuePattern）クラスを含み得る。RangeValuePatternクラスは、コントロールの有効な最小値および最大値ならびにその現在値を伝える。RangeValuePatternクラスは、要素の現在値およびレンジバリューを得るためにオートメーションクライアント３００によって使用されるフィールド、プロパティおよびメソッドを含む。次の表は、本発明の一実施形態によるRangeValuePatternクラスを示している。

また、コントロールパターンクラス３２０は、見える領域を変更することが可能なＵＩ要素を表現するスクロールパターン（ScrollPattern）クラスも含み得る。ScrollPatternクラスは、スクロールによってその可視領域の部分を変更する能力を有する要素を操作するためにオートメーションクライアント３００によって使用されるフィールド、プロパティおよびメソッドを含む。次の表は、本発明の一実施形態によるScrollPatternクラスを示している。

また、コントロールパターンクラス３２０は、セレクションを管理するコンテナを表すセレクションパターン（SelectionPattern）クラスも含み得る。関連するセレクション項目パターン（SelectionItemPattern）クラスが、選択および選択解除可能な要素を操作するためにクライアント３００によって使用されるフィールド、プロパティおよびメソッドを含む。次の表は、本発明の一実施形態による例示的なSelectionPatternクラスおよびSelectionItemPatternクラスを示している。

また、コントロールパターンクラス３２０は、ソートパターン（SortPattern）クラスも含み得る。SortPatternクラスは、サブ要素をソートすることが可能なコンテナ要素を操作するためにオートメーションクライアントによって使用されるフィールド、プロパティおよびメソッドを含む。次の表は、本発明の一実施形態によるSortPatternクラスを示している。

また、コントロールパターンクラス３２０は、値を表すＵＩ要素を表現する値パターン（ValuePattern）クラスも含み得る。ValuePatternクラスは、関連する値を有する要素を操作するためにクライアント３００によって使用されるフィールド、プロパティおよびメソッドを含む。次の表は、本発明の一実施形態によるValuePatternクラスを示している。

コントロールパターンクラス３２０は、さらに、ユーザに情報を伝えているイメージまたはアニメーションに関する情報を表すために使用可能なビジュアル情報パターン（VisualInformationPattern）クラスを含み得る。VisualInformationPatternクラスは、ユーザに情報を伝えているイメージまたはアニメーションを有する要素を操作するためにオートメーションクライアント３００によって使用されるフィールド、プロパティおよびメソッドを含む。次の表は、本発明の一実施形態によるVisualInformationPatternクラスを示している。

コントロールパターンクラス３２０は、さらに、ウィンドウパターンのラッパークラスとして作用するウィンドウパターン（WindowPattern）クラスを含み得る。WindowPatternクラスは、ユーザのデスクトップ上のウィンドウを操作するためにオートメーションクライアント３００によって使用されるフィールド、プロパティおよびメソッドを含む。次の表は、本発明の一実施形態によるWindowPatternクラスを示している。

また、クライアント側ＡＰＩ３０５は、補助クラス３５０も含み得る。補助クラスは、イベントメカニズムおよび入力機能を使用するためのヘルパクラスとともに、プロパティ、イベント、およびパターン識別子を表現する複数のクラスを含み得る。

補助クラス３５０は、オートメーション識別子（AutomationIdentifier）クラスを含み得る。AutomationIdentifierクラスは、オブジェクト識別に基づく識別子の基本クラスである。このクラスは、派生クラス（derived class）のみがインスタンス化(instantiate)されるので、事実上は抽象クラスである。補助クラス３５０は、さらに、アクセシビリティシステム２００におけるイベントを識別するために使用されるタイプを表現するオートメーションイベント（AutomationEvent）クラスを含み得る。また、補助クラス３５０は、アクセシビリティシステム２００におけるコントロールパターンを識別するために使用されるタイプを表現するオートメーションパターン（AutomationPattern）クラスも含み得る。補助クラス３５０は、さらに、アクセシビリティシステム２００におけるプロパティを識別するために使用されるタイプを表現するオートメーションプロパティ（AutomationProperty）クラスを含み得る。

補助クラス３５０は、さらに、イベントとともに使用されるコントロールパターンまたはカスタムイベント引数を表現するオートメーションイベント引数（AutomationEventArgs）クラスを含み得る。クライアント３００は、カスタムイベントとともにこのクラスのインスタンスを受け取る。AutomationEventArgsは、クライアント３００にオートメーションイベントに関する情報を送るために使用される。

また、補助クラス３５０は、ＵＩイベントとともに使用されるオートメーションプロパティ変更イベント引数（AutomationPropertyChangedEventArgs）クラスも含み得る。クライアント３００は、プロパティ変更イベントとともにこのクラスのインスタンスを受け取る。AutomationPropertyChangedEventArgsは、クライアント３００にプロパティ変更イベントに関する情報を送るために使用される。

補助クラス３５０は、さらに、論理ストラクチャ変更イベント引数（LogicalStructureChangedEventArgs）クラスを含み得る。LogicalStructureChangedEventArgsクラスは、論理ツリー変更イベントとともにこのクラスのインスタンスをクライアント３００に提供するために、ＵＩイベントとともに使用され得る。LogicalStructureChangedEventArgsは、クライアント３００に論理ストラクチャ変更に関する情報を送るために使用される。

補助クラス３５０は、さらに、トップレベルウィンドウイベント引数（TopLevelWindowEventArgs）クラスを含み得る。これは、カスタムイベントとともにこのクラスのインスタンスをクライアント３００に提供するために、ＵＩイベントとともに使用され得る。TopLevelWindowEventArgsは、クライアント３００にトップレベルウィンドウイベントに関する情報を送るために使用される。トップレベルウィンドウとは、その親がデスクトップであるウィンドウである。「開いている(opened)」という用語の使用は、新しいトップレベルウィンドウがユーザに対して現れていることを示す。「閉じている(closed)」という用語の使用は、トップレベルウィンドウが破棄・無効化（destroy）されていることを示す。

補助クラス３５０は、さらに、ツリーロードイベント引数（TreeLoadEventArgs）クラスを含み得る。TreeLoadEventArgsクラスは、ＵＩイベントとともに使用されるカスタムイベント引数クラスである。クライアント３００は、ツリーロードイベントとともにこのクラスのインスタンスを受け取ることができる。TreeLoadEventArgsは、クライアント３００にツリーロードイベントに関する情報を送るために使用され得る。

補助クラス３５０は、さらに、入力関連メソッドに対する定数を提供するVKeysクラスを含み得る。また、補助クラス３５０は、NoClickablePointExceptionも含み得る。この例外は、クリッカブルポイントにおける論理要素内でエラーが発生した時に投げられる。エラーは、境界長方形が空である時、幅もしくは高さがない時、またはそのポイントにおける論理要素が変更された時に発生し得る。

また、補助クラス３５０は、イベント通知を受け取るためのいくつかのクラスも含み実装し得る。フォーカス変更イベント引数（FocusChangedEventArgs）クラスは、クライアントにフォーカス変更イベントに関する情報を送るために使用され得る。

図９に示すように、プロバイダ側ＡＰＩ４４０は、プロバイダオートメーションクラス４４２、プロバイダオートメーションインタフェース４４８およびプロバイダraw要素インタフェース４５０を含む。また、プロバイダ側ＡＰＩ４４０は、コントロールパターンプロバイダインタフェース４６０および補助クラス４８０も含み得る。補助クラス４８０および３５０は、プロパティ識別子、イベント識別子、パターン識別子ならびに長方形やポイントを表すクラスのような基本タイプ等の情報を使用および通信するためにタイプを共有してもよい。他の特徴は、プロバイダ補助クラス４８０またはクライアント補助クラス３５０に固有であってもよい。例えば、Vkeysクラスは、クライアント補助クラス３５０としてのみ予約されてもよい。

プロバイダオートメーションクラス４４２は、好ましくは、図１０に示すようなオートメーションインターオペラビリティプロバイダ（AutomationInteropProvider）クラス５０２を含む。AutomationInteropProviderクラス５０２は、Ｗｉｎ３２またはサードパーティのオートメーション実装とともにアクセシビリティシステム２００によって使用されるメソッドを含み得る。AutomationInteropProviderクラス５０２は、Ｗｉｎ３２またはサードパーティのＵＩオートメーションプロバイダ側実装によって使用されるプロパティおよびメソッドを含む。次の表は、本発明の一実施形態によるAutomationInteropProviderクラス５０２を示している。

オートメーションプロバイダ（AutomationProvider）クラス５００は、Windows Client Platformとともにアクセシビリティシステム２００によって使用され得るメソッドを含む類似のクラスである。

また、プロバイダ側ＡＰＩ４４０は、プロバイダオートメーションインタフェース４４８も含む。プロバイダオートメーションインタフェース４４８は、アクセシビリティシステム２００がデフォルトで公開するプロパティ以外に追加プロパティを公開するためにＷｉｎ３２またはサードパーティのプロバイダによって実装されるオートメーションプロパティインターオペラビリティプロバイダ（IAutomationPropertyInteropProvider）インタフェース４４７を含み得る。プロバイダオートメーションインタフェース４４８は、さらに、オートメーションプロパティプロバイダ（IAutomationPropertyProvider）インタフェース４４９を含み得る。このインタフェース４４９はインタフェース４４７に類似しているが、デフォルトでアクセシビリティシステム２００によって公開されるプロパティ以外のプロパティを公開するためにネイティブWindows Client Platformプロバイダによって実装されることが可能である。

プロバイダraw要素インタフェース４５０は、raw要素プロバイダ（IRawElementProvider）インタフェース４５６を含み得る。IRawElementProviderインタフェース４５６は、ネイティブWindows Client Platform、Ｗｉｎ３２またはサードパーティのプロバイダによって実装され、最初の子、最後の子、次の兄弟および親のような関係要素を返すため、ならびに特定のまたはすべてのネイティブおよびＵＩオートメーションプロパティを返すためにアクセシビリティシステム２００によって呼び出されるメソッドを定義する。IRawElementProviderインタフェース４５６は、さらに、コントロールパターンに対するプロバイダオブジェクトを返す。IRawElementProviderインタフェース４５６は、アクセシビリティシステム２００によって実装され、特定の要素に関連する機能についてプロバイダと相互作用する。IRawElementProviderインタフェース４５６の一実施形態の一例を下記の表に与える。

もう１つのプロバイダraw要素インタフェース４５０として、raw要素コンテクストインターオペラビリティプロバイダ（IRawElementContextInteropProvider）インタフェース４５２があり得る。インタフェース４５２は、Ｗｉｎ３２またはサードパーティのプロバイダによって実装され得る。インタフェース４５２は、特定の要素に関連しないイベントおよび他の機能を管理するために使用され得る。さらにもう１つのraw要素インタフェース４５０として、raw要素コンテクストプロバイダ（IRawElementContextProvider）インタフェース４５８があり得る。これは、ネイティブWindows Client Platformプロバイダによって実装され、特定の要素に関連しないイベントおよび他の機能を管理するために使用され得る。IRawElementContextProviderインタフェース４５８の一実施形態を下記の表に示す。

また、プロバイダ側ＡＰＩ４４０は、コントロールパターンプロバイダインタフェース４６０も含み得る。各コントロールパターンは、アクセシビリティシステム２００にコントロールパターンを公開するオブジェクトによって実装されるプロバイダインタフェース４６０を有する。例えば、アプリケーションウィンドウプロバイダ（IApplicationWindowProvider）インタフェースは、アプリケーションのトップレベルウィンドウに関連する動作および情報を公開する。下記のコントロールパターンプロバイダインタフェース４６０は、ＨＷＮＤに基づくプロバイダおよびサードパーティのプロバイダによって実装可能なインターオペラビリティプロバイダ（InteropProvider）インタフェースを含む。また、コントロールパターンプロバイダインタフェース４６０は、Windows Client Platformプロバイダによってネイティブに実装可能なプロバイダインタフェースも含み得る。

コントロールパターンプロバイダインタフェース４６０は、さらに、アプリケーションウィンドウプロバイダ（IApplicationWindowProvider）インタフェースを含み得る。IApplicationWindowProviderまたはIApplicationWindowInteropProviderインタフェースは、トップレベルアプリケーションウィンドウに通常関連する動作および情報を公開し得る。このインタフェースは通常、アプリケーションのメインウィンドウを操作するための機能を公開するためにプロバイダによって実装される。

また、コントロールパターンプロバイダインタフェース４６０は、展開・折りたたみプロバイダ（IExpandCollapseProvider）インタフェースまたはIExpandCollapseInteropProviderインタフェースも含み得る。このインタフェースは、コントロールがより多くのコンテンツを表示するための展開またはコンテンツを非表示にするための折りたたみを行う能力を公開し得る。IExpandCollapseProviderインタフェースは、ツリー型動作を提供するためのHierarchyItemパターン（後述）とともにサポートされてもよいが、開く、および閉じる個々のコントロールにも関連がある。ツールバー、コンボボックス、およびメニューのようなＵＩ要素が、関連する実装を含み得る。

コントロールパターンプロバイダインタフェース４６０は、さらに、グリッドプロバイダ（IGridProvider）インタフェースまたはIGridInteropProviderインタフェースを含み得る。IGridProviderインタフェースは、グリッドサイズおよび指定されたセルへの情報の移動を含む基本グリッド機能を公開する。

グリッド項目プロバイダ（IGridItemProvider）またはIGridItemInteropProviderが、もう１つのコントロールパターンプロバイダインタフェース４６０を提供し得る。IgridItemProviderインタフェースは、グリッド内にある項目を表現する。このインタフェースは、メソッドなしで、プロパティのみを含んでもよい。IGridItemProviderまたはIGridItemInteropProviderインタフェースは、グリッド内のセルの機能を公開するコントロールを操作するための機能を公開するためにプロバイダによって実装される。

コントロールパターンプロバイダインタフェース４６０は、さらに、階層項目プロバイダ（IHierarchyItemProvider）またはIHierarchyItemInteropProviderインタフェースを含み得る。IHierarchyItemProviderまたはIHierarchyItemInteropProviderインタフェースは、論理ツリー２２２内でのＵＩ要素の関係とは独立に、ＵＩ要素間の階層関係を公開し、クライアント３００がその関係内を移動することを可能にする。階層関係は、定義により非巡回的である。このインタフェースを実装し得るＵＩ要素としては、メニューおよびリストビューコントロールがある。

もう１つのコントロールパターンプロバイダインタフェース４６０として、呼出しプロバイダ（IInvokeProvider）またはIInvokeInteropProviderインタフェースがあり得る。呼出しプロバイダインタフェースは、関連する単一の明瞭なアクションを有するオブジェクトによって実装され得る。これらのオブジェクトは通常ステートレスであり、それらを呼び出すことはそれら自身の状態を変更しないが、アプリケーションの、より大きいコンテクストの変化を引き起こす。IInvokeProviderインタフェースを実装し得るＵＩ要素としては、プッシュボタンおよびハイパーリンクメニュー項目がある。

マルチビュープロバイダ（IMultipleViewProviderまたはIMultipleViewInteropProvider）インタフェースが、もう１つのコントロールパターンインタフェース４６０を提供する。マルチビュープロバイダインタフェースは、情報、データ、または子の同じセットの複数の表現の間の切替を行う要素の能力を公開し得る。このパターンは、コンテンツのカレントビューを制御するコンテナに対して実装されるべきである。

また、コントロールパターンプロバイダインタフェース４６０は、レンジバリュープロバイダ（IRangeValueProvider）または（IRangeValueInteropProvider）インタフェースも含み得る。レンジバリュープロバイダインタフェースは、有限範囲内の値を管理するコントロールの能力を反映する、関連するプロパティのセットを公開し得る。このインタフェースは、コントロールの有効な最小値および最大値ならびにその現在値を伝え得る。このインタフェースを実装し得るＵＩ要素としては、プログレスバー（progress bar）およびスクロールバー上の数値スピナ(spinner)がある。

もう１つのコントロールパターンプロバイダインタフェース４６０として、スクロールプロバイダ（IScrollProviderまたはIScrollInteropProvider）インタフェースが提供され得る。このインタフェースは、コントロールがそのコンテンツをスクロールすることによってユーザに可視となる可視領域の部分を変更する能力を公開する。このインタフェースは、コントロールの可視領域より大きいコンテンツエリアを保持するリストボックス、ツリービュー等のコンテナのように、コンテンツをスクロールするＵＩ要素を表現する。IscrollInteropProviderインタフェースの一実施形態を下記の表に与える。

もう１つのコントロールパターンプロバイダインタフェース４６０として、識別による選択プロバイダ（ISelectionByIDProviderまたはISelectionByIDInteropProvider）インタフェースがある。このインタフェースは、それが含む項目間の選択を提供するコンテナ要素を表す。識別による選択プロバイダインタフェースは、論理要素の子を持たないコントロールのためのプロバイダ側インタフェースである。クライアントにとっては、同じメソッドが、このコントロールが論理要素を子として有するかのように見えるであろう。このインタフェースは、プロバイダが、選択または選択解除可能なコンテナ内の要素を操作するための機能を公開することを支援するように実装される。このインタフェースの一実施形態を下記の表に与える。

また、コントロールパターンプロバイダインタフェース４６０は、セレクションプロバイダ（ISelectionProviderまたはISelectionInteropProvider）インタフェースも含み得る。セレクションプロバイダインタフェースは、セレクションを管理するコンテナを表すことができ、選択可能な要素を含む要素を操作するための機能を公開するためにプロバイダによって実装される。このインタフェースの一実施形態を次の表に示す。

コントロールパターンプロバイダインタフェース４６０は、さらに、セレクション項目プロバイダ（ISelectionItemProviderまたはISelectionItemInteropProvider）インタフェースを含み得る。このインタフェースは、選択可能項目を定義し、それを選択または選択解除することができるようにその機能を公開し得る。

また、コントロールパターンプロバイダインタフェース４６０は、ソートプロバイダ（ISortProviderまたはISortInteropProvider）インタフェースも含み得る。このインタフェースは、コンテナの現在のソート順序を公開し、クライアントがプログラムでその要素を再ソートすることを可能にする。

コントロールパターンプロバイダインタフェース４６０によれば、値プロバイダ（IValueProviderまたはIValueInteropProvider）インタフェースが、関連する値を有する要素を表現し操作するために実装され得る。

コントロールパターンプロバイダインタフェース４６０には、ユーザに情報を伝えているイメージまたはアニメーションに関する情報を表すために、ビジュアル情報プロバイダ（IVisualInformationProviderまたはIVisualInformationInteropProvider）インタフェースが含まれ得る。

また、コントロールパターンプロバイダインタフェース４６０には、ウィンドウプロバイダ（IWindowProviderまたはIWindowInteropProvider）インタフェースも含まれ得る。このインタフェースは、要素がそのスクリーン上の位置またはサイズを変更する能力、ならびにビジュアル状態を変更する能力およびそれを閉じる能力を公開することができる。このインタフェースの一例を下記の表に与える。

また、プロバイダ側ＡＰＩ４４０は、補助クラス４８０も含み得る。補助クラス４８０は、クライアント側ＡＰＩ３０５内で利用されるものと実質的に同一であってもよい。上記のように、クライアントおよびプロバイダが補助クラスを共有してもよい。この特徴について、図１０に関連してさらに説明する。

図１０は、クライアント側ＡＰＩ３０５、アクセシビリティシステムコア２０1
、およびサーバ側ＡＰＩ４４０の間のインタラクションを示している。クライアントアプリケーション３００は、アクセシビリティシステムコア２０１を通じて情報を取得するために、オートメーションクラス３１２、論理要素クラス３１４、raw要素クラス３１６またはコントロールパターンクラス３２０を実装する。また、クライアントアプリケーション３００は、クライアント補助クラス３５０および入力クラス３４０も実装し得る。

図１０は、Ｗｉｎ３２ Run１２を用いた実装Ａ（１０）およびＷＣＰ runを用いた実装Ｂ（２０）とともにプロバイダ側ＡＰＩ４４０を示している。実装Ａは、オートメーションインターオペラビリティプロバイダインタフェース５０２、raw要素プロバイダインタフェース４５６、raw要素コンテクストインターオペラビリティプロバイダインタフェース４５２、およびコントロールパターンインタフェース４６０を必要に応じて使用する。実装Ｂは、オートメーションプロバイダ５００、raw要素プロバイダインタフェース４５６、オートメーションプロパティプロバイダインタフェース４４８、raw要素コンテクストプロバイダインタフェース４５８、およびコントロールパターンインタフェース４６０を必要に応じて使用する。実装１０および２０は両方とも、プロバイダ補助クラス４８０を利用してもよい。上記のように、プロバイダ補助クラスは、クライアント補助クラス３５０と実質的に同一であってもよく、または、共有補助クラス５１０によって示されているようにクライアント補助クラス３５０とタイプを共有してもよい。上記のように、共有補助クラス５１０は、クライアントとプロバイダがプロパティ識別子、パターン識別子、およびイベント識別子のような情報を通信するために共有するタイプを含み得る。

動作において、クライアント側ＡＰＩ３０５は、クライアント３００が論理ツリーを取得することを可能にする。機能としては、（１）ポイントからポイントへの論理要素、（２）イベントからの論理要素、および（３）現在フォーカスのある論理要素がある。上記のように、論理要素はＵＩコンポーネントを表し、場合により、コントロール、コントロールの一部、またはコンテナあるいは論理グルーピング（すなわち、ダイアログ、ペイン、またはフレーム）を表す。コントロールは、その機能に関して多様であり得る。したがって、特定のタイプのコントロールに関連する機能を表すために異なるインタフェースが使用される。しかし、これらのコントロール固有のインタフェースは、すべてのコントロールに共通の機能を表す共通基本インタフェースから派生する。共通基本インタフェースはコアクラス３１０を含む。コアクラス３１０は、（１）論理ツリー２２２内をナビゲートするメソッド、（２）プロパティ値を取得する一般的メソッド、および（３）サポートされているコントロール固有のインタフェースにアクセスするメソッドを含む。論理ツリー２２２内をナビゲートする場合、それぞれの基盤アプリケーションのＵＩテクノロジがそれ自身のナビゲーション技法を提供する。

アプリケーションにおいてアクセシビリティシステムイベントの使用を開始するには、クライアント３００は、次のいずれかを行えばよい：（１）オートメーションクラス３１２からの「AddTopLevelWindowEventHandler」メソッドを用いて、デスクトップ上に現れる新しいＵＩを発見し、そのイベントに対するハンドラにおいて、他のイベントに対する登録を行い、これにより、任意のプロセスからのイベントを受け取る；（２）オートメーションクラス３１２からの「Find」メソッドのうちの１つを用いて、関心のあるＵＩを位置判定し、特定のＵＩをターゲットとする；（３）ウィンドウハンドルやスクリーン上のポイントを見つける等、オートメーションクラス３１２からの他の何らかのメソッドを用いて関心のあるＵＩを発見し、そのハンドルまたはポイントを用いて、イベントをリスンするための基準として使用する論理要素を獲得する；または（４）オートメーションクラス３１２からの「AddFocusChangedEventHandler」メソッドを用いて入力フォーカスを追跡し、現在フォーカスを有しているＵＩ上のイベントに対して登録を行う。

クライアント側ＡＰＩ３０５およびサーバ側ＡＰＩ４４０は、クライアント３００のニーズを満たすように動作する。以下の例は、クライアントがどのようにクライアント側ＡＰＩ３０５を使用し、その後、サーバ側ＡＰＩ４４０がユーザインタフェース情報をクライアント３００に提供するためにどのように呼び出されるかを示すために提供される。

トップレベルウィンドウイベントとしては、メニューおよびコンボボックスのドロップダウンに関連するイベントや、デスクトップを親とする任意のフィーチャ(feature:機能)がある。本発明の一実施形態では、トップレベルウィンドウが開くことおよび閉じることの通知を受け取るために、AddTopLevelWindowEventHandlerメソッドが使用される。AddTopLevelWindowEventHandlerを呼び出すと、カレントデスクトップ上で新しいトップレベルウィンドウが開くこと、またはトップレベルウィンドウが閉じることの通知が得られる。RemoveTopLevelWindowEventHandlerメソッドは、デスクトップ上でトップレベルウィンドウが開くこと、または閉じることの通知を受け取ることを停止するためのメカニズムを提供する。このメソッドは、このリスナを識別するためにコールバックオブジェクト（callback object）を使用する。したがって、RemoveTopLevelWindowEventHandlerメソッドに渡されるオブジェクトは、AddTopLevelWindowEventHandlerに渡されたものと同一である。開かれるそれぞれの新しいトップレベルウィンドウごとに、メソッドがプロバイダ側ＡＰＩ４４０から呼び出される。同様に、トップレベルウィンドウが閉じた時に一度、メソッドがアクセシビリティシステム２００によって呼び出され得る。これらの通知を受け取るには、クライアント３００は、AddTopLevelWindowEventHandlerメソッドを呼び出す。

もう１つのタイプのイベントとして、フォーカスイベントがある。クライアント３００は、フォーカスを追跡するメソッドをしばしば必要とする。これをMicrosoft Windows ＯＳで行うことは困難である。例えば、メニュー（例えばMicrosoft WordにおけるFile（ファイル）メニュー）がドロップダウンされる時、メニュー内の項目は、ユーザが各項目にカーソルを移動して下って行くにつれてフォーカスを得る。メニューが閉じる時（例えばユーザがＥＳＣキーを押す）、現在では、送られるフォーカスイベントはない。代わりに、フォーカス変更に関心のあるクライアントは、いくつかのイベントをリスンして、それらのうちのいずれがフォーカス変更を論理的に表現しているかを見出さなければならない。本発明の一実施形態では、フォーカス変更イベントをリスナに通知するために、オートメーションクラス３１２からのAddFocusChangedEventHandlerメソッドを使用することができる。クライアント３００は、このメソッドおよび他のイベント登録メソッドを用いて返されるプロパティのセットを指定することができる。クライアント３００は、フォーカス変更の通知を受け取ることを停止するためにRemoveFocusChangedEventHandlerメソッドを呼び出すことができる。このメソッドは、このリスナを識別するためにコールバックオブジェクトを使用し得る。この場合、RemoveFocusChangedEventHandlerメソッドに渡されるオブジェクトは、AddFocusChangedEventHandlerプロシージャ（procedure）に渡されたものと同一となる。アクセシビリティシステム２００は、クライアント３００に通知するために、フォーカスが変化した時にプロバイダ側オートメーションクラス４４２からのRaiseFocusChangedEventのようなメソッドを呼び出すことができる。

プロパティ変更イベントは、論理要素のプロパティが変化する時に発火する。本発明の一実施形態では、クライアント３００は、プロパティ変更の通知を受け取るために、オートメーションクラス３１２からのAddPropertyChangedEventHandlerメソッドを呼び出す。アクセシビリティシステム２００は、AddPropertyChangedEventHandlerで指定された論理要素ツリー内の論理要素でプロパティの値が変化した時にプロバイダ側ＡＰＩ４４０からのプロバイダ側メソッドを呼び出す。スコープパラメータが、どの要素についてイベントが発火すべきかを示す。例えば、ウィンドウのルート論理要素および子孫に対する要求を渡すことは、プロパティ変更コールバックをそのウィンドウに限定する。スコープパラメータがツリー内の全要素に設定されている場合、スコープは無視され、デスクトップ上で発生する指定されたプロパティに対する任意の変更が送られる。クライアント３００は、異なるプロパティのセットおよび／または異なるコールバックオブジェクトを用いてAddPropertyChangedEventHandlerを複数回呼び出してもよい。アクセシビリティシステム２００によって提供される通知は、変化したプロパティ、新しいプロパティ値、および利用可能であれば古いプロパティ値を示す。クライアント３００は、プロパティ変更の通知を受け取ることを停止するためにRemovePropertyChangedEventHandlerメソッドを呼び出すことができる。このメソッドは、スコープ要素およびコールバックオブジェクトを用いてこのリスナを識別することができる。この場合、渡されるオブジェクトはAddPropertyChangedEventHandlerに渡されたものと同一でなければならない。プロバイダオートメーションクラス４４２は、オートメーションプロパティ変更をクライアント３００に通知するためのRaiseAutomationPropertyChangedEventメソッドを含む。

クライアントオートメーションクラス３１２からのAddAutomationEventHandlerメソッドは、クライアント３００がコントロールに対するイベントを受け取ることを可能にする。スコープパラメータは、どの要素に対してイベントを発火させるべきかを示すために使用可能である。例えば、ウィンドウのルート論理要素および要求側の子孫を渡すことは、イベントをそのウィンドウに限定する。ツリー内の全要素が要求される場合、デスクトップ上の全イベントが送られる。RemoveAutomationEventHandlerメソッドを用いて、コントロールに対するイベントを受け取ることを停止することができる。このメソッドは、リスナを識別するためにスコープ要素、コールバックオブジェクトおよびイベント識別子を使用することができる。この場合、渡されるオブジェクトは、AddAutomationEventHandlerメソッドに渡されたものと同一でなければならない。プロバイダオートメーションクラス４４２は、イベントをクライアント３００に通知するためのRaiseAutomationEventメソッドを含む。

クライアントアプリケーション３００がAddAutomationEventHandlerメソッドを呼び出すと、アクセシビリティシステム２００は、コントロール固有のイベントが発火しイベントのソースがAddAutomationEventHandlerで指定された論理要素ツリー内の論理要素である場合に、プロバイダ側ＡＰＩ４４０からのメソッドを呼び出す。コントロールに対するイベントが発火する時、イベント固有の情報が利用可能なことが多い。イベントを受け取ることを停止するために、RemoveAllEventHandlersメソッドを呼び出すことができる。これは、クライアントアプリケーションがシャットダウンする前にクリーンアップを行う迅速な方法である。この削除メソッドは、アプリケーション終了時に使用するのが最適であろう。

論理要素ツリーストラクチャが変化する時、論理ストラクチャ変更イベントが発火する。AddLogicalStructureChangedEventHandlerメソッドが、論理要素ツリーにおけるストラクチャ変更の通知を受け取るために実装され得る。論理要素が追加、削除または無効化される時、指定されたコールバックオブジェクトに対するメソッドが呼び出される。論理要素ツリー変更のイベントを受け取ることを停止するために、RemoveLogicalStructureChangedEventHandlerメソッドを呼び出すことができる。このメソッドは、このリスナを識別するためにコールバックオブジェクトおよびスコープ要素を使用することができる。この場合、渡されるオブジェクトはAddAutomationEventHandlerに渡されたものと同一でなければならない。プロバイダオートメーションクラス４４２は、論理ストラクチャ変更をクライアント３００に通知するためのRaiseLogicalStructureChangedEventメソッドを含む。

ＵＩオートメーションサーバまたはプロバイダ側ＡＰＩ４４０は、サーバまたは基盤ＵＩエンジンがプロパティ変更通知を遂行するために呼出し得るメソッドを含む。サーバ４００は、ＵＩが変化した時に適切なパラメータを生成するためにこれらの通知メソッドを呼び出すことができる。

以上、本発明を特定実施形態に関連して説明したが、これらの実施形態はすべての点において限定的ではなく例示的であることを意図している。本発明の範囲から逸脱することなく、本発明が関係する技術分野の当業者には、代替実施形態は明らかとなるであろう。

以上の記載から理解されるように、本発明は、上記のすべての目標および目的を、本システムおよび方法に固有の明らかな他の利点とともに、達成するのに適している。いうまでもなく、いくつかの特徴およびサブコンビネーション(sub-combination:小結合、副結合)が有益であり、他の特徴およびサブコンビネーションとは無関係に使用され得る。これは特許請求の範囲で考慮されている。

本発明の実施において使用するのに好適なコンピューティングシステム環境のブロック図である。 アクセシビリティシステム、クライアント環境、およびサーバ環境の間のインタラクションのブロック図である。 アクセシビリティシステムコアのコンポーネントを示すブロック図である。 ネイティブ要素からの論理ツリーの作成を示す図である。 ネイティブ要素からの論理ツリーの作成を示す図である。 ネイティブ要素からの論理ツリーの作成を示す図である。 ネイティブ要素からの論理ツリーの作成を示す図である。 論理ツリーを構築する手続きのシーケンスを示すフローチャートである。 論理要素を形成するダイアログボックスおよびそのコンポーネントを示す図である。 本発明のイベントメカニズムをアクティベートすることに関与する手続きを示すフローチャートである。 本発明の一実施形態におけるクライアント側ＡＰＩを示すブロック図である。 本発明の一実施形態におけるサーバ側ＡＰＩを示すブロック図である。 本発明のアクセシビリティシステムの一実施形態を用いたクライアントとサーバの間のインタラクションを示す図である。 イベント通知のための周知のシステムを示す図である。

Claims (64)

1. ユーザインタフェース情報をクライアントに提供するアクセシビリティシステムにおいて使用するためのツールのシステムにおいて、該アクセシビリティシステムがクライアント側およびプロバイダ側を含み、
   ユーザインタフェース情報を求めるためのクライアントオートメーションクラスを含むクライアント側オートメーションツールであって、該クライアントオートメーションクラスがイベント登録ツールおよび論理要素発見ツールを含む、クライアント側オートメーションツールと、
   ユーザインタフェース情報を前記クライアントに提供するプロバイダ側オートメーションツールであって、イベント情報を前記クライアントに提供するツールを有するオートメーションプロバイダクラスを含む、プロバイダ側オートメーションツールと
   を備えたことを特徴とするツールのシステム。
2. ユーザインタフェース要素を表現するクライアント側論理要素ツールをさらに備えたことを特徴とする請求項１に記載のシステム。
3. raw要素ツリー内の要素を表現するクライアント側raw要素ツールをさらに備えたことを特徴とする請求項２に記載のシステム。
4. 入力をシミュレートするメソッドを提供するクライアント側入力クラスをさらに備えたことを特徴とする請求項１に記載のシステム。
5. マウス入力およびキーボード入力をシミュレートするツールをさらに備えたことを特徴とする請求項４に記載のシステム。
6. 前記クライアントがアクセシビリティシステムコントロールパターンと相互作用（interact）することを可能にするクライアント側コントロールパターンクラスをさらに備えたことを特徴とする請求項２に記載のシステム。
7. 前記クライアント側コントロールパターンクラスが、アプリケーションのメインウィンドウに関連する情報を公開(expose)するアプリケーションウィンドウパターンクラスを含むことを特徴とする請求項６に記載のシステム。
8. 前記クライアント側コントロールパターンクラスが、表示することおよび非表示にすることが可能なコンテンツを操作するための展開・折りたたみパターンクラスを含むことを特徴とする請求項６に記載のシステム。
9. 前記クライアント側コントロールパターンクラスが、項目（item）がグリッドの一部であるかどうかを発見するためのグリッド項目クラスを含むことを特徴とする請求項６に記載のシステム。
10. 前記クライアント側コントロールパターンクラスが、論理ツリー内でのＵＩ要素の関係とは独立なＵＩ要素間の階層関係を公開するＵＩ要素を表現するための階層項目パターンクラスを含むことを特徴とする請求項６に記載のシステム。
11. 前記クライアント側コントロールパターンクラスが、単一の関連するアクションを有するオブジェクトを表現する呼出し(invoke)パターンクラスを含むことを特徴とする請求項６に記載のシステム。
12. 前記クライアント側コントロールパターンクラスが、複数の表現の間の切替が可能な要素を操作するためのマルチビューパターンクラスを含むことを特徴とする請求項６に記載のシステム。
13. 前記クライアント側コントロールパターンクラスが、コントロールの最小値および最大値を公開するためのレンジバリューパターンクラスを備えたことを特徴とする請求項６に記載のシステム。
14. 前記クライアント側コントロールパターンクラスが、スクロールにより可視性の変更が可能な要素を操作するためのスクロールパターンクラスを備えたことを特徴とする請求項６に記載のシステム。
15. 前記クライアント側コントロールパターンクラスが、選択および選択解除が可能なコンテナ内の要素を操作するためのセレクションパターンクラスを備えたことを特徴とする請求項６に記載のシステム。
16. 前記クライアント側コントロールパターンクラスが、サブ要素をソートすることが可能なコンテナ要素を操作するためのソートパターンクラスを備えたことを特徴とする請求項６に記載のシステム。
17. 前記クライアント側コントロールパターンクラスが、値を表すユーザインタフェース要素を表現するバリューパターンクラスを備えたことを特徴とする請求項６に記載のシステム。
18. ユーザデスクトップ上のウィンドウを操作するためのウィンドウパターンクラスをさらに備えたことを特徴とする請求項６に記載のシステム。
19. 追加機能を実行する補助ツールをさらに備えたことを特徴とする請求項１に記載のシステム。
20. 追加プロパティを公開するためのプロバイダ側オートメーションインタフェースをさらに備えたことを特徴とする請求項１に記載のシステム。
21. raw要素ツリーからの関係要素を返すプロバイダraw要素インタフェースをさらに備えたことを特徴とする請求項１に記載のシステム。
22. 定義済みコントロールパターンに関連する動作および情報を公開するためのコントロールパターンプロバイダインタフェースをさらに備えたことを特徴とする請求項１に記載のシステム。
23. ユーザインタフェース情報をクライアントに提供するアクセシビリティシステムに実装されるクライアント側ツールのシステムにおいて、該アクセシビリティシステムが、プロバイダ側から該クライアント側へユーザインタフェース情報を転送するメカニズムと、ユーザインタフェース情報を選択的に公開する論理ツリーを含み、該クライアント側ツールが、
    前記プロバイダ側からユーザインタフェースイベント情報を求めるクライアントオートメーションクラスを含むクライアント側オートメーションメカニズムと、
    前記論理ツリー内のユーザインタフェース要素を表現する論理要素クラスを含むクライアント側論理要素メカニズムと
    を備えたことを特徴とするクライアント側ツールのシステム。
24. 前記クライアントオートメーションクラスが、オートメーションイベントハンドラを追加するツールおよび該オートメーションイベントハンドラを削除するツールを備えたことを特徴とする請求項２３に記載のシステム。
25. 前記クライアントオートメーションクラスが、オートメーションプロパティ変更イベントハンドラを追加するツールおよび該オートメーションプロパティ変更イベントハンドラを削除するツールを備えたことを特徴とする請求項２３に記載のシステム。
26. 前記クライアントオートメーションクラスが、フォーカス変更イベントハンドラを追加するツールおよびフォーカス変更イベントハンドラを削除するツールを備えたことを特徴とする請求項２３に記載のシステム。
27. 前記クライアントオートメーションクラスが、トップレベルウィンドウイベントハンドラを追加するツールおよびトップレベルウィンドウイベントハンドラを削除するツールを備えたことを特徴とする請求項２３に記載のシステム。
28. 前記クライアントオートメーションクラスが、論理ストラクチャ変更イベントハンドラを追加するツールおよび該論理ストラクチャ変更イベントハンドラを削除するツールを備えたことを特徴とする請求項２３に記載のシステム。
29. 前記クライアントオートメーションクラスが、論理要素を見つけるためのツールおよびraw要素を見つけるためのツールを備えたことを特徴とする請求項２３に記載のシステム。
30. raw要素ツリー内の要素を表現するクライアント側raw要素クラスをさらに備えたことを特徴とする請求項２３に記載のシステム。
31. 前記論理要素クラスが、要素によってサポートされるすべてのパターンを取得するためのツールをさらに備えたことを特徴とする請求項２３に記載のシステム。
32. 入力をシミュレートするメソッドを提供する入力クラスをさらに備えたことを特徴とする請求項２３に記載のシステム。
33. 前記入力がマウス入力およびキーボード入力を含むことを特徴とする請求項３２に記載のシステム。
34. ユーザインタフェース情報をクライアントに提供するアクセシビリティシステムに実装されるプロバイダ側ツールのシステムにおいて、該アクセシビリティシステムが、該プロバイダ側から該クライアントへユーザインタフェース情報を転送するメカニズムと、ユーザインタフェース情報を選択的に公開する論理ツリーを含み、該プロバイダ側ツールが、
    前記クライアントにイベント通知を提供するツールを含むプロバイダ側オートメーションクラスと、
    ユーザインタフェースプロパティを公開するプロバイダ側オートメーションインタフェースと、
    特定の関係要素に関連する情報を返すraw要素インタフェースと、
    特定の要素に関連しないイベントおよび機能を管理するraw要素コンテクストインタフェースと
    を備えたことを特徴とするプロバイダ側ツールのシステム。
35. 前記プロバイダ側オートメーションクラスが、オートメーションイベントを発生するためのツールを含むことを特徴とする請求項３４に記載のシステム。
36. 前記プロバイダ側オートメーションクラスが、プロパティ変更イベントを発生するためのツールを含むことを特徴とする請求項３４に記載のシステム。
37. 前記プロバイダ側オートメーションクラスが、フォーカス変更イベントを発生するためのツールを含むことを特徴とする請求項３４に記載のシステム。
38. 前記プロバイダ側オートメーションクラスが、論理ストラクチャ変更イベントを発生するためのツールを含むことを特徴とする請求項３４に記載のシステム。
39. コントロールパターンプロバイダインタフェースをさらに備えたことを特徴とする請求項３４に記載のシステム。
40. 前記コントロールパターンプロバイダインタフェースが、トップレベルアプリケーションウィンドウに関連する動作および情報を公開するためのアプリケーションウィンドウプロバイダインタフェースを含むことを特徴とする請求項３９に記載のシステム。
41. 前記コントロールパターンプロバイダインタフェースが、コンテンツを非表示にし、および表示するための展開・折りたたみインタフェースを含むことを特徴とする請求項３９に記載のシステム。
42. 前記コントロールパターンプロバイダインタフェースが、基本グリッド機能を公開するためのグリッドプロバイダインタフェースを含むことを特徴とする請求項３９に記載のシステム。
43. 前記コントロールパターンプロバイダインタフェースが、前記クライアントがユーザインタフェース要素間の階層関係内を行き来する（traverse）ことを可能にする階層項目プロバイダインタフェースを含むことを特徴とする請求項３９に記載のシステム。
44. 前記コントロールパターンプロバイダインタフェースが、単一アクションを実行するオブジェクトによって使用される呼出しプロバイダインタフェースを含むことを特徴とする請求項３９に記載のシステム。
45. 前記コントロールパターンプロバイダインタフェースが、オブジェクトが複数の表現の間の切替を行う能力を公開するためのマルチビュープロバイダインタフェースを含むことを特徴とする請求項３９に記載のシステム。
46. 前記コントロールパターンプロバイダインタフェースが、有限範囲の値を管理する能力を可能にするプロパティのセットを公開するためのレンジバリュープロバイダインタフェースを含むことを特徴とする請求項３９に記載のシステム。
47. 前記コントロールパターンプロバイダインタフェースが、可視領域を変更する能力を公開するためのスクロールプロバイダインタフェースを含むことを特徴とする請求項３９に記載のシステム。
48. 前記コントロールパターンプロバイダインタフェースが、項目間の選択を提供する要素を公開するための識別による選択プロバイダを含むことを特徴とする請求項３９に記載のシステム。
49. 前記コントロールパターンプロバイダインタフェースが、セレクションを管理するコンテナを表現するためのセレクションプロバイダインタフェースを含むことを特徴とする請求項３９に記載のシステム。
50. 前記コントロールパターンプロバイダインタフェースが、サイズおよび位置を変更する能力を公開するためのウィンドウプロバイダインタフェースを含むことを特徴とする請求項３９に記載のシステム。
51. アクセシビリティシステムを通じてクライアントにユーザインタフェース情報を提供するアプリケーションプログラムインタフェースシステムにおいて、該アクセシビリティシステムが、プロバイダ側から該クライアント側へユーザインタフェース情報を転送するメカニズムと、ユーザインタフェース情報を選択的に公開する論理ツリーを含み、
    前記クライアントがユーザインタフェース情報を取得することを支援するクライアント側アプリケーションプログラムインタフェースであって、オートメーションクラス、論理要素クラス、raw要素クラス、コントロールパターンクラス、および入力クラスを含むクライアント側アプリケーションプログラムインタフェースと、
    クライアント要求に応答するプロバイダ側アプリケーションプログラムインタフェースであって、プロバイダオートメーションクラス、プロバイダオートメーションインタフェース、raw要素インタフェース、およびコントロールパターンプロバイダインタフェースを備えたプロバイダ側アプリケーションプログラムインタフェースと
    を備えたことを特徴とするアプリケーションプログラムインタフェースシステム。
52. 前記プロバイダ側および前記クライアント側によって使用される補助クラスをさらに備えたことを特徴とする請求項５１に記載のシステム。
53. アクセシビリティシステムを通じてクライアントにユーザインタフェース情報を提供するコンピュータ実施方法において、該アクセシビリティシステムが、プロバイダ側から該クライアント側へユーザインタフェース情報を転送するメカニズムと、ユーザインタフェース情報を選択的に公開する論理ツリーを含み、
    前記クライアントがユーザインタフェース情報を取得することを支援するクライアント側アプリケーションプログラムインタフェースを提供することであって、該クライアント側アプリケーションプログラムインタフェースが、オートメーションクラス、論理要素クラス、raw要素クラス、コントロールパターンクラス、および入力クラスを含む、クライアント側アプリケーションプログラムインタフェースを提供すること、および
    クライアント要求に応答するプロバイダ側アプリケーションプログラムインタフェースを提供することであって、該プロバイダ側アプリケーションプログラムインタフェースが、プロバイダオートメーションクラス、プロバイダオートメーションインタフェース、raw要素インタフェース、およびコントロールパターンプロバイダインタフェースを備えた、プロバイダ側アプリケーションプログラムインタフェースを提供すること
    を含むことを特徴とするコンピュータ実施方法。
54. 前記プロバイダ側および前記クライアント側によって使用される補助クラスを提供することをさらに含むことを特徴とする請求項５３に記載の方法。
55. アクセシビリティシステムを通じてクライアントにユーザインタフェース情報を提供するコンピュータ実施方法において、該アクセシビリティシステムが、プロバイダ側から該クライアント側へユーザインタフェース情報を転送するメカニズムと、ユーザインタフェース情報を選択的に公開する論理ツリーを含み、
    選択されたイベントハンドラを用いてクライアントオートメーションクラスに対してユーザインタフェース情報を要求すること、および
    対応するイベント発生メソッドを用いてユーザインタフェースイベント通知を提供するためのプロバイダオートメーションクラスを呼び出すこと
    を含むことを特徴とするコンピュータ実施方法。
56. ユーザインタフェース要素情報を取得するために論理要素ツールを使用することをさらに含むことを特徴とする請求項５５に記載の方法。
57. raw要素ツリー内の要素に関するraw要素情報を取得するためにクライアント側raw要素ツールを使用することをさらに含むことを特徴とする請求項５５に記載の方法。
58. 入力をシミュレートするメソッドを提供するクライアント側入力クラスを利用することをさらに含むことを特徴とする請求項５５に記載の方法。
59. マウス入力およびキーボード入力をシミュレートすることをさらに含むことを特徴とする請求項５８に記載の方法。
60. 前記クライアントがアクセシビリティシステムコントロールパターンと相互作用することを可能にするクライアント側コントロールパターンクラスを使用することをさらに含むことを特徴とする請求項５５に記載の方法。
61. 追加機能を実行する補助ツールを実装することをさらに含むことを特徴とする請求項５５に記載の方法。
62. 追加プロパティを公開するためのプロバイダ側オートメーションインタフェースを利用することをさらに含むことを特徴とする請求項５５に記載の方法。
63. raw要素ツリーからの関係要素を返すプロバイダraw要素インタフェースを実装することを含むことを特徴とする請求項５５に記載の方法。
64. 定義済みコントロールパターンに関連する動作および情報を公開するためのコントロールパターンプロバイダインタフェースを実装することをさらに含むことを特徴とする請求項５５に記載の方法。

Images