ユーザインターフェース情報へのアクセスを提供するためのシステムおよび方法
【課題】クライアントにユーザインターフェース情報を提供するためのシステムを提供すること。
【解決手段】クライアントにユーザインターフェース情報を提供するためのアクセシビリティシステムは、ユーザインターフェース自動化サービスとAPIとを含むアクセシビリティシステムコアを備える。ユーザインターフェース自動化ツールは、ユーザインターフェース情報がクライアントにとって関心のあるものかどうかに基づいて情報をフィルタリングする。アクセシビリティシステムは追加で、クライアントにとって関心のあるユーザインターフェース情報を見えるようにすると共にクライアントにとって関心のないユーザインターフェース情報を隠すための論理ツリーを含むクライアント側インターフェースを備える。アクセシビリティシステムはまた、サーバ側の技術にかかわらずサーバ側からの情報転送を容易にするためのサーバ側インターフェースも備える。
【解決手段】クライアントにユーザインターフェース情報を提供するためのアクセシビリティシステムは、ユーザインターフェース自動化サービスとAPIとを含むアクセシビリティシステムコアを備える。ユーザインターフェース自動化ツールは、ユーザインターフェース情報がクライアントにとって関心のあるものかどうかに基づいて情報をフィルタリングする。アクセシビリティシステムは追加で、クライアントにとって関心のあるユーザインターフェース情報を見えるようにすると共にクライアントにとって関心のないユーザインターフェース情報を隠すための論理ツリーを含むクライアント側インターフェースを備える。アクセシビリティシステムはまた、サーバ側の技術にかかわらずサーバ側からの情報転送を容易にするためのサーバ側インターフェースも備える。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、支援技術(assistive technology)製品および自動テスト製品、ならびにこれらの製品とユーザインターフェース情報との対話の分野に関する。
【背景技術】
【0002】
支援技術(AT)製品は、学習や、コミュニケーションや、コンピュータソフトウェアに含まれる、またコンピュータソフトウェアによって提示される情報へのアクセスの領域において支援を必要とするコンピュータユーザを補助するために存在する。これらの製品は、コンピュータインターフェースに関連する情報を必要とする。同様に、既存の自動テスト製品およびユーザインターフェースコマンディングユーティリティも、ユーザインターフェースに関する情報を必要とする。現在、これらの製品には、ユーザインターフェース(UI)情報のソースが十分にない。この3つのタイプの製品(クライアント)は、(1)アプリケーションのユーザインターフェースに関する情報を収集すること、(2)UIを構築するために使用されている技術にかかわらずプログラムに基づいてUI要素を発見し問い合わせること、(3)キーボード入力およびポインタ入力を生成すること、(4)どのタイプの挙動または機能が現在利用可能かを理解することを可能にするために、必要なサポートをどこか他の場所から得る必要がある。これらすべての機能をAT製品に提供する現在利用可能な技術は、1つとしてない。さらに、現在のAT製品は、すべてのグラフィカルオペレーティングシステム(OS)技術に適合するとは限らず、また、余分な通知または誤解を招く通知を一元的にフィルタリングし調整を図ることができない。もう1つの欠点として、現在の自動化およびアクセシビリティインフラストラクチャは拡張可能ではなく、そのため、新しい機能を追加するにはOSレベルの変更が必要である。
【0003】
さらに、現在、アプリケーションのユーザインターフェースに関する情報を収集するには、AT製品は、ユーザに対する情報を得るためにアプリケーション特有コードを書かなければならない。このアプリケーション特有コードを書くプロセスは、時間がかかり、継続的な保守を必要とする。現在の自動化インフラストラクチャもまた、余分なまたは誤解を招くイベント通知を一貫性のある方式でフィルタリングし調整を図ることができない。そのため、イベントコンシューマが独自に情報をフィルタリングする必要がある。
【0004】
現在のシステムでは、AT製品は、イベント通知を3つの細分性レベルで要求することができる。すなわち、(1)デスクトップ上のあらゆるもの、(2)特定のプロセス中(ワードプロセッサの立上げなど)、または(3)特定プロセス中のスレッド中(プロセス中で働いている複数のオブジェクト)である。現在、クライアントがイベントを受け取るとき、クライアントは、イベントが発生した特定のウィンドウに対するウィンドウハンドルと、イベントがどこで発生したかを示すその他の情報ビットとを受け取る。クライアントは、プロセス間呼出しを行って、イベントに関係するUIオブジェクトを取り出すことができる。このオブジェクトを使用して、クライアントは、追加のプロセス間呼出しを行ってこのオブジェクトに関する情報を要求することができる。クライアントが5つの情報を必要とする場合、クライアントは5つのプロセス間呼出しを行わなければならない。プロセス間呼出しは非常に遅く、そのため、現在のアクセシビリティインフラストラクチャを使用してUI情報を収集することの性能コストは高い。図8に、このタイプの既知のシナリオを示す。サーバアプリケーション12がイベント6を発火(fire)する。カーネル14が、どのクライアントが通知を受けなければならないかを決定し、当該のクライアント10にイベント通知18を送る。クライアント10は、イベント通知18に関係するオブジェクトを求める要求16を、プロセス境界2をまたいでサーバアプリケーション12に送る。サーバアプリケーション12はオブジェクト20を返し、次いでクライアント10は、イベントを発火したUIコントロールに関する情報を求める要求16の送信を開始することができる。サーバアプリケーション12は、要求された情報20を、プロセス境界2をまたいでクライアント10に返す。
【0005】
別の現行オプションでは、クライアントコードをプロセス内のダイナミックリンクライブラリ(.DLL)としてロードすることができる。このオプションはいくつかの欠点を有する。第1に、クライアントコードをプロセスにロードするために、システムからの協力を必要とする。第2に、クライアントコードがアプリケーションのプロセスにロードされた後は、それが収集する情報を制限するのが難しいので、セキュリティ問題を引き起こす。第3に、クライアントにとって効果的な技法であるためには、システム上のあらゆるプロセスにロードしなければならない。信用できるクライアントだけを別のアプリケーションのプロセスにロードできるべきであるのが最適である。
【0006】
さらに、どのイベント通知を受け取りたいかを指定する能力をクライアントに与えるシステムも必要である。知られているシステムでは、クライアントは、いくつかのプロセス間呼出しを行い、次いで情報を分析して、そのイベントに関心があるかどうかを判定することが必要な場合がある。このイベントフィルタリングをより高性能な方式で実施することができ、新しいシステムイベントまたはアプリケーションイベントをサポートするよう容易に更新することができる機構が必要とされている。さらに、セキュリティ問題を軽減するために、信用できるコンポーネントだけを使用するシステムも必要とされている。
【0007】
現在、ユーザインターフェースに関する情報を探すとき、AT製品は、特定のUIフレームワークにネイティブであるツリーにアクセスする必要がある。そのため、複数のUIフレームワークについてのユーザインターフェース情報を伝えるには、複数のツリーが必要である。これらの異なるツリーは、エンドユーザによって操作される可視のUIコントロールを管理する隠れたコンテナオブジェクトなど、ユーザにとって関心がないかまたは見えない情報を含む場合がある。したがって、ユーザにとって関心のあるノードだけを有する単一の統合ツリーが存在する必要がある。
【発明の概要】
【発明が解決しようとする課題】
【0008】
AT製品、自動テストツール、コマンディングユーティリティのニーズに対処する解決法が必要とされている。この解決法は、すべてのグラフィカルOS技術によって使用可能であるべきであり、すべての形のUIおよびUIコンポーネントをアクセス可能にすることができるべきである。
【課題を解決するための手段】
【0009】
本発明は、クライアントにユーザインターフェース情報を提供するための方法およびコンピュータアプリケーションを対象とする。本発明の一態様では、クライアントにユーザインターフェース情報を提供するためのアクセシビリティシステムが提供される。アクセシビリティシステムは、ユーザインターフェース情報がクライアントにとって関心のあるものかどうかに基づいて情報をフィルタリングするためのユーザインターフェース自動化サービスを含むアクセシビリティシステムコアを備える。アクセシビリティシステムは追加で、クライアントにとって関心のあるユーザインターフェース情報を見えるようにすると共にクライアントにとって関心のないユーザインターフェース情報を隠すための論理ツリーを含むクライアント側インターフェースも備える。アクセシビリティシステムはまた、サーバ側アプリケーションを構築するために使用されているユーザインターフェースエンジンにかかわらずサーバ側アプリケーションからの情報転送を容易にするための、サーバ側インターフェースも備える。
【0010】
本発明の別の態様では、クライアントにユーザインターフェース情報を提供するためのコンピュータ実施方法が提供される。この方法は、アクセシビリティシステム自動化サービスによってユーザインターフェース情報を監視すること、および、サーバ側技術にかかわらずサーバ側インターフェースを介してユーザインターフェース情報を転送することを含む。この方法はさらに、クライアント側インターフェースの一部を形成する論理要素ツリーを使用して、クライアントにとって関心のある特定のユーザインターフェース情報を決定することも含む。
【0011】
本発明の追加の利点および新規な特徴については以下の記述に示すが、その一部は以下の記述を検討すれば当業者には明らかであろうし、あるいは本発明の実施からわかるであろう。
【0012】
以下、添付の図面を参照しながら本発明を述べる。
【図面の簡単な説明】
【0013】
【図1】本発明を実施する際に使用するのに好適なコンピューティングシステム環境のブロック図である。
【図2】アクセシビリティシステム、クライアント環境、サーバ環境の間の対話のブロック図である。
【図3】アクセシビリティシステムコアのコンポーネントを示すブロック図である。
【図4A】ネイティブ要素から論理ツリーを生み出すことを示す図である。
【図4B】ネイティブ要素から論理ツリーを生み出すことを示す図である。
【図4C】ネイティブ要素から論理ツリーを生み出すことを示す図である。
【図4D】ネイティブ要素から論理ツリーを生み出すことを示す図である。
【図5】論理ツリーを構築するための一連の手順を示すフローチャートである。
【図6】ダイアログボックスと、論理要素を形成するそのコンポーネントを示す図である。
【図7】本発明のイベント機構をアクティブ化することに関連する手順を示すフローチャートである。
【図8】既知のイベント通知システムを示す図である。
【発明を実施するための形態】
【0014】
図1に、本発明を実施することのできる好適なコンピューティングシステム環境の例100を示す。コンピューティングシステム環境100は、好適なコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲についてどんな制限も意味しない。またコンピューティング環境100は、この例示的な動作環境100に示すコンポーネントのいずれか1つまたは組合せに関してどんな依存や要件を有するものとも解釈すべきではない。
【0015】
本発明は、プログラムモジュールなど、コンピュータによって実行されるコンピュータ実行可能命令の一般的なコンテキストで述べることができる。一般にプログラムモジュールは、特定のタスクを実施するか特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、本発明は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な民生用電子機器、ミニコンピュータ、メインフレームコンピュータなどを含めて、その他のコンピュータシステム構成で実施することもできることは、当業者なら理解するであろう。本発明はまた、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実施される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶デバイスを含めたローカルとリモートの両方のコンピュータ記憶媒体に位置することができる。
【0016】
図1を参照すると、本発明を実施するための例示的なシステム100は、コンピュータ110の形の汎用コンピューティングデバイスを含み、コンピュータ110は、処理ユニット120と、システムメモリ130と、システムメモリを含めた様々なシステムコンポーネントを処理ユニット120に結合するシステムバス121とを備える。
【0017】
コンピュータ110は通常、様々なコンピュータ可読媒体を備える。限定ではなく例として、コンピュータ可読媒体には、コンピュータ記憶媒体および通信媒体を含めることができる。システムメモリ130は、読取り専用メモリ(ROM)131やランダムアクセスメモリ(RAM)132など、揮発性および/または不揮発性メモリの形のコンピュータ記憶媒体を含む。ROM131には通常、起動中などにコンピュータ110内の要素間で情報を転送するのを助ける基本ルーチンを含むBIOS(basic input/output system)133が記憶されている。RAM132は通常、処理ユニット120がすぐにアクセス可能な、かつ/または処理ユニット120が現在作用している、データおよび/またはプログラムモジュールを含む。限定ではなく例として、図1には、オペレーティングシステム134、アプリケーションプログラム135、その他のプログラムモジュール136、プログラムデータ137を示す。
【0018】
コンピュータ110は、その他の着脱式/固定式、揮発性/不揮発性のコンピュータ記憶媒体を備えることもできる。例にすぎないが図1には、固定式かつ不揮発性の磁気媒体に対して読み書きするハードディスクドライブ141と、着脱式の不揮発性の磁気ディスク152に対して読み書きする磁気ディスクドライブ151と、CD ROMやその他の光媒体など着脱式の不揮発性の光ディスク156に対して読み書きする光ディスクドライブ155を示す。この例示的な動作環境で使用することのできるその他の着脱式/固定式、揮発性/不揮発性のコンピュータ記憶媒体には、限定しないが磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、固体RAM、固体ROMなどが含まれる。ハードディスクドライブ141は通常、インターフェース140などの固定式メモリインターフェースを介してシステムバス121に接続され、磁気ディスクドライブ151および光ディスクドライブ155は通常、インターフェース150などの着脱式メモリインターフェースでシステムバス121に接続される。
【0019】
以上に論じ図1に示したドライブおよびそれらに関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、その他のデータの記憶域をコンピュータ110に提供する。例えば図1には、ハードディスクドライブ141がオペレーティングシステム144、アプリケーションプログラム145、その他のプログラムモジュール146、プログラムデータ147を記憶しているのが示されている。これらのコンポーネントは、オペレーティングシステム134、アプリケーションプログラム135、その他のプログラムモジュール136、プログラムデータ137と同じものとすることもでき、異なるものとすることもできることに留意されたい。ここでは、オペレーティングシステム144、アプリケーションプログラム145、その他のプログラムモジュール146、プログラムデータ147が少なくとも異なるコピーであることを示すために、異なる番号を付けてある。ユーザは、キーボード162、マウスやトラックボールやタッチパッドと一般に呼ばれるポインティングデバイス161などの入力デバイスを介して、コンピュータ110にコマンドおよび情報を入力することができる。その他の入力デバイス(図示せず)には、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどを含めることができる。これらおよび他の入力デバイスは、システムバスに結合されたユーザ入力インターフェース160を介して処理ユニット120に接続されることが多いが、パラレルポート、ゲームポート、ユニバーサルシリアルバス(「USB」)など、その他のインターフェースおよびバス構造で接続されてもよい。モニタ191または他のタイプの表示デバイスも、ビデオインターフェース190などのインターフェースを介してシステムバス121に接続される。モニタに加えて、コンピュータは通常、スピーカ197やプリンタ196など他の周辺出力デバイスも備えることができ、これらは出力周辺インターフェース195を介して接続することができる。
【0020】
本発明においてコンピュータ110は、リモートコンピュータ180など1つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク化された環境で動作することができる。リモートコンピュータ180はパーソナルコンピュータとすることができ、図1にはメモリ記憶デバイス181しか示していないが、通常はコンピュータ110に関して上述した要素の多くまたはすべてを備える。図1に示す論理接続は、ローカルエリアネットワーク(LAN)171およびワイドエリアネットワーク(WAN)173を含むが、その他のネットワークを含むこともできる。
【0021】
LANネットワーキング環境で使用されるときは、コンピュータ110は、ネットワークインターフェースまたはアダプタ170を介してLAN171に接続される。WANネットワーキング環境で使用されるときは、コンピュータ110は通常、インターネットなどのWAN173を介した通信を確立するためのモデム172または他の手段を備える。モデム172は内蔵でも外付けでもよく、ユーザ入力インターフェース160または他の適切な機構を介してシステムバス121に接続することができる。ネットワーク化された環境では、コンピュータ110に関して示したプログラムモジュールまたはその一部をリモートのメモリ記憶デバイスに記憶することができる。限定ではなく例として、図1には、リモートアプリケーションプログラム185がメモリデバイス181上にあるものとして示す。図示のネットワーク接続は例示的なものであり、コンピュータ間で通信リンクを確立するための他の手段を使用してもよいことは理解されるであろう。
【0022】
コンピュータ110のその他多くの内部コンポーネントは図示していないが、そのようなコンポーネントおよび相互接続が周知であることは、当業者なら理解するであろう。したがって、コンピュータ110の内部構造に関するこれ以上の詳細は、本発明に関して開示する必要はない。
【0023】
(アクセシビリティシステムの構造)
図2に示すように、アクセシビリティシステム200は、クライアント環境300およびサーバ環境400と対話する。アクセシビリティシステム200は、図1に関して上述したコンピュータ環境100内で実施することができる。アクセシビリティシステム200は、クライアント300との対話を容易にするためのクライアント側アクセシビリティインターフェース220と、サーバ側400との対話を容易にするためのサーバ側アクセシビリティインターフェース230と、アクセシビリティシステムコア201とを備える。本発明のアクセシビリティシステム200は、プログラムに基づいてユーザインターフェース(UI)にアクセスするための、新しいアプリケーションプログラムインターフェース(API)、インターフェース、メタファーを提供する。アクセシビリティシステム200では、アプリケーションが、アプリケーション自体と、アプリケーションが使用する任意のコンポーネントとをアクセス可能にすることができる。
【0024】
クライアント環境300は、支援技術(AT)製品または自動UIテストツールを含むことが好ましい。サーバ側400は、図2に示す様々な異なる技術を実装することができる。サーバシステム410はアダプタ412およびコア414を含み、これらは第1タイプのUIに見ることができるものである。サーバシステム420はプロキシコンポーネント422およびコントロール424を含み、これらはワシントン州レドモンドのMicrosoft Corporationから出ているMicrosoft Operating System製品で利用可能なWin32UIなど、第2タイプのUIに見ることができるものである。サーバシステム430はアダプタ432および内部OM434を含み、これらは代替の第3タイプのUIに見ることができるものである。
【0025】
図3に示すように、アクセシビリティシステム200にはイベント機構210が備わるが、このイベント機構210は、クライアント環境300との、およびサーバ環境400との対話を容易にするために、UI自動化クライアント202およびUI自動化サーバ204に依拠する。UI自動化クライアント202およびUI自動化サーバ204については、後で本発明のイベント機構210に関してより詳細に述べる。本発明のアクセシビリティシステム200は、クライアント(AT製品)300に、(1)アプリケーションのユーザインターフェースに関する情報を収集する能力、(2)UIを構築するために使用されている技術にかかわらずプログラムに基づいてUI要素を発見し問い合わせる能力、(3)キーボード入力およびポインタ入力を生成する能力、(4)どのタイプの挙動または機能が現在利用可能かを理解する能力を提供する。アクセシビリティシステム200では、アプリケーションが、アプリケーション自体およびそのコンポーネントをアクセス可能にすることができる。図2および3に示す構造は、(1)論理UIツリー、(2)コントロールパターン、(3)イベント機構、(4)入力API(この文書ではカバーされていない)、(5)プロパティを含めた、アクセシビリティシステム200の5つの主要な面を可能にする。
【0026】
(UIアクセス論理ツリー222)
アクセシビリティシステム200の統合コンポーネントとして論理ツリー222があり、この例を図4(D)に示す。ツリー222は、クライアント側アクセシビリティインターフェース220に含まれる。
【0027】
論理ツリー222は、UI要素の基礎的な構造階層がフィルタリングされたビューであり、コントロールまたはアプリケーションの開発者が実装しなければならない別個のツリーではない。そうではなく論理ツリー222は、関心あり(interesting)、関心なし(uninteresting)という少数の明確なプロパティを符丁とし、これらのプロパティは、構造の要素が論理ツリー222中で公開されるべきかどうかを示す。アクセシビリティシステムコア201は、この情報を消費してフィルタリング済みUI論理ツリー222を生み出し、フィルタリング済み論理ツリー222は、AT製品またはテストスクリプトに提示される。
【0028】
論理ツリー222は要素のツリーであり、各要素はコントロール、コントロール中の項目、またはグループ構造を表し、グループ構造はダイアログ、ペイン、またはフレームとすることができる。論理ツリー222の構造は、ユーザによって知覚されるアプリケーションUIを表すべきである(コントロールが実際には異なる基礎構造を使用して実装される場合でも)。ツリーは、時が経過しても一定であるべきである。アプリケーションがユーザにとって同じに見える限り、そのアプリケーションを表す論理ツリー222は、背後でアプリケーションの実装詳細が変化しても、同じのままであるべきである。Microsoft OS製品のシェルの「ShDocView」ウィンドウなど、構造上および実装上の理由で存在するネイティブ要素は、ユーザが知覚しないのでこのツリー中に現れるべきではない。
【0029】
論理ツリー222は、複数の異なるプロセスがクライアントにとって同じになるようにこれらのプロセスを統一することのできる、複数のフラグメントから構築された単一のツリーである。論理ツリー222は、バルク検索を可能にし、プロパティリストの値を得ることができる。通常ならユーザがプロセス間呼出しを行って値を要求している時までに、アクセシビリティシステム200は、論理ツリー222を使用してそれらをフェッチしていることになる。
【0030】
論理ツリー222は、知られているシステムの場合のように1つのステップで構築されるのではなく、生ツリーの構築に使用されるフラグメントから構築される。図5に示すように、3つの主要な手順が論理ツリー222を構築する。手順72で、アクセシビリティシステム200は、基礎をなす技術のネイティブ要素を突き止め、図4(A)に示すネイティブツリーに達する。手順74で、アクセシビリティシステム200は、図4(B)に示すようにネイティブ要素を結合して生ツリー20を形成する。最後に手順76で、図4(D)に示すように、関心を持たれない生ツリー20中のコンポーネントを隠すことによって論理ツリー222が得られる。
【0031】
図4(A)に、2つのネイティブツリー10および14を示す。これらは、Win32UIやその他の任意の利用可能なUIなど、基礎をなす技術のネイティブ要素から構築される。ネイティブツリー10は、親ノード11と、相互に様々な関係を有する複数の子孫12とを含む。同様に、ネイティブツリー14は、複数の子ノード16を有する親ノード15を含む。子ノード16は、相互の兄弟として記述することができる。
【0032】
図4(B)に示すように、ネイティブツリー10および14を結合して、生ツリー20を形成することができる。生ツリー20は、2つの子ノード22および30を有する親ノード21を含む。子ノード22は子孫23〜29を有し、子ノード30は子孫31〜33を有する。この生ツリー20は、ネイティブツリー10と14の結合であり、ネイティブツリー10のノードがノード22〜29を形成し、ネイティブツリー14のノードがノード30〜33を形成している。
【0033】
図4(C)および4(D)に概して示す方法によって、生ツリー20が論理ツリー222に変換される。生ツリー20から論理ツリー222に移行するために、開発者は生ツリーにヒントを挿入することができる。開発者は、生ツリー20内のノードに「それ自体を隠す」または「それ自体および子を隠す」、あるいは「ノードの子を隠す」などとしてマークすることができる。開発者はまた、ノードを横に移動することや、子の前にノードを配置することもできる。生ツリー20中のこれらの「ヒント」および修正を用いて、論理ツリー222を形成する。例えば、図4(C)で開発者は、ブロック40および41で示すように、生ツリー20のノード24〜26および33を関心なしとしてマークしている。通常、ユーザからは見えないことになる要素を含むノードは関心なしとしてマークされる。見えるUIに関係するノードは通常、関心ありと考えられ、ATクライアント300によって使用されるように論理ツリー222に含められる。図4(D)に示すように、関心なしとしてマークされたノードは、論理ツリー222に含められない。
【0034】
アクセシビリティシステム200は、論理ツリー222を使用して、イベントに関する情報、システムの状態、オブジェクトの位置、コントロールに関する情報を見つける。知られているシステムでは、それらのツリー内で範囲指定する機能がなかった。論理ツリー222は、クライアント300の選好に基づいてナビゲートすることができ、使用されているサーバ側アプリケーションにかかわらず情報を提供することができる。
【0035】
動作時、クライアント300がユーザのためにアプリケーションに関する情報を得る必要がある場合、クライアント300は、押すべきボタンを探し、ボタン上のテキストを観察する。クライアント300は、API「find an element(要素を見つける)」を呼び出すことになる。このAPIは、クライアント側インターフェース220の論理ツリー222中の位置を基準とする値を返す。論理ツリー222を介して、アクセシビリティシステム200は、使用されているアプリケーションにかかわらずUIの抽象ビューをクライアント300に提供する。この抽象モデルは、構造、プロパティ、イベントを含み、また、リストボックス、ボタン、またはその他のUIコンポーネントが相互と共通に有すると考えることのできる機能を含む。
【0036】
論理ツリー222は、UIの論理表現である単一の統合ツリーであり、クライアント300にとって関心のある要素だけを含む形状に形成されている。したがって、AT製品にUI要素の構造階層をフィルタリングさせて、エンドユーザに提示されるモデルにおいて推測させるのではなく、論理ツリー222は、エンドユーザに提示される構造にぴったりマッピングする階層を提示する。このことは、UIをユーザに対して記述するというAT製品のタスクを大幅に単純化し、ユーザがアプリケーションと対話するのを助ける。
【0037】
この論理UIツリー222はアクセシビリティシステム200の根底的な部分なので、アクセシビリティシステム200の他のコンポーネントはすべて、論理ツリー222から機能するように設計される。例えば、図6に簡単なダイアログボックス60を示すが、これは非常に単純な構造を有するように見える。しかし、現在利用可能なアクセシビリティ技術を通して見ると、このダイアログボックス60の構造は驚くほど複雑である。これは264個のオブジェクトを含み、AT製品はこれらをフィルタリングして、エンドユーザにとって意味のあるものを発見しなければならない。アクセシビリティシステム200と、論理UIツリー222に対するそのサポートとを用いれば、このダイアログボックス60を所有する開発者は、わずかなプロパティを設定して、図6に示す以下の構造をAT製品300に提示することができる。
【0038】
図6に示すように、「実行」ダイアログで、開発者は、フライングウィンドウグラフィック62と、63の「プログラム、フォルダ、文書、またはインターネットリソースの名前を入力して下さい。そうするとWindows(登録商標)がそれを開きます。」とを、関心ありとして指示することができる。開発者はまた、メモ帳、ワード、計算機などを含むコンボボックス64と、OK65、キャンセル66、閲覧67のボタンとを、関心ありとして指示することができる。これは、開発者がUIアクセシビリティシステム200を介して自分の要素階層にタグ付けし、それにより自分のアプリケーションのUIの論理表現を生み出すための、低コストの機構を開発者にもたらす。図示の各機能は、論理ツリー222中で他の各ノードと指定の関係を有するノードによって表すことができる。この論理表現は、テストチームに対して、およびAT製品またはクライアント300に対して、直接的な利益をもたらす。
【0039】
クライアント300は、APIのセットによってツリーに達することができる。機能には、(1)ポイントからポイントへの論理要素、(2)イベントからの論理要素、(3)現在フォーカスされている論理要素が含まれる。前述のように、論理要素はUIコンポーネントを表し、これは場合により、コントロール、コントロールの一部、あるいはコンテナまたは論理グループ(すなわちダイアログ、ペイン、またはフレーム)である。コントロールは、それらの機能の点で非常に多様である可能性がある。したがって、特定のタイプのコントロールに関連する機能を表すのに、種々のインターフェースが使用される。これらのコントロール特有インターフェースは、すべてのコントロールに共通の機能を表す共通ベースインターフェースから派生する。共通ベースインターフェースは、(1)論理ツリー222をナビゲートするためのメソッド、(2)プロパティ値を得るための一般的なメソッド、(3)サポートされるコントロール特有インターフェースにアクセスするためのメソッドを含む。論理ツリー222をナビゲートする際には、基礎をなす各アプリケーションUI技術が、それ自体のナビゲーション技術を提供することになる。
【0040】
ユーザにとって最終的に関心があるのは論理ツリー222だが、生要素ツリー20もまた、いくつかの重要な機能を果たす。論理ツリー222はユーザに関係する可能性のある要素だけしか含まないが、生要素ツリー20は、ノード22など、基礎をなすフレームワークの実装構造を表すノードも含む。例えばWin32UIフラグメントの場合、このツリーは、HWNDを表すノードを含むことになる。いくつかの点で、生要素ツリー20は、論理要素ツリー222と基礎をなすフレームワーク自体のネイティブ要素ツリーとの間の「中間施設」である。生要素ツリー20は、論理要素ツリー222を構築するための基礎として使用されるものであり、ネイティブ要素が最初にシステムにプラグインする場所である。
【0041】
生要素ツリー20は、デバッグおよびテストに使用することもできる。これは、問題を含む特定のノードがどこにあるかを正確に示すかまたは記述するのに有用である。ベース生要素ノードに関する機能には、生要素ツリーをナビゲートするためのメソッドと、対応する論理要素(もしあれば)にジャンプするためのメソッドと、例えばHWNDノードの場合の「HWND0x483FE」など、この要素に対する「デバッグ文字列」を含むプロパティと、その他の「背後にあるインフラストラクチャ」のメソッドとが含まれる。これらのその他のメソッドは、ヒットテストおよび位置決めと、イベントと、フレームワークが容易に提供することのできるプロパティ(例えばフォーカス(focused)、イネーブル(enabled))の公開とを可能にする。
【0042】
生要素ツリー20は、様々なレンダリングエンジンからの要素を表すノード22〜33を含む。生要素ツリーは、レンダリングエンジンがそれら自体をアクセシビリティシステム200にプラグインするための開始点として使用され、Win32からのHWNDなどのネイティブ要素を統合論理ツリー222に適合させる軽量アダプタオブジェクトから構築される。さらに、ある技術が別の技術をホストする場合に、ホスティング移行を処理するのにも使用される。生要素ツリー20は論理ツリー222が構築されるベースなので、論理ツリー222が完全であり接続されていることをチェックするために使用することができ、また、説明のつかない要素があるかどうかチェックするために使用することができる。生要素ツリー20はさらに、その他のインフラストラクチャのようなタスクに使用することもできる。すなわち、何らかの基本的な要素IDを提供することや、フォーカス、イネーブル、ロケーション(location)など、フレームワークによって提供される何らかの基本的な要素プロパティを提供することなどである。
【0043】
生要素ツリー20は、AT製品またはクライアント300のための主要な情報源ではなく、論理ナビゲーションには使用されず、エンドユーザには公開されない。生要素ツリー20はまた、将来のいずれかの時点で返せるようにツリー中の要素の位置を取り込むために使用することはできない。これらの機能はすべて、論理要素ツリー222が実施する。
【0044】
生要素ツリー20は通常、表される論理要素がわからなくても、基礎をなすレンダリング技術(HWND、Element)の生要素から機械的に構築することができる。したがって、これを使用して、論理ツリー222中で説明のつかなかった生要素を探すことができる。生要素ツリー20は、取り込まれるノードの位置の「スタックダンプ」のような記述を可能にするので、有用なデバッグおよび診断ツールである。さらに、知られているシステムでは、システムのツリーはコード特有の基準に基づき、種々の技術で実現するのが難しい。本手法は、一般的な抽象「生要素」型を使用する。これは、基礎をなす任意のレンダリング技術によって、またはそれに代わって実装することができる。
【0045】
生要素ツリーを得るには、生要素ルートを呼び出すとデスクトップ要素が得られる。この要素は、その親がNULLであり他のすべてのノードがそれを究極的な祖先とすることを確実にすることによって検証される。他の要素を得るには、生要素を指定のポイントから得るためのメソッドを呼び出すと、有効な画面座標を使用して要素が返される。生要素ツリーを得た後は、要素(親、兄弟、子)をチェックすることによって、生要素ツリーをチェックおよび検証することができる。
【0046】
動作時、クライアント300は、親、次の兄弟、前の兄弟、第1の子、最後の子などの関係を使用して、生要素ツリー20をナビゲートすることができる。次いでクライアント300は、生要素から論理ツリー222中の対応する論理要素にジャンプすることができる。
【0047】
(イベント機構)
クライアント300は、イベントがあり次第その通知を受けたい場合、図3に示すUI自動化クライアント202を介して登録して、情報を得ることができる。クライアント300は、受け取りたいオブジェクト情報と、情報がどこに行くようにしたいかと、返してもらいたいプロパティのリストとを指定する。クライアント要求は、UI自動化クライアント202に行く。UI自動化クライアント202は、デスクトップ上の任意のプロセスを監視することができる。UI自動化サーバ204は、どのクライアント300がリッスンしているかを常に把握しており、どのようにUI自動化クライアント202に返すかを知っている。UI自動化クライアント202はクライアントの関心をUIエンジン206に勧告し、したがってUIエンジン206は、いつイベントをUI自動化サーバ204に通知するかを知る。UIエンジンは、クライアント勧告を利用しなくてもよく、その代わり、イベントを常にUI自動化サーバ204に知らせるか、あるいはクライアントがいずれかのイベントをリッスンしている場合にだけUI自動化サーバに知らせることを選択することもできる。勧告は、イベントをリッスンしているクライアントがある場合にだけUIエンジンがUI自動化サーバ通知をオンにしたい場合に、有用である。これは、UIエンジンが、UIの速度低下の可能性を避けるため、および通常なら必要のないコードモジュールをロードするのを避けるために行うことになる。
【0048】
次いで、UIエンジン206は、UI自動化サーバ204にUIイベントを通知する。UI自動化サーバ204は、要求された論理要素をクライアント300に返し、クライアント300が要求したイベントのプロパティを含めた情報を、クライアント300に送る。UI自動化サーバ204は、どの情報がクライアント要求の範囲内かを決定し、情報が該当する場合にだけ、論理要素を形成する。論理要素の形成は、クライアントがイベント処理時に使用することになると指示したプロパティのセットを、UI自動化サーバ側でプリフェッチすることを含む。例えば、UI自動化サーバ204は、コンボボックスの論理要素を発見することができる。範囲は、コンボボックスまたはその子である。クライアント300は、登録段階の間に、子/親/従属部分を要求して範囲を定義することができる。
【0049】
UI自動化サーバ204は、情報が要求範囲内かどうかを判定した後、論理要素を構築する。UI自動化クライアント202は、ターゲットアプリケーションに問い合わせ、要求の情報をUI自動化サーバ204から受け取り、オブジェクトをクライアント300上の正しい空間にルーティングすることによって、クライアント300にサービスする。
【0050】
UI自動化サーバ204は、クライアント300がイベント通知の受信に登録したときに生み出される。例えば、UIエンジン206がMicrosoft Wordワードプロセッシングアプリケーションを実行している。クライアント300は、名前プロパティの変化に登録済みである。このクライアントの登録により、UI自動化サーバ204が生み出される。クライアントの登録によってまた、UIエンジン206は、名前プロパティについてUI自動化サーバ204に通知するのを開始するよう勧告される。UIエンジン206は、範囲情報は入手しない。UIエンジン206は、サーバ側用APIのうちの1つを呼び出す。UIエンジン206は、(1)どのプロパティが変化したか、(2)プロパティの新しい値、および(3)おそらくは古い値を指定する。UI自動化サーバ204は、クライアント300にとって関心のあるイベントに基づいて生み出されたのであり、したがって関心のあるイベント、プロパティ、クライアント、範囲を知っており、そのため、作成された論理要素に関心のあるクライアント300があるかどうかがわかる。複数のクライアント300が特定のUI自動化サーバ204とイベント登録した場合であって、これらのクライアント300が1つの同じイベントに登録し、返される論理要素と共にプロパティがバルクフェッチされるよう要求した場合は、各クライアント300は、UI自動化サーバ204がクライアント300にイベントを送り返したときに、返された論理要素と共に要求のバルクフェッチプロパティの結合を得ることになる。
【0051】
リッスンしている各クライアント300に対し、UI自動化サーバ204はクライアント300に通知して、イベントに関連する論理要素をクライアントに渡す。UI自動化サーバ204は、論理要素を1つだけ生み出す。これは、各クライアント300がイベントのソースであるオブジェクトの自分用コピーを要求する必要のある現行技術に勝る改良点である。
【0052】
クライアントがイベントに登録したときにUIエンジン206がUI自動化クライアントの勧告を利用しない場合、UIエンジン206は、リッスンしているアクセシビリティクライアント300があるかどうかをUI自動化サーバ204に尋ねることができ、どれもリッスンしていない場合は、情報を作成してUI自動化サーバ204に送る作業を回避することができる。例えば、クライアント300がスクリーンリーダであり、このスクリーンリーダは、どこに情報が行くようにしたいかと、イベントを受け取るフォーカス変化オブジェクトと、関心のあるプロパティの特定のリストとを指定する。UIエンジン206は、勧告を受けて、UI自動化サーバ204にイベントを送るべきであることを知る。フォーカス変化を検出すると、UIエンジン206は、UI自動化サーバ204に通知する。UI自動化サーバ204は、周知のインターフェースに変換し、イベントおよびオブジェクトをUI自動化クライアント202に送る。UI自動化クライアント202は、オブジェクトをクライアント300上の適切な空間にルーティングする。
【0053】
上述のコンポーネントは、カーネル中のイベント用中央リポジトリをなくすことで、知られているシステムよりも改良されている。そうではなくUI自動化サーバ204は、それが実行されているコンテキストに関する情報を得ることに関心のあるすべてのクライアント300を知っている。カーネルリポジトリをなくすことでまた、よりピアツーピアの対話が生み出される。というのは、以前はカーネル中で実施されていた機能を、UI自動化サーバ204が達成するからである。本発明のアクセシビリティシステム200は、何を見たいかを指定する能力をクライアント300に与え、それにより、サーバ側でUI自動化サーバ204を使用してフィルタリングが達成される。
【0054】
図7は、イベント登録および通知方法に関連する手順を示すフローチャートである。ステップ80で、クライアント300はイベント通知を要求する。ステップ82で、UI自動化クライアント202はこの要求をUI自動化サーバ204に通信する。ステップ84で、UI自動化クライアントは、通知が欲しいことをUIエンジン206に勧告する。ステップ86で、UI自動化サーバ204はUIエンジン206から通知を受け取る。ステップ88で、UI自動化サーバ204は受け取った情報をフィルタリングする。ステップ90で、受け取った情報がユーザにとって関心のないものであるとわかった場合は、UI自動化サーバ204は情報を廃棄し、ステップ92で引き続き通知を待機する。あるいは、ステップ90で情報が関心のあるものであるとわかった場合は、ステップ94で、UI自動化サーバ204は論理要素を作成し、UI自動化クライアント202に送る。ステップ96で、UI自動化クライアント202は、受け取った情報をクライアント300上におけるその正しい位置に配置する。
【0055】
アクセシビリティシステム200のイベント機構210により、クライアント300は、UIにおけるプロパティの変化、コントロールの構造におけるツリーの変化、マルチメディアイベント、および関連情報について通知を受け取ることに登録することができる。これらの機能がなければ、クライアント300は、システム内のすべてのUI要素を絶えずポーリングして、情報、構造、または状態に変化があったかどうか調べなければならない。アクセシビリティシステム200のイベント機構210によってまた、クライアント300は、プロセス外のイベントを受け取ることができ、プロパティの集まりがイベント通知と共に返されるよう要求することができ、複数の要素に関するイベントに登録することができる。
【0056】
イベント機構210は、AT製品またはテストアプリケーションがイベントに登録するために使用するインターフェースと、AT製品がイベント通知の受信に使用されるオブジェクトに対して実装するインターフェースと、制御インプリメンタがUIイベントをイベントエンジンに通知するために使用するインターフェースとを公開する。イベント機構210は、AT製品およびテストアプリケーションがUIのレンダリングに使用されるUIエンジンから独立してイベントを受け取れるようにするために使用され、また、基礎をなす技術にかかわらずAT製品およびテストアプリケーションが最上レベルのアプリケーションウィンドウを追跡してフォーカスできるようにする。
【0057】
図2に、クライアント300がどのようにアクセシビリティシステム200と対話するかを示す。プロセスにまたがる大域的なイベント管理はない。そうではなく、各アクセシビリティシステムクライアント300またはサーバ400が、それ自体のコンテキストを有する。クライアントアプリケーションは、アクセシビリティシステム200をサポートするアプリケーションについてのイベントだけを受け取る。アプリケーション中でアクセシビリティシステムイベントの使用を開始するには、クライアント300は、以下の4つのうちの1つを行うことができる。すなわち、(1)「AddTopLevelWindowListener」APIを使用して、デスクトップ上およびこのイベントに対するハンドラ中に現れる新しいUIを発見し、その他のイベントに登録し、これによって任意のプロセスからイベントを受け取ること、(2)Find APIの1つを使用して、関心のあるUIを突き止め、特定のUIをターゲットにすること、(3)画面上のウィンドウハンドルやポイントを見つけるなど、他の何らかの手段を使用して関心のあるUIを発見し、このハンドルまたはポイントを使用して、イベントをリッスンするための参照として使用する論理要素を獲得すること、または(4)「AddFocusChangedListener」APIを使用して、入力フォーカスを追跡し、フォーカスを現在有するUIに関するイベントに登録することである。
【0058】
最上レベルのウィンドウは、デスクトップを親に持つウィンドウである。「開かれた」という語を使用する場合、これは新しい最上レベルウィンドウがユーザに対して表示されたことを示す。「閉じた」という語を使用する場合、これは最上レベルのウィンドウが破壊されたことを示す。
【0059】
アクセシビリティシステムのサーバ側インターフェース230は、追加および削除されるイベントをアクセシビリティシステム200に通知するための、2つのAPIを含む。UI自動化クライアントは、クライアントがイベントに登録および登録解除するときにこれらのAPIを呼び出す。これによりUIエンジン206は、どのアクセシビリティイベントがそのコンテキストで要求されているかに関する情報を得ることができる。
【0060】
適用可能な場合、イベントは、アプリケーションの論理要素ツリー222からの論理要素に関連付けられる。論理要素が適用可能でない場合は、イベントは人間可読の文字列に、またはイベントソースを表すその他の周知のオブジェクトに関連付けられる。イベント機構210は、イベント登録中にユーザから供給された選好に基づいてフィルタリングを提供する。イベント関連データを作成してクライアントにプロセス間送信する前に、クライアントのフィルタリング選好をサーバで使用することにより、イベント機構210は本質的に、プロセス間呼出しの数を削減することでプロセス外性能を改善する。イベント機構210は、イベント登録中に関心のある論理要素のプロパティをそのイベントに対して指定する方法を提供する。これによってさらにプロセス間呼出しの数が削減される。イベント機構210は、大きなオペレーティングシステム(OS)変更を必要とすることなく拡張可能である。イベント機構210はマネージコードを使用して実現することができるが、アンマネージアプリケーションは、COM相互運用性を介してそれにアクセスすることができる。
【0061】
ATクライアント300がイベントを処理するために実施するタスクは2つある。すなわち、(1)イベント登録、(2)コールバックにおけるイベントの処理である。どちらのタスクにとっても重要な要件は、マネージコードとアンマネージコードの両方で使用可能であることである。本発明の一実施形態では、クライアント300はイベント登録時にインターフェースを渡すことができる。クライアント300は、周知のインターフェースを実装するオブジェクトを登録時に渡し、UIエンジン206は、これらのインターフェースに対してコールバックして、リスナに通知する。論理要素ツリー222中にソースオブジェクトがある場合、各コールバックは、ソース要素および追加のパラメータを受け取る。
【0062】
AT製品によって実装される周知のインターフェースが、イベントを返す方法として使用される。以下の章では、いくつかのタイプのイベントと、登録がどのようであるかと、イベントがどのように受け取られるかを示す。
【0063】
(1.最上レベルウィンドウのイベント)
最上レベルウィンドウのイベントには、メニューおよびコンボボックスドロップダウンに関するイベント、またはデスクトップを親に持つ任意の機能に関するイベントが含まれる。本発明の一実施形態では、AddTopLevelWindowListenerメソッドを使用して、開閉される最上レベルウィンドウの通知を受け取る。AddTopLevelWindowListenerを呼び出すと、現在のデスクトップ上で開かれた新しい最上レベルウィンドウまたは閉じられた最上レベルウィンドウについての通知が得られる。RemoveTopLevelWindowListenerメソッドは、デスクトップ上で開かれたかまたは閉じられた最上レベルウィンドウについての通知を受け取るのを停止するための機構を提供する。このメソッドは、コールバックオブジェクトを使用してこのリスナを識別する。したがって、RemoveTopLevelWindowListenerメソッドに渡されるオブジェクトは、AddTopLevelWindowListenerに渡されるオブジェクトと同じである。開かれた新しい最上レベルウィンドウそれぞれにつき一度、OnTopLevelWindowOpenedメソッドがアクセシビリティシステム200によって呼び出される。同様に、最上レベルウィンドウが閉じられたときに一度、OnTopLevelWindowClosedメソッドをアクセシビリティシステム200によって呼び出すことができる。これらの通知を受け取るために、クライアント300は、AddTopLevelWindowListenerメソッドを呼び出す。
【0064】
(2.フォーカスイベント)
クライアント300はしばしば、フォーカスを追跡するためのメソッドを必要とする。Microsoft Windows(登録商標)OSでこれを行うのは難しい。例えば、メニュー(例えばMicrosoft Wordのファイルメニュー)がドロップダウンされるとき、ユーザがカーソルをメニュー中の各項目に沿って下げるにつれて、各項目がフォーカスを得る。今日では、メニューが閉じたとき(例えばユーザがESCキーを押したとき)、フォーカスイベントは送られない。そうではなく、フォーカスの変化に関心のあるクライアントは、いくつかのイベントをリッスンして、それらのうちのどれが論理的にフォーカス変化を表すかを理解しなければならない。本発明の一実施形態では、AddFocusChangedListenerメソッドを使用して、フォーカス変化イベントをリスナに通知することができる。クライアント300は、返されるプロパティのセットを指定することができる。この、論理要素と共に返すプロパティを指定する機能は、すべてのイベント登録APIの一部である。クライアント300は、RemoveFocusChangedListenerメソッドを呼び出して、フォーカス変化についての通知を受け取るのを停止することができる。このメソッドは、コールバックオブジェクトを使用してこのリスナを識別することができ、この場合、RemoveFocusChangedListenerメソッドに渡されるオブジェクトは、AddFocusChangedListenerプロシージャに渡されるオブジェクトと同じになる。フォーカスが変化したとき、アクセシビリティシステム200は、OnFocusChangedメソッドを呼び出す。OnFocusChangedメソッド中で使用されるFocusEventArgsパラメータが、フォーカスの変化に関係する情報を公開する。最後にフォーカスされた論理要素に関する情報が入手可能な場合は、この要素は、OnFocusChanged要素中で使用されるevent argsパラメータ中で入手可能になる。何かが明示的に要素にフォーカスを当てるまではどのUI要素もフォーカスを有さない場合もある。
【0065】
(3.プロパティ変化イベント)
プロパティ変化イベントは、論理要素のプロパティが変化したときに発火される。本発明の一実施形態では、クライアント300は、AddPropertyChangedListenerメソッドを呼び出して、プロパティ変化についての通知を受け取る。AddPropertyChangedListener中で指定された論理要素ツリー内の論理要素に関するプロパティの値が変化したとき、OnPropertyChangedメソッドがアクセシビリティシステム200によって呼び出される。範囲パラメータが、どの要素に対してイベントを発火すべきかを示す。例えば、ウィンドウのルート論理要素と子孫要求とを渡すと、プロパティ変化コールバックはそのウィンドウに制限される。範囲パラメータがツリー中のすべての要素に設定されている場合は、範囲は無視され、デスクトップ上で生じた指定のプロパティのどんな変化も送られる。クライアント300は、AddPropertyChangedListenerを、異なるプロパティセットおよび/または異なるコールバックオブジェクトで複数回呼び出すことができる。アクセシビリティシステム200によって提供される通知は、変化したプロパティと、新しいプロパティ値と、入手可能なら古いプロパティ値とを示す。
【0066】
クライアント300は、RemovePropertyChangedListenerメソッドを呼び出して、プロパティ変化についての通知を受け取るのを停止することができる。このメソッドは、範囲要素およびコールバックオブジェクトを使用してこのリスナを識別することができ、この場合、渡されるオブジェクトは、AddPropertyChangedListenerに渡されるオブジェクトと同じでなければならない。
【0067】
(4.コントロールパターンからのイベント)
コントロールパターンから発火されるイベントは、拡張可能である必要があり、したがってこれらのイベントはGUIDで識別される。登録時、任意のGUID値が受け入れられる。新しいコントロールパターンの場合、それがドキュメントするイベントは、固有のGUIDである必要がある。AT製品は、新しいコントロールパターンのイベントをリッスンするよう修正されることが必要な場合がある。リスナはまた、これらのイベントを範囲指定できる必要がある。例えば、管理されたテストでは、これらのイベントを特定のアプリケーションに、またはアプリケーション内のコントロールに制限したい場合がある。コントロールパターンは何がソースかを定義し、イベントコンシューマは、どのようにソース要素およびイベント引数オブジェクトを使用するかを知るために、ドキュメンテーションのその部分を参照する必要がある。
【0068】
AddEventListenerメソッドは、クライアント300がコントロールについてのイベントを受け取ることを可能にする。範囲パラメータを使用して、どの要素に対してイベントを発火するかを指示することができる。例えば、ウィンドウのルート論理要素を渡して子孫を要求すると、イベントはそのウィンドウに制限される。ツリー中のすべての要素が望まれる場合は、デスクトップ上のすべてのイベントが送られる。RemoveEventListenerメソッドを使用して、コントロールについてのイベントを受け取るのを停止することができる。このメソッドは、範囲要素とコールバックオブジェクトとイベント識別子とを使用して、リスナを識別することができる。この場合、渡されるオブジェクトは、AddEventListenerに渡されるオブジェクトと同じでなければならない。
【0069】
アプリケーションがAddEventListenerメソッドを呼び出すと、コントロール特有のイベントが発火されてイベントソースがAddEventListener中で指定された論理要素ツリー内の論理要素であるとき、OnEventメソッドがアクセシビリティシステム200によって呼び出される。コントロールについてのイベントが発火されるときは、イベント特有の情報がしばしば入手可能である。
【0070】
RemoveAllListenersメソッドを呼び出して、どんなイベントを受け取るのも停止することができる。これは、クライアントアプリケーションがシャットダウンする前にクリーンアップするための素早い方法である。この削除メソッドは、アプリケーション終了時に使用することができるのが最適である。
【0071】
(5.論理構造変化イベント)
論理構造変化イベントは、論理要素ツリーの構造が変化したときに発火される。AddLogicalStructureChangedListenerメソッドを実施して、論理要素ツリーの構造変化についての通知を受け取ることができる。論理要素が追加、削除、または無効にされるとき、指定のコールバックオブジェクトに対するメソッドが呼び出される。前述のように、範囲パラメータが要素を制限することができる。RemoveLogicalStructureChangedListenerメソッドを呼び出して、論理要素ツリーの変化についてのイベントを受け取るのを停止することができる。このメソッドは、コールバックオブジェクトおよび範囲要素を使用してこのリスナを識別することができ、この場合、渡されるオブジェクトは、AddEventListenerに渡されるオブジェクトと同じでなければならない。
【0072】
子要素が追加されるときであって、親がAddLogicalStructureChangedListener中で指定された論理要素ツリー222内の論理要素であるときは、OnChildAddedメソッドをアクセシビリティシステム200によって呼び出すことができる。子要素が削除されるときであって、古い親がAddLogicalStructureChangedListener中で指定された論理要素ツリー内の論理要素であるときは、OnChildRemovedメソッドがアクセシビリティシステム200によって呼び出される。
【0073】
短時間に多数の子(例えば20個を超える子)が追加されるときは、OnChildrenBulkAddedメソッドがアクセシビリティシステムによって呼び出される。短時間に多数の子が削除されるときは、OnChildrenBulkRemovedメソッドがアクセシビリティシステムによって呼び出される。短時間に多数の子(例えば20個を超える子)の追加と削除の両方が行われるときは、OnChildrenInvalidatedメソッドがアクセシビリティシステム200によって呼び出される。
【0074】
(6.マルチメディアイベント)
別のタイプのイベントは、マルチメディアイベントである。マルチメディアには、音声、ビデオ、アニメーションを含めることができる。メソッドは、マルチメディアイベントをサポートし、「停止された」「一時停止された」「早送りされた」「巻戻された」「ミュートにされた」を含めたアクションをクライアントに通知する。前述と同様のメソッドを実施して、マルチメディアリスナを追加および削除することができる。
【0075】
(7.単純音声イベント)
単純音声イベントは、マルチメディアイベントとは別に扱うことができる。単純音声イベントは、音声自体以外の何らかのイベントをユーザに伝えるために存在する、単純かつ短時間の音声を表す。単純音声イベントには、新しいメールが到着したときに再生される音声、ラップトップの電池が低いときに生成される音声、またはIconExclamationタイプのメッセージボックスが表示されるときに再生される音声を含めることができる。AddSoundListenerメソッドを呼び出して、再生される単純音声の通知を受け取ることができ、RemoveSoundListenerメソッドを実施して、単純音声イベントについての通知を受け取るのを停止することができる。
【0076】
単純音声が再生されたとき、OnSoundメソッドがアクセシビリティシステム200によって呼び出される。この通知を受け取るために、リッスンしているアプリケーションは、AddSoundListenerを呼び出す。OnSoundメソッドは、音声の名前と、音声のソースと、ユーザに対する音声の重要性を示すアラートレベル値との情報を取り出す。可能なアラートレベルには、重要性が未知であることを示す「未知」と、情報が提示されたことを示す「情報」と、警告条件を示す「警告」と、ユーザ応答が必要であることを示す「疑問」と、イベントがクリティカルではないが重要かもしれないことを示す「感嘆符」と、クリティカルなイベントの発生を示す「クリティカル」が含まれる。
【0077】
(8.ソフトフォーカスイベント)
ソフトフォーカスイベントは、デスクトップ上に現れるが背景にとどまっているものである。ソフトフォーカスイベントのいくつかの例としては、通知領域で「新しい更新が利用可能です」と示すバルーンヘルプウィンドウと、フォーカスを得たい背景アプリケーションについての、タスクバー中の点滅アイコンと、印刷が開始および終了したときに通知トレイから現れて消えるプリンタアイコンがある。これらのイベントは、他のイベント範疇といくぶん重複するように思われるかもしれない(ソフトフォーカスがするのと同様に、マルチメディアもアニメーションイベントを含む場合がある)。しかしイベントは、それがどのように伝えられるかではなく、何をユーザに伝えるかに基づいて範疇化される。
【0078】
入力フォーカスを利用せずにユーザの注意を引こうとするイベントの通知を、AddSoftFocusListenerメソッドを実施して受け取ることができる。RemoveSoftFocusListenerメソッドは通知を停止する。このメソッドは、コールバックオブジェクトを使用してリスナを識別することができ、したがって、渡されるオブジェクトは、AddSoftFocusListenerに渡されるオブジェクトと同じのはずである。
【0079】
ソフトフォーカスイベントが発生したとき、OnSoftFocusメソッドをアクセシビリティシステム200によって呼び出すことができる。この通知を受け取るために、リッスンしているアプリケーションまたはクライアント300は、AddSoftFocusListenerを呼び出す。ソース要素が利用可能なら、これを使用してイベントに関するより多くの情報を得ることができる。ソース要素の一例は、システムトレー中の通知アプリケーションのうちの1つによって使用されるバルーンヘルプウィンドウの論理ルート要素であろう。OnSoftFocusメソッドは、イベントの名前と、イベントのソースと、ユーザに対するイベントの重要性を示すアラートレベルとを返す。
【0080】
以下の表に、クライアント300がAddTopLevelWindowListener APIを使用して特定のプロセスからのイベントをリッスンするときの、クライアント300およびアクセシビリティシステム200のアクションを示す。
【0081】
【表1】
【0082】
(イベント通知)
サーバ400または基礎をなすUIエンジンは、対応するイベント通知メソッドを使用して、上に挙げたアクセシビリティシステムイベントをサポートする。UI自動化サーバAPIは、サーバまたは基礎をなすUIエンジンがこれを達成するために呼び出すことのできるメソッドを含む。例えば、論理要素上で特定のプロパティが変化したときにサーバが通知するために呼び出すNotifyPropertyChangedメソッドがある。UIが変化したときに適切なパラメータを生成してこれらの通知メソッドを呼び出すことは、サーバ400または基礎をなすUIエンジンの任務である。
【0083】
(サーバメソッド)
クライアント300がイベントを要求しているとき、AdviseEventAddedメソッドおよびAdviseEventRemovedメソッドがUI自動化クライアントによって呼び出されて、サーバ400に通知される。これによりサーバ400は、関心のあるイベントがない場合にはアクセシビリティシステム200にイベントを伝搬しないようにすることができる。サーバは、これらの通知を用いて、それらのイベントを使用しているクライアントがいるかどうかに性能が依存するようにすることができる。
【0084】
(コントロールパターン)
アクセシビリティモデルは、特定のUI要素またはコントロールによってサポートされる機能を範疇化および公開するための独自の手法を提供する。従来技術のように機能を特定のコントロールタイプ(例えばボタン、編集ボックス、またはリストボックス)に関連付けるのではなく、アクセシビリティモデルは、共通コントロールパターンのセットを定義し、各パターンはUI挙動の1つの面を定義する。これらのパターンは相互に独立しているので、これらを組み合わせて、特定のUI要素によってサポートされる機能の完全なセットを記述することができる。
【0085】
例えば、要素をそのクラス名(Buttonなど)で記述するのではなく、アクセシビリティシステム200は、呼出し可能なコントロールパターンをサポートするものとして要素を記述する。コントロールパターンは、要素によってサポートされる、構造、プロパティ、イベント、メソッドを定義する。したがって、これらのパターンにより、クライアントはコントロールの挙動を照会することができるだけでなく、特定のパターン用に設計されたインターフェースを使用してコントロールをプログラムに基づいて操作することもできる。例えば、SelectionContainerパターンは、選択された項目を照会するためのメソッド、特定の項目を選択または選択解除するためのメソッド、あるいは、コントロールが単一の選択モードをサポートするか複数の選択モードをサポートするかを決定するためのメソッドを提供する。
【0086】
アクセシビリティシステム200に対して現在定義されているコントロールパターンには、(1)選択コンテナ、(2)階層、(3)呼出し可能、(4)単純グリッド、(5)テキスト、(6)値、(7)オブジェクトを表す、(8)スクロール可能、(9)ソート可能、(10)ドローイング、(11)その他のコンテナが含まれる。
【0087】
この技法により、コントロール開発者は、新しいタイプのコントロールを実装することができ、その挙動をAT製品およびテストスクリプトに公開するための明確な手法もなお有する。新しいタイプの挙動が導入される場合、新しいコントロールパターンを定義して必要な機能を表すことができる。
【0088】
支援技術製品およびテストスクリプトは今や、各UIコントロールによってではなく、各パターンによってどのように機能するかを理解するように書くことができる。コントロールパターンはコントロールクラスよりもずっと少ないので、この技法は、必要なコードを最小限に抑える。この手法はまた、新しいコントロールを効果的に問合せおよび操作することのできる、よりフレキシブルなアーキテクチャを奨励する(新しいコントロールが既知のコントロールパターンをサポートする限り)。
【0089】
以下の表に、共通コントロールとそれらがサポートするパターンの、いくつかの例を提供する。
【0090】
【表2】
【0091】
より具体的なインターフェースを使用すると、共通コントロールパターンに関連する機能が公開される。これらのパターンの例には、(1)選択管理コンテナ、(2)グリッドレイアウトコンテナ、(3)値を含むUI要素、(4)オブジェクト(ファイル、eメールなど)を表すアイコン、(5)呼び出すことのできるUI要素が含まれる。一般に、これらのパターンは特定のコントロールに密に結び付いたものではなく、異なるコントロールが同じパターンを実装することもできる。例えば、リストボックス、コンボボックス、ツリービューはすべて、「選択管理コンテナ」パターンを実装する。いくつかのコントロールは、適切なら複数のパターンを実装することができる。すなわち、選択グリッドが「グリッドレイアウトコンテナ」パターンと「選択管理コンテナ」パターンの両方を実装することになる。
【0092】
以前のアプリケーションのように単一の「ロール(role)」プロパティはない。そうではなく、2つの別々の機構が使用される。コントロールパターンが、コントロールについての利用可能な機能を決定し、人間可読のローカライズ可能プロパティが、「ボタン(button)」や「リストボックス(list box)」など、ユーザが理解できるコントロールタイプ名を提供する。
【0093】
(プロパティ)
アクセシビリティシステム200は、一般的なGetPropertyメソッドを特徴づけることになる。プロパティはGUIDで表されることが好ましく、ユーティリティメソッドを使用して、ローカライズ不可能なニーモニック形式(スクリプティングおよび構成ファイルに有用である)との間で変換し、ローカライズされた記述も得る。個別のメソッドではなく一般的なGetPropertyメソッドであることの2つの重要な利点は、(a)インターフェースを変更せずに時の経過に伴って新しいプロパティを追加することができること、および(b)アレイ駆動型バルクプロパティフェッチングなど、別々のメソッドを使用したときには不可能な実装技術を可能にすることである。各プロパティは、明確に定義された意図を有さなければならない。プロパティが人間によって消費されるように意図されているか機械によって消費されるように意図されているか、プロパティがローカライズされるかどうかなどが、明確に定義されなければならない。
【0094】
本発明を特定の実施形態に関して述べたが、これらの実施形態は、あらゆる点で限定的ではなく例示的なものである。本発明が関連する当業者には、その範囲を逸脱することなく代替実施形態も明らかになるであろう。
【0095】
以上のことから、本発明は、自明であり本システムおよび方法に内在するその他の利点と共に、前述のすべての目標および目的を達成するようにうまく適合されたものであることがわかるであろう。いくつかの特徴およびサブコンビネーションは、他の特徴およびサブコンビネーションを参照しなくても有用であり採用することができることは理解されるであろう。このことを、特許請求の範囲によって企図する。
【技術分野】
【0001】
本発明は、支援技術(assistive technology)製品および自動テスト製品、ならびにこれらの製品とユーザインターフェース情報との対話の分野に関する。
【背景技術】
【0002】
支援技術(AT)製品は、学習や、コミュニケーションや、コンピュータソフトウェアに含まれる、またコンピュータソフトウェアによって提示される情報へのアクセスの領域において支援を必要とするコンピュータユーザを補助するために存在する。これらの製品は、コンピュータインターフェースに関連する情報を必要とする。同様に、既存の自動テスト製品およびユーザインターフェースコマンディングユーティリティも、ユーザインターフェースに関する情報を必要とする。現在、これらの製品には、ユーザインターフェース(UI)情報のソースが十分にない。この3つのタイプの製品(クライアント)は、(1)アプリケーションのユーザインターフェースに関する情報を収集すること、(2)UIを構築するために使用されている技術にかかわらずプログラムに基づいてUI要素を発見し問い合わせること、(3)キーボード入力およびポインタ入力を生成すること、(4)どのタイプの挙動または機能が現在利用可能かを理解することを可能にするために、必要なサポートをどこか他の場所から得る必要がある。これらすべての機能をAT製品に提供する現在利用可能な技術は、1つとしてない。さらに、現在のAT製品は、すべてのグラフィカルオペレーティングシステム(OS)技術に適合するとは限らず、また、余分な通知または誤解を招く通知を一元的にフィルタリングし調整を図ることができない。もう1つの欠点として、現在の自動化およびアクセシビリティインフラストラクチャは拡張可能ではなく、そのため、新しい機能を追加するにはOSレベルの変更が必要である。
【0003】
さらに、現在、アプリケーションのユーザインターフェースに関する情報を収集するには、AT製品は、ユーザに対する情報を得るためにアプリケーション特有コードを書かなければならない。このアプリケーション特有コードを書くプロセスは、時間がかかり、継続的な保守を必要とする。現在の自動化インフラストラクチャもまた、余分なまたは誤解を招くイベント通知を一貫性のある方式でフィルタリングし調整を図ることができない。そのため、イベントコンシューマが独自に情報をフィルタリングする必要がある。
【0004】
現在のシステムでは、AT製品は、イベント通知を3つの細分性レベルで要求することができる。すなわち、(1)デスクトップ上のあらゆるもの、(2)特定のプロセス中(ワードプロセッサの立上げなど)、または(3)特定プロセス中のスレッド中(プロセス中で働いている複数のオブジェクト)である。現在、クライアントがイベントを受け取るとき、クライアントは、イベントが発生した特定のウィンドウに対するウィンドウハンドルと、イベントがどこで発生したかを示すその他の情報ビットとを受け取る。クライアントは、プロセス間呼出しを行って、イベントに関係するUIオブジェクトを取り出すことができる。このオブジェクトを使用して、クライアントは、追加のプロセス間呼出しを行ってこのオブジェクトに関する情報を要求することができる。クライアントが5つの情報を必要とする場合、クライアントは5つのプロセス間呼出しを行わなければならない。プロセス間呼出しは非常に遅く、そのため、現在のアクセシビリティインフラストラクチャを使用してUI情報を収集することの性能コストは高い。図8に、このタイプの既知のシナリオを示す。サーバアプリケーション12がイベント6を発火(fire)する。カーネル14が、どのクライアントが通知を受けなければならないかを決定し、当該のクライアント10にイベント通知18を送る。クライアント10は、イベント通知18に関係するオブジェクトを求める要求16を、プロセス境界2をまたいでサーバアプリケーション12に送る。サーバアプリケーション12はオブジェクト20を返し、次いでクライアント10は、イベントを発火したUIコントロールに関する情報を求める要求16の送信を開始することができる。サーバアプリケーション12は、要求された情報20を、プロセス境界2をまたいでクライアント10に返す。
【0005】
別の現行オプションでは、クライアントコードをプロセス内のダイナミックリンクライブラリ(.DLL)としてロードすることができる。このオプションはいくつかの欠点を有する。第1に、クライアントコードをプロセスにロードするために、システムからの協力を必要とする。第2に、クライアントコードがアプリケーションのプロセスにロードされた後は、それが収集する情報を制限するのが難しいので、セキュリティ問題を引き起こす。第3に、クライアントにとって効果的な技法であるためには、システム上のあらゆるプロセスにロードしなければならない。信用できるクライアントだけを別のアプリケーションのプロセスにロードできるべきであるのが最適である。
【0006】
さらに、どのイベント通知を受け取りたいかを指定する能力をクライアントに与えるシステムも必要である。知られているシステムでは、クライアントは、いくつかのプロセス間呼出しを行い、次いで情報を分析して、そのイベントに関心があるかどうかを判定することが必要な場合がある。このイベントフィルタリングをより高性能な方式で実施することができ、新しいシステムイベントまたはアプリケーションイベントをサポートするよう容易に更新することができる機構が必要とされている。さらに、セキュリティ問題を軽減するために、信用できるコンポーネントだけを使用するシステムも必要とされている。
【0007】
現在、ユーザインターフェースに関する情報を探すとき、AT製品は、特定のUIフレームワークにネイティブであるツリーにアクセスする必要がある。そのため、複数のUIフレームワークについてのユーザインターフェース情報を伝えるには、複数のツリーが必要である。これらの異なるツリーは、エンドユーザによって操作される可視のUIコントロールを管理する隠れたコンテナオブジェクトなど、ユーザにとって関心がないかまたは見えない情報を含む場合がある。したがって、ユーザにとって関心のあるノードだけを有する単一の統合ツリーが存在する必要がある。
【発明の概要】
【発明が解決しようとする課題】
【0008】
AT製品、自動テストツール、コマンディングユーティリティのニーズに対処する解決法が必要とされている。この解決法は、すべてのグラフィカルOS技術によって使用可能であるべきであり、すべての形のUIおよびUIコンポーネントをアクセス可能にすることができるべきである。
【課題を解決するための手段】
【0009】
本発明は、クライアントにユーザインターフェース情報を提供するための方法およびコンピュータアプリケーションを対象とする。本発明の一態様では、クライアントにユーザインターフェース情報を提供するためのアクセシビリティシステムが提供される。アクセシビリティシステムは、ユーザインターフェース情報がクライアントにとって関心のあるものかどうかに基づいて情報をフィルタリングするためのユーザインターフェース自動化サービスを含むアクセシビリティシステムコアを備える。アクセシビリティシステムは追加で、クライアントにとって関心のあるユーザインターフェース情報を見えるようにすると共にクライアントにとって関心のないユーザインターフェース情報を隠すための論理ツリーを含むクライアント側インターフェースも備える。アクセシビリティシステムはまた、サーバ側アプリケーションを構築するために使用されているユーザインターフェースエンジンにかかわらずサーバ側アプリケーションからの情報転送を容易にするための、サーバ側インターフェースも備える。
【0010】
本発明の別の態様では、クライアントにユーザインターフェース情報を提供するためのコンピュータ実施方法が提供される。この方法は、アクセシビリティシステム自動化サービスによってユーザインターフェース情報を監視すること、および、サーバ側技術にかかわらずサーバ側インターフェースを介してユーザインターフェース情報を転送することを含む。この方法はさらに、クライアント側インターフェースの一部を形成する論理要素ツリーを使用して、クライアントにとって関心のある特定のユーザインターフェース情報を決定することも含む。
【0011】
本発明の追加の利点および新規な特徴については以下の記述に示すが、その一部は以下の記述を検討すれば当業者には明らかであろうし、あるいは本発明の実施からわかるであろう。
【0012】
以下、添付の図面を参照しながら本発明を述べる。
【図面の簡単な説明】
【0013】
【図1】本発明を実施する際に使用するのに好適なコンピューティングシステム環境のブロック図である。
【図2】アクセシビリティシステム、クライアント環境、サーバ環境の間の対話のブロック図である。
【図3】アクセシビリティシステムコアのコンポーネントを示すブロック図である。
【図4A】ネイティブ要素から論理ツリーを生み出すことを示す図である。
【図4B】ネイティブ要素から論理ツリーを生み出すことを示す図である。
【図4C】ネイティブ要素から論理ツリーを生み出すことを示す図である。
【図4D】ネイティブ要素から論理ツリーを生み出すことを示す図である。
【図5】論理ツリーを構築するための一連の手順を示すフローチャートである。
【図6】ダイアログボックスと、論理要素を形成するそのコンポーネントを示す図である。
【図7】本発明のイベント機構をアクティブ化することに関連する手順を示すフローチャートである。
【図8】既知のイベント通知システムを示す図である。
【発明を実施するための形態】
【0014】
図1に、本発明を実施することのできる好適なコンピューティングシステム環境の例100を示す。コンピューティングシステム環境100は、好適なコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲についてどんな制限も意味しない。またコンピューティング環境100は、この例示的な動作環境100に示すコンポーネントのいずれか1つまたは組合せに関してどんな依存や要件を有するものとも解釈すべきではない。
【0015】
本発明は、プログラムモジュールなど、コンピュータによって実行されるコンピュータ実行可能命令の一般的なコンテキストで述べることができる。一般にプログラムモジュールは、特定のタスクを実施するか特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、本発明は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な民生用電子機器、ミニコンピュータ、メインフレームコンピュータなどを含めて、その他のコンピュータシステム構成で実施することもできることは、当業者なら理解するであろう。本発明はまた、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実施される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶デバイスを含めたローカルとリモートの両方のコンピュータ記憶媒体に位置することができる。
【0016】
図1を参照すると、本発明を実施するための例示的なシステム100は、コンピュータ110の形の汎用コンピューティングデバイスを含み、コンピュータ110は、処理ユニット120と、システムメモリ130と、システムメモリを含めた様々なシステムコンポーネントを処理ユニット120に結合するシステムバス121とを備える。
【0017】
コンピュータ110は通常、様々なコンピュータ可読媒体を備える。限定ではなく例として、コンピュータ可読媒体には、コンピュータ記憶媒体および通信媒体を含めることができる。システムメモリ130は、読取り専用メモリ(ROM)131やランダムアクセスメモリ(RAM)132など、揮発性および/または不揮発性メモリの形のコンピュータ記憶媒体を含む。ROM131には通常、起動中などにコンピュータ110内の要素間で情報を転送するのを助ける基本ルーチンを含むBIOS(basic input/output system)133が記憶されている。RAM132は通常、処理ユニット120がすぐにアクセス可能な、かつ/または処理ユニット120が現在作用している、データおよび/またはプログラムモジュールを含む。限定ではなく例として、図1には、オペレーティングシステム134、アプリケーションプログラム135、その他のプログラムモジュール136、プログラムデータ137を示す。
【0018】
コンピュータ110は、その他の着脱式/固定式、揮発性/不揮発性のコンピュータ記憶媒体を備えることもできる。例にすぎないが図1には、固定式かつ不揮発性の磁気媒体に対して読み書きするハードディスクドライブ141と、着脱式の不揮発性の磁気ディスク152に対して読み書きする磁気ディスクドライブ151と、CD ROMやその他の光媒体など着脱式の不揮発性の光ディスク156に対して読み書きする光ディスクドライブ155を示す。この例示的な動作環境で使用することのできるその他の着脱式/固定式、揮発性/不揮発性のコンピュータ記憶媒体には、限定しないが磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、固体RAM、固体ROMなどが含まれる。ハードディスクドライブ141は通常、インターフェース140などの固定式メモリインターフェースを介してシステムバス121に接続され、磁気ディスクドライブ151および光ディスクドライブ155は通常、インターフェース150などの着脱式メモリインターフェースでシステムバス121に接続される。
【0019】
以上に論じ図1に示したドライブおよびそれらに関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、その他のデータの記憶域をコンピュータ110に提供する。例えば図1には、ハードディスクドライブ141がオペレーティングシステム144、アプリケーションプログラム145、その他のプログラムモジュール146、プログラムデータ147を記憶しているのが示されている。これらのコンポーネントは、オペレーティングシステム134、アプリケーションプログラム135、その他のプログラムモジュール136、プログラムデータ137と同じものとすることもでき、異なるものとすることもできることに留意されたい。ここでは、オペレーティングシステム144、アプリケーションプログラム145、その他のプログラムモジュール146、プログラムデータ147が少なくとも異なるコピーであることを示すために、異なる番号を付けてある。ユーザは、キーボード162、マウスやトラックボールやタッチパッドと一般に呼ばれるポインティングデバイス161などの入力デバイスを介して、コンピュータ110にコマンドおよび情報を入力することができる。その他の入力デバイス(図示せず)には、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどを含めることができる。これらおよび他の入力デバイスは、システムバスに結合されたユーザ入力インターフェース160を介して処理ユニット120に接続されることが多いが、パラレルポート、ゲームポート、ユニバーサルシリアルバス(「USB」)など、その他のインターフェースおよびバス構造で接続されてもよい。モニタ191または他のタイプの表示デバイスも、ビデオインターフェース190などのインターフェースを介してシステムバス121に接続される。モニタに加えて、コンピュータは通常、スピーカ197やプリンタ196など他の周辺出力デバイスも備えることができ、これらは出力周辺インターフェース195を介して接続することができる。
【0020】
本発明においてコンピュータ110は、リモートコンピュータ180など1つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク化された環境で動作することができる。リモートコンピュータ180はパーソナルコンピュータとすることができ、図1にはメモリ記憶デバイス181しか示していないが、通常はコンピュータ110に関して上述した要素の多くまたはすべてを備える。図1に示す論理接続は、ローカルエリアネットワーク(LAN)171およびワイドエリアネットワーク(WAN)173を含むが、その他のネットワークを含むこともできる。
【0021】
LANネットワーキング環境で使用されるときは、コンピュータ110は、ネットワークインターフェースまたはアダプタ170を介してLAN171に接続される。WANネットワーキング環境で使用されるときは、コンピュータ110は通常、インターネットなどのWAN173を介した通信を確立するためのモデム172または他の手段を備える。モデム172は内蔵でも外付けでもよく、ユーザ入力インターフェース160または他の適切な機構を介してシステムバス121に接続することができる。ネットワーク化された環境では、コンピュータ110に関して示したプログラムモジュールまたはその一部をリモートのメモリ記憶デバイスに記憶することができる。限定ではなく例として、図1には、リモートアプリケーションプログラム185がメモリデバイス181上にあるものとして示す。図示のネットワーク接続は例示的なものであり、コンピュータ間で通信リンクを確立するための他の手段を使用してもよいことは理解されるであろう。
【0022】
コンピュータ110のその他多くの内部コンポーネントは図示していないが、そのようなコンポーネントおよび相互接続が周知であることは、当業者なら理解するであろう。したがって、コンピュータ110の内部構造に関するこれ以上の詳細は、本発明に関して開示する必要はない。
【0023】
(アクセシビリティシステムの構造)
図2に示すように、アクセシビリティシステム200は、クライアント環境300およびサーバ環境400と対話する。アクセシビリティシステム200は、図1に関して上述したコンピュータ環境100内で実施することができる。アクセシビリティシステム200は、クライアント300との対話を容易にするためのクライアント側アクセシビリティインターフェース220と、サーバ側400との対話を容易にするためのサーバ側アクセシビリティインターフェース230と、アクセシビリティシステムコア201とを備える。本発明のアクセシビリティシステム200は、プログラムに基づいてユーザインターフェース(UI)にアクセスするための、新しいアプリケーションプログラムインターフェース(API)、インターフェース、メタファーを提供する。アクセシビリティシステム200では、アプリケーションが、アプリケーション自体と、アプリケーションが使用する任意のコンポーネントとをアクセス可能にすることができる。
【0024】
クライアント環境300は、支援技術(AT)製品または自動UIテストツールを含むことが好ましい。サーバ側400は、図2に示す様々な異なる技術を実装することができる。サーバシステム410はアダプタ412およびコア414を含み、これらは第1タイプのUIに見ることができるものである。サーバシステム420はプロキシコンポーネント422およびコントロール424を含み、これらはワシントン州レドモンドのMicrosoft Corporationから出ているMicrosoft Operating System製品で利用可能なWin32UIなど、第2タイプのUIに見ることができるものである。サーバシステム430はアダプタ432および内部OM434を含み、これらは代替の第3タイプのUIに見ることができるものである。
【0025】
図3に示すように、アクセシビリティシステム200にはイベント機構210が備わるが、このイベント機構210は、クライアント環境300との、およびサーバ環境400との対話を容易にするために、UI自動化クライアント202およびUI自動化サーバ204に依拠する。UI自動化クライアント202およびUI自動化サーバ204については、後で本発明のイベント機構210に関してより詳細に述べる。本発明のアクセシビリティシステム200は、クライアント(AT製品)300に、(1)アプリケーションのユーザインターフェースに関する情報を収集する能力、(2)UIを構築するために使用されている技術にかかわらずプログラムに基づいてUI要素を発見し問い合わせる能力、(3)キーボード入力およびポインタ入力を生成する能力、(4)どのタイプの挙動または機能が現在利用可能かを理解する能力を提供する。アクセシビリティシステム200では、アプリケーションが、アプリケーション自体およびそのコンポーネントをアクセス可能にすることができる。図2および3に示す構造は、(1)論理UIツリー、(2)コントロールパターン、(3)イベント機構、(4)入力API(この文書ではカバーされていない)、(5)プロパティを含めた、アクセシビリティシステム200の5つの主要な面を可能にする。
【0026】
(UIアクセス論理ツリー222)
アクセシビリティシステム200の統合コンポーネントとして論理ツリー222があり、この例を図4(D)に示す。ツリー222は、クライアント側アクセシビリティインターフェース220に含まれる。
【0027】
論理ツリー222は、UI要素の基礎的な構造階層がフィルタリングされたビューであり、コントロールまたはアプリケーションの開発者が実装しなければならない別個のツリーではない。そうではなく論理ツリー222は、関心あり(interesting)、関心なし(uninteresting)という少数の明確なプロパティを符丁とし、これらのプロパティは、構造の要素が論理ツリー222中で公開されるべきかどうかを示す。アクセシビリティシステムコア201は、この情報を消費してフィルタリング済みUI論理ツリー222を生み出し、フィルタリング済み論理ツリー222は、AT製品またはテストスクリプトに提示される。
【0028】
論理ツリー222は要素のツリーであり、各要素はコントロール、コントロール中の項目、またはグループ構造を表し、グループ構造はダイアログ、ペイン、またはフレームとすることができる。論理ツリー222の構造は、ユーザによって知覚されるアプリケーションUIを表すべきである(コントロールが実際には異なる基礎構造を使用して実装される場合でも)。ツリーは、時が経過しても一定であるべきである。アプリケーションがユーザにとって同じに見える限り、そのアプリケーションを表す論理ツリー222は、背後でアプリケーションの実装詳細が変化しても、同じのままであるべきである。Microsoft OS製品のシェルの「ShDocView」ウィンドウなど、構造上および実装上の理由で存在するネイティブ要素は、ユーザが知覚しないのでこのツリー中に現れるべきではない。
【0029】
論理ツリー222は、複数の異なるプロセスがクライアントにとって同じになるようにこれらのプロセスを統一することのできる、複数のフラグメントから構築された単一のツリーである。論理ツリー222は、バルク検索を可能にし、プロパティリストの値を得ることができる。通常ならユーザがプロセス間呼出しを行って値を要求している時までに、アクセシビリティシステム200は、論理ツリー222を使用してそれらをフェッチしていることになる。
【0030】
論理ツリー222は、知られているシステムの場合のように1つのステップで構築されるのではなく、生ツリーの構築に使用されるフラグメントから構築される。図5に示すように、3つの主要な手順が論理ツリー222を構築する。手順72で、アクセシビリティシステム200は、基礎をなす技術のネイティブ要素を突き止め、図4(A)に示すネイティブツリーに達する。手順74で、アクセシビリティシステム200は、図4(B)に示すようにネイティブ要素を結合して生ツリー20を形成する。最後に手順76で、図4(D)に示すように、関心を持たれない生ツリー20中のコンポーネントを隠すことによって論理ツリー222が得られる。
【0031】
図4(A)に、2つのネイティブツリー10および14を示す。これらは、Win32UIやその他の任意の利用可能なUIなど、基礎をなす技術のネイティブ要素から構築される。ネイティブツリー10は、親ノード11と、相互に様々な関係を有する複数の子孫12とを含む。同様に、ネイティブツリー14は、複数の子ノード16を有する親ノード15を含む。子ノード16は、相互の兄弟として記述することができる。
【0032】
図4(B)に示すように、ネイティブツリー10および14を結合して、生ツリー20を形成することができる。生ツリー20は、2つの子ノード22および30を有する親ノード21を含む。子ノード22は子孫23〜29を有し、子ノード30は子孫31〜33を有する。この生ツリー20は、ネイティブツリー10と14の結合であり、ネイティブツリー10のノードがノード22〜29を形成し、ネイティブツリー14のノードがノード30〜33を形成している。
【0033】
図4(C)および4(D)に概して示す方法によって、生ツリー20が論理ツリー222に変換される。生ツリー20から論理ツリー222に移行するために、開発者は生ツリーにヒントを挿入することができる。開発者は、生ツリー20内のノードに「それ自体を隠す」または「それ自体および子を隠す」、あるいは「ノードの子を隠す」などとしてマークすることができる。開発者はまた、ノードを横に移動することや、子の前にノードを配置することもできる。生ツリー20中のこれらの「ヒント」および修正を用いて、論理ツリー222を形成する。例えば、図4(C)で開発者は、ブロック40および41で示すように、生ツリー20のノード24〜26および33を関心なしとしてマークしている。通常、ユーザからは見えないことになる要素を含むノードは関心なしとしてマークされる。見えるUIに関係するノードは通常、関心ありと考えられ、ATクライアント300によって使用されるように論理ツリー222に含められる。図4(D)に示すように、関心なしとしてマークされたノードは、論理ツリー222に含められない。
【0034】
アクセシビリティシステム200は、論理ツリー222を使用して、イベントに関する情報、システムの状態、オブジェクトの位置、コントロールに関する情報を見つける。知られているシステムでは、それらのツリー内で範囲指定する機能がなかった。論理ツリー222は、クライアント300の選好に基づいてナビゲートすることができ、使用されているサーバ側アプリケーションにかかわらず情報を提供することができる。
【0035】
動作時、クライアント300がユーザのためにアプリケーションに関する情報を得る必要がある場合、クライアント300は、押すべきボタンを探し、ボタン上のテキストを観察する。クライアント300は、API「find an element(要素を見つける)」を呼び出すことになる。このAPIは、クライアント側インターフェース220の論理ツリー222中の位置を基準とする値を返す。論理ツリー222を介して、アクセシビリティシステム200は、使用されているアプリケーションにかかわらずUIの抽象ビューをクライアント300に提供する。この抽象モデルは、構造、プロパティ、イベントを含み、また、リストボックス、ボタン、またはその他のUIコンポーネントが相互と共通に有すると考えることのできる機能を含む。
【0036】
論理ツリー222は、UIの論理表現である単一の統合ツリーであり、クライアント300にとって関心のある要素だけを含む形状に形成されている。したがって、AT製品にUI要素の構造階層をフィルタリングさせて、エンドユーザに提示されるモデルにおいて推測させるのではなく、論理ツリー222は、エンドユーザに提示される構造にぴったりマッピングする階層を提示する。このことは、UIをユーザに対して記述するというAT製品のタスクを大幅に単純化し、ユーザがアプリケーションと対話するのを助ける。
【0037】
この論理UIツリー222はアクセシビリティシステム200の根底的な部分なので、アクセシビリティシステム200の他のコンポーネントはすべて、論理ツリー222から機能するように設計される。例えば、図6に簡単なダイアログボックス60を示すが、これは非常に単純な構造を有するように見える。しかし、現在利用可能なアクセシビリティ技術を通して見ると、このダイアログボックス60の構造は驚くほど複雑である。これは264個のオブジェクトを含み、AT製品はこれらをフィルタリングして、エンドユーザにとって意味のあるものを発見しなければならない。アクセシビリティシステム200と、論理UIツリー222に対するそのサポートとを用いれば、このダイアログボックス60を所有する開発者は、わずかなプロパティを設定して、図6に示す以下の構造をAT製品300に提示することができる。
【0038】
図6に示すように、「実行」ダイアログで、開発者は、フライングウィンドウグラフィック62と、63の「プログラム、フォルダ、文書、またはインターネットリソースの名前を入力して下さい。そうするとWindows(登録商標)がそれを開きます。」とを、関心ありとして指示することができる。開発者はまた、メモ帳、ワード、計算機などを含むコンボボックス64と、OK65、キャンセル66、閲覧67のボタンとを、関心ありとして指示することができる。これは、開発者がUIアクセシビリティシステム200を介して自分の要素階層にタグ付けし、それにより自分のアプリケーションのUIの論理表現を生み出すための、低コストの機構を開発者にもたらす。図示の各機能は、論理ツリー222中で他の各ノードと指定の関係を有するノードによって表すことができる。この論理表現は、テストチームに対して、およびAT製品またはクライアント300に対して、直接的な利益をもたらす。
【0039】
クライアント300は、APIのセットによってツリーに達することができる。機能には、(1)ポイントからポイントへの論理要素、(2)イベントからの論理要素、(3)現在フォーカスされている論理要素が含まれる。前述のように、論理要素はUIコンポーネントを表し、これは場合により、コントロール、コントロールの一部、あるいはコンテナまたは論理グループ(すなわちダイアログ、ペイン、またはフレーム)である。コントロールは、それらの機能の点で非常に多様である可能性がある。したがって、特定のタイプのコントロールに関連する機能を表すのに、種々のインターフェースが使用される。これらのコントロール特有インターフェースは、すべてのコントロールに共通の機能を表す共通ベースインターフェースから派生する。共通ベースインターフェースは、(1)論理ツリー222をナビゲートするためのメソッド、(2)プロパティ値を得るための一般的なメソッド、(3)サポートされるコントロール特有インターフェースにアクセスするためのメソッドを含む。論理ツリー222をナビゲートする際には、基礎をなす各アプリケーションUI技術が、それ自体のナビゲーション技術を提供することになる。
【0040】
ユーザにとって最終的に関心があるのは論理ツリー222だが、生要素ツリー20もまた、いくつかの重要な機能を果たす。論理ツリー222はユーザに関係する可能性のある要素だけしか含まないが、生要素ツリー20は、ノード22など、基礎をなすフレームワークの実装構造を表すノードも含む。例えばWin32UIフラグメントの場合、このツリーは、HWNDを表すノードを含むことになる。いくつかの点で、生要素ツリー20は、論理要素ツリー222と基礎をなすフレームワーク自体のネイティブ要素ツリーとの間の「中間施設」である。生要素ツリー20は、論理要素ツリー222を構築するための基礎として使用されるものであり、ネイティブ要素が最初にシステムにプラグインする場所である。
【0041】
生要素ツリー20は、デバッグおよびテストに使用することもできる。これは、問題を含む特定のノードがどこにあるかを正確に示すかまたは記述するのに有用である。ベース生要素ノードに関する機能には、生要素ツリーをナビゲートするためのメソッドと、対応する論理要素(もしあれば)にジャンプするためのメソッドと、例えばHWNDノードの場合の「HWND0x483FE」など、この要素に対する「デバッグ文字列」を含むプロパティと、その他の「背後にあるインフラストラクチャ」のメソッドとが含まれる。これらのその他のメソッドは、ヒットテストおよび位置決めと、イベントと、フレームワークが容易に提供することのできるプロパティ(例えばフォーカス(focused)、イネーブル(enabled))の公開とを可能にする。
【0042】
生要素ツリー20は、様々なレンダリングエンジンからの要素を表すノード22〜33を含む。生要素ツリーは、レンダリングエンジンがそれら自体をアクセシビリティシステム200にプラグインするための開始点として使用され、Win32からのHWNDなどのネイティブ要素を統合論理ツリー222に適合させる軽量アダプタオブジェクトから構築される。さらに、ある技術が別の技術をホストする場合に、ホスティング移行を処理するのにも使用される。生要素ツリー20は論理ツリー222が構築されるベースなので、論理ツリー222が完全であり接続されていることをチェックするために使用することができ、また、説明のつかない要素があるかどうかチェックするために使用することができる。生要素ツリー20はさらに、その他のインフラストラクチャのようなタスクに使用することもできる。すなわち、何らかの基本的な要素IDを提供することや、フォーカス、イネーブル、ロケーション(location)など、フレームワークによって提供される何らかの基本的な要素プロパティを提供することなどである。
【0043】
生要素ツリー20は、AT製品またはクライアント300のための主要な情報源ではなく、論理ナビゲーションには使用されず、エンドユーザには公開されない。生要素ツリー20はまた、将来のいずれかの時点で返せるようにツリー中の要素の位置を取り込むために使用することはできない。これらの機能はすべて、論理要素ツリー222が実施する。
【0044】
生要素ツリー20は通常、表される論理要素がわからなくても、基礎をなすレンダリング技術(HWND、Element)の生要素から機械的に構築することができる。したがって、これを使用して、論理ツリー222中で説明のつかなかった生要素を探すことができる。生要素ツリー20は、取り込まれるノードの位置の「スタックダンプ」のような記述を可能にするので、有用なデバッグおよび診断ツールである。さらに、知られているシステムでは、システムのツリーはコード特有の基準に基づき、種々の技術で実現するのが難しい。本手法は、一般的な抽象「生要素」型を使用する。これは、基礎をなす任意のレンダリング技術によって、またはそれに代わって実装することができる。
【0045】
生要素ツリーを得るには、生要素ルートを呼び出すとデスクトップ要素が得られる。この要素は、その親がNULLであり他のすべてのノードがそれを究極的な祖先とすることを確実にすることによって検証される。他の要素を得るには、生要素を指定のポイントから得るためのメソッドを呼び出すと、有効な画面座標を使用して要素が返される。生要素ツリーを得た後は、要素(親、兄弟、子)をチェックすることによって、生要素ツリーをチェックおよび検証することができる。
【0046】
動作時、クライアント300は、親、次の兄弟、前の兄弟、第1の子、最後の子などの関係を使用して、生要素ツリー20をナビゲートすることができる。次いでクライアント300は、生要素から論理ツリー222中の対応する論理要素にジャンプすることができる。
【0047】
(イベント機構)
クライアント300は、イベントがあり次第その通知を受けたい場合、図3に示すUI自動化クライアント202を介して登録して、情報を得ることができる。クライアント300は、受け取りたいオブジェクト情報と、情報がどこに行くようにしたいかと、返してもらいたいプロパティのリストとを指定する。クライアント要求は、UI自動化クライアント202に行く。UI自動化クライアント202は、デスクトップ上の任意のプロセスを監視することができる。UI自動化サーバ204は、どのクライアント300がリッスンしているかを常に把握しており、どのようにUI自動化クライアント202に返すかを知っている。UI自動化クライアント202はクライアントの関心をUIエンジン206に勧告し、したがってUIエンジン206は、いつイベントをUI自動化サーバ204に通知するかを知る。UIエンジンは、クライアント勧告を利用しなくてもよく、その代わり、イベントを常にUI自動化サーバ204に知らせるか、あるいはクライアントがいずれかのイベントをリッスンしている場合にだけUI自動化サーバに知らせることを選択することもできる。勧告は、イベントをリッスンしているクライアントがある場合にだけUIエンジンがUI自動化サーバ通知をオンにしたい場合に、有用である。これは、UIエンジンが、UIの速度低下の可能性を避けるため、および通常なら必要のないコードモジュールをロードするのを避けるために行うことになる。
【0048】
次いで、UIエンジン206は、UI自動化サーバ204にUIイベントを通知する。UI自動化サーバ204は、要求された論理要素をクライアント300に返し、クライアント300が要求したイベントのプロパティを含めた情報を、クライアント300に送る。UI自動化サーバ204は、どの情報がクライアント要求の範囲内かを決定し、情報が該当する場合にだけ、論理要素を形成する。論理要素の形成は、クライアントがイベント処理時に使用することになると指示したプロパティのセットを、UI自動化サーバ側でプリフェッチすることを含む。例えば、UI自動化サーバ204は、コンボボックスの論理要素を発見することができる。範囲は、コンボボックスまたはその子である。クライアント300は、登録段階の間に、子/親/従属部分を要求して範囲を定義することができる。
【0049】
UI自動化サーバ204は、情報が要求範囲内かどうかを判定した後、論理要素を構築する。UI自動化クライアント202は、ターゲットアプリケーションに問い合わせ、要求の情報をUI自動化サーバ204から受け取り、オブジェクトをクライアント300上の正しい空間にルーティングすることによって、クライアント300にサービスする。
【0050】
UI自動化サーバ204は、クライアント300がイベント通知の受信に登録したときに生み出される。例えば、UIエンジン206がMicrosoft Wordワードプロセッシングアプリケーションを実行している。クライアント300は、名前プロパティの変化に登録済みである。このクライアントの登録により、UI自動化サーバ204が生み出される。クライアントの登録によってまた、UIエンジン206は、名前プロパティについてUI自動化サーバ204に通知するのを開始するよう勧告される。UIエンジン206は、範囲情報は入手しない。UIエンジン206は、サーバ側用APIのうちの1つを呼び出す。UIエンジン206は、(1)どのプロパティが変化したか、(2)プロパティの新しい値、および(3)おそらくは古い値を指定する。UI自動化サーバ204は、クライアント300にとって関心のあるイベントに基づいて生み出されたのであり、したがって関心のあるイベント、プロパティ、クライアント、範囲を知っており、そのため、作成された論理要素に関心のあるクライアント300があるかどうかがわかる。複数のクライアント300が特定のUI自動化サーバ204とイベント登録した場合であって、これらのクライアント300が1つの同じイベントに登録し、返される論理要素と共にプロパティがバルクフェッチされるよう要求した場合は、各クライアント300は、UI自動化サーバ204がクライアント300にイベントを送り返したときに、返された論理要素と共に要求のバルクフェッチプロパティの結合を得ることになる。
【0051】
リッスンしている各クライアント300に対し、UI自動化サーバ204はクライアント300に通知して、イベントに関連する論理要素をクライアントに渡す。UI自動化サーバ204は、論理要素を1つだけ生み出す。これは、各クライアント300がイベントのソースであるオブジェクトの自分用コピーを要求する必要のある現行技術に勝る改良点である。
【0052】
クライアントがイベントに登録したときにUIエンジン206がUI自動化クライアントの勧告を利用しない場合、UIエンジン206は、リッスンしているアクセシビリティクライアント300があるかどうかをUI自動化サーバ204に尋ねることができ、どれもリッスンしていない場合は、情報を作成してUI自動化サーバ204に送る作業を回避することができる。例えば、クライアント300がスクリーンリーダであり、このスクリーンリーダは、どこに情報が行くようにしたいかと、イベントを受け取るフォーカス変化オブジェクトと、関心のあるプロパティの特定のリストとを指定する。UIエンジン206は、勧告を受けて、UI自動化サーバ204にイベントを送るべきであることを知る。フォーカス変化を検出すると、UIエンジン206は、UI自動化サーバ204に通知する。UI自動化サーバ204は、周知のインターフェースに変換し、イベントおよびオブジェクトをUI自動化クライアント202に送る。UI自動化クライアント202は、オブジェクトをクライアント300上の適切な空間にルーティングする。
【0053】
上述のコンポーネントは、カーネル中のイベント用中央リポジトリをなくすことで、知られているシステムよりも改良されている。そうではなくUI自動化サーバ204は、それが実行されているコンテキストに関する情報を得ることに関心のあるすべてのクライアント300を知っている。カーネルリポジトリをなくすことでまた、よりピアツーピアの対話が生み出される。というのは、以前はカーネル中で実施されていた機能を、UI自動化サーバ204が達成するからである。本発明のアクセシビリティシステム200は、何を見たいかを指定する能力をクライアント300に与え、それにより、サーバ側でUI自動化サーバ204を使用してフィルタリングが達成される。
【0054】
図7は、イベント登録および通知方法に関連する手順を示すフローチャートである。ステップ80で、クライアント300はイベント通知を要求する。ステップ82で、UI自動化クライアント202はこの要求をUI自動化サーバ204に通信する。ステップ84で、UI自動化クライアントは、通知が欲しいことをUIエンジン206に勧告する。ステップ86で、UI自動化サーバ204はUIエンジン206から通知を受け取る。ステップ88で、UI自動化サーバ204は受け取った情報をフィルタリングする。ステップ90で、受け取った情報がユーザにとって関心のないものであるとわかった場合は、UI自動化サーバ204は情報を廃棄し、ステップ92で引き続き通知を待機する。あるいは、ステップ90で情報が関心のあるものであるとわかった場合は、ステップ94で、UI自動化サーバ204は論理要素を作成し、UI自動化クライアント202に送る。ステップ96で、UI自動化クライアント202は、受け取った情報をクライアント300上におけるその正しい位置に配置する。
【0055】
アクセシビリティシステム200のイベント機構210により、クライアント300は、UIにおけるプロパティの変化、コントロールの構造におけるツリーの変化、マルチメディアイベント、および関連情報について通知を受け取ることに登録することができる。これらの機能がなければ、クライアント300は、システム内のすべてのUI要素を絶えずポーリングして、情報、構造、または状態に変化があったかどうか調べなければならない。アクセシビリティシステム200のイベント機構210によってまた、クライアント300は、プロセス外のイベントを受け取ることができ、プロパティの集まりがイベント通知と共に返されるよう要求することができ、複数の要素に関するイベントに登録することができる。
【0056】
イベント機構210は、AT製品またはテストアプリケーションがイベントに登録するために使用するインターフェースと、AT製品がイベント通知の受信に使用されるオブジェクトに対して実装するインターフェースと、制御インプリメンタがUIイベントをイベントエンジンに通知するために使用するインターフェースとを公開する。イベント機構210は、AT製品およびテストアプリケーションがUIのレンダリングに使用されるUIエンジンから独立してイベントを受け取れるようにするために使用され、また、基礎をなす技術にかかわらずAT製品およびテストアプリケーションが最上レベルのアプリケーションウィンドウを追跡してフォーカスできるようにする。
【0057】
図2に、クライアント300がどのようにアクセシビリティシステム200と対話するかを示す。プロセスにまたがる大域的なイベント管理はない。そうではなく、各アクセシビリティシステムクライアント300またはサーバ400が、それ自体のコンテキストを有する。クライアントアプリケーションは、アクセシビリティシステム200をサポートするアプリケーションについてのイベントだけを受け取る。アプリケーション中でアクセシビリティシステムイベントの使用を開始するには、クライアント300は、以下の4つのうちの1つを行うことができる。すなわち、(1)「AddTopLevelWindowListener」APIを使用して、デスクトップ上およびこのイベントに対するハンドラ中に現れる新しいUIを発見し、その他のイベントに登録し、これによって任意のプロセスからイベントを受け取ること、(2)Find APIの1つを使用して、関心のあるUIを突き止め、特定のUIをターゲットにすること、(3)画面上のウィンドウハンドルやポイントを見つけるなど、他の何らかの手段を使用して関心のあるUIを発見し、このハンドルまたはポイントを使用して、イベントをリッスンするための参照として使用する論理要素を獲得すること、または(4)「AddFocusChangedListener」APIを使用して、入力フォーカスを追跡し、フォーカスを現在有するUIに関するイベントに登録することである。
【0058】
最上レベルのウィンドウは、デスクトップを親に持つウィンドウである。「開かれた」という語を使用する場合、これは新しい最上レベルウィンドウがユーザに対して表示されたことを示す。「閉じた」という語を使用する場合、これは最上レベルのウィンドウが破壊されたことを示す。
【0059】
アクセシビリティシステムのサーバ側インターフェース230は、追加および削除されるイベントをアクセシビリティシステム200に通知するための、2つのAPIを含む。UI自動化クライアントは、クライアントがイベントに登録および登録解除するときにこれらのAPIを呼び出す。これによりUIエンジン206は、どのアクセシビリティイベントがそのコンテキストで要求されているかに関する情報を得ることができる。
【0060】
適用可能な場合、イベントは、アプリケーションの論理要素ツリー222からの論理要素に関連付けられる。論理要素が適用可能でない場合は、イベントは人間可読の文字列に、またはイベントソースを表すその他の周知のオブジェクトに関連付けられる。イベント機構210は、イベント登録中にユーザから供給された選好に基づいてフィルタリングを提供する。イベント関連データを作成してクライアントにプロセス間送信する前に、クライアントのフィルタリング選好をサーバで使用することにより、イベント機構210は本質的に、プロセス間呼出しの数を削減することでプロセス外性能を改善する。イベント機構210は、イベント登録中に関心のある論理要素のプロパティをそのイベントに対して指定する方法を提供する。これによってさらにプロセス間呼出しの数が削減される。イベント機構210は、大きなオペレーティングシステム(OS)変更を必要とすることなく拡張可能である。イベント機構210はマネージコードを使用して実現することができるが、アンマネージアプリケーションは、COM相互運用性を介してそれにアクセスすることができる。
【0061】
ATクライアント300がイベントを処理するために実施するタスクは2つある。すなわち、(1)イベント登録、(2)コールバックにおけるイベントの処理である。どちらのタスクにとっても重要な要件は、マネージコードとアンマネージコードの両方で使用可能であることである。本発明の一実施形態では、クライアント300はイベント登録時にインターフェースを渡すことができる。クライアント300は、周知のインターフェースを実装するオブジェクトを登録時に渡し、UIエンジン206は、これらのインターフェースに対してコールバックして、リスナに通知する。論理要素ツリー222中にソースオブジェクトがある場合、各コールバックは、ソース要素および追加のパラメータを受け取る。
【0062】
AT製品によって実装される周知のインターフェースが、イベントを返す方法として使用される。以下の章では、いくつかのタイプのイベントと、登録がどのようであるかと、イベントがどのように受け取られるかを示す。
【0063】
(1.最上レベルウィンドウのイベント)
最上レベルウィンドウのイベントには、メニューおよびコンボボックスドロップダウンに関するイベント、またはデスクトップを親に持つ任意の機能に関するイベントが含まれる。本発明の一実施形態では、AddTopLevelWindowListenerメソッドを使用して、開閉される最上レベルウィンドウの通知を受け取る。AddTopLevelWindowListenerを呼び出すと、現在のデスクトップ上で開かれた新しい最上レベルウィンドウまたは閉じられた最上レベルウィンドウについての通知が得られる。RemoveTopLevelWindowListenerメソッドは、デスクトップ上で開かれたかまたは閉じられた最上レベルウィンドウについての通知を受け取るのを停止するための機構を提供する。このメソッドは、コールバックオブジェクトを使用してこのリスナを識別する。したがって、RemoveTopLevelWindowListenerメソッドに渡されるオブジェクトは、AddTopLevelWindowListenerに渡されるオブジェクトと同じである。開かれた新しい最上レベルウィンドウそれぞれにつき一度、OnTopLevelWindowOpenedメソッドがアクセシビリティシステム200によって呼び出される。同様に、最上レベルウィンドウが閉じられたときに一度、OnTopLevelWindowClosedメソッドをアクセシビリティシステム200によって呼び出すことができる。これらの通知を受け取るために、クライアント300は、AddTopLevelWindowListenerメソッドを呼び出す。
【0064】
(2.フォーカスイベント)
クライアント300はしばしば、フォーカスを追跡するためのメソッドを必要とする。Microsoft Windows(登録商標)OSでこれを行うのは難しい。例えば、メニュー(例えばMicrosoft Wordのファイルメニュー)がドロップダウンされるとき、ユーザがカーソルをメニュー中の各項目に沿って下げるにつれて、各項目がフォーカスを得る。今日では、メニューが閉じたとき(例えばユーザがESCキーを押したとき)、フォーカスイベントは送られない。そうではなく、フォーカスの変化に関心のあるクライアントは、いくつかのイベントをリッスンして、それらのうちのどれが論理的にフォーカス変化を表すかを理解しなければならない。本発明の一実施形態では、AddFocusChangedListenerメソッドを使用して、フォーカス変化イベントをリスナに通知することができる。クライアント300は、返されるプロパティのセットを指定することができる。この、論理要素と共に返すプロパティを指定する機能は、すべてのイベント登録APIの一部である。クライアント300は、RemoveFocusChangedListenerメソッドを呼び出して、フォーカス変化についての通知を受け取るのを停止することができる。このメソッドは、コールバックオブジェクトを使用してこのリスナを識別することができ、この場合、RemoveFocusChangedListenerメソッドに渡されるオブジェクトは、AddFocusChangedListenerプロシージャに渡されるオブジェクトと同じになる。フォーカスが変化したとき、アクセシビリティシステム200は、OnFocusChangedメソッドを呼び出す。OnFocusChangedメソッド中で使用されるFocusEventArgsパラメータが、フォーカスの変化に関係する情報を公開する。最後にフォーカスされた論理要素に関する情報が入手可能な場合は、この要素は、OnFocusChanged要素中で使用されるevent argsパラメータ中で入手可能になる。何かが明示的に要素にフォーカスを当てるまではどのUI要素もフォーカスを有さない場合もある。
【0065】
(3.プロパティ変化イベント)
プロパティ変化イベントは、論理要素のプロパティが変化したときに発火される。本発明の一実施形態では、クライアント300は、AddPropertyChangedListenerメソッドを呼び出して、プロパティ変化についての通知を受け取る。AddPropertyChangedListener中で指定された論理要素ツリー内の論理要素に関するプロパティの値が変化したとき、OnPropertyChangedメソッドがアクセシビリティシステム200によって呼び出される。範囲パラメータが、どの要素に対してイベントを発火すべきかを示す。例えば、ウィンドウのルート論理要素と子孫要求とを渡すと、プロパティ変化コールバックはそのウィンドウに制限される。範囲パラメータがツリー中のすべての要素に設定されている場合は、範囲は無視され、デスクトップ上で生じた指定のプロパティのどんな変化も送られる。クライアント300は、AddPropertyChangedListenerを、異なるプロパティセットおよび/または異なるコールバックオブジェクトで複数回呼び出すことができる。アクセシビリティシステム200によって提供される通知は、変化したプロパティと、新しいプロパティ値と、入手可能なら古いプロパティ値とを示す。
【0066】
クライアント300は、RemovePropertyChangedListenerメソッドを呼び出して、プロパティ変化についての通知を受け取るのを停止することができる。このメソッドは、範囲要素およびコールバックオブジェクトを使用してこのリスナを識別することができ、この場合、渡されるオブジェクトは、AddPropertyChangedListenerに渡されるオブジェクトと同じでなければならない。
【0067】
(4.コントロールパターンからのイベント)
コントロールパターンから発火されるイベントは、拡張可能である必要があり、したがってこれらのイベントはGUIDで識別される。登録時、任意のGUID値が受け入れられる。新しいコントロールパターンの場合、それがドキュメントするイベントは、固有のGUIDである必要がある。AT製品は、新しいコントロールパターンのイベントをリッスンするよう修正されることが必要な場合がある。リスナはまた、これらのイベントを範囲指定できる必要がある。例えば、管理されたテストでは、これらのイベントを特定のアプリケーションに、またはアプリケーション内のコントロールに制限したい場合がある。コントロールパターンは何がソースかを定義し、イベントコンシューマは、どのようにソース要素およびイベント引数オブジェクトを使用するかを知るために、ドキュメンテーションのその部分を参照する必要がある。
【0068】
AddEventListenerメソッドは、クライアント300がコントロールについてのイベントを受け取ることを可能にする。範囲パラメータを使用して、どの要素に対してイベントを発火するかを指示することができる。例えば、ウィンドウのルート論理要素を渡して子孫を要求すると、イベントはそのウィンドウに制限される。ツリー中のすべての要素が望まれる場合は、デスクトップ上のすべてのイベントが送られる。RemoveEventListenerメソッドを使用して、コントロールについてのイベントを受け取るのを停止することができる。このメソッドは、範囲要素とコールバックオブジェクトとイベント識別子とを使用して、リスナを識別することができる。この場合、渡されるオブジェクトは、AddEventListenerに渡されるオブジェクトと同じでなければならない。
【0069】
アプリケーションがAddEventListenerメソッドを呼び出すと、コントロール特有のイベントが発火されてイベントソースがAddEventListener中で指定された論理要素ツリー内の論理要素であるとき、OnEventメソッドがアクセシビリティシステム200によって呼び出される。コントロールについてのイベントが発火されるときは、イベント特有の情報がしばしば入手可能である。
【0070】
RemoveAllListenersメソッドを呼び出して、どんなイベントを受け取るのも停止することができる。これは、クライアントアプリケーションがシャットダウンする前にクリーンアップするための素早い方法である。この削除メソッドは、アプリケーション終了時に使用することができるのが最適である。
【0071】
(5.論理構造変化イベント)
論理構造変化イベントは、論理要素ツリーの構造が変化したときに発火される。AddLogicalStructureChangedListenerメソッドを実施して、論理要素ツリーの構造変化についての通知を受け取ることができる。論理要素が追加、削除、または無効にされるとき、指定のコールバックオブジェクトに対するメソッドが呼び出される。前述のように、範囲パラメータが要素を制限することができる。RemoveLogicalStructureChangedListenerメソッドを呼び出して、論理要素ツリーの変化についてのイベントを受け取るのを停止することができる。このメソッドは、コールバックオブジェクトおよび範囲要素を使用してこのリスナを識別することができ、この場合、渡されるオブジェクトは、AddEventListenerに渡されるオブジェクトと同じでなければならない。
【0072】
子要素が追加されるときであって、親がAddLogicalStructureChangedListener中で指定された論理要素ツリー222内の論理要素であるときは、OnChildAddedメソッドをアクセシビリティシステム200によって呼び出すことができる。子要素が削除されるときであって、古い親がAddLogicalStructureChangedListener中で指定された論理要素ツリー内の論理要素であるときは、OnChildRemovedメソッドがアクセシビリティシステム200によって呼び出される。
【0073】
短時間に多数の子(例えば20個を超える子)が追加されるときは、OnChildrenBulkAddedメソッドがアクセシビリティシステムによって呼び出される。短時間に多数の子が削除されるときは、OnChildrenBulkRemovedメソッドがアクセシビリティシステムによって呼び出される。短時間に多数の子(例えば20個を超える子)の追加と削除の両方が行われるときは、OnChildrenInvalidatedメソッドがアクセシビリティシステム200によって呼び出される。
【0074】
(6.マルチメディアイベント)
別のタイプのイベントは、マルチメディアイベントである。マルチメディアには、音声、ビデオ、アニメーションを含めることができる。メソッドは、マルチメディアイベントをサポートし、「停止された」「一時停止された」「早送りされた」「巻戻された」「ミュートにされた」を含めたアクションをクライアントに通知する。前述と同様のメソッドを実施して、マルチメディアリスナを追加および削除することができる。
【0075】
(7.単純音声イベント)
単純音声イベントは、マルチメディアイベントとは別に扱うことができる。単純音声イベントは、音声自体以外の何らかのイベントをユーザに伝えるために存在する、単純かつ短時間の音声を表す。単純音声イベントには、新しいメールが到着したときに再生される音声、ラップトップの電池が低いときに生成される音声、またはIconExclamationタイプのメッセージボックスが表示されるときに再生される音声を含めることができる。AddSoundListenerメソッドを呼び出して、再生される単純音声の通知を受け取ることができ、RemoveSoundListenerメソッドを実施して、単純音声イベントについての通知を受け取るのを停止することができる。
【0076】
単純音声が再生されたとき、OnSoundメソッドがアクセシビリティシステム200によって呼び出される。この通知を受け取るために、リッスンしているアプリケーションは、AddSoundListenerを呼び出す。OnSoundメソッドは、音声の名前と、音声のソースと、ユーザに対する音声の重要性を示すアラートレベル値との情報を取り出す。可能なアラートレベルには、重要性が未知であることを示す「未知」と、情報が提示されたことを示す「情報」と、警告条件を示す「警告」と、ユーザ応答が必要であることを示す「疑問」と、イベントがクリティカルではないが重要かもしれないことを示す「感嘆符」と、クリティカルなイベントの発生を示す「クリティカル」が含まれる。
【0077】
(8.ソフトフォーカスイベント)
ソフトフォーカスイベントは、デスクトップ上に現れるが背景にとどまっているものである。ソフトフォーカスイベントのいくつかの例としては、通知領域で「新しい更新が利用可能です」と示すバルーンヘルプウィンドウと、フォーカスを得たい背景アプリケーションについての、タスクバー中の点滅アイコンと、印刷が開始および終了したときに通知トレイから現れて消えるプリンタアイコンがある。これらのイベントは、他のイベント範疇といくぶん重複するように思われるかもしれない(ソフトフォーカスがするのと同様に、マルチメディアもアニメーションイベントを含む場合がある)。しかしイベントは、それがどのように伝えられるかではなく、何をユーザに伝えるかに基づいて範疇化される。
【0078】
入力フォーカスを利用せずにユーザの注意を引こうとするイベントの通知を、AddSoftFocusListenerメソッドを実施して受け取ることができる。RemoveSoftFocusListenerメソッドは通知を停止する。このメソッドは、コールバックオブジェクトを使用してリスナを識別することができ、したがって、渡されるオブジェクトは、AddSoftFocusListenerに渡されるオブジェクトと同じのはずである。
【0079】
ソフトフォーカスイベントが発生したとき、OnSoftFocusメソッドをアクセシビリティシステム200によって呼び出すことができる。この通知を受け取るために、リッスンしているアプリケーションまたはクライアント300は、AddSoftFocusListenerを呼び出す。ソース要素が利用可能なら、これを使用してイベントに関するより多くの情報を得ることができる。ソース要素の一例は、システムトレー中の通知アプリケーションのうちの1つによって使用されるバルーンヘルプウィンドウの論理ルート要素であろう。OnSoftFocusメソッドは、イベントの名前と、イベントのソースと、ユーザに対するイベントの重要性を示すアラートレベルとを返す。
【0080】
以下の表に、クライアント300がAddTopLevelWindowListener APIを使用して特定のプロセスからのイベントをリッスンするときの、クライアント300およびアクセシビリティシステム200のアクションを示す。
【0081】
【表1】
【0082】
(イベント通知)
サーバ400または基礎をなすUIエンジンは、対応するイベント通知メソッドを使用して、上に挙げたアクセシビリティシステムイベントをサポートする。UI自動化サーバAPIは、サーバまたは基礎をなすUIエンジンがこれを達成するために呼び出すことのできるメソッドを含む。例えば、論理要素上で特定のプロパティが変化したときにサーバが通知するために呼び出すNotifyPropertyChangedメソッドがある。UIが変化したときに適切なパラメータを生成してこれらの通知メソッドを呼び出すことは、サーバ400または基礎をなすUIエンジンの任務である。
【0083】
(サーバメソッド)
クライアント300がイベントを要求しているとき、AdviseEventAddedメソッドおよびAdviseEventRemovedメソッドがUI自動化クライアントによって呼び出されて、サーバ400に通知される。これによりサーバ400は、関心のあるイベントがない場合にはアクセシビリティシステム200にイベントを伝搬しないようにすることができる。サーバは、これらの通知を用いて、それらのイベントを使用しているクライアントがいるかどうかに性能が依存するようにすることができる。
【0084】
(コントロールパターン)
アクセシビリティモデルは、特定のUI要素またはコントロールによってサポートされる機能を範疇化および公開するための独自の手法を提供する。従来技術のように機能を特定のコントロールタイプ(例えばボタン、編集ボックス、またはリストボックス)に関連付けるのではなく、アクセシビリティモデルは、共通コントロールパターンのセットを定義し、各パターンはUI挙動の1つの面を定義する。これらのパターンは相互に独立しているので、これらを組み合わせて、特定のUI要素によってサポートされる機能の完全なセットを記述することができる。
【0085】
例えば、要素をそのクラス名(Buttonなど)で記述するのではなく、アクセシビリティシステム200は、呼出し可能なコントロールパターンをサポートするものとして要素を記述する。コントロールパターンは、要素によってサポートされる、構造、プロパティ、イベント、メソッドを定義する。したがって、これらのパターンにより、クライアントはコントロールの挙動を照会することができるだけでなく、特定のパターン用に設計されたインターフェースを使用してコントロールをプログラムに基づいて操作することもできる。例えば、SelectionContainerパターンは、選択された項目を照会するためのメソッド、特定の項目を選択または選択解除するためのメソッド、あるいは、コントロールが単一の選択モードをサポートするか複数の選択モードをサポートするかを決定するためのメソッドを提供する。
【0086】
アクセシビリティシステム200に対して現在定義されているコントロールパターンには、(1)選択コンテナ、(2)階層、(3)呼出し可能、(4)単純グリッド、(5)テキスト、(6)値、(7)オブジェクトを表す、(8)スクロール可能、(9)ソート可能、(10)ドローイング、(11)その他のコンテナが含まれる。
【0087】
この技法により、コントロール開発者は、新しいタイプのコントロールを実装することができ、その挙動をAT製品およびテストスクリプトに公開するための明確な手法もなお有する。新しいタイプの挙動が導入される場合、新しいコントロールパターンを定義して必要な機能を表すことができる。
【0088】
支援技術製品およびテストスクリプトは今や、各UIコントロールによってではなく、各パターンによってどのように機能するかを理解するように書くことができる。コントロールパターンはコントロールクラスよりもずっと少ないので、この技法は、必要なコードを最小限に抑える。この手法はまた、新しいコントロールを効果的に問合せおよび操作することのできる、よりフレキシブルなアーキテクチャを奨励する(新しいコントロールが既知のコントロールパターンをサポートする限り)。
【0089】
以下の表に、共通コントロールとそれらがサポートするパターンの、いくつかの例を提供する。
【0090】
【表2】
【0091】
より具体的なインターフェースを使用すると、共通コントロールパターンに関連する機能が公開される。これらのパターンの例には、(1)選択管理コンテナ、(2)グリッドレイアウトコンテナ、(3)値を含むUI要素、(4)オブジェクト(ファイル、eメールなど)を表すアイコン、(5)呼び出すことのできるUI要素が含まれる。一般に、これらのパターンは特定のコントロールに密に結び付いたものではなく、異なるコントロールが同じパターンを実装することもできる。例えば、リストボックス、コンボボックス、ツリービューはすべて、「選択管理コンテナ」パターンを実装する。いくつかのコントロールは、適切なら複数のパターンを実装することができる。すなわち、選択グリッドが「グリッドレイアウトコンテナ」パターンと「選択管理コンテナ」パターンの両方を実装することになる。
【0092】
以前のアプリケーションのように単一の「ロール(role)」プロパティはない。そうではなく、2つの別々の機構が使用される。コントロールパターンが、コントロールについての利用可能な機能を決定し、人間可読のローカライズ可能プロパティが、「ボタン(button)」や「リストボックス(list box)」など、ユーザが理解できるコントロールタイプ名を提供する。
【0093】
(プロパティ)
アクセシビリティシステム200は、一般的なGetPropertyメソッドを特徴づけることになる。プロパティはGUIDで表されることが好ましく、ユーティリティメソッドを使用して、ローカライズ不可能なニーモニック形式(スクリプティングおよび構成ファイルに有用である)との間で変換し、ローカライズされた記述も得る。個別のメソッドではなく一般的なGetPropertyメソッドであることの2つの重要な利点は、(a)インターフェースを変更せずに時の経過に伴って新しいプロパティを追加することができること、および(b)アレイ駆動型バルクプロパティフェッチングなど、別々のメソッドを使用したときには不可能な実装技術を可能にすることである。各プロパティは、明確に定義された意図を有さなければならない。プロパティが人間によって消費されるように意図されているか機械によって消費されるように意図されているか、プロパティがローカライズされるかどうかなどが、明確に定義されなければならない。
【0094】
本発明を特定の実施形態に関して述べたが、これらの実施形態は、あらゆる点で限定的ではなく例示的なものである。本発明が関連する当業者には、その範囲を逸脱することなく代替実施形態も明らかになるであろう。
【0095】
以上のことから、本発明は、自明であり本システムおよび方法に内在するその他の利点と共に、前述のすべての目標および目的を達成するようにうまく適合されたものであることがわかるであろう。いくつかの特徴およびサブコンビネーションは、他の特徴およびサブコンビネーションを参照しなくても有用であり採用することができることは理解されるであろう。このことを、特許請求の範囲によって企図する。
【特許請求の範囲】
【請求項1】
プロセッサ及びメモリを有し、クライアントにユーザインターフェース情報を提供するアクセシビリティシステムにおいて、
前記クライアントを登録し、かつ、前記ユーザインターフェース情報がイベント登録要求と合致するか否かに基づいて前記ユーザインターフェース情報をフィルタリングするユーザインターフェース自動化サービスを含むアクセシビリティシステムコアであって、前記ユーザインターフェース情報は、前記クライアントに提供されるものであるアクセシビリティシステムコアと、
前記クライアントに提供された前記イベント登録要求と合致するユーザインターフェース情報を見えるようにすると共に前記クライアントに提供された前記イベント登録要求と合致しないユーザインターフェース情報を隠す論理ツリーを含むクライアント側インターフェースと、
サーバ側アプリケーションを構築するために使用されているユーザインターフェースエンジンにかかわらず、前記サーバ側アプリケーションから前記アクセシビリティシステムコアへの情報転送を可能にするサーバ側インターフェースと
を備え、
前記アクセシビリティシステムコアの前記ユーザインターフェース自動化サービスは、ユーザインターフェース自動化サーバに通信可能に結合されたユーザインターフェース自動化クライアントを備え、
前記ユーザインターフェース自動化クライアントは、前記クライアント側インターフェースにわたり動作して、前記イベント登録要求を前記クライアントから受け取り、かつ、前記ユーザインターフェース自動化サーバに前記イベント登録要求を通知するために前記ユーザインターフェース自動化サーバと通信し、
前記ユーザインターフェース自動化サーバは、前記クライアントが前記イベント登録要求を開始したときに生成され、前記サーバ側インターフェースに結合されたユーザインターフェースエンジンからのイベント情報を探し出すために前記サーバ側インターフェースにわたり動作して、(a)前記イベント登録要求と合致するイベントについて前記ユーザインターフェースエンジンのユーザインターフェースをモニタし、(b)前記イベント登録要求と一致するイベント情報をフィルタリングし、(c)フィルタリングされた前記イベント情報に基づいて前記論理ツリーを生成し、(d)前記論理ツリーを前記ユーザインターフェース自動化クライアントに送信する(補正前の請求項4、図7等)ことを特徴とするアクセシビリティシステム。
【請求項2】
前記論理ツリーは複数の要素を含み、前記要素はそれぞれ、コントロール、コントロール中の項目、グループ構造のうちの1つを表すことを特徴とする請求項1に記載のアクセシビリティシステム。
【請求項3】
基礎をなすアプリケーション技術が、前記論理ツリーをナビゲートするための適切な技法を決定することを特徴とする請求項1に記載のアクセシビリティシステム。
【請求項4】
前記論理ツリーは異なるアプリケーション及び異なるユーザインターフェースフレームワークからのユーザインターフェースを統合することを特徴とする請求項1に記載のアクセシビリティシステム。
【請求項5】
コントロールパターンに関連する機能を公開するためのインターフェースをさらに備えることを特徴とする請求項1に記載のアクセシビリティシステム。
【請求項6】
アクセシビリティシステムAPIが、アプリケーションに関連する情報を前記クライアントに提供するための論理ツリー位置を返すことを特徴とする請求項5に記載のアクセシビリティシステム。
【請求項7】
クライアントにユーザインターフェース情報を提供するためのコンピュータ実施方法であって、
ユーザインターフェース自動化サービスを含むアクセシビリティシステムコアを通じて前記クライアントを登録し、かつ、前記ユーザインターフェース情報がイベント登録要求と合致するか否かに基づいて第1のユーザインターフェース情報をフィルタリングするステップであって、前記第1のユーザインターフェース情報は、前記クライアントに提供されるものであるステップと、
論理ツリーを含むクライアント側インターフェースを通じて、前記イベント登録要求と合致するユーザインターフェース情報を見えるようにすると共に、前記論理ツリーを含む前記クライアント側インターフェースを通じて、前記イベント登録要求と合致しないユーザインターフェース情報を隠すステップと、
サーバ側インターフェースを通じて、サーバ側アプリケーションを構築するために使用されているユーザインターフェースエンジンにかかわらず、前記サーバ側アプリケーションから前記アクセシビリティシステムコアへの情報転送を可能にするステップと
を含み、
前記アクセシビリティシステムコアの前記ユーザインターフェース自動化サービスは、ユーザインターフェース自動化サーバに通信可能に結合されたユーザインターフェース自動化クライアントを含むイベント機構を備え、
前記ユーザインターフェース自動化クライアントは、前記クライアント側インターフェースにわたり動作して、前記イベント登録要求を前記クライアントから受け取り、かつ、前記ユーザインターフェース自動化サーバに前記イベント登録要求を通知するために前記ユーザインターフェース自動化サーバと通信し、
前記ユーザインターフェース自動化サーバは、前記クライアントが前記イベント登録要求を開始したときに生成され、前記サーバ側インターフェースに結合されたユーザインターフェースエンジンからのイベント情報を探し出すために前記サーバ側インターフェースにわたり動作して、(a)前記イベント登録要求と合致するイベントについて前記ユーザインターフェースエンジンのユーザインターフェースをモニタし、(b)前記イベント登録要求と一致するイベント情報をフィルタリングし、(c)フィルタリングされた前記イベント情報に基づいて前記論理ツリーを生成し、(d)前記論理ツリーを前記ユーザインターフェース自動化クライアントに送信することを特徴とする方法。
【請求項8】
前記論理ツリー中の各要素によって、コントロール、コントロール中の項目、グループ構造のうちの1つを表すことをさらに含むことを特徴とする請求項7に記載の方法。
【請求項9】
基礎をなすアプリケーション技術を使用して、前記論理ツリーをナビゲートするための適切な技法を決定することをさらに含むことを特徴とする請求項7に記載の方法。
【請求項10】
異なるアプリケーションからのユーザインターフェースを前記論理ツリー中で統合することをさらに含むことを特徴とする請求項7に記載の方法。
【請求項11】
コントロールパターンに関連する機能を公開するためのインターフェースを提供することをさらに含むことを特徴とする請求項7に記載の方法。
【請求項12】
アクセシビリティシステムを使用して、アプリケーションに関連する情報を前記クライアントに提供するための論理ツリー位置を返すことをさらに含むことを特徴とする請求項7に記載の方法。
【請求項13】
前記クライアントは、支援技術アプリケーションであることを特徴とする請求項1に記載のアクセシビリティシステム。
【請求項14】
前記クライアントは、スクリーンリーダアプリケーションであること特徴とする請求項1に記載のアクセシビリティシステム。
【請求項15】
クライアントにユーザインターフェース情報を提供するための方法に対する命令を記憶するコンピュータ読み取り可能な記憶媒体であって、前記方法は、
ユーザインターフェース自動化サービスを含むアクセシビリティシステムコアを通じて前記クライアントを登録し、かつ、前記ユーザインターフェース情報がイベント登録要求と合致するか否かに基づいて第1のユーザインターフェース情報をフィルタリングするステップであって、前記第1のユーザインターフェース情報は、前記クライアントに提供されるものであるステップと、
論理ツリーを含むクライアント側インターフェースを通じて、前記イベント登録要求と合致するユーザインターフェース情報を見えるようにすると共に、前記論理ツリーを含む前記クライアント側インターフェースを通じて、前記イベント登録要求と合致しないユーザインターフェース情報を隠すステップと、
サーバ側インターフェースを通じて、サーバ側アプリケーションを構築するために使用されているユーザインターフェースエンジンにかかわらず、前記サーバ側アプリケーションから前記アクセシビリティシステムコアへの情報転送を可能にするステップと
を含み、
前記アクセシビリティシステムコアの前記ユーザインターフェース自動化サービスは、ユーザインターフェース自動化サーバに通信可能に結合されたユーザインターフェース自動化クライアントを含むイベント機構を備え、
前記ユーザインターフェース自動化クライアントは、前記クライアント側インターフェースにわたり動作して、前記イベント登録要求を前記クライアントから受け取り、かつ、前記ユーザインターフェース自動化サーバに前記イベント登録要求を通知するために前記ユーザインターフェース自動化サーバと通信し、
前記ユーザインターフェース自動化サーバは、前記クライアントが前記イベント登録要求を開始したときに生成され、前記サーバ側インターフェースに結合されたユーザインターフェースエンジンからのイベント情報を探し出すために前記サーバ側インターフェースにわたり動作して、(a)前記イベント登録要求と合致するイベントについて前記ユーザインターフェースエンジンのユーザインターフェースをモニタし、(b)前記イベント登録要求と一致するイベント情報をフィルタリングし、(c)フィルタリングされた前記イベント情報に基づいて前記論理ツリーを生成し、(d)前記論理ツリーを前記ユーザインターフェース自動化クライアントに送信することを特徴とするコンピュータ読み取り可能な記憶媒体。
【請求項1】
プロセッサ及びメモリを有し、クライアントにユーザインターフェース情報を提供するアクセシビリティシステムにおいて、
前記クライアントを登録し、かつ、前記ユーザインターフェース情報がイベント登録要求と合致するか否かに基づいて前記ユーザインターフェース情報をフィルタリングするユーザインターフェース自動化サービスを含むアクセシビリティシステムコアであって、前記ユーザインターフェース情報は、前記クライアントに提供されるものであるアクセシビリティシステムコアと、
前記クライアントに提供された前記イベント登録要求と合致するユーザインターフェース情報を見えるようにすると共に前記クライアントに提供された前記イベント登録要求と合致しないユーザインターフェース情報を隠す論理ツリーを含むクライアント側インターフェースと、
サーバ側アプリケーションを構築するために使用されているユーザインターフェースエンジンにかかわらず、前記サーバ側アプリケーションから前記アクセシビリティシステムコアへの情報転送を可能にするサーバ側インターフェースと
を備え、
前記アクセシビリティシステムコアの前記ユーザインターフェース自動化サービスは、ユーザインターフェース自動化サーバに通信可能に結合されたユーザインターフェース自動化クライアントを備え、
前記ユーザインターフェース自動化クライアントは、前記クライアント側インターフェースにわたり動作して、前記イベント登録要求を前記クライアントから受け取り、かつ、前記ユーザインターフェース自動化サーバに前記イベント登録要求を通知するために前記ユーザインターフェース自動化サーバと通信し、
前記ユーザインターフェース自動化サーバは、前記クライアントが前記イベント登録要求を開始したときに生成され、前記サーバ側インターフェースに結合されたユーザインターフェースエンジンからのイベント情報を探し出すために前記サーバ側インターフェースにわたり動作して、(a)前記イベント登録要求と合致するイベントについて前記ユーザインターフェースエンジンのユーザインターフェースをモニタし、(b)前記イベント登録要求と一致するイベント情報をフィルタリングし、(c)フィルタリングされた前記イベント情報に基づいて前記論理ツリーを生成し、(d)前記論理ツリーを前記ユーザインターフェース自動化クライアントに送信する(補正前の請求項4、図7等)ことを特徴とするアクセシビリティシステム。
【請求項2】
前記論理ツリーは複数の要素を含み、前記要素はそれぞれ、コントロール、コントロール中の項目、グループ構造のうちの1つを表すことを特徴とする請求項1に記載のアクセシビリティシステム。
【請求項3】
基礎をなすアプリケーション技術が、前記論理ツリーをナビゲートするための適切な技法を決定することを特徴とする請求項1に記載のアクセシビリティシステム。
【請求項4】
前記論理ツリーは異なるアプリケーション及び異なるユーザインターフェースフレームワークからのユーザインターフェースを統合することを特徴とする請求項1に記載のアクセシビリティシステム。
【請求項5】
コントロールパターンに関連する機能を公開するためのインターフェースをさらに備えることを特徴とする請求項1に記載のアクセシビリティシステム。
【請求項6】
アクセシビリティシステムAPIが、アプリケーションに関連する情報を前記クライアントに提供するための論理ツリー位置を返すことを特徴とする請求項5に記載のアクセシビリティシステム。
【請求項7】
クライアントにユーザインターフェース情報を提供するためのコンピュータ実施方法であって、
ユーザインターフェース自動化サービスを含むアクセシビリティシステムコアを通じて前記クライアントを登録し、かつ、前記ユーザインターフェース情報がイベント登録要求と合致するか否かに基づいて第1のユーザインターフェース情報をフィルタリングするステップであって、前記第1のユーザインターフェース情報は、前記クライアントに提供されるものであるステップと、
論理ツリーを含むクライアント側インターフェースを通じて、前記イベント登録要求と合致するユーザインターフェース情報を見えるようにすると共に、前記論理ツリーを含む前記クライアント側インターフェースを通じて、前記イベント登録要求と合致しないユーザインターフェース情報を隠すステップと、
サーバ側インターフェースを通じて、サーバ側アプリケーションを構築するために使用されているユーザインターフェースエンジンにかかわらず、前記サーバ側アプリケーションから前記アクセシビリティシステムコアへの情報転送を可能にするステップと
を含み、
前記アクセシビリティシステムコアの前記ユーザインターフェース自動化サービスは、ユーザインターフェース自動化サーバに通信可能に結合されたユーザインターフェース自動化クライアントを含むイベント機構を備え、
前記ユーザインターフェース自動化クライアントは、前記クライアント側インターフェースにわたり動作して、前記イベント登録要求を前記クライアントから受け取り、かつ、前記ユーザインターフェース自動化サーバに前記イベント登録要求を通知するために前記ユーザインターフェース自動化サーバと通信し、
前記ユーザインターフェース自動化サーバは、前記クライアントが前記イベント登録要求を開始したときに生成され、前記サーバ側インターフェースに結合されたユーザインターフェースエンジンからのイベント情報を探し出すために前記サーバ側インターフェースにわたり動作して、(a)前記イベント登録要求と合致するイベントについて前記ユーザインターフェースエンジンのユーザインターフェースをモニタし、(b)前記イベント登録要求と一致するイベント情報をフィルタリングし、(c)フィルタリングされた前記イベント情報に基づいて前記論理ツリーを生成し、(d)前記論理ツリーを前記ユーザインターフェース自動化クライアントに送信することを特徴とする方法。
【請求項8】
前記論理ツリー中の各要素によって、コントロール、コントロール中の項目、グループ構造のうちの1つを表すことをさらに含むことを特徴とする請求項7に記載の方法。
【請求項9】
基礎をなすアプリケーション技術を使用して、前記論理ツリーをナビゲートするための適切な技法を決定することをさらに含むことを特徴とする請求項7に記載の方法。
【請求項10】
異なるアプリケーションからのユーザインターフェースを前記論理ツリー中で統合することをさらに含むことを特徴とする請求項7に記載の方法。
【請求項11】
コントロールパターンに関連する機能を公開するためのインターフェースを提供することをさらに含むことを特徴とする請求項7に記載の方法。
【請求項12】
アクセシビリティシステムを使用して、アプリケーションに関連する情報を前記クライアントに提供するための論理ツリー位置を返すことをさらに含むことを特徴とする請求項7に記載の方法。
【請求項13】
前記クライアントは、支援技術アプリケーションであることを特徴とする請求項1に記載のアクセシビリティシステム。
【請求項14】
前記クライアントは、スクリーンリーダアプリケーションであること特徴とする請求項1に記載のアクセシビリティシステム。
【請求項15】
クライアントにユーザインターフェース情報を提供するための方法に対する命令を記憶するコンピュータ読み取り可能な記憶媒体であって、前記方法は、
ユーザインターフェース自動化サービスを含むアクセシビリティシステムコアを通じて前記クライアントを登録し、かつ、前記ユーザインターフェース情報がイベント登録要求と合致するか否かに基づいて第1のユーザインターフェース情報をフィルタリングするステップであって、前記第1のユーザインターフェース情報は、前記クライアントに提供されるものであるステップと、
論理ツリーを含むクライアント側インターフェースを通じて、前記イベント登録要求と合致するユーザインターフェース情報を見えるようにすると共に、前記論理ツリーを含む前記クライアント側インターフェースを通じて、前記イベント登録要求と合致しないユーザインターフェース情報を隠すステップと、
サーバ側インターフェースを通じて、サーバ側アプリケーションを構築するために使用されているユーザインターフェースエンジンにかかわらず、前記サーバ側アプリケーションから前記アクセシビリティシステムコアへの情報転送を可能にするステップと
を含み、
前記アクセシビリティシステムコアの前記ユーザインターフェース自動化サービスは、ユーザインターフェース自動化サーバに通信可能に結合されたユーザインターフェース自動化クライアントを含むイベント機構を備え、
前記ユーザインターフェース自動化クライアントは、前記クライアント側インターフェースにわたり動作して、前記イベント登録要求を前記クライアントから受け取り、かつ、前記ユーザインターフェース自動化サーバに前記イベント登録要求を通知するために前記ユーザインターフェース自動化サーバと通信し、
前記ユーザインターフェース自動化サーバは、前記クライアントが前記イベント登録要求を開始したときに生成され、前記サーバ側インターフェースに結合されたユーザインターフェースエンジンからのイベント情報を探し出すために前記サーバ側インターフェースにわたり動作して、(a)前記イベント登録要求と合致するイベントについて前記ユーザインターフェースエンジンのユーザインターフェースをモニタし、(b)前記イベント登録要求と一致するイベント情報をフィルタリングし、(c)フィルタリングされた前記イベント情報に基づいて前記論理ツリーを生成し、(d)前記論理ツリーを前記ユーザインターフェース自動化クライアントに送信することを特徴とするコンピュータ読み取り可能な記憶媒体。
【図1】
【図2】
【図3】
【図4A】
【図4B】
【図4C】
【図4D】
【図5】
【図6】
【図7】
【図8】
【図2】
【図3】
【図4A】
【図4B】
【図4C】
【図4D】
【図5】
【図6】
【図7】
【図8】
【公開番号】特開2009−199618(P2009−199618A)
【公開日】平成21年9月3日(2009.9.3)
【国際特許分類】
【出願番号】特願2009−125718(P2009−125718)
【出願日】平成21年5月25日(2009.5.25)
【分割の表示】特願2004−541439(P2004−541439)の分割
【原出願日】平成15年5月16日(2003.5.16)
【出願人】(500046438)マイクロソフト コーポレーション (3,165)
【Fターム(参考)】
【公開日】平成21年9月3日(2009.9.3)
【国際特許分類】
【出願日】平成21年5月25日(2009.5.25)
【分割の表示】特願2004−541439(P2004−541439)の分割
【原出願日】平成15年5月16日(2003.5.16)
【出願人】(500046438)マイクロソフト コーポレーション (3,165)
【Fターム(参考)】
[ Back to top ]