Mozilla アクセシビリティ・アーキテクチャー

各オペレーティングシステムのアクセシビリティ API は、次のような点について固有の前提を備えてます： 最も重要な情報は何か、Mozilla のようなアクセシビリティ・サーバが API のプログラム・インターフェースをどのように使用して、この情報をアクセシビリティ・クライアント（補助テクノロジー）に渡すべきかといった点についてです。各プラットフォームのアクセシビリティ API は、異なる条件を備えていますが、共通の特徴が数多くあります。たとえばすべて、各オブジェクトのアクセシビリティの名前や、テキスト表示を公表し、限定されたリストから列挙整数値を使用して、オブジェクトの役割を公表します。アクセシビリティの役割の定数は、ROLE_BUTTON、ROLE_CHECKBOX および ROLE_LIST であり、各 API によって名前や数値が少し異なる可能性はあります。一般的に、アクセシビリティの API は類似する概念を備えますが、メソッド、定数、インターフェイスなどの名前は異なります。

アクセシビリティ API ツールキット間に共通性が高いことを考えると、クロスプラットフォーム風にコードについて書いてから、一貫した方法でプラットフォームの違いを処理すると自然です。 公表したいオブジェクトの情報を返す標準の XPCOM のインターフェイスによって、共通化されたコードがツールキット特有のコードへ適応可能となります。フォーカス可能なすべてのノード、テーブル、テキストには、アクセシビリティのインターフェイスがあります。これらのオブジェクトは「アクセシビリティのノード」と呼ばれます。これらの各ノードは、最低でも、標準のクロスプラットフォームなアクセシビリティ・インターフェイスである nsIAccessible （テキストの名前、列挙された役割識別子、状態フラグ一式を提供します)と、時には追加のインターフェイスをサポートします。たとえば、テーブルは nsIAccessibleTable を、テキストは nsIAccessibleText を、エディット・ボックスは nsIEditableText をサポートします。ただし、nsIAccessible は現在 Windows で使用されていないために、ATK の特定のデイレクトリーに移動しています。私たちは、複数あるリッチな ATK インターフェイスを Windows 上でサポートする可能性を排除するつもりはありません。

ツールキット特有のクラスはその結果、XPCOM インターフェイスを使用して、公表したいオブジェクトについての情報を収集し、必要な変更を行い、そして、Windows 上で Microsofit COM や、Linux/Unix上で GTK2 の ATK API を使用します。

補助テクノロジーはその時、この情報を様々に使用することが出来ます。ドキュメント全部をすぐに読み込む、最近のイベント関連のドキュメントのみを見る、あるいは画面の位置に基づいてアクセシビリティのオブジェクト・モデルを探索するなどです。

すべの DOM ノードがアクセシビリティ API ツールキットによって公表されるわけではなく、ツールキットの開発者が重要であるとみなすもののみが、公表されます。Mozilla は独自のアクセシビリティ・オブジェクトを維持しています。これは DOM ツリーに似ていますが、完全に同じような構造を保っているわけではありません。

上記：MSAA ツリーを示す図は、DOM ツリーの下位集合です。他のアクセシビリティ API の状況も同様です。

補助テクノロジー・ベンダーが知りたいのに、公表されていない DOM ノードがあるとすればどうなる ？ というのは問題です。CSS 規則、タグの名前と属性などの DOM 情報を知りたいのに、MSAA の IAccessible が提供していなければどうなる ? というのも問題です。

Windows 上では、MSAA の IAccessible を飛び越してすべての DOM ノード用の追加インターフェイスをサポートすることで、私たちはこの問題を解決します。QueryInterface() は、二つのインターフェイス間を切り替えるのに使用することが出来ます。DOM ノード用に MSAA のノードが存在しないならば、  pAccessible -> QueryInterface(IID_IAccessible) が null を返します。さらに、テキストノードよりも小さなテキストの断片（例：単語）の情報とサポートの提供を私たちに依頼して来たベンダーもありました。そして、このために Mozilla が ISimpleDOMText をサポートします。

ATK では、現実の DOM 情報を取得するインターフェイスはありません。Mozilla の ATK サポートを管理している Sun Microsystems は、ATK が十分にリッチで、Sun Microsystems で求められる補助テクノロジーの全てを提供できると考えています。

ディレクトリー構造の一般規則:

