Gecko Info for Windows Accessibility Vendors 校正その3

昨日の続きです。



原題: Gecko Info for Windows Accessibility Vendors
訳題: Windows アクセシビリティベンダー向け Gecko 情報
原文：　 青色表示
訳文：　 黒色表示
校正文： 赤色表示
校正対象範囲：　黒色太字表示
*n(=int)校正コメント:赤色表示

MSAA tree vs. DOM tree - what's the relation?

Diagram showing MSAA tree is a subset of the DOM tree
The MSAA tree and the DOM tree are parallel structures, although the MSAA tree is a subset of the DOM tree. QueryService() can be used to switch between the interfaces (IAccessible, ISimpleDOMDocument, ISimpleDOMNode and ISimpleDOMText). If there is no MSAA node for a DOM node, or vice-versa, QueryService() will return null.

MSAA ツリー対 DOM ツリー：その関係は？

図は、MSAA ツリーが DOM ツリーの下位集合であることを示します。
MSAA ツリーと DOM ツリーでは、MSAA ツリーは DOM ツリーの下位にあるものの、平行的構造を備えています。 QueryService() はインターフェイス (IAccessible、ISimpleDOMDocument、ISimpleDOMNode、ISimpleDOMText) を切り替えるのに使われます。DOM ノード用に MSAA ノードが存在しないならば(もしくはその逆でも)//→DOM ノードに対応する MSAA ノードが存在しない(また反対に MSAA ノードに対応する DOM ノードが存在しない)ならば//、QueryService() は null を返します。

本日は短いですが、ここまでにしましょう（できるだけ意味のまとまりの点から、節単位で校正しますので長かったり短かったりするのは申し訳ないですが。）

Gecko Info for Windows Accessibility Vendors 校正その2

本日は、小ぬか雨降る寒い日です。こういう日は、暖かいコーヒーと音楽があれば、滅入りがちな気持ちも、安らぎと小さな幸福感に満たされますね。さて、おもむろに、今日も校正作業へを始めます。



原題: Gecko Info for Windows Accessibility Vendors
訳題: Windows アクセシビリティベンダー向け Gecko 情報

原文：　 青色表示
訳文：　 黒色表示
校正文： 赤色表示
校正対象範囲：　黒色太字表示
*n(=整数)+校正コメント:赤色表示

Definitions

* Gecko : Mozilla's rendering engine. Gecko is the internal engine that Mozilla uses to render any kind of web content. It supports HTML, Cascading Style Sheets (CSS) and the Document Object Model (DOM).

定義

* Gecko : Mozilla の表示エンジン。Gecko は Mozilla があらゆる種類のウェブコンテンツを表示するために使う内部エンジンです。HTML、Cascading Style Sheets (CSS)、Document Object Model (DOM) をサポートします。

