JP2006501566A - ユーザインターフェース情報へのアクセスを提供するためのシステムおよび方法 - Google Patents

Abstract

クライアントにユーザインターフェース情報を提供するための方法およびシステムについて述べる。クライアントにユーザインターフェース情報を提供するためのアクセシビリティシステム。このアクセシビリティシステムは、ユーザインターフェース自動化サービスとＡＰＩとを含むアクセシビリティシステムコアを備える。ユーザインターフェース自動化ツールは、ユーザインターフェース情報がクライアントにとって関心のあるものかどうかに基づいて情報をフィルタリングする。アクセシビリティシステムは追加で、クライアントにとって関心のあるユーザインターフェース情報を見えるようにすると共にクライアントにとって関心のないユーザインターフェース情報を隠すための論理ツリーを含むクライアント側インターフェースを備える。アクセシビリティシステムはまた、サーバ側の技術にかかわらずサーバ側からの情報転送を容易にするためのサーバ側インターフェースも備える。

Description

本発明は、支援技術（ａｓｓｉｓｔｉｖｅ ｔｅｃｈｎｏｌｏｇｙ）製品および自動テスト製品、ならびにこれらの製品とユーザインターフェース情報との対話の分野に関する。

支援技術（ＡＴ）製品は、学習や、コミュニケーションや、コンピュータソフトウェアに含まれる、またコンピュータソフトウェアによって提示される情報へのアクセスの領域において支援を必要とするコンピュータユーザを補助するために存在する。これらの製品は、コンピュータインターフェースに関連する情報を必要とする。同様に、既存の自動テスト製品およびユーザインターフェースコマンディングユーティリティも、ユーザインターフェースに関する情報を必要とする。現在、これらの製品には、ユーザインターフェース（ＵＩ）情報のソースが十分にない。この３つのタイプの製品（クライアント）は、（１）アプリケーションのユーザインターフェースに関する情報を収集すること、（２）ＵＩを構築するために使用されている技術にかかわらずプログラムに基づいてＵＩ要素を発見し問い合わせること、（３）キーボード入力およびポインタ入力を生成すること、（４）どのタイプの挙動または機能が現在利用可能かを理解することを可能にするために、必要なサポートをどこか他の場所から得る必要がある。これらすべての機能をＡＴ製品に提供する現在利用可能な技術は、１つとしてない。さらに、現在のＡＴ製品は、すべてのグラフィカルオペレーティングシステム（ＯＳ）技術に適合するとは限らず、また、余分な通知または誤解を招く通知を一元的にフィルタリングし調整を図ることができない。もう１つの欠点として、現在の自動化およびアクセシビリティインフラストラクチャは拡張可能ではなく、そのため、新しい機能を追加するにはＯＳレベルの変更が必要である。

さらに、現在、アプリケーションのユーザインターフェースに関する情報を収集するには、ＡＴ製品は、ユーザに対する情報を得るためにアプリケーション特有コードを書かなければならない。このアプリケーション特有コードを書くプロセスは、時間がかかり、継続的な保守を必要とする。現在の自動化インフラストラクチャもまた、余分なまたは誤解を招くイベント通知を一貫性のある方式でフィルタリングし調整を図ることができない。そのため、イベントコンシューマが独自に情報をフィルタリングする必要がある。

現在のシステムでは、ＡＴ製品は、イベント通知を３つの細分性レベルで要求することができる。すなわち、（１）デスクトップ上のあらゆるもの、（２）特定のプロセス中（ワードプロセッサの立上げなど）、または（３）特定プロセス中のスレッド中（プロセス中で働いている複数のオブジェクト）である。現在、クライアントがイベントを受け取るとき、クライアントは、イベントが発生した特定のウィンドウに対するウィンドウハンドルと、イベントがどこで発生したかを示すその他の情報ビットとを受け取る。クライアントは、プロセス間呼出しを行って、イベントに関係するＵＩオブジェクトを取り出すことができる。このオブジェクトを使用して、クライアントは、追加のプロセス間呼出しを行ってこのオブジェクトに関する情報を要求することができる。クライアントが５つの情報を必要とする場合、クライアントは５つのプロセス間呼出しを行わなければならない。プロセス間呼出しは非常に遅く、そのため、現在のアクセシビリティインフラストラクチャを使用してＵＩ情報を収集することの性能コストは高い。図８に、このタイプの既知のシナリオを示す。サーバアプリケーション１２がイベント６を発火（ｆｉｒｅ）する。カーネル１４が、どのクライアントが通知を受けなければならないかを決定し、当該のクライアント１０にイベント通知１８を送る。クライアント１０は、イベント通知１８に関係するオブジェクトを求める要求１６を、プロセス境界２をまたいでサーバアプリケーション１２に送る。サーバアプリケーション１２はオブジェクト２０を返し、次いでクライアント１０は、イベントを発火したＵＩコントロールに関する情報を求める要求１６の送信を開始することができる。サーバアプリケーション１２は、要求された情報２０を、プロセス境界２をまたいでクライアント１０に返す。

別の現行オプションでは、クライアントコードをプロセス内のダイナミックリンクライブラリ（．ＤＬＬ）としてロードすることができる。このオプションはいくつかの欠点を有する。第１に、クライアントコードをプロセスにロードするために、システムからの協力を必要とする。第２に、クライアントコードがアプリケーションのプロセスにロードされた後は、それが収集する情報を制限するのが難しいので、セキュリティ問題を引き起こす。第３に、クライアントにとって効果的な技法であるためには、システム上のあらゆるプロセスにロードしなければならない。信用できるクライアントだけを別のアプリケーションのプロセスにロードできるべきであるのが最適である。

さらに、どのイベント通知を受け取りたいかを指定する能力をクライアントに与えるシステムも必要である。知られているシステムでは、クライアントは、いくつかのプロセス間呼出しを行い、次いで情報を分析して、そのイベントに関心があるかどうかを判定することが必要な場合がある。このイベントフィルタリングをより高性能な方式で実施することができ、新しいシステムイベントまたはアプリケーションイベントをサポートするよう容易に更新することができる機構が必要とされている。さらに、セキュリティ問題を軽減するために、信用できるコンポーネントだけを使用するシステムも必要とされている。

現在、ユーザインターフェースに関する情報を探すとき、ＡＴ製品は、特定のＵＩフレームワークにネイティブであるツリーにアクセスする必要がある。そのため、複数のＵＩフレームワークについてのユーザインターフェース情報を伝えるには、複数のツリーが必要である。これらの異なるツリーは、エンドユーザによって操作される可視のＵＩコントロールを管理する隠れたコンテナオブジェクトなど、ユーザにとって関心がないかまたは見えない情報を含む場合がある。したがって、ユーザにとって関心のあるノードだけを有する単一の統合ツリーが存在する必要がある。

ＡＴ製品、自動テストツール、コマンディングユーティリティのニーズに対処する解決法が必要とされている。この解決法は、すべてのグラフィカルＯＳ技術によって使用可能であるべきであり、すべての形のＵＩおよびＵＩコンポーネントをアクセス可能にすることができるべきである。

本発明は、クライアントにユーザインターフェース情報を提供するための方法およびコンピュータアプリケーションを対象とする。本発明の一態様では、クライアントにユーザインターフェース情報を提供するためのアクセシビリティシステムが提供される。アクセシビリティシステムは、ユーザインターフェース情報がクライアントにとって関心のあるものかどうかに基づいて情報をフィルタリングするためのユーザインターフェース自動化サービスを含むアクセシビリティシステムコアを備える。アクセシビリティシステムは追加で、クライアントにとって関心のあるユーザインターフェース情報を見えるようにすると共にクライアントにとって関心のないユーザインターフェース情報を隠すための論理ツリーを含むクライアント側インターフェースも備える。アクセシビリティシステムはまた、サーバ側アプリケーションを構築するために使用されているユーザインターフェースエンジンにかかわらずサーバ側アプリケーションからの情報転送を容易にするための、サーバ側インターフェースも備える。

本発明の別の態様では、クライアントにユーザインターフェース情報を提供するためのコンピュータ実施方法が提供される。この方法は、アクセシビリティシステム自動化サービスによってユーザインターフェース情報を監視すること、および、サーバ側技術にかかわらずサーバ側インターフェースを介してユーザインターフェース情報を転送することを含む。この方法はさらに、クライアント側インターフェースの一部を形成する論理要素ツリーを使用して、クライアントにとって関心のある特定のユーザインターフェース情報を決定することも含む。

