00:06
はい、5月21日日曜日ですね。
時刻は朝9時7分になりました。
寝坊というか、夜更かしが過ぎるうちで、
最近また夜がリズムになってしまったので、直さなきゃいけないなと思いながらです。
はい、おはようございます。
イメミのkkeethからです。
では、本日も朝から始めていきたいなと思います。
本日はですけど、タイトルになります。
How Chrome Accessibility Works Part 2ですね。
という記事ですね。読んでいきたいと思います。
前回ですね、ファイアフォックスのバージョン113がリリースされていて、
その時の記事の一つに、Cache the Worldという公式ブログがあって、
ファイアフォックスが内部でやっているキャッシュ戦略ですね。
どんな感じでブラウザの中でキャッシュを使っているかというところですね。
思想とか戦略、もしくは設計周りの話という記事があって、
その中にChromeとの比較も書いてあって、すごく興味深くて面白かったんですけど、
アクセシビリティは勉強したいと思いますけど、
そういうブラウザの中の構造とか知りたかったので、
それを読んでいたら、その中にChromeのキャッシュ戦略とか、
アクセシビリティの話の別の記事のリンクがあって、
ちょっとそれも興味があったので、やっぱり読みたくなったので、
今日はそれを読んでいこうと思っています。
それがその記事ですね。
一応、Part 1 Firstって書いてあるんですけど、
Part 1も読んでいくと長いので、どうしようか悩ましかったんですけど、
でもやっぱりちゃんとPart 1も読みますかね。
ではPart 1からですね、やっていきたいと思います。
えーと、参加者ですね。
エルナさん、おはようございます。ご参加いただきありがとうございます。
今日もタラタラーと読んでいこうと思っています。
はい。
まったら、How Chrome Accessibility Worksのプログラムですけど、
その前にPlease Read the Accessibility Overview Firstって書いてあるので、
Overview先に読めって書いてあります。
シリーズモードとして、Overview先に読んで、
First読んで、Second読むと言っているのか。
あーどうしようかな。
まあいいや。長いんですけど、シリーズ全部読んでいこうかな。
頑張っていきたいと思います。
じゃあ早速入っていきたいと思います。
Part 1ではなくて、まずOverviewからですね。
アクセシビリティとは障害のあるユーザーを含む、
すべてのユーザーがソフトウェアに平等にアクセスできるようにすることを意味します。
適切なフォントサイズと色のコントラストを使用する。
重要な情報を伝えるためにフォントサイズと色のコントラストを使用すると。
はいはい。
あ、もしくはその色を使用しないとか。
通常はポインティングデバイスで達成できることを
キーボードで代替できるようにとかにする。
っていうような基本的な設計原則がその一つに含まれております。
しかし、Chromiumのディレクトリ名にアクセシビリティという言葉がある場合、
そのコードの目的は支援技術によって利用される外部のアクセシビリティAPIを介して、
ChromiumのUIにフルアクセスを提供するってことになります。
ここで言う支援技術とは、例えば、特定のニーズに対応するために
これらのAPIを利用して、ユーザーのための大体インターフェースを作成する
ソフトウェアまたはハードウェアを指します。
支援技術には以下のようなものがありますと。
大体5つぐらい引用されてますね。
1つ目には、合成音声や点字を使って画面を表示する。
03:03
目の不自由なユーザー向けのスクリーンリーダーだったり、
コンピューターで話すことができる音声制御アプリケーションだったり、
スイッチアクセスですね。
少数の物理的なスイッチでコンピューターを操作できるようにするとか、
画面の一部を拡大し、カーソルやキャレットを強調表示して見やすくする拡大鏡など。
印刷物を読むのが苦手なユーザーを支援する選択したテキストを
ハイライトしたり話したりする学習、
もしくは識字支援サービスとかソフトウェアですね。
などなどがあります。
さらにアクセシビリティAPIというのは、
アプリケーションを探索し制御するための便利で普遍的な方法を提供するため、
自動テストスクリプトやパスワードマネージャーなどのUIか自動ソフトウェアですね。
にもよく使用されます。
ウェブブラウザーは自身のUIへのアクセスを提供するだけでなく、
ウェブの全てのコンテンツへのアクセスを提供する必要があるため、
このエコシステムにおいて重要な役割を持っています。
各オペレーティングシステムには独自のネイティブアクセシビリティAPIがあります。
コアAPIというのは十分に文書化されている傾向がありますけど、
特にウェブブラウザーでは標準APIではウェブの複雑さに対応できないため、
スクリーンリーダーが完全に機能するためには文書化されていない
ベンダー固有のAPIに依存することが残念な力があります。
これはしゃあないですね。
Chromiumは全てのプラットフォームの支援技術の
完全なエコシステムで使用できるようにするために、
これらのオペレーティングシステム及びベンダー固有の
アクセシビリティAPIを全てサポートする必要があります。
Chromiumが古いブラウザーの癖やバグを真似することがあるように、
Chromiumも他のブラウザーのアクセシビリティAPIの実装の癖や
バグを真似する必要があることが多いのです。
冒頭の話はそのところで、早速コンセプトから入っていきたいと思います。
OSやベンダーのアクセシビリティAPIはそれぞれ異なりますが、
全てに共通するコンセプトがあります。大きく3つです。
1つ目はツリーです。
インターフェース全体をオブジェクトのツリーとしてモデル化したもので、
アクセシビリティAPIを介して支援技術に公開されます。
2つ目はイベントです。
ツリーの一部が何らかの形で変化したことを支援技術に知らせるようなものです。
3つ目はアクションです。
支援技術から提供され、インターフェースを変更するように要求されるものです。
次のようなhtmlファイルを考えてみましょう。
htmlのソースコードが貼られているのですが、
ざっくり読んでみます。
htmlタグがあって、headタグが次に置いています。
メタもなしのシンプルなhtmlです。
タイトルだけセットされたheadタグがあります。
How old are you?というタイトルです。
次にボディタグがあって、
最初にあるラベルです。
ラベルタグのageというのがあります。
ラベルタグの属性として4イコールageという文字列が指定されています。
インプットIDイコールageです。
ここにリンクするようなラベルです。
タイプはナンバーです。
ネームのageでvalue42を指定しています。
その下にさらにdivタグでボタンが2つ置いています。
06:01
backとnextというボタンが置いています。
別にリンクとか特にないですけどね。
divタグを閉じてボディタグとしてhtmlタグを閉じると。
とてもシンプルなhtmlですね。
ヘッドとボディがあって、タイトルとラベルとインプットのナンバーがあって、
あとはボタンが2つ並べられています。
アクセシビリティツリーとアクセシビリティアトリビュートというところの話に入ります。
Chromiumは内部的に以下のようなデータ構造で
そのウェブページのアクセシビリティツリーというのを表現しています。
ここでまたソースコード的なものですけども、
先ほどのhtmlタグがあるんですけど、
それをモデル化したツリーで出されています。
最初にIDイコール1ですね。
ネストするレベルごとにIDがどんどん振られていくんですけど、
同階層の中でもIDがどんどん増えていくという感じですね。
まずトップレベルにIDイコール1で、
ロールイコールウェブエリア、
で、ネームイコールHowOldAreYouという文字列が指定されています。
何タグとかは全然無視。
とにかくトップレベルから1、2、3という風にIDが振られていく。
トップレベルにロールイコールウェブエリアというのが指定されているそうです。
ネームのところはHowOldAreYouなんで、
ここはヘッドタグのところが指定されている感じですかね。
続いてIDイコール2です。
これ1階層のネストとしてIDイコール2で、
ロールイコールラベル、ネームイコールエージというのが指定されています。
これがさっきのラベルというわけですね。
同階層にIDイコール3で、ロールイコールテキストフィールド。
ラベルドゥバイIDズで2というのが文字列でなくて、
カギカッコで指定されています。
配列的な感じで指定されています。
この2は多分IDイコール2のことですね。
で、バリューイコール42と。
これがさっき見たインプットタイプナンバーの。
続いて同階層にIDイコール4で、ロールイコールグループとなっています。
これは単純にDivタグですよ、単純な。
それでまたさらにネストしてIDイコール5で、
ロールイコールボタン、ネームイコールバックとIDイコール6ですね。
同階層にロールイコールボタンで、ネームイコールNextという風に指定されています。
ちょっと音読でイメージしづらいですけど、
この記事見てもらうと、なるほどってわかると思うので、
後ほどツイートしますので見てみてください。
そんな感じでツリーっていうのをモデル化してるってことですね。
わかりました。
仮想どもにイメージ的には近い感触が僕の中でありますね。
では戻りまして、
ツリー構造はHTMLの要素の構造によく似ていますが、
若干簡略化されていることに注意してください。
アクセシビリティツリーの各ノードにはIDという役割があります。
多くは名前を持っています。
リストフィールドには値があり、
名前の代わりにLabeledByIdがあります。
これはそのアクセス可能な名前がツリーの別のノード、
IDイコール2のラベルノードに由来することを示しています。
特定のプラットフォームでは、
アクセシビリティツリーの各ノードは
特定のプロトコルに準拠したオブジェクトによって実装されています。
Windowsでは、ルートノードがIAccessibleプロトコルを実装しており、
IAccessible://getのアンダーバー、
ACCロールというのを呼び出すと、
ロールアンダーバー、システムアンダーバードキュメントというものが
IAccessible://gethackのネームと呼ぶと、
09:03
何歳ですかというふうに返されます。
その後のメソッドではツリーを歩くことができます。
そんな感じで、Windowsでは内部的に独自に持っているメソッドとかをコールして、
そのツリーを歩くことができる。
LinuxのアクセシビリティAPIであるATKというものは、
IAccessible2、通称IA2に似ています。
通称IA2と呼ぶのです。
僕は初めて知りました。
歴史的な宙ですけれど、
IA2というものは、MSAA//IAccessibleを拡張し、
より豊かなドキュメントサポートを追加するために、
ATKと調和する方法で、
同じ製品内で両方の実装を簡素化するために開発されました。
両APIはLinux Foundationによってメンテナンスされています。
MacOSでは、RootノードがNSAccessibilityプロトコルと実装しており、
NXAccessibilityアクセシビリティロールというのを呼ぶと、
アットマーク文字列でAXWebArea、
あとはNXAccessibilityのアクセシビリティラベルというのを呼ぶと、
CowOrderUというのが開発されます。
NSって懐かしいですね。
iOSの御用達というか、
アプリを作っている方はNSクラスとか、
本当によくご存知だと思いますけど。
これがちゃんとMacOSですね。
やっぱり中でもずっと使われているということですね。
続いてAndroidのアクセシビリティAPIですけれど、
ここではもちろんJavaをベースにしています。
主なデータ構造はAccessibilityNodeInfoというものです。
これはロールを持ちませんが、
RootノードでAccessibilityNodeInfo.GetClassNameというのを呼ぶと、
Android.WebKit.WebViewというのを返し、
AccessibilityNodeInfo.GetContentDescriptionというメソッドを呼ぶと、
CowOrderUというのを返します。
なるほど。
Androidの方はもっとわかりやすく、
クラスとインスタンスという形にさされたもので、
インスタンスメソッドを呼んでいく感じですね。
GetClassNameというのを呼んだりとか、
GetContentDescriptionというのを呼ぶと、
値が返ってくると。
僕ら的にはこっちのほうがイメージしやすくて、
わかりやすいなと思いますね。
それぞれプラットフォームごとによってAPIが分かれているよ
というような説明になっていますね、これは。
Chrome OSでは、
Chrome内部のアクセシビリティAPIと密接に対応する
独自のアクセシビリティAPIというのを使用しています。
そのためインターフェースの詳細は異なりますが、
基本的なコンセプトというのは、
それぞれのプラットフォームと似ています。
I-AccessibleとNS-Accessibilityは
どちらもロールの概念を持ちますが、
I-Accessibleはウェブページに対して
ドキュメントというロールを使用し、
NS-Accessibilityはウェブエリアというような
ロールを使用します。
I-AccessibleとNS-Accessibilityの両方が
ノードの主要なアクセス可能なテキストという
概念を持っていますが、
I-Accessibleはそれを名前と呼び、
NS-Accessibilityはそれをラベルと呼びます。
Androidはそれをコンテンツ記述と呼びます。
さっきのコンテンツディスクリプションと呼んだりします。
それぞれのプラットフォームで呼び方が
全然違いますよという話ですね。
なかなかいろんな歴史とAPIの定義とか
名前がありますけど、
12:01
これが全部統一するなんてことは
まさありえませんからね。
してくれたらそれはそれで僕らからすると
やりやすいというか分かりやすくていいんですけど、
名前が分かれていないと、
逆に今どのプラットフォームを実装しているのか
というのが分からなくなってしまうので、
一つの利点というふうに捉えてもいいかもしれないですね。
戻りまして、
ちょっと歴史的な注釈も一個張られています。
太字になっているのでちょっと大事かもしれないですね。
ChromiumはもともとWebKitをベースにしており、
アクセシビリティコードのほとんどは
Appleによって書かれていたため、
Chromeのロールや属性の内部名称は
macOSアクセシビリティAPIに最も近い傾向にあります。
ARIAのようなWebアクセシビリティの標準では、
これらのロールや属性はどのように呼ばれているのか
時間をかけてゆっくりと内部名称を移行しています。
ガツンとやるのではなく、ちょっとずつ移行しています。
では続いて、
アクセシビリティイベントの話です。
Chromiumの内部用語では、
アクセシビリティイベントは
常にアプリから支援技術への通信を表し、
アクセシビリティツリーが何らかの方法で変更されたことを示します。
例として、ユーザーがタブキーを押して、
長期の例のテキストフィールドがフォーカスされた場合、
Chromiumは支援技術が聞くことができる
フォーカス、アクセシビリティイベントを発生します。
スクリーンリーダーはテキストフィールドの名前と
現在の値をアナウンスするかもしれません。
拡大鏡はテキストフィールドの境界線まで
画面を拡大することができます。
ユーザーがテキストフィールドにテキストを入力すると、
Chromiumはバリューチェンジルアクセシビリティイベントを発生させます。
アクセシビリティツリーのノードと同様に、
各プラットフォームはアクセシビリティイベントのAPIが若干異なります。
Windowsではフォーカスが変更されると、
イベントアンダーバー、オブジェクトアンダーバー、
フォーカスというのが発生し、
Macでは、ATTの字列、AXフォーカスという
エレメントチェンジというのが発生します。
これらはよく似ています。
名称とかあればさておき、
構成といいますか、
仕組みというものは大体似ているということですね。
Library、Library Region、
ウェブページの特定の重要な部分が変更されたことを通知する
Library、Library Regionというのがあるらしいですね。
このLibrary Regionをサポートするために、
Macでは単に、
ATT AX LIBRARY REGION CHANGEDというのを発生させますけど、
Windowsでは変更領域内の影響を受ける各ノードに個別に
IA2アンダーバー、イベントアンダーバー、テキストアンダーバー、
INSERTEDと
IA2アンダーバー、イベントアンダーバー、テキストアンダーバー、
REMOVEDというイベントを発生させて、
影響を受けるノードがライブ領域の一部だったことを示す
コンテナーライブ、コロン、ポライトなどの追加属性で
イベントを起動することが必要になっている。
結構この辺は異なりますよと。
完全にコンセプトとか実装が似てるというわけではないですね。
この議論は、技術的な詳細をすべて説明するものではなく、
コンセプトは似ているが、各プラットフォームのソフトウェアに
変更を通知する詳細がかなり異なる可能性があるということを
15:01
説明するためのものですよと。
これちょっと読んだ感じ、前回読んだCache the Worldですね。
Firefox113の公式ブログなんですけど、
ブラウザ固有とかOS固有のコードが結構残っていて、
特にWindows固有のソースコードが結構残ったって話をしていて、
それを今回113のリリースで約2万行ぐらいですかね、
ソースコードを削減できたって言ってたので、
かなりベンダーロックのようなソースコードがあったのかな
というのがありますね。
これを今若干見た感じ、やっぱWindowsだけちょっと特殊な
感じのAPIとか構成になっているなという気がしていますね。
まだこの一部しか読んでいないのであれですけど。
では続けましょう。
続いてAccessibility Actionsというところです。
プラットフォームのネイティブアクセシビリティAPIを実装する
各ネイティブオブジェクトというのは多数のアクションをサポートします。
アクションとはUIを制御または変更するための支援技術からの要求です。
これはChromiumから支援技術へのメッセージであるイベントとは逆のものです。
例えばAndroidのボイスアクセスのような音声制御アプリケーションを
実行している場合、ユーザーはページ上のボタンの名前を
次へのように話すことができます。
このテキストを認識し、それがページ上のUI要素の一つと一致する
音声コントロールアプリというのは、Chromeのアクセシビリティツリーにある
ボタンID="6",というのをクリックするアクションを実行します。
このアクションをあらゆるタイプのコントロールのデフォルトアクションを
表すために、内部ではクリックでなくデフォルトを実行するという風に
呼んだりしています。
フォーカスの設定とか、コントロールの値の変更とか、ページのスクロールなども
一応他のアクションの例としてありますよと。
デフォルトのアクションを実行するという風に定義をしているんですね、ボタンとか。
クリックじゃない。
続いて、パラメータ化された属性の話です。
パラメータライズドアトリビュートですね。
アクセシビリティ属性とイベント、アクションに加えて、
ネイティブのアクセシビリティAPIには、いわゆるパラメータ化された属性というのが
ある場合があります。
例えば、テキスト範囲のバウンディングボックスを取得する関数であったりとか、
特定の文字位置のテキスト属性、フォントファミリーとかフォントサイズ、
ウェイトなどを取得する関数があります。
パラメータ化された関数であって属性というのは、
Chromiumのマルチプロセスアーキテクチャのため、特に実装が難しいですよ。
これについてはちょっと以下で詳しく説明しますので、
今からバードの話が続くかですかね。
アクセシビリティツリーを検査するためのツールというお話です。
開発者はいくつかの方法でアクセシビリティツリーを検査することができます。
chrome://のアクセシビリティというURLに移動して、ツリーを直接検査もできます。
こんなのあったんですね。
なお、内部オプションを有効にしておくと良いでしょう。
特定のタブのアクセシビリティツリーを表示というのがあるので、
それをクリックし、もう一度クリックするとそのツリーが更新されます。
オートメーションAPIを使用しますと書いてますね。
オートメーションインスペクター、Chrome拡張機能というのがあるので、それをインストールしておきましょう。
あと、ax-dump-tree、またはax-dump-eventsというのを構築して使用します。
18:03
これらを使用すると、Windows、Mac、Linuxのどのアプリケーションからでも
アクセシビリティツリーやイベントを表示することができます。
または、ネイティブツールというのを使って、
Androidの場合はUI Automator Viewerというものと、
Mac OSではアクセシビリティインスペクターというものですね。
あとは、Windowsの場合だとインスペクトAViewerですね。
あと、acc-probe、その他いろんな関数があるので、
その辺を使ってみるというのも一つです。
いろんなツールがあるので、その辺を使ってみてほしいと。
結構、Chrome拡張もあったりするし、
Chromeを使われている方は、
chrome://のアクセシビリティというURLがあるので、
そこに直接アクセスすると全然見れますよという話ですね。
これ、Chromeのアカウントがない場合、
いきなり行くと、not foundで返されるので、
そもそもログインする必要がありません。
というところでした。
では続きまして、コマンドラインオプションですね。
入っていきたいと思います。
Chromeのアクセシビリティ機能というのは、
デフォルトではオフになっており、
オンデマンドで自動的に有効になります。
コマンドラインからChromeを実行する場合、
特定のオプションを使用すると、
起動時のChromeのアクセシビリティエンジンの動作に
影響を与えることができます。
オプション2つありますね。
1つ目は、
--force-render-accessibility="
仮括弧ですね。
配列的なやつですけど、
ベーシックでパイプ、もしくはですね、
perform-control-pipe-completeみたいなやつですね。
を指定してあげる必要があります。
アクセシビリティを強制的にこれで有効にできます。
オプションのパラメーターで、
実行中ずっとaxモードを定義済みバンドで
いずれかに強制的に変更します。
オプションのパラメーターが無効な場合、
デフォルトのaxモードというのは
コンプリートになります。
オプションのパラメーターが無い場合、
axモードのデフォルトは
コンプリートになりますが、
実行中にモードを変更することができますよ。
後場のようなforceっていうのが
名前のついたオプションなんで、
これ結構強いんですね、本当に。
無理やり強制的にやることができると。
もう1個は、
--disable-render-accessibilityというやつですね。
これはアクセシビリティを無効にするものですね。
名前の通りのオプションがあります。
一応、コマンドラインからOSを起動する場合は
こういうオプションがありますよって話でした。
オプションっていうか、
コマンドライン、CLIからOSを起動すること
ほぼほぼ僕ないので、
こんなのあるんやなって感じですね。
ちゃんといろんな実装されてて面白いなと思いました。
続いて、
Supported Platforms and APIsですね。
対応プラットフォームとAPIという話です。
まずWindowsからですけど、
iAccessibleですね。
マイクロソフトアクティブアクセシビリティ
またはMSAAとしても知られている
iAccessibleってやつと
iAccessible2ってやつと
UIオートメーションでもあると。
ChromiumはiAccessible2と
UIオートメーションのノード間のマッピングも
一応サポートしてますよと。
一応この辺の記事も別のリンク貼られてるんで
見てみてください。
これ公式ドキュメントですね。
Chromeのほうの。
あとは、
21:00
MacではNSアクセシビリティってやつですね。
これを使ってますと。
LinuxではATKってやつですね。
最後Androidでは
アクセシビリティノードインフォーおよび
アクセシビリティノードプロバイダー
っていうものがありますよと。
この辺が各プラットフォームのAPIですね。
この記事内容の最初のほうで
いろいろ常に名前出てきてますけど
一応改めてまとめたものって感じですね。
中途半端だけど
ここで一旦区切ろうと思います。
明日はこれの続き
Chromium's Multiprocess Architecture
これが終わったら
やっと本題の記事である
How Chrome Accessibility Worksの
パート1そしてパート2と続いていきたいと思います。
6日間に渡る気がしますね。
結構長いんですけど。
今ここが興味あるんで
この辺頑張って読んでいきたいなと思いますので
興味あればお話してください。
では改めまして
日曜日の朝からはレノアさんですね。
おはようございます。
ご参加いただき大変ありがとうございました。
いつも通りこんな感じで
ゆるーくやっていきますので
また来てみてくれたら嬉しいです。
じゃあ日曜日ですね。
しっかり休んでいただいて
また明日月曜日から
お仕事頑張れればと思いますので
ゆっくり日曜日休んでいただければと思います。
それでは終了したいと思います。
おつかれさまでした。