MSAA : Microsoft Active Accessibility, an API devised by Microsoft so that accessibility aids can track what's going on inside the user interface of any software package that supports it. If you seriously need to understand MSAA, you'll need to read the docs on MSDN and play with the sample apps and code that come with MSAA SDK 1.3. (I recommend SDK 1.3 because the MSAA SDK 2.0 doesn't come with the source code to the testing tools. The other differences are minor).

MSAA : Microsoft Active Accessibility は Microsoft によって作られた API で、アクセシビリティの補助機能が、ユーザーインターフェイスをサポートするソフトウエアーパッケージにおいて、ユーザーインターフェイスの内部で発生している事を追跡できます。もし MSAA を真剣に理解しようとするならば、MSDN についての//→で//資料を読み、MSAA SDK 1.3 によって提供されるアプリケーションとコードを試してみる必要があります。（MSAA SDK 2.0 はテストツールのソースコードを備えていないので、 SDK 1.3 を推奨します。他の違いは重要ではありません。）

DOM : Document Object Model. This is the W3C's specification for how web content is exposed to Javascripts and other languages. It covers content, style and events. Inside the process, Gecko-based products have full support for DOM level 1, and more support for the standard is on the way. However, exposing the entire DOM to external software packages is quite involved. We have chosen a subset of the DOM needed for accessibility aid vendors. Events such as focus changes must be tracked through MSAA events, rather than DOM events.

DOM : Document Object Model。これは、ウェブコンテンツがどのようにして Javascript や他の言語へ公開されるかについての W3C の仕様です。DOM はコンテンツ、スタイル、イベントをカバーします。プロセス内部では、Gecko ベースの//→をベースにした//製品は DOM レベル 1 をフルサポートし、標準//*1→標準(DOM)//への一層のサポートが進行中です。しかし、全 DOM を外部ソフトウエアーパッケージに公開することはあまりに大掛かりとなります。私たちはアクセシビリティ補助機器ベンダー用に不可欠な DOM の下位集合を選択しています//→に選択を限定しています//。フォーカスの変更などのイベントは DOM イベントではなく、MSAA イベントを通じて//→によって//追跡される必要があります。

*1 the standard= DOM: Mozilla による DOMレベルのサポート

本日はここまでにします。

Gecko Info for Windows Accessibility Vendors 校正その1

昨日校正を完了しました「MSAA サーバーを実装する」の後に、わたしが Mozilla Japan で公開しているアーロン(Aaron Leventhal)さんの草稿で残っているものが、2本のみとなりました。その一本が今回の公開校正？でとりあげます"Gecko Info for Windows Accessibility Vendors"です。それと、もう一本は以前にも触れたかもしれませんが、アクセシビリティの歴史を説明したSoftware Accessibility - Where Are We Today?でこちらも、現在草稿公開中です。この2本を完成原稿に上げると、ほぼアーロンさんの文書の主なものは、和訳を完了することになると思います。それで、一区切りできるので、その後は、次のチャレンジに向かうことができます。

今回の文書である"Gecko Info for Windows Accessibility Vendors" の Gecko とは Mozilla で使用されているレイアウトエンジンですが、詳細の説明についてはリンクGecko とは何ですか？をご参照ください。

ところで、新しい草稿のチェックに入るにあたって、少し改善をしたいと思います。校正による変更点にコメントを入れるようにして、変更の理由や考え方をできるだけ明らかにします。いままでは、変更した結果しか書きませんでしたが、こうして校正作業を公開している以上、なんらかの説明を加えた方が良いと思います。また、自分でも考えを整理できると考えました。・・・・・と、前置きは短く本日も、作業にとりかかります。


原題: Gecko Info for Windows Accessibility Vendors
訳題: Windows アクセシビリティベンダー向け Gecko 情報

原文：　 青色表示
訳文：　 黒色表示
校正文： 赤色表示
校正対象範囲：　黒色太字表示
*n(=整数)校正コメント:赤色表示

Gecko Info for Windows Accessibility Vendors

This FAQ explains how makers of Windows screen readers, voice dictation packages and magnification software can support Gecko-based software. The base of our support for these products is MSAA (Microsoft Active Accessibility), external content DOM support, and the keyboard API/user interface. Currently, support for accessibility API's exists only on the Windows platform.

Windows アクセシビリティベンダー向け Gecko 情報

この FAQ は Windows のスクリーンリーダ、音声検出パッケージ、拡大鏡ソフトウエアーの製造者//→製作者*1//がいかにして Gecko ベースのソフトウエアーをサポート出来るかについて説明しています。これらの製品をサポートする私たちのベースとなるのは、MSAA (Microsoft Active Accessibility)、外部コンテンツの DOM サポート、およびキーボード API/ ユーザーインターフェイスです。アクセシビリティ API のサポートは現在、Windows プラットフォームのみに存在します。

//→*1:maker 製作者; 製造者(=manufacturer)より、広い意味をもたせる。//

Contents

* Definitions
* Windows Applications Based on the Gecko Layout Engine
* MSAA Support: IAccessible Methods
* MSAA Support: Event Tracking and Unique ID's
* MSAA Features We Do Not Support
* Intentional Differences with Internet Explorer
* Enhancing Performance on the Client End via IEnumVARIANT
* Additional DOM support
* Keyboard UI Information
* Beyond HTML: Other Types of Web Content
* Questions or Comments?

目次

* 定義
* Gecko レイアウトエンジンに基づく Windows アプリケーション
* MSAA サポート: IAccessible メソッド
* MSAA サポート: イベント追跡と一意の ID
* サポートしない MSAA の機能
* Internet Explorer との意図的な違い
* IEnumVARIANT によるクライアントエンドの性能向上
* 追加的 DOM サポート
* キーボード UI 情報
* HTML を超えて: 他の種類のウェブコンテンツ
* 質問あるいはコメント?

本日は一回目なので、このくらいにして明日から張り切っていきましょう。

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

本日ようやくマラソンのゴールを切るために、スタジアムに入ります。ほぼ、一ヶ月に渡り長々と草稿の見直しを継続して来ましたが、最後の感動的？段階に達しました。こうして見ると、意味の取り違え、不十分な日本語、誤訳など様々な問題点　-　校正すべき箇所に気付いて変更をかけてきました。その結果、ようやく、完全とはいえないとしても、完成稿に少しは近づいたと思います。もちろん、まだまだ多くの問題点や、誤訳箇所も存在するかもしれません。特に、プログラムの専門家でない者が、プログラム関連書を参照しながら、訳しておりますので、技術的解釈面において問題点が少なからず、存在するかもしれません。その時は、気付かれた方にご指摘をいただければ、幸いです。当原稿は、 Mozilla Japan org. に完成稿として登録いたしますが、登録後も引きづづき皆様のご意見をお待ちしております。



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

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

Generating MSAA Events

First, keep in mind that most MSAA events aren't utilized by accessibility aids. Therefore we implement only the handful that matter. See the Events cheat sheet above for the list of events we implement. By far the most important one is EVENT_OBJECT_FOCUS.

MSAA イベントを発生させる

ほとんどの MSAA イベントがアクセシビリティの補助機器によって使用されないことを最初に留意してください。従って私たちは重要な一握りのみを実装することになります。実装されるイベントのリストとして上記のイベントカンニングペーパーを参照してください。これまでで一番重要なイベントは、 EVENT_OBJECT_FOCUS です。

When a potential accessibility-related event occurs within Mozilla, it is typically listened for by nsDocAccessible or nsRootAccessible. The event listeners on these classes call FireToolkitEvent(), which is implemented for every accessible. Eventually, the event ends up at nsDocAccessibleWrap::FireToolkitEvent() which calls NotifyWinEvent from the Win32 API. NotifyWinEvent is passed arguments for the window the event occurred in, and the ID of the child within that window. Accessibility aids use the Win32 call SetWinEventHook() to register as a listener for these events. Creating a unique child ID for every object within a window can be difficult, see the problem and solution for no unique child ID for object in window.

Mozilla 内でアクセシビリティ関連のイベントが発生する可能性があれば、ふつう nsDocAccessible か nsRootAccessible によって監視されます。これらのクラスのイベントリスナーは、全てのアクセシビリティに実装されている FireToolkitEvent() を呼びます//→ 呼び出します//。最後にイベントは、 Win32 API から NotifyWinEvent を呼ぶ//→ 呼び出す// nsDocAccessibleWrap::FireToolkitEvent() で終わります。イベントがその中で発生するウィンドウのために NotifyWinEvent は引数とそのウィンドウ内の子の ID とを渡されます//→ NotifyWinEvent はイベントが発生するウィンドウのための引数とそのウィンドウ内の子の ID とを渡されます//。アクセシビリティ補助機器は、Win32 を使い SetWinEventHook() をよび//→ Win32 の呼出しである SetWinEventHook() を使い//これらのイベント用にリスナーとして登録します。ウィンドウ内のすべのオブジェクトに対して一意の子 ID を作成する事は困難です。ウィンドウ中のオブジェクトに一意の子 ID がない問題と解決方法を参照ください。　

The assistive technology chooses which events it is interested in learning more about by calling the Win32 method AccessibleObjectFromEvent, which returns the IAccessible to the node corresponding to the child number that had been indicated from NotifyWinEvent(). This ends up asking nsDocAccessibleWrap::get_accChild() for a child IAccessible which matches the child ID we indicated through NotifyWinEvent().

補助テクノロジーは、NotifyWinEvent() から指示された子番号に対応しているノードへ IAccessible を返す Win32 メソッドの AccessibleObjectFromEvent を呼ぶことでもっとよく知りたい//→ 呼び出すことで、もっとよく知る必要のある//
イベントを選択します。これは、nsDocAccessibleWrap::get_accChild() に、NotifyWinEvent() を通して//→ によって//指示された子 ID に合う子 IAccessible を要求することで完了します。

In Mozilla, we use the DOM node pointer in the accessible object as a basis for its child ID, which is also used as a hash key into our cache. We also negate the 32 bit value so that it is always <0, telling us that they're really looking for the IAccessible for an event, not child number x. During the callback, we look up the original accessible node in the nsDocAccessible's cache and return it. Mozilla ではアクセシビリティ・オブジェクトでその子 ID のベースとして DOM ノードポインターを使用します。そしてまた、キャッシュ内の//→ キャッシュ内への//ハッシュキーとしても使われます。また 32 ビット値をネゲートして、いつも <0//→ 必ず 「<0」 ////→で//始めのアクセシビリティノードを調べて、戻します。

6. Feedback
How can this document be improved? Was it useful? Questions? Contact Aaron Leventhal - aaronleventhal@ m o o n s e t . net

6. フィードバック
この文書はどのように改善できますか//→この文書の改善すべき点にお気づきですか//。役に立ちましたか。質問はありますか。//挿入→何かあれば //Aaron Leventhal に連絡してください。- aaronleventhal@ m o o n s e t . net

フーツ、やれやれこれで、ひとつの作業が終了しました。この草稿の校正に取り掛かったときは、まだ青々とした固いつぼみにすぎなかった、我が家の花壇のチューリップは満開の段階を経て、すでに一部、最初に咲き出した赤色や、白色の花の花弁を地面に散らせています。葉もまばらだたバラの木も、花の開花はまだ先とはいえ、芽を吹き始め、新葉を盛んに繁らすほどの勢いです。

・・・・・・・さて、次のテーマをきめて、また新しいチャレンジに邁進したいですね。ちょっと、せっかちかな。(笑)

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

本日は長い節ですが、一気に走り抜けます。



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

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

A Variety of Implementations for IAccessible

There are two main kinds of classes in Mozilla's accessibility class hierarchy, platform-specifc and cross-platform. All of the platform-specific classes have the word "Wrap" appended to them. The Wrap classes contain implementations and interfaces specific to MSAA or ATK. These platform-specific classes inherit from cross-platform classes, where the most of the implementation is done. For example, nsAccessibleWrap inherits from nsAccessible. Every accessible object in the MSAA tree has an implementation dertived from nsAccessible, which exposes accessibility information through nsIAccessible, in a generic cross-platform manner.

IAccessible 用実装のいろいろ

Mozilla のアクセシビリティクラスの階層には、プラットフォーム固有//→に固有なものと//とクロスプラットフォーム//→クロスプラットフォームである//という 2 つの主要//→主要な種類の//クラスがあります。プラットフォーム固有の//→に固有な//クラスのすべてはクラス//→クラス名//に「Wrap」が追加されています。Wrap クラスは MSAA や ATK に固有の//→な//実装やインターフェイスを保持します//→含んでいます//。これらのプラットフォーム固有の//→に固有な//クラスは、ほとんどの実装か完了しているクロスプラットフォームなクラスを継承します//→クロスプラットフォームなクラスを継承し、後者では、ほとんどの実装が完了しています//。例えば、nsAccessibleWrap は nsAccessible を継承しています。 MSAA ツリーのすべてのアクセシビリティオブジェクトは nsAccessible に起源のある実装を備えており、一般的なクロスプラットフォームがするように、nsAccessible を通じてアクセシビリティ情報を公開します。

This default implementation for nsIAccessible knows how to use nsAccessibleTreeWalker to walk Mozilla's content DOM and frame tree, exposing only the objects that are needed for accessibility. The nsAccessibleTreeWalker class knows what it needs to expose by asking each DOM node's primary frame (a Gecko formatting object) for an nsIAccessible, using the nsIFrame::GetAccessible() method. If nsAccessibleTreeWalker gets an nsIAccessible back, then the DOM node considered to be an accessible object. The nsIAccessible that is returned is either a new one, or reused from the accessibility cache, and the correct type of accessibility object to correctly expose that DOM node through the cross-platform nsIAccessible and MSAA-specific IAccessible interfaces.


nsIAccessible の初期設定実装によって、nsAccessibleTreeWalker に Mozilla のコンテンツ DOM とフレームツリーを歩かせて、アクセシビリティ用に必要なオブジェクトのみを表示させることができます。nsAccessibleTreeWalker クラスは、 nsIFrame::GetAccessible() メソッドを使って、各 DOM ノードの主要フレーム（Gecko のフォーマットマット化オブジェクト）に nsIAccessible を要求することで、何を表示する必要があるかを知っています。もし nsAccessibleTreeWalker が nsIAccessible を取り戻すと、DOM ノードはアクセシビリティのオブジェクトと見なされます。返される nsIAccessible は新しいものかアクセシビリティのキャッシュから再利用されものか//→されるものか//のいずれかで、正しい型のアクセシビリティオブジェクトが、クロスプラットフォームな nsIAccessible インターフェイスと MSAA 固有の//→に固有の// IAccessible インターフェイスによって、正確にドームノードを公開します//→該当するドームノードを明らかにします//。（草稿訳注：and the correct type.... 以下の文は構文上"文"になってない。）　

Every accessibility object created must be cached, and must inherit from nsAccessibleWrap so that it supports a base implementation of nsIAccessible and IAccessible. Apart from that, it is free to override IAccessible or nsIAccessible methods. In this way each class is tailored to the specific abilities and properties of the HTML or XUL/UI objects it applies to, and can support both MSAA, ATK and hopefully any future accessibility API's we need to support. For example nsHTMLButtonAccessible overrides nsIAccessible::GetAccRole to expose ROLE_BUTTON for IAccessible::get_accRole which uses that.


作られるすべてのアクセシビリティオブジェクトはキャッシュされる必要があり、nsIAccessible と IAccessible のベースの実装をサポートするために nsAccessibleWrap を継承する必要あります//→nsIAccessible と IAccessible のベースとなる実装をサポートするために、作られるすべてのアクセシビリティオブジェクトはキャッシュされ、 nsAccessibleWrap を継承する必要あります//。それに加えて、nsIAccessible や IAccessible メソッド//→のメソッド//をオーバーライドするのは自由です//→任意です//。こんな風にして、各クラスは自分が適用される HTML や XUL/UI オブジェクトの固有な機能や属性へ合うように刈り込まれ//→仕立てられ//、 MSAA と ATK の両者をサポートサポート可能となり//→サポートできます。そして//、望ましくは将来サポートする必要のあるすべてのアクセシビリティ API が//→を//サポートできればいいと思います。例えば、nsHTMLButtonAccessible は nsIAccessible::GetAccRole をオーバーライドし、ROLE_BUTTON を使う IAccessible::get_accRole 用の ROLE_BUTTON を公開します//→に ROLE_BUTTON を開示します//。（草稿訳注：which uses that の that は ROLE_BUTTON でいいか？）

A more complicated set of nsIAccessible methods which can be overridden are GetAccFirstChild/GetAccLastChild/GetAccChildCount, which allows for objects to define their own decendant subtrees. The default behavior for nsIAccessible::getAccFirstChild is to instantiate a nsDOMTreeWalker, and ask it for the first child. However, nsImageAccessible overrides getAccFirstChild, returning the first area of an image map if there is one, otherwise nsnull. This is necessary because the image map areas can be in a completely different area of the DOM from the image they apply to.


オーバライドされる事が可能なもっと複雑な nsIAccessible メッソドのセット//→のメソッドの組合せ//として GetAccFirstChild/GetAccLastChild/GetAccChildCount があり、これらはオブジェクトが自分自身の子孫の下位集合を定義する事を可能にします//→これらによって、オブジェクトは自分自身の下位ツリーを定義できます//。nsIAccessible::getAccFirstChild の初期設定の動作は nsDOMTreeWalker のインスタンスを作り最初の子を要求します。しかし、nsImageAccessible が getAccFirstChild をオーバライドして、領域があれば画像マップの最初の領域を返しますし、なければ//→返します。なければ// nsnull を返します。この事は、画像マップ領域が適用される画像とは完全に別の DOM エリアに存在するために必要になります。（草稿訳注："they apply to" の they が何を指すのか？　ユーザーか？　）　

これで完走間近、スタジアムの歓声がほらそこに聞こえております。ヨッシャ！

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

クラッシク音楽好きの私ですが、以前私はどうしてもシューベルトがあまり好きになれませんでした。美しい旋律にあふれる曲が多いのですが、単調で反復が多く退屈な音楽と感じていました。シューマンのように展開が予想できないような、変化にあふれた面白さがないですし、モーツアルトのような軽快さがなく、またベートベンのように精神的な深みもありません。特に若い頃は、シューベルトからはほとんど遠ざかっていました。当時、知人の中にシューベルトのファンがいましたので、私の感想を話したところ、彼は一瞬沈黙して、私のいうことは分からないでもないが、シューベルトの音楽には、言葉ではうまく言えないがなんともいえない好さがあると言いました。

最近私はシューベルトのピアノ曲を好んで聴くようになりました。翻訳の BGM として、大好きなバッハと並んでよく聞いていますが、これが本当にすばらしい。以前は単調に思えていた曲の構成も全然気にならないどころか、何度繰り返して聞いても飽きません。リヒテルの演奏が好きですが、ドラマッチクにハートに直接響いてきます。ブレンデルも、内田光子も、ポリーニも、どれもすばらしく、美しいピアノの音色は、心地よく天に上るような気分です。ほら見たことか、俺の音楽もすごいだろうと、眼鏡奥から穏やかなシューベルトの顔が語りかけてくるようです。本当に参りました。



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

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

The Accessible Tree vs. the DOM Tree

After the root or doc accessible for a window has been created and handed back to the MSAA client, it is used to traverse the rest of the IAccessible tree using accNavigation, get_accChild and get_accParent. Any IAccessible will support those methods. We also support IEnumVARIANT::Next() which allows for fast marshaling of all of an objects children to a client via COM. In other words, the assistive technology can say "give me all 20 children of this object into this array". That's much faster than 20 separate calls, one for each child.

アクセシビリティツリー対 DOM ツリー

ウィンドウ用に//→用の//ルートアクセシビリティやドキュメントアクセシビリティ//→ルート accessible やドキュメントaccessible// が作成され MSAA のクライアントに渡された//→戻された//後で、それらは、accNavigation、get_accChild および get_accParent を使って、IAccessible ツリーの残りの//→残りの部分の//探索に使用されます。すべの IAccessible がこれらのメソッドをサポートします。また COM 経由で//→ COM を使って//オブジェクト子からクライアントへとすべてを高速マーシャリング可能な IEnumVARIANT::Next() もサポートされます。言い換えれば、補助テクノロジーは「20 の子たちをすべてこの配列へ入れて私にください」と言っています。それは、各子を一人ずづ 20 回に分けて呼ぶ//→呼び出す//よりずっと速いことになります

In Mozilla, the client has another choice for tree navigation -- it can utilize data stored in the DOM via Mozilla's custom ISimpleDOMNode COM interface. Any IAccessible can be used to QueryInterface to an ISimpleDOMNode, and vice versa for a round trip. However, one might QI ISimpleDOMNode to IAccessible only to find it is null, which means that particular node in question is not exposed in the IAccessible tree. See the following diagram for examples of nodes that do no support IAccessible.

Mozilla ではクライアントはツリー移動にもう一つ選択肢があります。 Mozilla のカスタム ISimpleDOMNode COM インターフェイス経由で//→ によって//クライアントは、 DOM に保持されているデーターを使います//→ 使えます//。すべての IAccessible は ISimpleDOMNode への QueryInterface へ使用できますし//→ へ QueryInterface する事ができますし//、逆方向に回ることも出来ます//→ 可能です//。しかし、IAccessible への ISimpleDOMNode を QI し、null を見出すだけの人もいるかもしれません//→ しても、null しか見出せないかもしれません//。これは、問題の特定の//→ 該当の特定//ノードは IAccessible ツリーでは表示されない事を意味します。IAccessible をサポートしないノードのサンプルは下記の図を//→ 下図を//参照してください。

MSAA tree vs. DOM tree - what's the relationship?

Diagram showing MSAA tree is a subset of the DOM tree
The MSAA tree and the DOM tree are parallel structures, although the MSAA tree is a subset of the DOM tree. QueryInterface() can be used to switch between the interfaces used in the two trees (IAccessible and ISimpleDOMNode). If there is no MSAA node for a DOM node, pAccessible->QueryInterface(IID_IAccessible) will return null.

MSAA ツリー対 DOM ツリー：その関係は？

MSAA を示している図は　DOM ツリーの下位集合です。
MSAA ツリーと DOM ツリーは、MSAA ツリーが DOM ツリーの下位集合であるにもかかわらず、平行的な構造です。QueryInterface() は 2 つのツリーの間で使用されるインターフェイス間//→インターフェイス// (IAccessible and ISimpleDOMNode) を切り替えるのに使われます。DOM ノード用に//→に匹敵する// MSAA のノードが存在しないならば pAccessible->QueryInterface(IID_IAccessible) が null を返します。


本日はここまでです。遠くに、ゴール地点のスタジアムがチラホラ見え出しましたね。

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

本日は長いですが、重要な節です。一気に終わりまで行きましょう。



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

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

When the WIN32 API function AccessibleObjectFromWindow() is called, Windows sends the window in question a WM_GETOBJECT message requesting an IAccessible for your root object in the window. In our case, this event is received in mozilla/widget/src/windows/nsWindow.cpp. We send back an IAccessible pointer which can be used by the client to get information about this root object. The assistive technology will use that root IAccessible to traverse the rest of the object tree, by navigating to children and then siblings, etc. Every navigation function such as accNavigate(), get_accChild() and get_accParent() returns an IAccessible pointer.

AccessibleObjectFromWindow() という WIN32 API 機能//→関数//が呼ばれる時 Windows は、ウィンドウ中のあなたのルートオブジェクト用に IAccessible を要求する WM_GETOBJECT メッセージを問題のウィンドウに送ります//→ウィンドウ中のルートオブジェクト用の IAccessible を要求している WM_GETOBJECT メッセージを該当するウィンドウへ送ります//。私たちの場合は、このイベントは mozilla/widget/src/windows/nsWindow.cpp において受け取られます//→私たちは、このイベントを mozilla/widget/src/windows/nsWindow.cpp で受け取ります//。このルートオブジェクトについての情報を得るクライアントによって使われる IAccessible ポインターを私たちは、送り返します//→そして、このルートオブジェクトについての情報を得るクライアントによって使われる IAccessible ポインターを送り返します//。補助テクノロジーはこのルート IAccessible を使用してオブジェクトツリーの残りを子へ次に兄弟へ移動することで、探索します//→残りを、子へ次に兄弟へ移動することで探索します//。accNavigate(), get_accChild() および get_accParent() などのすべてのナビゲーション機能は IAccessible ポインターを返します。

To create the root IAccessible for a window the first time it gets the WM_GETOBJECT message in, nsWindow.cpp first generates an internal event called NS_GETACCESSIBLE, which is handled in PresShell::HandleEventInternal() via the creation of an nsDocAccessibleWrap for an inner window or nsRootAccessibleWrap for a top level window. These classes implement both nsIAccessible, our cross platform API, as well as IAccessible, which is specific to Windows/MSAA/COM. The cross-platform nsDocAccessible and nsRootAccessible classes they inherit from are then told to start listening for DOM, page load and scroll events. These events cause MSAA-specific events, such as EVENT_OBJECT_FOCUS or EVENT_OBJECT_STATECHANGE, to fire on UI and document objects within the applicable window. We'll explain more about events later in this section.

最初に nsWindow.cpp が WM_GETOBJECT メッセージを取り込んだ時ウィンドウ用のルート IAccessible を作成するために、nsWindow.cpp は NS_GETACCESSIBLE と呼ばれる内部イベントを発生させます。そして、内部ウィンドウ用に nsDocAccessibleWrap か最上レベルウィンドウ用に nsRootAccessibleWrap かが作るられる事によって、この内部イベントはPresShell::HandleEventInternal() を渡されます//→そして、内部ウィンドウ用の nsDocAccessibleWrap クラスか、トップレベルウィンドウ用の nsRootAccessibleWrap クラスかが作られる事によって、この内部イベントは、PresShell::HandleEventInternal() で渡されます//。これらのクラスは、私たちのクロスプラットフォーム API である nsIAccessible と Windows/MSAA/COM に固有の IAccessible の 2 つを実装します//→これらのクラスは、私たちのクロスプラットフォーム API の nsIAccessible と Windows/MSAA/COM に固有の IAccessible の 2 つを実装します//。これらが//→これらのクラスが//継承するクロスプラットフォームな nsDocAccessible と nsRootAccessible クラスはその時 DOM イベント、//→DOM の//ページロードイベントとスクロールイベントの監視を開始するように命じられます。これらのイベントは EVENT_OBJECT_FOCUS や EVENT_OBJECT_STATECHANGE など MSAA 固有のイベントを、適用可能なウィンドウ内の UI オブジェクトおよびドキュメントオブジェクト上で起動させます。イベントについては、後ほどこの章で、さらに//→ さらに詳しく//解説します。

Until the WM_GETOBJECT message is processed, the Gecko accessibility service is not used, and thus the accessibility.dll is not loaded, so there is almost zero overhead for accessibility API support in Mozilla or Gecko, in the general case. Once the accessibility service is created, however, Gecko loads code to create an object on demand for every UI or document object that should support IAccessible. The created objects are cached in a hash table, and shutdown when they're no longer needed. They may still exist in memory in a nonfunctional state until the assistive technology completely releases them. See the section on accessible roles to see what kinds of objects Gecko support IAccessible for.

WM_GETOBJECT メッセージが処理されるまで、Gecko アクセシビリティ・サービスは使われず、こうして accessibility.dll はロードされないので、通常は Mozilla や Gecko におけるアクセシビリティ API サポートはほとんどオーバーヘッドがありません。しかし、一度アクセシビリティ・サービスが作られると、Gecko は、IAccessible をサポートするべきすべての UI やドキュメントオブジェクトのために要求があればオブジェクトを作るコードをロードします//→IAccessible をサポートするべきすべての UI やドキュメントオブジェクトのために Gecko は、要求があればオブジェクトを作るコードをロードします//。作られたオブジェクトはハッシュテーブルにキャッシュされ、不要になる時に終了されます。補助テクノロジーによって完全に解放されるまで、オブジェクトはメモリー中に引き続き機能しない状態で存在するかもしれません。どの種類のオブジェクトのために//→に対して// Gecko が IAccessible をサポートするかを参照するために//→するのには//アクセシビリティの役割の章を見てください//挿入→。//


明日に続きます。

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

長々と草稿の校正を継続して来ましたが、この章が実質的に最終章となります。マラソンで言えば走者がゴール地点であるスタジアムの存在を強く意識し始める頃です。そこで、一層走りに力が加わることになりそうです。そんなわけで、有終の美？を迎えられるように、最後の力を振り絞っていざ行かん！


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

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

5. Example: How Gecko and Mozilla Implement MSAA

The Accessible module is where the Mozilla MSAA implementation lives. Feel free to peruse the source code in the accessible module whenever you want to see how something can be implemented.

The accessible module is also where support for Sun's ATK accessibility API for Linux and UNIX is implemented. For documentation specific to the Mozilla ATK effort, supported by Sun Microsystems, see the Mozilla accessibility on Unix page.

5. 例: Gecko と Mozilla が MSAA を実装する方法

アクセシビリティ・モジュール は Mozilla MSAA の実装が存在する場所です。何ががどのように実装されているかを参照したい時は、ご自由に アクセシビリティ・モジュールのソースコードを精読してください。

アクセシビリティ・モジュールはまた Linux と UNIX 用に Sun のATK アクセシビリティ API 用サポートが実装されている場所です。Sun Microsystems によってサポートされる Mozilla ATK の試みに固有の文書化については、Unix 上の Mozilla アクセシビリティページを参照してください。

Creation of IAccessible Objects

The first thing that happens when an assistive technology wants to watch our application is that calls the Windows API function AccessibleObjectFromWindow(). This usually happens right after a window gets focused.

IAccessible オブジェクトの作成

補助テクノロジーが、私たちのアプリケーションを調べたい時に最初に発生する事は//→調べようとする時最初に起こることは//
、AccessibleObjectFromWindow() という Windows API 機能を呼び出すことです。これは通常、ウィンドウがフォーカスされた直後に発生します。

ここからはまた明日にしましょう。ここは、この先まだ長いようなので。

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

昨日の続きです。本日は、章の最後なのでとりわけ力が入ります。



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

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

Vendor quirks

Problem: Because assistive technology tends to utilize MSAA as an additional solution resting on top of old hacks, rather than a completely clean and separate way to deal with an application, and because of the quirky nature of MSAA and of the inflexible heuristics that screen readers use, we do not have a "plug and play solution". In addition, assistive technology vendors are tiny companies, often scrambling to keep up with changes in the applications they already support, or new products other than yours which they need to support. It's very difficult to get vendors to spend time testing an MSAA implementation, send feedback or help find out why things aren't working. Time and version commitments often fall through. There is always a belated new version due around corner, after which you will be promised to be the next priority.

ベンダーの気まぐれ

問題: 補助テクノロジーは、アプリケーションを扱う完全にきれいな個別の方法としてではなく、古い裏技上の補助的解決手段としてMSAA を使い勝ちであり//→アプリケーションを扱う完全に明確で独立した方法としてではなく、古い裏技的テクニックに乗っかった補助的解決手段として補助テクノロジーは MSAA を使いがちであり//、 MSAA の気まぐれな性質とスクリーンリーダに使われる柔軟性のない経験則のために、「プラグアンドプレイ」を備えていません。その上、補助テクノロジーのベンダーは小さな会社で、彼らがすでにサポートするアプリケーションの変更や、これからサポートする必要のあるあなたのもの以外の新商品に対して慌てて追いつこうと//→あたふたとどうにか追随して行こうと//しているのがごく普通です。 ベンダーに MSAA 実装の試験に時間を割いたり、うまく動作しない内容のフィードバックや原因究明の支援をしてもらうのは、とても困難です//→大変なことです//。納期やバージョンアップの約束は頻繁に破られます。常に遅れているバージョンアップ製品がそこにあって//→を抱えており//、あなたの製品の優先度はその後に来ます。


Solution: Try to reach out in a friendly manner to the assistive technology company. Be as easy to work with as you possibly can -- this includes being extremely responsive to their bug reports with new test builds, as well as being very communicative about what you have changed and when. Do as much work as you possibly can without their help. See if your organization can offer something they can't get for themselves. Be patient, and set your expectations to a reasonable level. Realize that it's about both pride and revenue for these companies, and that they need to sell a lot of copies of their software to make up the work they put in to support your app. Remember that no matter how small they are, you need them more than they need you, unless your application's accessibility is being demanded by end-users

解決方法: 補助テクノロジーの会社に友好的に//→気さくに//コンタクトしましょう。できるだけ気安く協力しましょう。すなわち、新しいテキストビルドに対する彼らのバク報告に対して多くの責任を持ち//→きちんと返事を返し//、変更点や変更時期について情報が緊密に共有できているようにします。彼らの支援に頼らずに出来るだけの仕事//→事//をしましょう。あなたの組織が彼らにはできない事をしてやれるかどうか考えましょう。辛抱強く、期待レベルを高く持ちすぎないようにしましょう。期待レベルは彼らのプライドと収入の両者にかかわる事と、あなたのアプリケーションをサポートした仕事を埋め合わせるために//→あたたの期待によって、彼らのプライドと収入の両方が影響を受けて、アプリケーションをサポートした仕事を埋め合わせるために、彼らは//ソフトウエアーのコピーを多く売る必要がある事を考慮してください。彼らがどんなに小さくとも、あなたのアプリケーションのアクセシビリティがエンドユーザーに要求されている状態でなければ、彼らがあなたを必要であるより//→あなたのアプリケーションのアクセシビリティがエンドユーザーに要求されているのでなければ、彼らがあなたを必要であるより、どんなに小さくとも//あなたが彼らを必要としている事を忘れないでください。

本日を持ちまして、MSAA に関する問題点と解決方法の指摘について完了しました。先にも述べましたが、この章は原著者のアーロンさんの知識と経験から記述されており当文書の中核的部分といえるでしょう。日本にアクセシビリティのソフトウェアの開発に関わっている方がどの位おられるのか、よく知りませんが、あまり多くはおられないにしても、そういう方々にとって役立つ情報であって欲しいと思います。

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

今日は寒の戻りというのでしょうか、とても冷え冷えとする日です。花冷えともいうのでしょうか。こんな日は、暖かいコーヒーでも飲みながら、こたつに入ってテレビでも見るのが最高ですね。思考が停止しそうな日もたまにはありますよ。そんなわけで、今日は少しで止めておきます。・・・・てへへ・・・・(^^;



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

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

Not all MSAA features utilized by 3rd party vendors

Problem: The assistive technology does not use 50% of what's available in MSAA, e.g. MSAA caret, a lot of events, roles, states and methods. It's difficult to know which things to support.

Solution: Use this document to see what is generally considered important by assistive technology manufacturers. Contact the the top vendors early and often as you plan and implement your architecture, to see what's important to them. Implement only what's needed -- supporting everything would take too long for zero results.


すべてがサードパーティーベンダーによって利用されているわけではない MSAA の機能

問題: MSAA で有効なものの//→使える機能の// 50% を、補助テクノロジーは使用していません。例えば、 MSAA キャレットや、イベント、役割、状態とメソッドの多くが使われていません。//挿入：→従って//どれをサポートすべきかを理解するのは簡単ではありません。

解決方法: この文書を使って何が補助テクノロジー製造者によって一般的に重要と見なされているかを理解してください。自分のアーキテクチャーを計画し//→立案し//実装する時は、気安く、たびたび//→早めに足しげく//大手ベンダーと接触して、彼らにとって重要な事柄を理解してください。必要なものだけを実装してください。すべてをサポートすると時間がかかり成果が無いこともあります。

明日はもっとがんばるぞ！