本発明の追加の利点および新規な特徴については以下の記述に示すが、その一部は以下の記述を検討すれば当業者には明らかであろうし、あるいは本発明の実施からわかるであろう。

以下、添付の図面を参照しながら本発明を述べる。

図１に、本発明を実施することのできる好適なコンピューティングシステム環境の例１００を示す。コンピューティングシステム環境１００は、好適なコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲についてどんな制限も意味しない。またコンピューティング環境１００は、この例示的な動作環境１００に示すコンポーネントのいずれか１つまたは組合せに関してどんな依存や要件を有するものとも解釈すべきではない。

本発明は、プログラムモジュールなど、コンピュータによって実行されるコンピュータ実行可能命令の一般的なコンテキストで述べることができる。一般にプログラムモジュールは、特定のタスクを実施するか特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、本発明は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な民生用電子機器、ミニコンピュータ、メインフレームコンピュータなどを含めて、その他のコンピュータシステム構成で実施することもできることは、当業者なら理解するであろう。本発明はまた、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実施される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶デバイスを含めたローカルとリモートの両方のコンピュータ記憶媒体に位置することができる。

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

コンピュータ１１０は通常、様々なコンピュータ可読媒体を備える。限定ではなく例として、コンピュータ可読媒体には、コンピュータ記憶媒体および通信媒体を含めることができる。システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。ＲＯＭ１３１には通常、起動中などにコンピュータ１１０内の要素間で情報を転送するのを助ける基本ルーチンを含むＢＩＯＳ（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）１３３が記憶されている。ＲＡＭ１３２は通常、処理ユニット１２０がすぐにアクセス可能な、かつ／または処理ユニット１２０が現在作用している、データおよび／またはプログラムモジュールを含む。限定ではなく例として、図１には、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、プログラムデータ１３７を示す。

コンピュータ１１０は、その他の着脱式／固定式、揮発性／不揮発性のコンピュータ記憶媒体を備えることもできる。例にすぎないが図１には、固定式かつ不揮発性の磁気媒体に対して読み書きするハードディスクドライブ１４１と、着脱式の不揮発性の磁気ディスク１５２に対して読み書きする磁気ディスクドライブ１５１と、ＣＤ ＲＯＭやその他の光媒体など着脱式の不揮発性の光ディスク１５６に対して読み書きする光ディスクドライブ１５５を示す。この例示的な動作環境で使用することのできるその他の着脱式／固定式、揮発性／不揮発性のコンピュータ記憶媒体には、限定しないが磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭなどが含まれる。ハードディスクドライブ１４１は通常、インターフェース１４０などの固定式メモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通常、インターフェース１５０などの着脱式メモリインターフェースでシステムバス１２１に接続される。

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

本発明においてコンピュータ１１０は、リモートコンピュータ１８０など１つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク化された環境で動作することができる。リモートコンピュータ１８０はパーソナルコンピュータとすることができ、図１にはメモリ記憶デバイス１８１しか示していないが、通常はコンピュータ１１０に関して上述した要素の多くまたはすべてを備える。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、その他のネットワークを含むこともできる。

ＬＡＮネットワーキング環境で使用されるときは、コンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用されるときは、コンピュータ１１０は通常、インターネットなどのＷＡＮ１７３を介した通信を確立するためのモデム１７２または他の手段を備える。モデム１７２は内蔵でも外付けでもよく、ユーザ入力インターフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関して示したプログラムモジュールまたはその一部をリモートのメモリ記憶デバイスに記憶することができる。限定ではなく例として、図１には、リモートアプリケーションプログラム１８５がメモリデバイス１８１上にあるものとして示す。図示のネットワーク接続は例示的なものであり、コンピュータ間で通信リンクを確立するための他の手段を使用してもよいことは理解されるであろう。

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

（アクセシビリティシステムの構造）
図２に示すように、アクセシビリティシステム２００は、クライアント環境３００およびサーバ環境４００と対話する。アクセシビリティシステム２００は、図１に関して上述したコンピュータ環境１００内で実施することができる。アクセシビリティシステム２００は、クライアント３００との対話を容易にするためのクライアント側アクセシビリティインターフェース２２０と、サーバ側４００との対話を容易にするためのサーバ側アクセシビリティインターフェース２３０と、アクセシビリティシステムコア２０１とを備える。本発明のアクセシビリティシステム２００は、プログラムに基づいてユーザインターフェース（ＵＩ）にアクセスするための、新しいアプリケーションプログラムインターフェース（ＡＰＩ）、インターフェース、メタファーを提供する。アクセシビリティシステム２００では、アプリケーションが、アプリケーション自体と、アプリケーションが使用する任意のコンポーネントとをアクセス可能にすることができる。

クライアント環境３００は、支援技術（ＡＴ）製品または自動ＵＩテストツールを含むことが好ましい。サーバ側４００は、図２に示す様々な異なる技術を実装することができる。サーバシステム４１０はアダプタ４１２およびコア４１４を含み、これらは第１タイプのＵＩに見ることができるものである。サーバシステム４２０はプロキシコンポーネント４２２およびコントロール４２４を含み、これらはワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから出ているＭｉｃｒｏｓｏｆｔ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ製品で利用可能なＷｉｎ３２ＵＩなど、第２タイプのＵＩに見ることができるものである。サーバシステム４３０はアダプタ４３２および内部ＯＭ４３４を含み、これらは代替の第３タイプのＵＩに見ることができるものである。

図３に示すように、アクセシビリティシステム２００にはイベント機構２１０が備わるが、このイベント機構２１０は、クライアント環境３００との、およびサーバ環境４００との対話を容易にするために、ＵＩ自動化クライアント２０２およびＵＩ自動化サーバ２０４に依拠する。ＵＩ自動化クライアント２０２およびＵＩ自動化サーバ２０４については、後で本発明のイベント機構２１０に関してより詳細に述べる。本発明のアクセシビリティシステム２００は、クライアント（ＡＴ製品）３００に、（１）アプリケーションのユーザインターフェースに関する情報を収集する能力、（２）ＵＩを構築するために使用されている技術にかかわらずプログラムに基づいてＵＩ要素を発見し問い合わせる能力、（３）キーボード入力およびポインタ入力を生成する能力、（４）どのタイプの挙動または機能が現在利用可能かを理解する能力を提供する。アクセシビリティシステム２００では、アプリケーションが、アプリケーション自体およびそのコンポーネントをアクセス可能にすることができる。図２および３に示す構造は、（１）論理ＵＩツリー、（２）コントロールパターン、（３）イベント機構、（４）入力ＡＰＩ（この文書ではカバーされていない）、（５）プロパティを含めた、アクセシビリティシステム２００の５つの主要な面を可能にする。

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

論理ツリー２２２は、ＵＩ要素の基礎的な構造階層がフィルタリングされたビューであり、コントロールまたはアプリケーションの開発者が実装しなければならない別個のツリーではない。そうではなく論理ツリー２２２は、関心あり（ｉｎｔｅｒｅｓｔｉｎｇ）、関心なし（ｕｎｉｎｔｅｒｅｓｔｉｎｇ）という少数の明確なプロパティを符丁とし、これらのプロパティは、構造の要素が論理ツリー２２２中で公開されるべきかどうかを示す。アクセシビリティシステムコア２０１は、この情報を消費してフィルタリング済みＵＩ論理ツリー２２２を生み出し、フィルタリング済み論理ツリー２２２は、ＡＴ製品またはテストスクリプトに提示される。

論理ツリー２２２は要素のツリーであり、各要素はコントロール、コントロール中の項目、またはグループ構造を表し、グループ構造はダイアログ、ペイン、またはフレームとすることができる。論理ツリー２２２の構造は、ユーザによって知覚されるアプリケーションＵＩを表すべきである（コントロールが実際には異なる基礎構造を使用して実装される場合でも）。ツリーは、時が経過しても一定であるべきである。アプリケーションがユーザにとって同じに見える限り、そのアプリケーションを表す論理ツリー２２２は、背後でアプリケーションの実装詳細が変化しても、同じのままであるべきである。Ｍｉｃｒｏｓｏｆｔ ＯＳ製品のシェルの「ＳｈＤｏｃＶｉｅｗ」ウィンドウなど、構造上および実装上の理由で存在するネイティブ要素は、ユーザが知覚しないのでこのツリー中に現れるべきではない。

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