• 内部使用のクロスプラットフォーム・インターフェイスとツールキット特有のインターフェイスは共に accessible/public. に存在します。
• 各種オブジェクト（ドキュメント、テキスト、テーブル、編集ボックス、ボタンなど）の実装は accessible/src. に存在します。
• 特定のツールキット用のコードとインターフェイスは正しいディレクトリーに収納されるべきです。ツールキットの特定の実装はクラスネームに「Wrap」を付け加えることになっています。たとえば、各ツールキット用の特定のドキュメントコードは public な nsDocAccessible である nsDocAccessibleWrap に収まっています。

ATK と MSAA とは、共通部分が 75% しかない、異なるアクセシビリティ API ツールキットなので、多数あるツールキット固有のコードをどこかに置かなければなりません。以前に、これは集合単位で存在しました。ひとつは、accessible/src に、もう一つは widget/src に、二つの別のオブジェクトのツリーが確保されました。しかし、アクセシビリティ・キャッシュを実装するとき、このことで多くの障害が発生する可能性があったので、コードは各ツールキットに固有のソースデイレクトリーの中の「Wrap」クラスへと移動されました。

nsTextAccessibleWrap と nsDocAccessibleWrap など、名前に「Wrap」が含まれるクラスは、名前に「Wrap」が含まれない似た名前のクロスプラットフォームのクラスを継承します。これらのクラスは、Init() と Shutdown() などのメソッドをオーバライドでき、所定のツールキットのみが必要とするインターフェイスをサポートする他のメソッドを追加できます。例えば、nsAccessibleWrap は IAccessible のメソッドを実装しますが、それもまた nsAccessible であるので、必要情報を参照するために、「this」 によって nsAccessible のメソッドを呼び込むだけで十分です。

ドキュメントアクセシビリティが要求されると、PresShell に到達するイベントが起動されます。PresShell はその時、accessibility service singleton(nsIAccessibilityService) を使用してドキュメントアクセシビリティを作りウィジェットコードへ返します。なぜドキュメントアクセシビリティがそれを必要としてるコードの中で直接作成されないかという理由は、何の nsIDOMNode が現在のウインドウのドキュメントオブジェクトと連携しているかウィジェットコードが知らないためです。pres shell がウィジェットコード用のドキュメントアクセシビリティを作るために、現在のウィジェット (nsWindow/nsIWidget) 用のドキュメントがなくてはなりません。

この方法のよい点のひとつは、accessibility.dll/libaccessibility.so が 実際にアクセシビリティの働きが使用されるまでは、ロードされる必要がないことであり、ほとんどのユーザーはロードすることはまずありません。

個々のオブジェクトの他のアクセシビリティも同様に、要求に応じて作られます。補助テクノロジーは、最初に深さ(または幅)の検索を使用して、ツリー全体を得る事を選択できますし、フォーカスのようなイベントに基づくだけで、アクセシビリティを得ることを選択できます。また、画面の特定の位置でアクセシビリティを得ることもできます。どのように補助テクノロジーのクライアントがデーターを要求しても、所定のノード用のアクセシビリティは一度しか作成されません。アクセシビリティのキャッシュは、所定の dom ノード用に既に作成されたアクセシビリティを読み出すために使用されます。

このツリーの探索はツールキットを使った特別な呼出しによってなされます。最終的に nsIAccessible メソッドの呼出しとなり、GetAccParent()、GetAccNextSibling()、GetAccPreviousSibling()、GetAccFirstChild()、GetAccLastChild()、GetAccChildCount() および GetChildAt(childNum) などが呼び出されます。探索では、ATK は MSAA よりもっと便利なメソッドを備えており、例えば、nsIAccessibleTable::CellRefAt() を使用することで、テーブルの特定の行や列へのアクセシビリティへ直接到達することが出来ます。

アクセシビリティのノードへアクセス可能な子の数を計算するのに使用されるアルゴリズムは高価です。現在のアクセシビリティのノードにおいて、すべてのアクセス可能な子が、直下の子か孫か何世代後の子から来ているかを推定することは出来ません。従って、あたかもすべてのアクセス可能な子を作っているかのように、ツリーを繰り返し下って、下りながら、全体数に追加しなければなりません。

この作業を安価にすませるために、子のカウントや子へのアクセスが1度要求されると、子のカウントとすべての子のカウントが共に、同時に計算されそしてキャッシュされることで、この高価な処理を二度以上実行することが避けられます。

