Gecko Info for Windows Accessibility Vendors 校正その6

IT とは関係のない話ですが、昨年は花壇が野菜畑になってしまいました。真っ赤なミニトマトが次から次へと実を結び、ほぼ２ヶ月間にわたり、サラダの食材を継続して提供してくれました。数えませんでしたが、合計で7～8百個の収穫があったと思います。もちろん、我が家だけで、食べきれずに近所におすそ分けして喜ばれたり、お向かいさんに自由に摘み取っていただいたりしました。なぜそんな事になったかと言いますと、マリーゴールドの苗が育たなかったためです。実は、一昨年マリーゴールドが花壇一面に咲き誇り、黄色いボリュームのある光景が長期間楽しめたので、昨年も種から苗を育てようとしたのですが、なぜかまともに育ちませんでした。その代わり、初めて試みたミニトマトの苗が育ち、それを試しに花壇に植えたところ、発育旺盛に実を結び、思いがけない食料基地が構築されてしまいました。トマトの味も、酸味のないほろ甘いもので、これは、日当たりの好い花壇のお陰で、野菜畑としても申し分ない立地条件であることが、分かりました。
さて、昨年の予期せぬ成功に味をしめた愚妻は、今年もミニトマトを植えようと言います。昨日ホームセンターへ行って、ミニトマトとマリーゴールドの種を購入し、早速ビニールポットに土を充填し、種をひとつひとつ丁寧に落とし込んで、最後に水差しで程よい水分を供給しました。しかし、同じ土地で2年続けて、豊作となるはずはないのは、マメ科のスイートピーが連作できないようなものだと思い、それならば、今年は花壇はマリーゴールドにして、トマトの苗は、別の場所にしようかなどと、まじめに考え出した自分に気付き、思わず笑い出してしまった、春うららな一日でありました。



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

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

MSAA Support: IAccessible Methods

To use MSAA with Gecko, you'll need the tools and docs that come with the MSAA SDK . The method AccessibleObjectFromWindow() will get you the root IAccessible corresponding to the top level window. Hold on to this root IAccessible, and use it to walk through the entire tree of IAccessible's.

MSAA サポート: IAccessible メソッド//→のメソッド*0//

Gecko で MSAA を使用するために、 MSAA SDK を備えているツールとドキュメントが必要です//→必要になります*1//。AccessibleObjectFromWindow() メソッドはトップレベルのウィンドウに対応するルート IAccessible を取得させます//→AccessibleObjectFromWindow() メソッドで、トップレベルのウィンドウに対応するルート IAccessible が取得できます*2//。ルート//→このルート// IAccessible を保持して IAccessible の全ツリーを移動するために//→するのに//使用して下さい。

*0→ IAccessible インターフェイスに所属するメソッドの意味。プログラムに習って、注記の番号も 0 から始める・・・・・・・・本当かな？
*1→原文の未来形の語感をより明確に伝える
*2→人を主体とする表現の方が自然か・・・・・

We currently support MSAA for HTML content, ala the IAccessible interface and MSAA events.

* IAccessible methods that we support:
get_accParent get_accChildCount get_accChild get_accName
get_accValue get_accDescription get_accRole get_accState
get_accFocus get_accDefaultAction accLocation accSelect
accHitTest accDoDefaultAction accNavigate get_accKeyboardShortcut

//挿入→IAccessible インターフェイスと MSAA イベントである限りは、HTML コンテンツのために MSAA を現在サポートします*3//

*サポートしている IAccessible メソッド:
get_accParent get_accChildCount get_accChild get_accName
get_accValue get_accDescription get_accRole get_accState
get_accFocus get_accDefaultAction accLocation accSelect
accHitTest accDoDefaultAction accNavigate get_accKeyboardShortcut

*3→ala = "as long as" の短縮形として解釈、こんな短縮あるのですね。asap(=as soon as possible)はよく聞きますけれど・・・・・・

MSAA Support: IAccessible Events and Unique ID's
What MSAA events do we support?

* EVENT_OBJECT_FOCUS is fired for focus changes on any kind of focusable object
* EVENT_OBJECT_STATECHANGE is used in check boxes, radio buttons, text fields, combo boxes and list boxes. It's also used in the root pane object to show when the STATE_BUSY flag changes from loading new content.
* EVENT_SYSTEM_SCROLLINGEND is used to indicate when a document has scrolled, even if only 1 line. Gecko does it's best to fire this event when the scrolling is finished, rather than fire excessive events.
* EVENT_SYSTEM_MENUPOPUPSTART and EVENT_SYSTEM_MENUPOPUPEND are fired when XUL menus are opened or closed.
* EVENT_SYSTEM_MENUSTART and EVENT_SYSTEM_MENUEND are fired when the XUL menubar is activated or deactivated.
* EVENT_OBJECT_SHOW, EVENT_OBJECT_HIDE and EVENT_OBJECT_LOCATIONCHANGE are fired for the caret object.


MSAA サポート: IAccessible イベントおよび一意の ID
私たちがサポートする MSAA イベントは何？