論理ツリー２２２は、知られているシステムの場合のように１つのステップで構築されるのではなく、生ツリーの構築に使用されるフラグメントから構築される。図５に示すように、３つの主要な手順が論理ツリー２２２を構築する。手順７２で、アクセシビリティシステム２００は、基礎をなす技術のネイティブ要素を突き止め、図４（Ａ）に示すネイティブツリーに達する。手順７４で、アクセシビリティシステム２００は、図４（Ｂ）に示すようにネイティブ要素を結合して生ツリー２０を形成する。最後に手順７６で、図４（Ｄ）に示すように、関心を持たれない生ツリー２０中のコンポーネントを隠すことによって論理ツリー２２２が得られる。

図４（Ａ）に、２つのネイティブツリー１０および１４を示す。これらは、Ｗｉｎ３２ＵＩやその他の任意の利用可能なＵＩなど、基礎をなす技術のネイティブ要素から構築される。ネイティブツリー１０は、親ノード１１と、相互に様々な関係を有する複数の子孫１２とを含む。同様に、ネイティブツリー１４は、複数の子ノード１６を有する親ノード１５を含む。子ノード１６は、相互の兄弟として記述することができる。

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

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

アクセシビリティシステム２００は、論理ツリー２２２を使用して、イベントに関する情報、システムの状態、オブジェクトの位置、コントロールに関する情報を見つける。知られているシステムでは、それらのツリー内で範囲指定する機能がなかった。論理ツリー２２２は、クライアント３００の選好に基づいてナビゲートすることができ、使用されているサーバ側アプリケーションにかかわらず情報を提供することができる。

動作時、クライアント３００がユーザのためにアプリケーションに関する情報を得る必要がある場合、クライアント３００は、押すべきボタンを探し、ボタン上のテキストを観察する。クライアント３００は、ＡＰＩ「ｆｉｎｄ ａｎ ｅｌｅｍｅｎｔ（要素を見つける）」を呼び出すことになる。このＡＰＩは、クライアント側インターフェース２２０の論理ツリー２２２中の位置を基準とする値を返す。論理ツリー２２２を介して、アクセシビリティシステム２００は、使用されているアプリケーションにかかわらずＵＩの抽象ビューをクライアント３００に提供する。この抽象モデルは、構造、プロパティ、イベントを含み、また、リストボックス、ボタン、またはその他のＵＩコンポーネントが相互と共通に有すると考えることのできる機能を含む。

論理ツリー２２２は、ＵＩの論理表現である単一の統合ツリーであり、クライアント３００にとって関心のある要素だけを含む形状に形成されている。したがって、ＡＴ製品にＵＩ要素の構造階層をフィルタリングさせて、エンドユーザに提示されるモデルにおいて推測させるのではなく、論理ツリー２２２は、エンドユーザに提示される構造にぴったりマッピングする階層を提示する。このことは、ＵＩをユーザに対して記述するというＡＴ製品のタスクを大幅に単純化し、ユーザがアプリケーションと対話するのを助ける。

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

図６に示すように、「実行」ダイアログで、開発者は、フライングウィンドウグラフィック６２と、６３の「プログラム、フォルダ、文書、またはインターネットリソースの名前を入力して下さい。そうするとＷｉｎｄｏｗｓ（登録商標）がそれを開きます。」とを、関心ありとして指示することができる。開発者はまた、メモ帳、ワード、計算機などを含むコンボボックス６４と、ＯＫ６５、キャンセル６６、閲覧６７のボタンとを、関心ありとして指示することができる。これは、開発者がＵＩアクセシビリティシステム２００を介して自分の要素階層にタグ付けし、それにより自分のアプリケーションのＵＩの論理表現を生み出すための、低コストの機構を開発者にもたらす。図示の各機能は、論理ツリー２２２中で他の各ノードと指定の関係を有するノードによって表すことができる。この論理表現は、テストチームに対して、およびＡＴ製品またはクライアント３００に対して、直接的な利益をもたらす。

クライアント３００は、ＡＰＩのセットによってツリーに達することができる。機能には、（１）ポイントからポイントへの論理要素、（２）イベントからの論理要素、（３）現在フォーカスされている論理要素が含まれる。前述のように、論理要素はＵＩコンポーネントを表し、これは場合により、コントロール、コントロールの一部、あるいはコンテナまたは論理グループ（すなわちダイアログ、ペイン、またはフレーム）である。コントロールは、それらの機能の点で非常に多様である可能性がある。したがって、特定のタイプのコントロールに関連する機能を表すのに、種々のインターフェースが使用される。これらのコントロール特有インターフェースは、すべてのコントロールに共通の機能を表す共通ベースインターフェースから派生する。共通ベースインターフェースは、（１）論理ツリー２２２をナビゲートするためのメソッド、（２）プロパティ値を得るための一般的なメソッド、（３）サポートされるコントロール特有インターフェースにアクセスするためのメソッドを含む。論理ツリー２２２をナビゲートする際には、基礎をなす各アプリケーションＵＩ技術が、それ自体のナビゲーション技術を提供することになる。

ユーザにとって最終的に関心があるのは論理ツリー２２２だが、生要素ツリー２０もまた、いくつかの重要な機能を果たす。論理ツリー２２２はユーザに関係する可能性のある要素だけしか含まないが、生要素ツリー２０は、ノード２２など、基礎をなすフレームワークの実装構造を表すノードも含む。例えばＷｉｎ３２ＵＩフラグメントの場合、このツリーは、ＨＷＮＤを表すノードを含むことになる。いくつかの点で、生要素ツリー２０は、論理要素ツリー２２２と基礎をなすフレームワーク自体のネイティブ要素ツリーとの間の「中間施設」である。生要素ツリー２０は、論理要素ツリー２２２を構築するための基礎として使用されるものであり、ネイティブ要素が最初にシステムにプラグインする場所である。

生要素ツリー２０は、デバッグおよびテストに使用することもできる。これは、問題を含む特定のノードがどこにあるかを正確に示すかまたは記述するのに有用である。ベース生要素ノードに関する機能には、生要素ツリーをナビゲートするためのメソッドと、対応する論理要素（もしあれば）にジャンプするためのメソッドと、例えばＨＷＮＤノードの場合の「ＨＷＮＤ０ｘ４８３ＦＥ」など、この要素に対する「デバッグ文字列」を含むプロパティと、その他の「背後にあるインフラストラクチャ」のメソッドとが含まれる。これらのその他のメソッドは、ヒットテストおよび位置決めと、イベントと、フレームワークが容易に提供することのできるプロパティ（例えばフォーカス（ｆｏｃｕｓｅｄ）、イネーブル（ｅｎａｂｌｅｄ））の公開とを可能にする。

生要素ツリー２０は、様々なレンダリングエンジンからの要素を表すノード２２〜３３を含む。生要素ツリーは、レンダリングエンジンがそれら自体をアクセシビリティシステム２００にプラグインするための開始点として使用され、Ｗｉｎ３２からのＨＷＮＤなどのネイティブ要素を統合論理ツリー２２２に適合させる軽量アダプタオブジェクトから構築される。さらに、ある技術が別の技術をホストする場合に、ホスティング移行を処理するのにも使用される。生要素ツリー２０は論理ツリー２２２が構築されるベースなので、論理ツリー２２２が完全であり接続されていることをチェックするために使用することができ、また、説明のつかない要素があるかどうかチェックするために使用することができる。生要素ツリー２０はさらに、その他のインフラストラクチャのようなタスクに使用することもできる。すなわち、何らかの基本的な要素ＩＤを提供することや、フォーカス、イネーブル、ロケーション（ｌｏｃａｔｉｏｎ）など、フレームワークによって提供される何らかの基本的な要素プロパティを提供することなどである。

生要素ツリー２０は、ＡＴ製品またはクライアント３００のための主要な情報源ではなく、論理ナビゲーションには使用されず、エンドユーザには公開されない。生要素ツリー２０はまた、将来のいずれかの時点で返せるようにツリー中の要素の位置を取り込むために使用することはできない。これらの機能はすべて、論理要素ツリー２２２が実施する。