上述の nsIAccessible GetAccBlah() 探索メソッドはすべて、nsAccessible において実装が初期設定されています。初期設定実装は nsAccessibleTreeWalker と呼ばれるクラスを使用し、実際の仕事をします。 nsAccessibleTreeWalker は DOM とドキュメント内の匿名のコンテンツを歩き、各ノードへのアクセシビリティの取得を nsIAccessibilityService::GetAccessible() に依頼します。もしアクセシビリティがキャッシュにあれば、返されます。XUL エレメントは、アクセシビリティを返すことができる nsIAccessibleProvider インターフェイスのサポートをチェックされます。HTML エレメントはノードの最初のフレームに nsIFrame::GetAccessible() によってアクセシビリティの取得を依頼します。もし、nsnull が返されると tree walker は、下位レベルの最初の並びにある次のノードをチェックします。

呼出しシーケンス:

ATK/MSAA ツールキット探索メソッド 
nsAccessible 探索メソッド 
DOM & 匿名コンテンツを探索する nsAccessibleTreeWalker method 
コンテンツノードを使う nsIAccessibilityService::GetAccessible()
    nsDocAccessible::GetCachedAccessNode() 成功なら返し、さもなくば、 
    nsIAccessibleProvider::GetAccessible() (if XUL) さもなくば 
    nsIFrame::GetAccessible() (if HTML)、何も返さないか、さもなくば
nsIAccessibilityService::Create[InsertTypeNameHere]Accessible() 
operator new によってオブジェクトが最終的にコンストラクトされる。

nsIAccessibleProvider::GetAccessible() か nsIFrame::GetAccessible() のいずれか経由で、accessibility service へと呼び戻したり、アクセシビリティの各型を作る特定のメソッドを使うことによって、新しいアクセシビリティは作られます。たとえば、nsHTMLTableCellFrame::GetAccessible() は最終的に nsIAccessibilityService::CreateHTMLTableCellAccessible() を呼出し、これは |new nsHTMLTableCellAccessible(domNode、weakPresShell) を使用します;

特別な例外: 探索オーバーロード

アクセスできる必要な子がノード用の DOM 従ツリーに存在しない場合があります。このようなケースとして：

• nsHTMLImageAccessible: MSAA では、画像アクセシビリティは、イメージマップを備えていれば、アクセス可能な子たちを持つことがでます。子たちはイメージマップの領域であり、DOM ツリーの異なる部分に存在します。
• nsHTMLComboboxAccessible: html コンボボックスは、DOM ノードを備えていませんし、テキスト領域や、ボタン、リスト用の匿名コンテンツを持ちません。将来は、XBL フォーム制御が使用される可能性がありますが、その場合は、これらの従部品用に dom コンテンツが存在することになり、探索メソッドをオーバーライドする必要もなくなります。こんなわけで、nsXULComboboxAccessible () 用にこれらの探索メソッドをオーバーライドする必要はありません。
• nsOuterDocAccessible: <iframe>、 <browser> および <editor>などのエレメントに使用され、新しいドキュメント全部を発生させますが、実際、エレメント自身の DOM には子のノードを備えていません。
• nsXULTreeAccessible: 各ツリー項目用に DOM ノードを備えていませんが、ツリーの各行、列用にテキストを得るために、ツリー自身によって特別なインターフェイスが提供されます。

これらのアクセシビリティの実装において、nsIAccessible::GetAccChildCount()、::GetAccFirstChild() および ::GetAccLastChild() がオーバライドされます。こうすれば、通常の探索メソッドである nsAccessibleTreeWalker を使わずに、私たちが欲するどのような子アクセシビリティでも作られます。nsHTMLComboboxAccessible と nsXULTreeItemAccessible の場合のように、各アクセシビリティに DOM ノードがない時は、Shutdown() メソッドをオーバライドして、親が終了された時にメモリーから子が取り除かれるようにします。この場合はまた、DOM の無い子用に ::GetAccNextSibling()、 ::GetAccPreviousSibling() をオーバーライドします。そうしないと、子たちはお互いどのように見つけてよいか分かりません。

必ず子を持ちたくないような nsLeafAccessible、nsTextAccessible および他のアクセシビリティの実装において、通常されているように、これらの子を得るメソッドをオーバーライドして何も返さないこともまた有益です。リーフやテキストオブジェクトに何も返さないことも、ツリーの構築と探索を高速化するのに役立ちます。

Gecko イベントからアクセシビリティ・イベントへの翻訳一覧表

DOM ミューテーションイベント - 多重的使用

• 補助テクノロジークライアントへのドキュメント変更の伝達。しかし、Windows には自動 Windows 生成版である EVENT_CREATE と EVENT_DESTROY によるクラッシュ問題があるため、MSAA のクライアントはミューテーションイベントを監視することは出来ません。その代用としてより安全な EVENT_REORDER を起動します・・。
• アクセシビリティ・キャッシュのどの部分が無効化を必要としているかを調べます。しかし、ドキュメントが引き続きロードされているのでミューテーションイベントが起動されるから、この仕事をするのではない事に注意が必要です。

