Implementing an MSAA Server を完成原稿にするーその21

BGM を聞きながら翻訳をする人も多いと思います。私も主にクラッシクのピアノ曲を BGM にしております。ところで、この BGM ですが、IT の恩恵を多いに授かっています。私は、学生時代からのクラッシク音楽のファンですが、当時音楽は　30 センチLP盤に収められておりました。バッハの平均律クラビアを、バルヒャという盲目のチェンバリストの演奏で聞いておりましたが、LP 盤で 5　枚に入っていました。全曲を通して聞こうとすると、裏表合わせて10面ほとレコード針を走らせる必要がありました。今であれば、MP3で全曲１枚のCDに収まります。3時間ほどノンストップで　BGM として流すことが可能です。まさに隔世の感じがします。本当に便利になりましたね。3時間はまとまった翻訳をするには丁度いい時間なので、BGM がタイムキーパの役割も果たしています。

さて、MSAA の世界へ今日も BGM を聞きながら優雅に旅立つことにします。



原題: Implementing an MSAA Server
訳題: MSAA サーバーを実装する

原文：　 青色表示
訳文：　 黒色表示
校正文： 赤色表示
校正対象範囲：　黒色太字表示

Not all MSAA objects implemented by 3rd party vendors

Problem: As described above, screen readers tend to look first for window classes they know, such as Button, ListBox, ComboBox, msctls_statusbar32, msctls_trackbar32, #32770 (dialog class), SysTreeView32, Static, Edit and RichEdit. AT vendors have typically spent the most time making windows with these classes work, so they are fully debugged. In addition, the user comes to expect appropriate behavior for status bars, dialog boxes and tree views based on the fact that most apps use the standard control. Unfortunately, the MSAA implementation often lags. For example, tree views will probably not be accessible with most assistive technologies even if you have a perfect MSAA implementation. Automatic screen reading of dialog boxes and status bars will often not work just because you're using the wrong class name, even if your MSAA implementation is perfect, and everything else about the objects is completely normal.

全てがサードパーティーベンダーによって実装されるわけでない MSAA オブジェクト

問題: 上記で説明しましたように//→上述しましたように//、スクリーンリーダは、ボタン、リストボックス、コンボボックス、msctls_statusbar32、 msctls_trackbar32、#32770 (ダイアログクラス)、SysTreeView32、Static、Edit および RichEdit など、最初に自分が知っているウィンドウクラスを探す傾向があります//→ボタン、リストボックス、コンボボックス、msctls_statusbar32、 msctls_trackbar32、#32770 (ダイアログクラス)、SysTreeView32、Static、Edit 、RichEdit など、スクリーンリーダは、最初に自分が知っているウィンドウクラスを探す傾向があります//。//挿入：→補助テクノロジー//ベンダーではこれらのクラスの働きによってウィンドウを機能させることに//→作ることに//時間のほとんどを費やし//→費やするので//、ウィンドウは完全にバクとりされます。さらに、ユーザーは、多くのアプリケーションが標準的な制御を使うという事実に基づいて、ステータスバー、ダイアローグボックス、ツリービューが正しく動作することを期待するようになります。不幸にして//→残念ながら//、 MSAA の実装は遅れ勝ちです。例えば、ツリービューは、完全な MSAA の実装が存在してるにのにおそらくほとんどの補助テクノロジーでアクセシビリティとして使えないでしょう。ダイアログボックスとステータスバーの自動スクリーン読み上げは、MSAA の実装が完ぺきで、オブジェクトに関して他の全てが完全に正常であるにもかかわらず、間違ったクラス名が使われているという理由のためだけに、しばしば//→ほとんど//動作しません。

Solution: There are three things you can do: 1) try to use the standard class names, 2) pressure the screen reader vendor to fix their MSAA implementation or use better heuristics, and 3) get around the problem with 3rd party scripts for those AT's that can use them.

解決方法: 出来ることが三つあります//→三つの対応が可能です。//：１）標準のクラス名を使うようにする。２）スクリーンリーダのベンダーにプレッシャーをかけて、 MSAA の実装を修正して//→修正したり//よりよい経験則を使うようにさせる。３）サードパーティーのスクリプトを使用している補助テクノロジー用のスクリプトの問題を解決する//→サードパーティーのスクリプトを使用することで、補助テクノロジーのスクリプトの問題を解決する//。

続きはまた明日。