生要素ツリー２０は通常、表される論理要素がわからなくても、基礎をなすレンダリング技術（ＨＷＮＤ、Ｅｌｅｍｅｎｔ）の生要素から機械的に構築することができる。したがって、これを使用して、論理ツリー２２２中で説明のつかなかった生要素を探すことができる。生要素ツリー２０は、取り込まれるノードの位置の「スタックダンプ」のような記述を可能にするので、有用なデバッグおよび診断ツールである。さらに、知られているシステムでは、システムのツリーはコード特有の基準に基づき、種々の技術で実現するのが難しい。本手法は、一般的な抽象「生要素」型を使用する。これは、基礎をなす任意のレンダリング技術によって、またはそれに代わって実装することができる。

生要素ツリーを得るには、生要素ルートを呼び出すとデスクトップ要素が得られる。この要素は、その親がＮＵＬＬであり他のすべてのノードがそれを究極的な祖先とすることを確実にすることによって検証される。他の要素を得るには、生要素を指定のポイントから得るためのメソッドを呼び出すと、有効な画面座標を使用して要素が返される。生要素ツリーを得た後は、要素（親、兄弟、子）をチェックすることによって、生要素ツリーをチェックおよび検証することができる。

動作時、クライアント３００は、親、次の兄弟、前の兄弟、第１の子、最後の子などの関係を使用して、生要素ツリー２０をナビゲートすることができる。次いでクライアント３００は、生要素から論理ツリー２２２中の対応する論理要素にジャンプすることができる。

（イベント機構）
クライアント３００は、イベントがあり次第その通知を受けたい場合、図３に示すＵＩ自動化クライアント２０２を介して登録して、情報を得ることができる。クライアント３００は、受け取りたいオブジェクト情報と、情報がどこに行くようにしたいかと、返してもらいたいプロパティのリストとを指定する。クライアント要求は、ＵＩ自動化クライアント２０２に行く。ＵＩ自動化クライアント２０２は、デスクトップ上の任意のプロセスを監視することができる。ＵＩ自動化サーバ２０４は、どのクライアント３００がリッスンしているかを常に把握しており、どのようにＵＩ自動化クライアント２０２に返すかを知っている。ＵＩ自動化クライアント２０２はクライアントの関心をＵＩエンジン２０６に勧告し、したがってＵＩエンジン２０６は、いつイベントをＵＩ自動化サーバ２０４に通知するかを知る。ＵＩエンジンは、クライアント勧告を利用しなくてもよく、その代わり、イベントを常にＵＩ自動化サーバ２０４に知らせるか、あるいはクライアントがいずれかのイベントをリッスンしている場合にだけＵＩ自動化サーバに知らせることを選択することもできる。勧告は、イベントをリッスンしているクライアントがある場合にだけＵＩエンジンがＵＩ自動化サーバ通知をオンにしたい場合に、有用である。これは、ＵＩエンジンが、ＵＩの速度低下の可能性を避けるため、および通常なら必要のないコードモジュールをロードするのを避けるために行うことになる。

次いで、ＵＩエンジン２０６は、ＵＩ自動化サーバ２０４にＵＩイベントを通知する。ＵＩ自動化サーバ２０４は、要求された論理要素をクライアント３００に返し、クライアント３００が要求したイベントのプロパティを含めた情報を、クライアント３００に送る。ＵＩ自動化サーバ２０４は、どの情報がクライアント要求の範囲内かを決定し、情報が該当する場合にだけ、論理要素を形成する。論理要素の形成は、クライアントがイベント処理時に使用することになると指示したプロパティのセットを、ＵＩ自動化サーバ側でプリフェッチすることを含む。例えば、ＵＩ自動化サーバ２０４は、コンボボックスの論理要素を発見することができる。範囲は、コンボボックスまたはその子である。クライアント３００は、登録段階の間に、子／親／従属部分を要求して範囲を定義することができる。

ＵＩ自動化サーバ２０４は、情報が要求範囲内かどうかを判定した後、論理要素を構築する。ＵＩ自動化クライアント２０２は、ターゲットアプリケーションに問い合わせ、要求の情報をＵＩ自動化サーバ２０４から受け取り、オブジェクトをクライアント３００上の正しい空間にルーティングすることによって、クライアント３００にサービスする。

ＵＩ自動化サーバ２０４は、クライアント３００がイベント通知の受信に登録したときに生み出される。例えば、ＵＩエンジン２０６がＭｉｃｒｏｓｏｆｔ Ｗｏｒｄワードプロセッシングアプリケーションを実行している。クライアント３００は、名前プロパティの変化に登録済みである。このクライアントの登録により、ＵＩ自動化サーバ２０４が生み出される。クライアントの登録によってまた、ＵＩエンジン２０６は、名前プロパティについてＵＩ自動化サーバ２０４に通知するのを開始するよう勧告される。ＵＩエンジン２０６は、範囲情報は入手しない。ＵＩエンジン２０６は、サーバ側用ＡＰＩのうちの１つを呼び出す。ＵＩエンジン２０６は、（１）どのプロパティが変化したか、（２）プロパティの新しい値、および（３）おそらくは古い値を指定する。ＵＩ自動化サーバ２０４は、クライアント３００にとって関心のあるイベントに基づいて生み出されたのであり、したがって関心のあるイベント、プロパティ、クライアント、範囲を知っており、そのため、作成された論理要素に関心のあるクライアント３００があるかどうかがわかる。複数のクライアント３００が特定のＵＩ自動化サーバ２０４とイベント登録した場合であって、これらのクライアント３００が１つの同じイベントに登録し、返される論理要素と共にプロパティがバルクフェッチされるよう要求した場合は、各クライアント３００は、ＵＩ自動化サーバ２０４がクライアント３００にイベントを送り返したときに、返された論理要素と共に要求のバルクフェッチプロパティの結合を得ることになる。

リッスンしている各クライアント３００に対し、ＵＩ自動化サーバ２０４はクライアント３００に通知して、イベントに関連する論理要素をクライアントに渡す。ＵＩ自動化サーバ２０４は、論理要素を１つだけ生み出す。これは、各クライアント３００がイベントのソースであるオブジェクトの自分用コピーを要求する必要のある現行技術に勝る改良点である。

クライアントがイベントに登録したときにＵＩエンジン２０６がＵＩ自動化クライアントの勧告を利用しない場合、ＵＩエンジン２０６は、リッスンしているアクセシビリティクライアント３００があるかどうかをＵＩ自動化サーバ２０４に尋ねることができ、どれもリッスンしていない場合は、情報を作成してＵＩ自動化サーバ２０４に送る作業を回避することができる。例えば、クライアント３００がスクリーンリーダであり、このスクリーンリーダは、どこに情報が行くようにしたいかと、イベントを受け取るフォーカス変化オブジェクトと、関心のあるプロパティの特定のリストとを指定する。ＵＩエンジン２０６は、勧告を受けて、ＵＩ自動化サーバ２０４にイベントを送るべきであることを知る。フォーカス変化を検出すると、ＵＩエンジン２０６は、ＵＩ自動化サーバ２０４に通知する。ＵＩ自動化サーバ２０４は、周知のインターフェースに変換し、イベントおよびオブジェクトをＵＩ自動化クライアント２０２に送る。ＵＩ自動化クライアント２０２は、オブジェクトをクライアント３００上の適切な空間にルーティングする。

上述のコンポーネントは、カーネル中のイベント用中央リポジトリをなくすことで、知られているシステムよりも改良されている。そうではなくＵＩ自動化サーバ２０４は、それが実行されているコンテキストに関する情報を得ることに関心のあるすべてのクライアント３００を知っている。カーネルリポジトリをなくすことでまた、よりピアツーピアの対話が生み出される。というのは、以前はカーネル中で実施されていた機能を、ＵＩ自動化サーバ２０４が達成するからである。本発明のアクセシビリティシステム２００は、何を見たいかを指定する能力をクライアント３００に与え、それにより、サーバ側でＵＩ自動化サーバ２０４を使用してフィルタリングが達成される。