MSAA における一意の 32 ビット識別子

なぜアクセシビリティ・キャッシュが必要か

アクセシビリティ・キャッシュにはたくさんの目的があります:

• 安定性: Gecko DOM とレイアウトチームは必要な場所でのメモリーの膨張を避けたいので、DOM 上やアクセシビリティオブジェクトへポイントバックするレイアウトノードで、4バイトを使用する余裕がありません。従って、所有権は逆転し--アクセシビリティノードが自分の dom オブジェクトを所有します。しかし、このことで、Mozilla は終了したいのに、補助テクノロジーのクライアントは引き続きアクセシビリティへの接続を保持しているため、不安定な状態が発生します。このクラッシュは、Gecko モジュールがすでにいくつかアンロードされ、メモリー内にもはや必要なデストラクターが存在しない時、補助テクノロジーがアクセシビリティを解放すると発生します。
• 性能: ハッシュテーブルで各 DOM ノード用にアクセシビリティノードをキャッシュすることで、非常に高速にアクセシビリティが戻されるので、ある DOM ノード用に新しいアクセシビリティが要求される度に再計算し、新アクセシビリティが作成されるのを回避することが出来ます。また、一度 GetAccChildCount() のために計算し、特定の子が要求される時再計算してしまうような、アクセシビリティの子の二重計算を避けることが出来ます。
• イベント: 私たちはアクセシビリティのクライアントがイベントのデータをチェックしない内に、イベント用のアクセシビリティが解放される事がないようにしなければなりません。また、MSAA のクライアントは、私たちがイベントに与える一意の子 ID を使ってイベントアクセシビリティにアクセスする必要があります。私たちが子 ID を取り戻す時、アクセシビリティを検索するために必要なハッシュキーを再び作ることが出来ます。最後にMSAA クライアントは、イベント用とツリー探索用に各々同じアクセシビリティを取得するので、自分自身の内部モデルと比較することが出来ます。たとえば、この事で MSAA クライアントは、自分自身のキャッシュの一部分や、DOM ミューテーションイベントに基づいたデーターモデルを無効にすることが可能です。

アクセシビリティ・キャッシュの 3 つのレベル

アクセシビリティ・キャッシュには 3 つのレベルがあります:

• ドキュメントアクセシビリティのグローバルキャッシュ (gGlobalDocAccessibleCache)、はどんなドキュメントにでもアクセスするのに使われます。
• アクセシビリティの Per-document キャッシュは、各 nsDocAccessible (mAccessNodeCache) のキャッシュで、それまで各ドキュメント用に作成された全てのアクセシビリティノードを保持しています。
• nsAccessible 内のメンバー変数 は、子の数 (mAccChildCount)、親 (mParent)、最初の子 (mFirstChild) および次の兄弟 (mNextSibling) を記録します。もし mNextSibling がマジックバリューの DEAD_END_ACCESSIBLE (void*)1 と等しければ、これ以上兄弟がいないことが通知されます。もし、mNextSiblings == nsnull であれば、さらに兄弟がいる可能性を示します。

このアーキテクチャーのお陰で、ドキュメントアクセシビリティのキャッシュを破棄するだけで、ドキュメントが消される時、ドキュメント全部のキャッシュノード量を迅速に除去することが出来ます。

しかし、DOM ノードのキャッシュされたアクセシビリティを取得するには二段階が必要です。まず最初に、ノードのドキュメント用のグローバルキャッシュからドキュメントアクセシビリティを取得する必要があり、次に、ドキュメントアクセシビリティの特定のキャッシュを使って dom ノードへのエントリーをチェックします。この事は、毎回新しいアクセシビリティを作成するよりはるかに高速な工程なので大きな問題とはなりません。この二段階は nsAccessibilityService::GetCachedAccessible(domNode) において実装されます。

子の数、親、最初の子、および次の兄弟の記録を保持しているメンバー変数のお陰で、すでに訪問されたアクセシビリティのノードへはたちどころに探索ができます。

nsAccessNode の役割

もしあなたが、私たちのアクセシビリティ・モジュールの ATK 部門で作業することが多いならば、 nsAccessNode の目的が分からないかもしれません。それを使用するインターフェイスが存在しないからです。事実上、nsAccessNode は ISimpleDOMNode を MSAA へ拡張するために存在しており、そしてそれは nsAccessNodeWrap において実装されます。ISimpleDOMNode は補助テクノロジーによって使用され、「アクセスが」可能であるか不可能である個々の DOM ノードについての情報へアクセスします。