Implementing an MSAA Server を完成原稿にするーその20

また、全然関係のない話となりますが、我が家の花壇は今チューリップが見ごろになっています。昨年の１０月に球根をいくつか植えたものがほぼすべて美しく開花しています。色は４色あって、開花した順番にいうと、赤、白、黄色、紫　で、黄色と紫がほぼ同時に開花しています。一番最初に開花した赤の中には、そろそろ花弁が落ちそうな気配のものもあります。ところで、この開花順とは考えてみると不思議な現象です。昨年植えたときは、当然すべて同じ日に植えています。もちろん個体差があるので、同じ赤でも早く開くものと、遅く開くものもあります。しかし色としてみた場合も花開く順番が存在するようです。最初に開いた赤と最後の紫まで、２週間くらいの差がありました。この色の集合としての開花順に気付いて非常に面白いと思いました。今風に言うと、球根として色別に開花期間が遺伝子に刷り込まれているのでしょうか。大げさですが、これも自然界の摂理のひとつでしょうか。

さて、MSAA の世界へ戻りましょう。



原題: Implementing an MSAA Server
訳題: MSAA サーバーを実装する

原文：　 青色表示
訳文：　 黒色表示
校正文： 赤色表示
校正対象範囲：　黒色太字表示

WindowFromAccessibleObject depends on client-window relationship

Problem: Unless certain rules are followed, WindowFromAccessibleObject will break, causing the failure of accessibility testing tools like accexplore.exe, and assistive technologies which require knowledge of the window class to know what app-specific configurations to run. WindowFromAccessibleObject works by walking up the parent chain until it finds an object of ROLE_WINDOW. If it can't find one, it fails.

クライアントとウィンドウの関係に依存する WindowFromAccessibleObject

問題: ある種の規則に従わなければ、WindowFromAccessibleObject は壊れ、accexplore.exe のようなアクセシビリティ試験ツールや、機能しているアプリケーション固有の設定を知るためにウィンドウクラスの情報を必要としている補助テクノロジーはエラーになります//→機能しているアプリケーション固有の設定を知るためにウィンドウクラスの情報を必要としている accexplore.exe のようなアクセシビリティ試験ツールや、補助テクノロジーはエラーになります//。WindowFromAccessibleObject は ROLE_WINDOW を見つけるまで親の連鎖を上ります//→上ることで機能します//。見つからないとエラーとなります。

Solution: Allow Microsoft Windows to handle WM_GETOBJECT messages for OBJID_WINDOW. For OBJID_CLIENT, the accessible parent must point to the ROLE_WINDOW object, or at least ensure that it's in the parent chain. The easiest way to do this is to OBJID_CLIENT object cache its parent's window handle and then implement its get_accParent() method to return the results of AccessibleObjectFromWindow(mParentHwnd OBJID_WINDOW, IID_IAccessible, &ptr);

解決方法: Microsoft Windows に OBJID_WINDOW 用の WM_GETOBJECT のメッセージを処理させてください。OBJID_CLIENT 用には//→に//、アクセシビリティの親は ROLE_WINDOW オブジェクトを指し示すか、//挿入：→ROLE_WINDOW オブジェクトが、//すくなくとも、親の連鎖に必ず存在するようにする必要があります。この事を実施する最も簡単な方法は、 OBJID_CLIENT オブジェクトに親のウィンドウハンドルをキャッシュし、get_accParent() メソッドを実装し AccessibleObjectFromWindow(mParentHwndOBJID_WINDOW, IID_IAccessible, &ptr) の結果を返すことです。（草稿訳注：OBJID_CLIENT がハンドルをキャッシュし get_accParent() メソッドで結果を返すと理解しましたが、これでいいでしょうか。原文で、cache に to-不定詞がないなど英語構文が理解しがたいです。）//→OBJID_CLIENT オブジェクトにアクセシビリティの親のウィンドウハンドルをキャッシュし、その get_accParent() メソッドを実装して AccessibleObjectFromWindow(mParentHwndOBJID_WINDOW, IID_IAccessible, &ptr) の結果を返すことによって、この事はごく簡単に実施できます//;

明日に続く。

Implementing an MSAA Server を完成原稿にするーその19

昨日の続きです。
本日は、結構やり応えのある内容かも。


原題: Implementing an MSAA Server
訳題: MSAA サーバーを実装する
原文：　 青色表示
訳文：　 黒色表示
校正文： 赤色表示
校正対象範囲：　黒色太字表示