図７は、イベント登録および通知方法に関連する手順を示すフローチャートである。ステップ８０で、クライアント３００はイベント通知を要求する。ステップ８２で、ＵＩ自動化クライアント２０２はこの要求をＵＩ自動化サーバ２０４に通信する。ステップ８４で、ＵＩ自動化クライアントは、通知が欲しいことをＵＩエンジン２０６に勧告する。ステップ８６で、ＵＩ自動化サーバ２０４はＵＩエンジン２０６から通知を受け取る。ステップ８８で、ＵＩ自動化サーバ２０４は受け取った情報をフィルタリングする。ステップ９０で、受け取った情報がユーザにとって関心のないものであるとわかった場合は、ＵＩ自動化サーバ２０４は情報を廃棄し、ステップ９２で引き続き通知を待機する。あるいは、ステップ９０で情報が関心のあるものであるとわかった場合は、ステップ９４で、ＵＩ自動化サーバ２０４は論理要素を作成し、ＵＩ自動化クライアント２０２に送る。ステップ９６で、ＵＩ自動化クライアント２０２は、受け取った情報をクライアント３００上におけるその正しい位置に配置する。

アクセシビリティシステム２００のイベント機構２１０により、クライアント３００は、ＵＩにおけるプロパティの変化、コントロールの構造におけるツリーの変化、マルチメディアイベント、および関連情報について通知を受け取ることに登録することができる。これらの機能がなければ、クライアント３００は、システム内のすべてのＵＩ要素を絶えずポーリングして、情報、構造、または状態に変化があったかどうか調べなければならない。アクセシビリティシステム２００のイベント機構２１０によってまた、クライアント３００は、プロセス外のイベントを受け取ることができ、プロパティの集まりがイベント通知と共に返されるよう要求することができ、複数の要素に関するイベントに登録することができる。

イベント機構２１０は、ＡＴ製品またはテストアプリケーションがイベントに登録するために使用するインターフェースと、ＡＴ製品がイベント通知の受信に使用されるオブジェクトに対して実装するインターフェースと、制御インプリメンタがＵＩイベントをイベントエンジンに通知するために使用するインターフェースとを公開する。イベント機構２１０は、ＡＴ製品およびテストアプリケーションがＵＩのレンダリングに使用されるＵＩエンジンから独立してイベントを受け取れるようにするために使用され、また、基礎をなす技術にかかわらずＡＴ製品およびテストアプリケーションが最上レベルのアプリケーションウィンドウを追跡してフォーカスできるようにする。

図２に、クライアント３００がどのようにアクセシビリティシステム２００と対話するかを示す。プロセスにまたがる大域的なイベント管理はない。そうではなく、各アクセシビリティシステムクライアント３００またはサーバ４００が、それ自体のコンテキストを有する。クライアントアプリケーションは、アクセシビリティシステム２００をサポートするアプリケーションについてのイベントだけを受け取る。アプリケーション中でアクセシビリティシステムイベントの使用を開始するには、クライアント３００は、以下の４つのうちの１つを行うことができる。すなわち、（１）「ＡｄｄＴｏｐＬｅｖｅｌＷｉｎｄｏｗＬｉｓｔｅｎｅｒ」ＡＰＩを使用して、デスクトップ上およびこのイベントに対するハンドラ中に現れる新しいＵＩを発見し、その他のイベントに登録し、これによって任意のプロセスからイベントを受け取ること、（２）Ｆｉｎｄ ＡＰＩの１つを使用して、関心のあるＵＩを突き止め、特定のＵＩをターゲットにすること、（３）画面上のウィンドウハンドルやポイントを見つけるなど、他の何らかの手段を使用して関心のあるＵＩを発見し、このハンドルまたはポイントを使用して、イベントをリッスンするための参照として使用する論理要素を獲得すること、または（４）「ＡｄｄＦｏｃｕｓＣｈａｎｇｅｄＬｉｓｔｅｎｅｒ」ＡＰＩを使用して、入力フォーカスを追跡し、フォーカスを現在有するＵＩに関するイベントに登録することである。

最上レベルのウィンドウは、デスクトップを親に持つウィンドウである。「開かれた」という語を使用する場合、これは新しい最上レベルウィンドウがユーザに対して表示されたことを示す。「閉じた」という語を使用する場合、これは最上レベルのウィンドウが破壊されたことを示す。

アクセシビリティシステムのサーバ側インターフェース２３０は、追加および削除されるイベントをアクセシビリティシステム２００に通知するための、２つのＡＰＩを含む。ＵＩ自動化クライアントは、クライアントがイベントに登録および登録解除するときにこれらのＡＰＩを呼び出す。これによりＵＩエンジン２０６は、どのアクセシビリティイベントがそのコンテキストで要求されているかに関する情報を得ることができる。

適用可能な場合、イベントは、アプリケーションの論理要素ツリー２２２からの論理要素に関連付けられる。論理要素が適用可能でない場合は、イベントは人間可読の文字列に、またはイベントソースを表すその他の周知のオブジェクトに関連付けられる。イベント機構２１０は、イベント登録中にユーザから供給された選好に基づいてフィルタリングを提供する。イベント関連データを作成してクライアントにプロセス間送信する前に、クライアントのフィルタリング選好をサーバで使用することにより、イベント機構２１０は本質的に、プロセス間呼出しの数を削減することでプロセス外性能を改善する。イベント機構２１０は、イベント登録中に関心のある論理要素のプロパティをそのイベントに対して指定する方法を提供する。これによってさらにプロセス間呼出しの数が削減される。イベント機構２１０は、大きなオペレーティングシステム（ＯＳ）変更を必要とすることなく拡張可能である。イベント機構２１０はマネージコードを使用して実現することができるが、アンマネージアプリケーションは、ＣＯＭ相互運用性を介してそれにアクセスすることができる。

ＡＴクライアント３００がイベントを処理するために実施するタスクは２つある。すなわち、（１）イベント登録、（２）コールバックにおけるイベントの処理である。どちらのタスクにとっても重要な要件は、マネージコードとアンマネージコードの両方で使用可能であることである。本発明の一実施形態では、クライアント３００はイベント登録時にインターフェースを渡すことができる。クライアント３００は、周知のインターフェースを実装するオブジェクトを登録時に渡し、ＵＩエンジン２０６は、これらのインターフェースに対してコールバックして、リスナに通知する。論理要素ツリー２２２中にソースオブジェクトがある場合、各コールバックは、ソース要素および追加のパラメータを受け取る。

ＡＴ製品によって実装される周知のインターフェースが、イベントを返す方法として使用される。以下の章では、いくつかのタイプのイベントと、登録がどのようであるかと、イベントがどのように受け取られるかを示す。

（１．最上レベルウィンドウのイベント）
最上レベルウィンドウのイベントには、メニューおよびコンボボックスドロップダウンに関するイベント、またはデスクトップを親に持つ任意の機能に関するイベントが含まれる。本発明の一実施形態では、ＡｄｄＴｏｐＬｅｖｅｌＷｉｎｄｏｗＬｉｓｔｅｎｅｒメソッドを使用して、開閉される最上レベルウィンドウの通知を受け取る。ＡｄｄＴｏｐＬｅｖｅｌＷｉｎｄｏｗＬｉｓｔｅｎｅｒを呼び出すと、現在のデスクトップ上で開かれた新しい最上レベルウィンドウまたは閉じられた最上レベルウィンドウについての通知が得られる。ＲｅｍｏｖｅＴｏｐＬｅｖｅｌＷｉｎｄｏｗＬｉｓｔｅｎｅｒメソッドは、デスクトップ上で開かれたかまたは閉じられた最上レベルウィンドウについての通知を受け取るのを停止するための機構を提供する。このメソッドは、コールバックオブジェクトを使用してこのリスナを識別する。したがって、ＲｅｍｏｖｅＴｏｐＬｅｖｅｌＷｉｎｄｏｗＬｉｓｔｅｎｅｒメソッドに渡されるオブジェクトは、ＡｄｄＴｏｐＬｅｖｅｌＷｉｎｄｏｗＬｉｓｔｅｎｅｒに渡されるオブジェクトと同じである。開かれた新しい最上レベルウィンドウそれぞれにつき一度、ＯｎＴｏｐＬｅｖｅｌＷｉｎｄｏｗＯｐｅｎｅｄメソッドがアクセシビリティシステム２００によって呼び出される。同様に、最上レベルウィンドウが閉じられたときに一度、ＯｎＴｏｐＬｅｖｅｌＷｉｎｄｏｗＣｌｏｓｅｄメソッドをアクセシビリティシステム２００によって呼び出すことができる。これらの通知を受け取るために、クライアント３００は、ＡｄｄＴｏｐＬｅｖｅｌＷｉｎｄｏｗＬｉｓｔｅｎｅｒメソッドを呼び出す。

