Chrome DevTools のフル ユーザー補助ツリー

ヨハンベイ
ヨハンベイ

Chrome DevTools で、完全なユーザー補助ツリーがリリースされます。これにより、デベロッパーはツリー全体の概要を簡単に把握できます。この投稿では、このツリーの作成方法と、このツリーを作業で使用する方法について説明します。

ユーザー補助ツリーとは

スクリーン リーダーなどの支援技術では、Chromium のユーザー補助 API を使用してウェブ コンテンツを操作します。この API の基盤となるモデルはユーザー補助ツリーです。ユーザー補助ツリーは、支援技術で属性とプロパティを照会し、アクションを実行できる、ユーザー補助オブジェクトのツリーです。ウェブ デベロッパーは、主に HTML の ARIA 属性などの DOM プロパティを使用して、ユーザー補助ツリーを形成、操作します。

Chrome DevTools には、デベロッパーがコンテンツがどのように支援技術に公開されているかを把握できるユーザー補助ペインが用意されています。具体的には、DOM ツリー ビューアでノードを選択すると、対応するユーザー補助ノードのプロパティが、そのノードの祖先および直接の子のビューとともにペインに表示されます。

Chrome DevTools のユーザー補助ペイン

ツリーはどのように作成されますか?

DevTools でのこの新しいフルツリービューについての説明に入る前に、ユーザー補助ツリーについてもう少し具体的に説明しましょう。アクセシビリティ ツリーは、DOM ツリーから派生したものです。その構造はほぼ同じですが、セマンティック コンテンツを持たないノード(スタイル設定にのみ使用される <div> 要素など)を削除するように簡素化されています。ツリー内の各ノードには ButtonHeading などのロールがあり、多くの場合、ARIA 属性に基づく名前か、ノードのコンテンツから取得された名前が付けられます。HTML ドキュメントの場合、次のようになります。

<html>
<head>
  <title>How old are you?</title>
</head>
<body>
  <label for="age">Age</label>
  <input id="age" type="number" name="age" value="42">
  <div>
    <button>Back</button>
    <button>Next</button>
  </div>
</body>
</html>

Blink という Chromium のレンダラは、おおまかな次のような内部アクセシビリティ ツリーを導出します。

role='rootWebArea' focusable name='How old are you?'
  role='genericContainer' ignored
    role='genericContainer' ignored
      role='labelText'
        role='staticText' name='Age'
      role='spinButton' editable focusable name='Age' value='42'
        role='genericContainer' editable
          role='staticText' editable name='42'
      role='genericContainer'
        role='button' focusable name='Back'
          role='staticText' name='Back'
        role='button' focusable name='Next'
          role='staticText' name='Next'

この表現には genericContainer ロールを持つ不要なノードが複数含まれています。これは、アクセシビリティ ツリーが DOM ツリーを簡略化した派生物であるという上記の文と一見矛盾しているように見えます。それでも、これらのノードのほとんどは内部ツリーにのみ存在するため、支援技術には公開されません。DevTools はレンダラ プロセスからユーザー補助情報を直接収集するため、これは DevTools で処理できるツリー表現です。

DevTools の完全なユーザー補助ツリー

新しい完全なユーザー補助ツリーが DOM ツリーと同期されるため、開発者は 2 つのツリーを行き来できます。この新しいツリーがさらに探索しやすく、便利で使いやすいものとなることを願っています。

ユーザー補助ツリーの仕組みを理解したところで、次は DevTools を使って新しいツリービューがどのように表示されるかを確認しましょう。タイトル、見出し、2 つのボタンがある次の HTML ドキュメントは、ツリーを表示するために使用されます。

<!DOCTYPE html>
<title>Test</title>
<h1>Heading for example page</h1>
<div>
  <button>Back</button>
  <button>Next</button>
</div>

前述のツリービューでは、1 つのノードとその祖先しか確認できません。

DevTools の前のツリービュー

今後は、新しいツリーを切り替えると DOM ツリービューに置き換わり、そのページのユーザー補助ツリー全体を表示できるようになります。

DevTools の新しいツリービュー

Lazy ツリー構築

大規模なサイトでもツリーのパフォーマンスを向上させるため、ツリーを探索するにつれてフロントエンドで遅延構築されます。ツリー内でノードが展開されると、Chrome DevTools Protocol(CDP)によってノードの子が取得され、ツリーが再構築されます。

大きなページの結果を示す新しいユーザー補助ツリー。

ライブ