Undocumented Window Class Usage

Problem: For common controls, MSAA is actually less direct than simply getting the window class and style bits for a window, so AT products only look for it only when necessary. In fact, when a control has its own Window, it's easy for a 3rd party application to know whether the object is disabled, focused, hidden, checked, etc.

文書化されていないウィンドウクラス使用方法//→文書にないウィンドウクラスの用法//

問題: 普通の制御では、MSAA は実際、ウィンドウ用に//→実際ウィンドウ用に//単にウィンドウクラスやスタイルビットを得るほど直接的ではないので、補助テクノロジー製品は必要な時だけ MSAA を探します。事実、制御が自分自身のウィンドウを備える時は、サードパーティーのアプリケーションが、オブジェクトの状態が機能不全、フォーカスされた、隠されている、チェックされたなどと知るのは簡単です//→オブジェクトが機能しない、フォーカスされている、隠されている、チェックされたなどその状態を知るのは簡単です//。

Some assistive technologies will look for MSAA if it doesn't already know that the given window class is used for something common. Common examples are Button, ListBox, ComboBox, msctls_statusbar32, msctls_trackbar32, #32770 (dialog class), SysTreeView32, Static, Edit and RichEdit. Other assistive technologies use a whitelist, and must list your window classes somewhere in their implementation, and then turn on MSAA support when a window of that class receives focus. The window class is also used to determine a host of hard-coded behaviors, such as whether or not a screen reader will load the entire MSAA tree into a special buffer for the user to navigate with screen reader commands. This is only supposed to occur for document navigation, not for UI/dialogs. where your application's keyboard commands will be solely used to navigate.

補助テクノロジーの中には、MSAA が所定のウィンドウクラスが共用物のために使われている事をまだ知らない内は//→所定のウィンドウクラスが共用物のために使われている事をまだ知らない内は//、MSAA を探すものがあります。共通物の例とは、ボタン、リストボックス、コンボボックス、msctls_statusbar32、 msctls_trackbar32、#32770 (ダイアログ クラス)、SysTreeView32、Static、Edit および RichEdit//→Edit 、 RichEdit//です。他の補助テクノロジーの中には、白表（whitelist）を使い実装時どこかにウィンドウクラスのリストを作成し、そのクラスのウィンドウがフォーカスを受け取る時に MSAA のサポートを有効にする必要のあるものもあります。そのウィンドウクラスはまた、ユーザーがスクリーンリーダのコマンドを使って移動するために、スクリーンリーダが MSAA ツリー全部を特別なバッファへロードするかしないかなど、ハードコード化された働きのホストを見つけるために使われます//→そのウィンドウクラスはまた、ハードコード化された多くの働きを決めるためにも使われます。たとえば、ユーザーがスクリーンリーダのコマンドを使って画面を移動するのに、スクリーンリーダが MSAA ツリー全部を特別なバッファへロードするかしないかなどについてです//。これは、UI/ ダイアログボックスのためではなく、アプリケーションのキーボードコマンドが専ら移動に使われるドキュメントの移動のためにのみ発生することになっています。（草稿訳注：where your application's keyboard commands will be solely used to navigate は、どちらにかかるか document navigation か UI/dialogs か、どっち？)//→アプリケーションのキーボードコマンドが専ら移動に使われる UI/ ダイアログボックスのためではなく、ドキュメント上の移動のためにこの事が発生するのです。//

Solution: Contact each vendor who's product isn't using your MSAA, and let them know what window classes you will be using MSAA for. If possible, use a different window class name for documents/content than you use for UI/dialogs. Or, do what Mozilla does - expose a control ID (GWL_ID) of 1 for content, and 0 for UI. Consistent window class names are important for the assistive technology vendors, so that they can determine what code to run for a given window. Don't change window class names after you have shipped a version.

解決方法: あなたの MSAA を使用していない製品のベンダーに連絡をとって、どのウィンドウクラスのためにあなたが、 MSAA を使うことになるかを//→あなたが MSAA を使うことになるウィンドウクラスを//知らせてあげてください。可能であれば、UI/ ダイアローグボックス用とは異なるドキュメント/コンテンツ用のウィンドウクラス名を使用してください。あるいは、 Mozilla がしているように、コンテンツ用に 1 、 UI 用に 2 として制御 ID (GWL_ID) を公開してください。補助テクノロジーベンダーにとっては、所定のウィンドウで機能しているコードを見つけるために//→見極めるのに//一貫した//→一貫性のある//ウィンドウクラスの名前を付けることが重要です。製品の出荷後にウィンドウクラス名を変更しないようにお願いします。