（２．フォーカスイベント）
クライアント３００はしばしば、フォーカスを追跡するためのメソッドを必要とする。Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）ＯＳでこれを行うのは難しい。例えば、メニュー（例えばＭｉｃｒｏｓｏｆｔ Ｗｏｒｄのファイルメニュー）がドロップダウンされるとき、ユーザがカーソルをメニュー中の各項目に沿って下げるにつれて、各項目がフォーカスを得る。今日では、メニューが閉じたとき（例えばユーザがＥＳＣキーを押したとき）、フォーカスイベントは送られない。そうではなく、フォーカスの変化に関心のあるクライアントは、いくつかのイベントをリッスンして、それらのうちのどれが論理的にフォーカス変化を表すかを理解しなければならない。本発明の一実施形態では、ＡｄｄＦｏｃｕｓＣｈａｎｇｅｄＬｉｓｔｅｎｅｒメソッドを使用して、フォーカス変化イベントをリスナに通知することができる。クライアント３００は、返されるプロパティのセットを指定することができる。この、論理要素と共に返すプロパティを指定する機能は、すべてのイベント登録ＡＰＩの一部である。クライアント３００は、ＲｅｍｏｖｅＦｏｃｕｓＣｈａｎｇｅｄＬｉｓｔｅｎｅｒメソッドを呼び出して、フォーカス変化についての通知を受け取るのを停止することができる。このメソッドは、コールバックオブジェクトを使用してこのリスナを識別することができ、この場合、ＲｅｍｏｖｅＦｏｃｕｓＣｈａｎｇｅｄＬｉｓｔｅｎｅｒメソッドに渡されるオブジェクトは、ＡｄｄＦｏｃｕｓＣｈａｎｇｅｄＬｉｓｔｅｎｅｒプロシージャに渡されるオブジェクトと同じになる。フォーカスが変化したとき、アクセシビリティシステム２００は、ＯｎＦｏｃｕｓＣｈａｎｇｅｄメソッドを呼び出す。ＯｎＦｏｃｕｓＣｈａｎｇｅｄメソッド中で使用されるＦｏｃｕｓＥｖｅｎｔＡｒｇｓパラメータが、フォーカスの変化に関係する情報を公開する。最後にフォーカスされた論理要素に関する情報が入手可能な場合は、この要素は、ＯｎＦｏｃｕｓＣｈａｎｇｅｄ要素中で使用されるｅｖｅｎｔ ａｒｇｓパラメータ中で入手可能になる。何かが明示的に要素にフォーカスを当てるまではどのＵＩ要素もフォーカスを有さない場合もある。

（３．プロパティ変化イベント）
プロパティ変化イベントは、論理要素のプロパティが変化したときに発火される。本発明の一実施形態では、クライアント３００は、ＡｄｄＰｒｏｐｅｒｔｙＣｈａｎｇｅｄＬｉｓｔｅｎｅｒメソッドを呼び出して、プロパティ変化についての通知を受け取る。ＡｄｄＰｒｏｐｅｒｔｙＣｈａｎｇｅｄＬｉｓｔｅｎｅｒ中で指定された論理要素ツリー内の論理要素に関するプロパティの値が変化したとき、ＯｎＰｒｏｐｅｒｔｙＣｈａｎｇｅｄメソッドがアクセシビリティシステム２００によって呼び出される。範囲パラメータが、どの要素に対してイベントを発火すべきかを示す。例えば、ウィンドウのルート論理要素と子孫要求とを渡すと、プロパティ変化コールバックはそのウィンドウに制限される。範囲パラメータがツリー中のすべての要素に設定されている場合は、範囲は無視され、デスクトップ上で生じた指定のプロパティのどんな変化も送られる。クライアント３００は、ＡｄｄＰｒｏｐｅｒｔｙＣｈａｎｇｅｄＬｉｓｔｅｎｅｒを、異なるプロパティセットおよび／または異なるコールバックオブジェクトで複数回呼び出すことができる。アクセシビリティシステム２００によって提供される通知は、変化したプロパティと、新しいプロパティ値と、入手可能なら古いプロパティ値とを示す。

クライアント３００は、ＲｅｍｏｖｅＰｒｏｐｅｒｔｙＣｈａｎｇｅｄＬｉｓｔｅｎｅｒメソッドを呼び出して、プロパティ変化についての通知を受け取るのを停止することができる。このメソッドは、範囲要素およびコールバックオブジェクトを使用してこのリスナを識別することができ、この場合、渡されるオブジェクトは、ＡｄｄＰｒｏｐｅｒｔｙＣｈａｎｇｅｄＬｉｓｔｅｎｅｒに渡されるオブジェクトと同じでなければならない。

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

ＡｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドは、クライアント３００がコントロールについてのイベントを受け取ることを可能にする。範囲パラメータを使用して、どの要素に対してイベントを発火するかを指示することができる。例えば、ウィンドウのルート論理要素を渡して子孫を要求すると、イベントはそのウィンドウに制限される。ツリー中のすべての要素が望まれる場合は、デスクトップ上のすべてのイベントが送られる。ＲｅｍｏｖｅＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドを使用して、コントロールについてのイベントを受け取るのを停止することができる。このメソッドは、範囲要素とコールバックオブジェクトとイベント識別子とを使用して、リスナを識別することができる。この場合、渡されるオブジェクトは、ＡｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒに渡されるオブジェクトと同じでなければならない。

アプリケーションがＡｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドを呼び出すと、コントロール特有のイベントが発火されてイベントソースがＡｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒ中で指定された論理要素ツリー内の論理要素であるとき、ＯｎＥｖｅｎｔメソッドがアクセシビリティシステム２００によって呼び出される。コントロールについてのイベントが発火されるときは、イベント特有の情報がしばしば入手可能である。

ＲｅｍｏｖｅＡｌｌＬｉｓｔｅｎｅｒｓメソッドを呼び出して、どんなイベントを受け取るのも停止することができる。これは、クライアントアプリケーションがシャットダウンする前にクリーンアップするための素早い方法である。この削除メソッドは、アプリケーション終了時に使用することができるのが最適である。

（５．論理構造変化イベント）
論理構造変化イベントは、論理要素ツリーの構造が変化したときに発火される。ＡｄｄＬｏｇｉｃａｌＳｔｒｕｃｔｕｒｅＣｈａｎｇｅｄＬｉｓｔｅｎｅｒメソッドを実施して、論理要素ツリーの構造変化についての通知を受け取ることができる。論理要素が追加、削除、または無効にされるとき、指定のコールバックオブジェクトに対するメソッドが呼び出される。前述のように、範囲パラメータが要素を制限することができる。ＲｅｍｏｖｅＬｏｇｉｃａｌＳｔｒｕｃｔｕｒｅＣｈａｎｇｅｄＬｉｓｔｅｎｅｒメソッドを呼び出して、論理要素ツリーの変化についてのイベントを受け取るのを停止することができる。このメソッドは、コールバックオブジェクトおよび範囲要素を使用してこのリスナを識別することができ、この場合、渡されるオブジェクトは、ＡｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒに渡されるオブジェクトと同じでなければならない。

子要素が追加されるときであって、親がＡｄｄＬｏｇｉｃａｌＳｔｒｕｃｔｕｒｅＣｈａｎｇｅｄＬｉｓｔｅｎｅｒ中で指定された論理要素ツリー２２２内の論理要素であるときは、ＯｎＣｈｉｌｄＡｄｄｅｄメソッドをアクセシビリティシステム２００によって呼び出すことができる。子要素が削除されるときであって、古い親がＡｄｄＬｏｇｉｃａｌＳｔｒｕｃｔｕｒｅＣｈａｎｇｅｄＬｉｓｔｅｎｅｒ中で指定された論理要素ツリー内の論理要素であるときは、ＯｎＣｈｉｌｄＲｅｍｏｖｅｄメソッドがアクセシビリティシステム２００によって呼び出される。

短時間に多数の子（例えば２０個を超える子）が追加されるときは、ＯｎＣｈｉｌｄｒｅｎＢｕｌｋＡｄｄｅｄメソッドがアクセシビリティシステムによって呼び出される。短時間に多数の子が削除されるときは、ＯｎＣｈｉｌｄｒｅｎＢｕｌｋＲｅｍｏｖｅｄメソッドがアクセシビリティシステムによって呼び出される。短時間に多数の子（例えば２０個を超える子）の追加と削除の両方が行われるときは、ＯｎＣｈｉｌｄｒｅｎＩｎｖａｌｉｄａｔｅｄメソッドがアクセシビリティシステム２００によって呼び出される。