nsAccessNode は、「アクセスでき」ない DOM ノードも含め、すべての　DOM モードを指し示すことが可能なので、nsAccessible になることも、またならないこともあります。つまり、私たちがキャッシュしなければならない最低の共通分母が nsAccessNode です。

nsAccessNode::Init()

Init() メソッドもまた仮想的で、アクセシビリティの多くがそのメソッドをオーバーライドして自分自身の特別な初期化を行います。オーバーライドするならば、完了時に、親クラスの Init() メソッドも呼び込む必要があります。

nsAccessNode::Shutdown()

Shutdown() は、所定の nsAccessNode/nsAccessible 用の dom ノードがもはや存在しない時、使用されます。その呼び出され方は様々です:

• nsWindow 用デストラクタによって: ドキュメントが破棄される時、そのウインドウもまた消えます。新たにロードしているドキュメントがあれば、既に作成されて提供される自分自身の別ウインドウを備えています。事実、約一秒間ほど二つの nsDocAccessible が同じ画面上のスペースに存在します。ひとつは破棄される古いドキュメント用であり、もうひとつは、まだ表示されていないロード中のドキュメント用です。側註: 新しいドキュメントが表示されるまで、新しいドキュメントが準備完了である事を示すイベントは起動されません。
• ノードやサブツリーのノードが変化したり排除されたりしていることを示している nsDocAccessible におけるミューテーションイベントの呼び戻しから 。私たちはサブツリー内のすべての dom ノードを繰り返し移動して、各ノードのキャッシュへ nsIAccessNode による追加がないかどうかチェックをし、ある場合はキャッシュから締め出します。この方法が、メンバー変数の mFirstChild と mNextSibling を使って、すべてのアクセシビリティをただ探索するのより優れているのは、nsAccessible ではない nsAccessNode を無視するからです。
• プログラムの終了によって、nsAccessibilityService は NS_XPCOM_SHUTDOWN_OBSERVER_ID を監視するとき、gGlobalDocAccessibleCache 内のドキュメントアクセシビリティを繰り返し移動して、すべてのドキュメントアクセシビリティを破壊します。　

アクセシビリティ・キャッシュの課題

アクセシビリティ・キャッシュを扱う時用心しなければならない問題があります:

• 有効で残っている: 所定のドキュメントの変更や、ドキュメントの排除によって、キャッシュの一部は更新されるか排除されなければなりません。私たちは DOM ミューテーションイベントを使ってドキュメントの変更を監視し、キャッシュの適当な部分を無効化します。注意すべきは、DOM ミューテーションイベントが完了しなければ、キャッシュは DOM を正しく反映しないことになっている点です。無くなるノードを排除しなければ、必要以上にメモリーを消費してしまいます。
• DOM ノードのないアクセシビリティ: DOM ノードを持たないアクセシビリティの子であるため、アクセシビリティの親が作り出すアクセシビリティの子がいます。これらのアクセシビリティは 、キャッシュへの追加が DOM ノードに基づいていないので、DOM の探索によって排除されません。従って、Shutdown() メソッドが呼び出された時、これらのアクセシビリティを作り出した親が排除の責任を負います。この件は、現在 nsHTMLComboboxAccessible と nsXULTreeAccessible へと実装されています。

概ね、アクセシビリティの API モジュールの仕事は、いまや結論に向かうべき時です。不幸にして、私たちは今もなお、市場の主要なスクリーンリーダーや、スクリーン拡大鏡や、音声検出器について、全面的な協力関係にありません。この状況を早く変えて、主要ベンダー（および Linux/UNIX のGnopernicus) と協力してこの目標を達成したいと思っています。

いずれにしても、当面 Windows 上の唯一の計画は補助テクノロジーベンダーからのフィードバック情報に基づいた細かいバグの修正のためのものです。Linux と UNIX では、新しいアーキテクチャー（「Wrap」クラスをもっと多く使用するなど）の注入に対してもっと多くの仕事が必要となるでしょう。

Macintosh アクセシビリティ API、Windows の将来のバージョン用に Microsoft によって開発されつつある新 API、または、クロスプラットフォームや小型装置での利用のために開発されたその他の新しい API をサポートすると決めると、さらなる作業が生まれます。私たちの全体的なアクセシビリティ・アーキテクチャーが、大きな困難を伴わずに、これらの API をサポートできることを願ってやみません。