フーツ、やれやれ、難しいですね。でも今日は終わったね。
駅に行く途中で、桜の満開の広場があるので、そこにビールでも持っていっぱいやりたい気分。・・・・・・

Implementing an MSAA Server を完成原稿にするーその18

まだまだ花粉症の季節は終わりません。それが終わるまえにはこの文書も完成稿になっていることでしょう。さて、今日もくしゃみをこらえて、なみだ目でがんばるぞ！


原題: Implementing an MSAA Server
訳題: MSAA サーバーを実装する

原文：　 青色表示
訳文：　 黒色表示
校正文： 赤色表示
校正対象範囲：　黒色太字表示


MSAA Implementation is Not Performant

Problem: The assistive technology may interact slowly with your application.

Solution: Try not to calculate the same things more than once or create the same objects more than once. For example, create and cache an object's children when you look for them in get_accChildCount(), so that you can just hand them back when asked for using get_accChild() or accNavigate(). Support IEnumVARIANT so that the MSAA client can ask for a number of children in one call. In custom interfaces, create methods that hand back a lot of data in one call, rather than requiring a large number of calls. Fewer calls are much better better because COM Marshaling is slow.

MSAA の実装は高性能でない。

問題: 補助テクノロジーとあなたのアプリケーションとの相互リアクションは遅いかもしれない//→ 補助テクノロジーは、あなたのアプリケーションとの間で高速に応答し合うことができないかもしれません//。

解決方法: 同じことを二度以上計算したり、同じオブジェクトを二度以上作らないようにしてください。例えば、get_accChildCount() で子を探す時、オブジェクトの子を作ってキャッシュしてください。そうすると、get_accChild() や accNavigate() を使う事が要求された時、子をただ返すだけで良いです//→ 十分です//。//→(訳抜けを補充） Support IEnumVARIANT をサポートして MSAA クライアントが一度の呼出しでたくさんの子を要求できるようにしてください。//カスタムインターフェイスでは、呼出し回数を増やす事はせずに、一度の呼出しでたくさんのデーターを返すメソッドを作ってください。COM //（挿入）→の//マーシャリングが遅いので、呼出し回数が少なければ少ない程良いと言えます。//

Differing client implementations

Problem: Every assistive technology uses MSAA differently.

Solution: We don't know of any outright conflicts in the differing uses of MSAA (yet). However, be on guard. If a vendors asks you to do something different from the spec, it's better to check with the other vendors before moving forward. Check to see what applications from Microsoft do in a similar situation.

異なるクライアント実装//→クライアントで異なる実装//

問題: 全ての補助テクノロジーは MSAA を異なる方法で使用しています。

解決方法: MSAA を異なる方法で使用して大きな争いがあったかどうか（まだ）知りませんが、用心するに越したことはありません。ベンダーに仕様と異なる事を求められたなら、実行する前に他のベンダーをチェックした方がよいでしょう。同じ//→似た//状況で Microsoft のアプリケーションの方法を調査するのも良いでしょう。

以上

Implementing an MSAA Server を完成原稿にするーその17

引き続きアーロンさんの MSAA の精緻なる検証をご覧ください。


原題: Implementing an MSAA Server
訳題: MSAA サーバーを実装する

原文： 青色で表示
訳文： 黒色で表示
校正箇所： 黒色太字で表示
校正文： 赤色で表示

Issues with Tree Views

Problem: Tree views are difficult to support MSAA in, because the nodes may be constantly changing or lazily instantiated. The screen reader vendors actually use the SysTreeView32 class directly rather than the MSAA support for them, and can thus provide better support for native tree views.

ツリービューに関する事柄

問題: ツリービューで MSAA をサポートするのは、ノードが常に変わっていて、インスタンス化がきっちりとされないために難しいです→ノードが常に変化し、インスタンス化がきっちりとされないために、ツリービューで MSAA をサポートするのは難しいです。スクリーンリーダのベンダーは MSAA に SysTreeView32 クラスをサポートさせるよりは→させずに、挿入：→自分たちで直接 SysTreeView32 クラスを実際に使用します。こうしてネイティブなツリービューによりラスをサポートさせるよりは、直接 SysTreeView32 クラスを実際に使用します。こうしてネイティブなツリービューにより→にとって良いサポートを提供できます。良いサポートを提供できます。