（６．マルチメディアイベント）
別のタイプのイベントは、マルチメディアイベントである。マルチメディアには、音声、ビデオ、アニメーションを含めることができる。メソッドは、マルチメディアイベントをサポートし、「停止された」「一時停止された」「早送りされた」「巻戻された」「ミュートにされた」を含めたアクションをクライアントに通知する。前述と同様のメソッドを実施して、マルチメディアリスナを追加および削除することができる。

（７．単純音声イベント）
単純音声イベントは、マルチメディアイベントとは別に扱うことができる。単純音声イベントは、音声自体以外の何らかのイベントをユーザに伝えるために存在する、単純かつ短時間の音声を表す。単純音声イベントには、新しいメールが到着したときに再生される音声、ラップトップの電池が低いときに生成される音声、またはＩｃｏｎＥｘｃｌａｍａｔｉｏｎタイプのメッセージボックスが表示されるときに再生される音声を含めることができる。ＡｄｄＳｏｕｎｄＬｉｓｔｅｎｅｒメソッドを呼び出して、再生される単純音声の通知を受け取ることができ、ＲｅｍｏｖｅＳｏｕｎｄＬｉｓｔｅｎｅｒメソッドを実施して、単純音声イベントについての通知を受け取るのを停止することができる。

単純音声が再生されたとき、ＯｎＳｏｕｎｄメソッドがアクセシビリティシステム２００によって呼び出される。この通知を受け取るために、リッスンしているアプリケーションは、ＡｄｄＳｏｕｎｄＬｉｓｔｅｎｅｒを呼び出す。ＯｎＳｏｕｎｄメソッドは、音声の名前と、音声のソースと、ユーザに対する音声の重要性を示すアラートレベル値との情報を取り出す。可能なアラートレベルには、重要性が未知であることを示す「未知」と、情報が提示されたことを示す「情報」と、警告条件を示す「警告」と、ユーザ応答が必要であることを示す「疑問」と、イベントがクリティカルではないが重要かもしれないことを示す「感嘆符」と、クリティカルなイベントの発生を示す「クリティカル」が含まれる。

（８．ソフトフォーカスイベント）
ソフトフォーカスイベントは、デスクトップ上に現れるが背景にとどまっているものである。ソフトフォーカスイベントのいくつかの例としては、通知領域で「新しい更新が利用可能です」と示すバルーンヘルプウィンドウと、フォーカスを得たい背景アプリケーションについての、タスクバー中の点滅アイコンと、印刷が開始および終了したときに通知トレイから現れて消えるプリンタアイコンがある。これらのイベントは、他のイベント範疇といくぶん重複するように思われるかもしれない（ソフトフォーカスがするのと同様に、マルチメディアもアニメーションイベントを含む場合がある）。しかしイベントは、それがどのように伝えられるかではなく、何をユーザに伝えるかに基づいて範疇化される。

入力フォーカスを利用せずにユーザの注意を引こうとするイベントの通知を、ＡｄｄＳｏｆｔＦｏｃｕｓＬｉｓｔｅｎｅｒメソッドを実施して受け取ることができる。ＲｅｍｏｖｅＳｏｆｔＦｏｃｕｓＬｉｓｔｅｎｅｒメソッドは通知を停止する。このメソッドは、コールバックオブジェクトを使用してリスナを識別することができ、したがって、渡されるオブジェクトは、ＡｄｄＳｏｆｔＦｏｃｕｓＬｉｓｔｅｎｅｒに渡されるオブジェクトと同じのはずである。

ソフトフォーカスイベントが発生したとき、ＯｎＳｏｆｔＦｏｃｕｓメソッドをアクセシビリティシステム２００によって呼び出すことができる。この通知を受け取るために、リッスンしているアプリケーションまたはクライアント３００は、ＡｄｄＳｏｆｔＦｏｃｕｓＬｉｓｔｅｎｅｒを呼び出す。ソース要素が利用可能なら、これを使用してイベントに関するより多くの情報を得ることができる。ソース要素の一例は、システムトレー中の通知アプリケーションのうちの１つによって使用されるバルーンヘルプウィンドウの論理ルート要素であろう。ＯｎＳｏｆｔＦｏｃｕｓメソッドは、イベントの名前と、イベントのソースと、ユーザに対するイベントの重要性を示すアラートレベルとを返す。

以下の表に、クライアント300がAddTopLevelWindowListener APIを使用して特定のプロセスからのイベントをリッスンするときの、クライアント300およびアクセシビリティシステム200のアクションを示す。

（イベント通知）
サーバ４００または基礎をなすＵＩエンジンは、対応するイベント通知メソッドを使用して、上に挙げたアクセシビリティシステムイベントをサポートする。ＵＩ自動化サーバＡＰＩは、サーバまたは基礎をなすＵＩエンジンがこれを達成するために呼び出すことのできるメソッドを含む。例えば、論理要素上で特定のプロパティが変化したときにサーバが通知するために呼び出すＮｏｔｉｆｙＰｒｏｐｅｒｔｙＣｈａｎｇｅｄメソッドがある。ＵＩが変化したときに適切なパラメータを生成してこれらの通知メソッドを呼び出すことは、サーバ４００または基礎をなすＵＩエンジンの任務である。

（サーバメソッド）
クライアント３００がイベントを要求しているとき、ＡｄｖｉｓｅＥｖｅｎｔＡｄｄｅｄメソッドおよびＡｄｖｉｓｅＥｖｅｎｔＲｅｍｏｖｅｄメソッドがＵＩ自動化クライアントによって呼び出されて、サーバ４００に通知される。これによりサーバ４００は、関心のあるイベントがない場合にはアクセシビリティシステム２００にイベントを伝搬しないようにすることができる。サーバは、これらの通知を用いて、それらのイベントを使用しているクライアントがいるかどうかに性能が依存するようにすることができる。

（コントロールパターン）
アクセシビリティモデルは、特定のＵＩ要素またはコントロールによってサポートされる機能を範疇化および公開するための独自の手法を提供する。従来技術のように機能を特定のコントロールタイプ（例えばボタン、編集ボックス、またはリストボックス）に関連付けるのではなく、アクセシビリティモデルは、共通コントロールパターンのセットを定義し、各パターンはＵＩ挙動の１つの面を定義する。これらのパターンは相互に独立しているので、これらを組み合わせて、特定のＵＩ要素によってサポートされる機能の完全なセットを記述することができる。

例えば、要素をそのクラス名（Ｂｕｔｔｏｎなど）で記述するのではなく、アクセシビリティシステム２００は、呼出し可能なコントロールパターンをサポートするものとして要素を記述する。コントロールパターンは、要素によってサポートされる、構造、プロパティ、イベント、メソッドを定義する。したがって、これらのパターンにより、クライアントはコントロールの挙動を照会することができるだけでなく、特定のパターン用に設計されたインターフェースを使用してコントロールをプログラムに基づいて操作することもできる。例えば、ＳｅｌｅｃｔｉｏｎＣｏｎｔａｉｎｅｒパターンは、選択された項目を照会するためのメソッド、特定の項目を選択または選択解除するためのメソッド、あるいは、コントロールが単一の選択モードをサポートするか複数の選択モードをサポートするかを決定するためのメソッドを提供する。

アクセシビリティシステム２００に対して現在定義されているコントロールパターンには、（１）選択コンテナ、（２）階層、（３）呼出し可能、（４）単純グリッド、（５）テキスト、（６）値、（７）オブジェクトを表す、（８）スクロール可能、（９）ソート可能、（１０）ドローイング、（１１）その他のコンテナが含まれる。

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

支援技術製品およびテストスクリプトは今や、各ＵＩコントロールによってではなく、各パターンによってどのように機能するかを理解するように書くことができる。コントロールパターンはコントロールクラスよりもずっと少ないので、この技法は、必要なコードを最小限に抑える。この手法はまた、新しいコントロールを効果的に問合せおよび操作することのできる、よりフレキシブルなアーキテクチャを奨励する（新しいコントロールが既知のコントロールパターンをサポートする限り）。