* EVENT_OBJECT_FOCUS はすべてのフォーカス可能オブジェクト上でフォーカスの変更のために起動されます。
* EVENT_OBJECT_STATECHANGE はチェックボックス、ラジオボタン、テキストフィールド、コンボボックス、リストボックスにおいて使用されます。また、STATE_BUSY フラグが新しいコンテンツからいつ変更になるかを示すために//→新しいコンテンツを読み込み中の状態から何時変更になるかを示すのに//、ルートペインオブジェクトにおいても使用されます。
* EVENT_SYSTEM_SCROLLINGEND は一行だけであっても、ドキュメントがいつスクロールしたかを示すために、使われます//→示すのに使われます//。スクロールが完了する時、過剰にイベントを起動せずに、このイベントを起動するのが最適である事を Gecko が示します。
* EVENT_SYSTEM_MENUPOPUPSTART と EVENT_SYSTEM_MENUPOPUPEND は XUL メニューバーが開かれたり閉じられた時起動されます。
* EVENT_SYSTEM_MENUSTART と EVENT_SYSTEM_MENUEND は XUL メニューバーが有効になったり無効になった時起動されます。
* EVENT_OBJECT_SHOW, EVENT_OBJECT_HIDE と EVENT_OBJECT_LOCATIONCHANGE はキャレットオブジェクトのために起動されます。

-To Be Continued-

Gecko Info for Windows Accessibility Vendors 校正その4

本日は長く難しい節を一気に料理します。（・・・・・・料理人と言えば、味平だっけ????）



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

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

Windows Applications Based on the Gecko Layout Engine

Gecko is a rendering engine that Mozilla, Netscape and other new browsers use. Gecko can render a variety of content, not just HTML and supports key web standards such as Cascading Style Sheets, Javascript and the W3C DOM. Gecko also handles the users keystrokes and mouse clicks. Gecko is the core architecture that we are adding accessibility to, in order to support accessibility in all applications that are based on it.

Gecko レイアウトエンジンに基づく Windows アプリケーション

Gecko は Mozilla、Netscape、その他のブラウザ//→新規ブラウザ//が使う表示エンジンです。Gecko は HTML だけでなく様々なコンテンツを表示可能で、Cascading Style Sheets、Javascript、W3C DOM などの主要ウェブの標準をサポートします。Gecko はまたユーザーのキーストローク//→キー入力*1//やマウスクリックをも操作します。Gecko は中核の構造体であり、Gecko に基づく全てのアプリケーションにおいてアクセシビリティをサポートするために、私たちはそこにアクセシビリティを追加しました//→Gecko に基づく全てのアプリケーションにおいてアクセシビリティをサポートするために、私たちは中核の構造体である Gecko にアクセシビリティを追加しているところです//。

→keystroke*1:キー入力； カタカナ英語(キーストローク)をどこまで和語に置き換えるかいつも迷うところです。「キー打ち」という訳語もあります。

embedded Clients (support MSAA)

embedded clients use Gecko only in the content window, at the moment for HTML and generic XML only. Since they use standard Windows controls (or support MSAA for their own user interface), they can be made accessible.

* MFCembed testing client: This is a very simple package, great for testing basic HTML accessibility with your products and the Gecko rendering engine. Contact Aaron Leventhal - aaronleventhal@ m o o n s e t . net for a copy.
* Many other clients are being developed, and are on the horizon.


(MSAA をサポートする)埋め込まれたクライアント

現在は HTML と標準的な XML だけ用に埋め込まれたクライアントは、ウィンドウコンテンツにおいてのみ Gecko を使います//→埋め込まれたクライアントは、現在 HTML と包括的な XML だけに、ウィンドウコンテンツだけで Gecko を使います//。それらは標準のウィンドウコントロール（あるいはそれら自身のユーザーインターフェイス用に MSAA をサポートする）を使用しますので、アクセスされる事が可能になります//→それらクライアントは標準のウィンドウコントロールを使用する（あるいは自分自身のユーザーインターフェイス用に MSAA をサポートする）ので、アクセスできるように(*2)なります//。

* MFCembed テストクライアント: これは非常に簡単なパッケージであり、あなたの製品と Gecko 表示エンジンによって基本的 HTML アクセシビリティを試験するのに最高です。コピーのご請求は Aaron Leventhal - aaronleventhal@ m o o n s e t . net へご連絡下さい。
* その他多数のクライアントが開発されつつあり、もうすぐ公表されるでしょう。


→アクセスできるように(*2)：態を変換すると下記のようになります
　they can be made accessible→
　the standard Windows controls can make them(=clients) accessible

XUL-Based Clients (now also support MSAA!)

XUL-based clients make full use of the Gecko architecture, not only for HTML content, as well as for menus, dialogs and the entire user interface via an XML language called XUL (eXtensible User-interface Language). None of the user interface contains standard Windows controls -- not even the menus! This is done to ensure a common look and feel across all supported platforms. MSAA support for XUL is available in Mozilla 1.0+.

* Mozilla the browser
* Netscape 6.x


XUL ベースのクライアント(今また MSAA をサポートする!)//→XUL ベースのクライアントは-今 MSAA をもサポートする!//

HTML コンテンツだけでなく、メニュー、ダイアログボックス、XUL(eXtensible User-interface Language) と呼ばれる XML 言語を使った全ユーザーインターフェイス用に//→に//、XUL ベースの//→をベースとする//クライアントは Gecko 構造体//→Gecko のアーキテクチャー//を全面的に使用しています//→使用します//。ユーザーインターフェイスには、メニューさえ//→メニューも//含めて、標準ウィンドウコントロールを備えたものはありません。すべてのサポートされるプラットフォームに関わる共通のルックアンドフィールを有効にするためにこうしています//→ためです//。XUL 用の//→への// MSAA のサポートは Mozilla 1.0+ において//→で//有効です。

* Mozilla 代表ブラウザ
* Netscape 6.x



フーッツ疲れた、？？？？？立ち眩みが・・・・・・・

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 機能を呼び出すことです。これは通常、ウィンドウがフォーカスされた直後に発生します。

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