新しいツリービューは有効であり、レンダラでユーザー補助ツリーが変更されると動的に更新されます。これは、支援技術にツリーの変更を通知するのと同じメカニズムに接続し、更新されたノードとともに DevTools フロントエンドにイベントを出力します。 実際には、CDP バックエンドはツリーの更新をリッスンし、以前にリクエストされたノードを追跡し、これらのノードのいずれかが変更された場合は DevTools フロントエンドにイベントを送信します。

たくさんの木にまつわる物語

ユーザー補助ツリーとは何かの説明では、Blink がレンダリングする DOM のユーザー補助ツリーを作成する方法について説明し、DevTools が CDP を通じてこのツリーを取得する仕組みについて説明しました。ただし、説明文では複雑な点を省略しています。実際には、Chromium のユーザー補助ツリーにはさまざまな表示方法があります。 DevTools の新しいツリービューを設計するにあたり、Chromium のユーザー補助の内部のどの部分を表示したいかについて、いくつかの選択を行いました。

プラットフォーム

プラットフォームごとにユーザー補助 API は異なります。すべてのプラットフォームでツリーの形状は同じですが、ツリーを操作するための API は異なり、属性の名前も異なる場合があります。DevTools には Chromium の内部ツリーが表示されます。このツリーでは、ロールと属性が ARIA 仕様で定義されているものと一致する傾向があります。

複数フレームとサイト分離

Chromium は、各タブのコンテンツを別のレンダラ プロセスに配置するだけでなく、クロスサイト ドキュメントを異なるレンダラ プロセスで分離するため、CDP を介してプロセス外の各子ドキュメントに個別に接続し、そのユーザー補助ツリーを取得する必要があります。次に、これらのサブツリーをフロントエンドでつなぎ合わせ、1 つのツリーのように見えます。これらのツリーは Chromium の異なるレンダラ プロセスに存在しますが、

無視され、興味のないノード

一部のノードは、デフォルトで非表示になります。無視されるノードと、名前のないロールが「generic」のノードです。これらのノードには意味論的意味がなく、無視されたノードの場合、支援技術には公開されません。ツリービューを見やすくするため、これらのノードは非表示になります。そうしないと、ほとんどのウェブページのアクセシビリティ ツリーは次のようになります。

新しいツリービューにすべてのノードが表示されています。

ここでの注意点は、基本的には、バックエンドで利用可能なものとは別のツリーを構築する必要があるということです。たとえば、ノード A、B、C、X があり、A には子 X と B があり、X には子 C があるとします。X が無視されるノードの場合は、X をツリーからプルーニングして、代わりに C が A の子であるツリーを作成します。

木の枝刈り方法を示す図。

フロントエンドでは、無視されたノードを含む完全なツリーを構築し、ノードのレンダリング直前にのみプルーニングします。これには次の 2 つの理由があります。

  • 両方のエンドポイントで同じツリー構造を使用できるため、バックエンドからノードの更新を簡単に処理できます。たとえば、この例でノード B が削除された場合、ノード X の更新を受け取ります(その子が変更されたため)。ただし、そのノードをプルーニングすると、更新する内容を見つけるのに苦労することになります。
  • すべての DOM ノードに対応するアクセシビリティ ノードを持つことが保証される。ツリーを切り替えると、DOM ツリーで現在選択されているノードに対応するノードが選択されます。したがって、前の例では、X に対応する DOM ノードが選択されている間にユーザーがツリーを切り替えると、ノード A とノード B の間に X を挿入し、ツリーの X を選択します。これにより、すべての DOM ノードのユーザー補助ノードを調べて、そのノードが無視される理由を特定できます。

未来のアイデア

新しいユーザー補助ツリーのリリースは、出発点にすぎません。Google ではこの新しいビューをベースに、今後のプロジェクトについていくつかのアイデアを用意しております。ぜひフィードバックをお寄せください

代替フィルタリング

上で説明したように、Google は現在、興味のないノードを除外しています。この動作を無効にしてすべてのノードを表示する方法や、[ランドマーク ノードを表示] や [見出しを表示] などの別のフィルタ処理を行うこともできます。

ユーザー補助の問題をハイライト表示する

このツリーに「ユーザー補助のベスト プラクティス」分析を組み込み、問題のあるノードで直接ユーザー補助の問題をハイライト表示できます。

DevTools でユーザー補助アクションを表示する

現在表示されているツリーは、完全に一方向です。つまり、特定のウェブページを閲覧しているとき、支援技術にどのような情報がフィードされるのかを把握できます。ユーザー補助アクションは、反対方向のコミュニケーションを表します。表示される UI で支援技術を動作させることができます。このようなアクションを DevTools に表示して、支援技術で利用できる API を使用して、ページ上の「クリック」、「スクロール」、「値の変更」などのアクションを許可できます。