Solution: Look carefully at how Microsoft implements MSAA for its tree views. The tree view object itself handles all of the requests for get_accName for child objects. The child ID is part of the VARIANT structure's information. This means you don't really need to create a separate object for each tree view row, which saves a lot of work. Also, rather than have multiple nested level of objects, treat all of the rows as direct children of the main tree view object. Simply put the level, i.e. "1", "2", 3", etc. in the value field.

解決方法: Microsoft のツリービューへの MSAA の実装方法を注意深く調べてください。ツリービューオブジェクトそのものが、子オブジェクト用の→用に get_accName への全ての要求を処理します。子 ID は変数構造の情報の一部です。これは、実際各ツリービューの並び用に別のオブジェクトを作る必要がないので、多くの仕事が省かれることを意味します→実際ツリービューの階層の並び毎に別のオブジェクトを作る必要がないので、このことは多くの仕事が省かれることを意味します。また、オブジェクトの複数の入れ子レベルを作らずに→オブジェクトの入れ子構造を複数レベル作らずに、すべての階層を主要ツリービューオブジェクトの直接の子たちとして扱ってください→ツリービュー主要オブジェクトの直接の子たちとして、すべての階層の並びを扱ってください。単純に→単に値の領域に「1、2、3、・・」と階層を入れてください。

以上

Implementing an MSAA Server を完成原稿にするーその16

昨日の続きです。

原題: Implementing an MSAA Server
訳題: MSAA サーバーを実装する
原文：　 青色表示
訳文：　 黒色表示
校正文： 赤色表示
校正対象範囲：　黒色太字表示


Issues with Links

Problem: Some assistive technologies have inflexible heuristics when it comes to reading links. They may not read the object unless the states are correctly set. Second, they can mishandle the object if it cannot parse the whitespace according to its own rules. Most assistive techologies don't know what to do with links embedded in a dialog, as is becoming more common.


リンクに関する事柄

問題: 補助テクノロジーの中にはリンクを参照する件に関して、柔軟性のない経験則を抱えるものもあります。状態が正しく設定されなければ、補助テクノロジーがオブジェクトを読まないこともあります。第二に、リンクの参照は独自の規則に従ってホワイトスペースを解析できなければ、補助テクノロジーがオブジェクトの処理を間違えることがあります。補助テクノロジーには、一般的になっている事なのに、ダイアローグボックスに埋め込まれたリンクの扱い方法を知らないものが多いのです//→一般的になっている事なのに、補助テクノロジーには、ダイアログボックスに埋め込まれたリンクの扱い方法を知らないものが多いのです//。

Solution: For links inside documents, make sure the ROLE_LINK object and its child ROLE_TEXT objects all have STATE_LINKED set. For multi-line links with a line break in the middle, make sure there is no whitespace at the beginning or end of any of the accessible names, and make sure there is a rn where the line breaks occur in the accessible name for the ROLE_LINK. For an example of how to do this properly, see Internet Explorer or Gecko. Again, if it's not done exactly this way, some links will not be read.

For links inside dialogs, just expose a single ROLE_LINK object and work on a scripting or code change solution with the assistive technology vendor.


解決方法: ドキュメント内のリンクでは、ROLE_LINK オブジェクトとその子 ROLE_TEXT オブジェクトにすべて、STATE_LINKED を必ず設定して下さい。途中で行が折れている複数行のリンクでは、すべてのアクセシビリティの名前の頭や末尾に必ずホワイトスペースが無いようにして下さい。ROLE_LINK 用のアクセシビリティの名前の中に行の折り返しが発生する箇所では、rn を必ず入れてください。この正しい処理例については、Internet Explorer や Gecko を参照して下さい。繰り返しになりますが、この事が正確に実行されなければ、参照できないリンクが存在することになります。

ダイアローグボックス//→ダイアログボックス//内のリンクでは、単一の ROLE_LINK オブジェクトを公開するだけにして、補助テクノロジーベンダーと一緒にスクリプトやコード変更の解決方法を調べて下さい//→補助テクノロジーベンダーによるスクリプトやコード変更の解決方法に取り組んでください//。

ここまでにしましょう。さきはまだ長いですね。マラソンで行くと折り返し地点を経過してしばらくたったくらいかな？