以下の表に、共通コントロールとそれらがサポートするパターンの、いくつかの例を提供する。

より具体的なインターフェースを使用すると、共通コントロールパターンに関連する機能が公開される。これらのパターンの例には、（１）選択管理コンテナ、（２）グリッドレイアウトコンテナ、（３）値を含むＵＩ要素、（４）オブジェクト（ファイル、ｅメールなど）を表すアイコン、（５）呼び出すことのできるＵＩ要素が含まれる。一般に、これらのパターンは特定のコントロールに密に結び付いたものではなく、異なるコントロールが同じパターンを実装することもできる。例えば、リストボックス、コンボボックス、ツリービューはすべて、「選択管理コンテナ」パターンを実装する。いくつかのコントロールは、適切なら複数のパターンを実装することができる。すなわち、選択グリッドが「グリッドレイアウトコンテナ」パターンと「選択管理コンテナ」パターンの両方を実装することになる。

以前のアプリケーションのように単一の「ロール（ｒｏｌｅ）」プロパティはない。そうではなく、２つの別々の機構が使用される。コントロールパターンが、コントロールについての利用可能な機能を決定し、人間可読のローカライズ可能プロパティが、「ボタン（ｂｕｔｔｏｎ）」や「リストボックス（ｌｉｓｔ ｂｏｘ）」など、ユーザが理解できるコントロールタイプ名を提供する。

（プロパティ）
アクセシビリティシステム２００は、一般的なＧｅｔＰｒｏｐｅｒｔｙメソッドを特徴づけることになる。プロパティはＧＵＩＤで表されることが好ましく、ユーティリティメソッドを使用して、ローカライズ不可能なニーモニック形式（スクリプティングおよび構成ファイルに有用である）との間で変換し、ローカライズされた記述も得る。個別のメソッドではなく一般的なＧｅｔＰｒｏｐｅｒｔｙメソッドであることの２つの重要な利点は、（ａ）インターフェースを変更せずに時の経過に伴って新しいプロパティを追加することができること、および（ｂ）アレイ駆動型バルクプロパティフェッチングなど、別々のメソッドを使用したときには不可能な実装技術を可能にすることである。各プロパティは、明確に定義された意図を有さなければならない。プロパティが人間によって消費されるように意図されているか機械によって消費されるように意図されているか、プロパティがローカライズされるかどうかなどが、明確に定義されなければならない。

本発明を特定の実施形態に関して述べたが、これらの実施形態は、あらゆる点で限定的ではなく例示的なものである。本発明が関連する当業者には、その範囲を逸脱することなく代替実施形態も明らかになるであろう。

以上のことから、本発明は、自明であり本システムおよび方法に内在するその他の利点と共に、前述のすべての目標および目的を達成するようにうまく適合されたものであることがわかるであろう。いくつかの特徴およびサブコンビネーションは、他の特徴およびサブコンビネーションを参照しなくても有用であり採用することができることは理解されるであろう。このことを、特許請求の範囲によって企図する。

本発明を実施する際に使用するのに好適なコンピューティングシステム環境のブロック図である。 アクセシビリティシステム、クライアント環境、サーバ環境の間の対話のブロック図である。 アクセシビリティシステムコアのコンポーネントを示すブロック図である。 ネイティブ要素から論理ツリーを生み出すことを示す図である。 ネイティブ要素から論理ツリーを生み出すことを示す図である。 ネイティブ要素から論理ツリーを生み出すことを示す図である。 ネイティブ要素から論理ツリーを生み出すことを示す図である。 論理ツリーを構築するための一連の手順を示すフローチャートである。 ダイアログボックスと、論理要素を形成するそのコンポーネントを示す図である。 本発明のイベント機構をアクティブ化することに関連する手順を示すフローチャートである。 既知のイベント通知システムを示す図である。

Claims (18)

1. クライアントにユーザインターフェース情報を提供するためのアクセシビリティシステムであって、前記ユーザインターフェース情報が前記クライアントにとって関心のあるものかどうかに基づいて情報をフィルタリングするためのユーザインターフェース自動化サービスを含むアクセシビリティシステムコアと、前記クライアントにとって関心のあるユーザインターフェース情報を見えるようにすると共に前記クライアントにとって関心のないユーザインターフェース情報を隠すための論理ツリーを含むクライアント側インターフェースと、サーバ側アプリケーションを構築するために使用されているユーザインターフェースエンジンにかかわらず前記サーバ側アプリケーションからの情報転送を容易にするためのサーバ側インターフェースとを備えることを特徴とするアクセシビリティシステム。
2. 前記ユーザインターフェース自動化サービスは、前記クライアント側インターフェースを介して動作するユーザインターフェース自動化クライアントと、前記サーバ側インターフェースを介して動作するユーザインターフェース自動化サーバとを備えるイベント機構を形成することを特徴とする請求項１に記載のアクセシビリティシステム。
3. 前記ユーザインターフェース自動化クライアントは、前記クライアントからイベント登録要求を受け取って、前記イベント登録要求を前記ユーザインターフェース自動化サーバに通知するように動作することを特徴とする請求項２に記載のアクセシビリティシステム。
4. 前記ユーザインターフェース自動化サーバは、サーバ側のユーザインターフェースエンジンからのイベント情報を求め、前記イベント情報をフィルタリングして、前記イベント登録要求の範囲外の情報を廃棄することを特徴とする請求項３に記載のアクセシビリティシステム。
5. 前記論理ツリーは複数の要素を含み、前記要素はそれぞれ、コントロール、コントロール中の項目、グループ構造のうちの１つを表すことを特徴とする請求項１に記載のアクセシビリティシステム。
6. 基礎をなすアプリケーション技術が、前記論理ツリーをナビゲートするための適切な技法を決定することを特徴とする請求項１に記載のアクセシビリティシステム。
7. 前記論理ツリーは異なるアプリケーションからのユーザインターフェースを統合することを特徴とする請求項１に記載のアクセシビリティシステム。
8. コントロールパターンに関連する機能を公開するためのインターフェースをさらに備えることを特徴とする請求項１に記載のアクセシビリティシステム。
9. アクセシビリティシステムＡＰＩが、アプリケーションに関連する情報をクライアントに提供するための論理ツリー位置を返すことを特徴とする請求項８に記載のアクセシビリティシステム。
10. クライアントにユーザインターフェース情報を提供するためのコンピュータ実施方法であって、アクセシビリティシステム自動化サービスによってユーザインターフェース情報を監視すること、サーバ側技術にかかわらずサーバ側インターフェースを介してユーザインターフェース情報を転送すること、および、クライアント側インターフェースの一部を形成する論理要素ツリーを使用して、前記クライアントにとって関心のある特定のユーザインターフェース情報を決定することを含むことを特徴とする方法。
11. 前記クライアント側インターフェースを介して動作するユーザインターフェース自動化クライアントと、前記サーバ側インターフェースを介して動作するユーザインターフェース自動化サーバとを提供することをさらに含むことを特徴とする請求項１０に記載の方法。
12. 前記ユーザインターフェース自動化クライアントにおいて前記クライアントからイベント登録要求を受け取って、前記イベント登録要求を前記ユーザインターフェース自動化サーバに通知することをさらに含むことを特徴とする請求項１１に記載の方法。
13. サーバ側のユーザインターフェースエンジンからのイベント情報を求め、前記イベント情報をフィルタリングして、前記イベント登録要求の範囲外の情報を廃棄することをさらに含むことを特徴とする請求項１２に記載の方法。
14. 前記論理ツリー中の各要素によって、コントロール、コントロール中の項目、グループ構造のうちの１つを表すことをさらに含むことを特徴とする請求項１０に記載の方法。
15. 基礎をなすアプリケーション技術を使用して、前記論理ツリーをナビゲートするための適切な技法を決定することをさらに含むことを特徴とする請求項１０に記載の方法。
16. 異なるアプリケーションからのユーザインターフェースを前記論理ツリー中で統合することをさらに含むことを特徴とする請求項１０に記載の方法。
17. コントロールパターンに関連する機能を公開するためのインターフェースを提供することをさらに含むことを特徴とする請求項１０に記載の方法。
18. アクセシビリティシステムを使用して、アプリケーションに関連する情報を前記クライアントに提供するための論理ツリー位置を返すことをさらに含むことを特徴とする請求項１０に記載の方法。
    

Images