ARIA DevTools - Webサイトのアクセシビリティツリーを可視化

 (chromewebstore.google.com)
4 ポイント 投稿者 GN⁺ 2024-10-09 | 1件のコメント | WhatsAppで共有
  • ARIA DevToolsは、Webアプリケーションをスクリーンリーダーが解釈する構造として確認でき、アクセシビリティの問題を開発段階で見つけやすくするChrome拡張機能
  • ページ要素を明示的・暗黙的なARIAロールを基準に表示し、見出し、画像、テーブル、フォーム項目などをあわせて確認できる
  • 欠落したARIAラベル、誤ったロール指定、不完全なキーボード対応のように、実際の支援技術の利用体験を損ねうる問題の点検に焦点を当てている
  • Chrome Web Store基準でユーザー10,000人、評価4.9/5点、レビュー33件で、Developer Toolsカテゴリに登録されている
  • 開発者はユーザーデータを収集または使用しないと公開しており、GitHubリポジトリとIssueページを通じてプロジェクトの状態を確認できる

スクリーンリーダー視点でアクセシビリティツリーを確認

  • ARIA DevToolsは、アクセシブルなWebアプリケーションの開発とテストを支援する開発者ツール拡張機能
  • Webサイトを、スクリーンリーダーが視覚障害のあるユーザーに伝える方法で表示する
  • ページ要素は明示的または暗黙的なARIAロールを基準に整理される
    • 見出し
    • 画像
    • テーブル
    • フォーム項目
    • その他のページ要素

点検できるアクセシビリティの問題

  • 欠落したARIAラベルをより簡単に確認できる
  • 誤って使われたARIAロールを見つけるのに役立つ
  • 不完全なキーボード対応もあわせて点検できる
  • アクセシブルなWebサイトの開発とテストのプロセスを短縮することが目的

Chrome Web Storeの登録情報

  • Chrome Web Storeに登録された拡張機能で、Developer Toolsカテゴリに属する
  • 登録情報上のユーザー数は10,000人
  • 評価は4.9/5点、レビュー数は33件
  • バージョンは1.4.3、サイズは156KiB
  • プロジェクトはGitHubで公開されているオープンソース

個人情報の取り扱い

  • 開発者は、この拡張機能がユーザーデータを収集または使用しないと公開している
  • データは第三者に販売されない
  • データは、拡張機能の中核機能と関係のない目的で使用または移転されない
  • データは、信用判断や融資目的で使用または移転されない

関連記事

1件のコメント

 
GN⁺ 2024-10-09
Hacker Newsのコメント

  • 素晴らしそうです。iframe内でも実行できるようにしてもらえますか？ Storybook/Playroomで使えたら本当に良さそうです
    Firefoxのリンク: https://addons.mozilla.org/en-US/firefox/addon/aria-devtools...

    • 気に入ってもらえてうれしいです。まだiframe対応を入れていない最大の理由は、権限範囲がはるかに広くなるからです
      今のように「ARIA DevTools」アイコンをクリックして現在のタブへのアクセスだけを許可するのではなく、訪問するすべてのWebサイト上のあらゆるデータへのアクセス権を与える必要があります。ただ、最後に確認してから状況が変わっていないか、もう一度調べてみます
    • iframeを新しいタブで開いて、その上で拡張機能を使えるのではないかと思います

  • 迅速なチェックにも、教育にも非常に役立つツールです。この可視化は、非技術系のステークホルダーにアクセシビリティ、特にスクリーンリーダーをどう考えるべきかを示すのに役立ちそうです
    WCAGの難しさの半分は、ステークホルダーに単なる準拠チェックボックスを埋める以上のことをしてもらう点にあります

    • 「すでにテキストなんだから、スクリーンリーダーがそのまま読めばいいのでは？」
    • ある程度もっともです。ユーザーの98%がアクセシビリティのないサイトでも問題なく使えるのなら、特にコンピューターをよく使う人はたいてい若いことを考えると、なぜチェックボックス以上のことをする必要があるのでしょうか？ 期待値がマイナスの選択に見えてしまいます

  • とても素敵です。最近、自分なりのアクセシビリティツリー可視化を実装したのですが [1]、このツールはツリーそのものから離れて、個々の単位のグルーピングにより焦点を当てた可視化になっていて興味深いです
    私は全体構造を見せて、そこからページの論理的な流れに注目できるようにする方向で考えました。一方で、ツリーを個別ブロックの集合として捉え、それぞれのブロック内部の凝集性を重視するアプローチはかなり面白いですね。比較してみたいなら、ぜひ話してみたいです
    [1] https://polypane.app/blog/polypane-20-1-the-accessibility-tr...

  • すっきりして見えますし、https://wave.webaim.org/よりずっと整理されています

    • ありがとうございます。ARIA DevToolsには大きな可能性があると思っています。私の基準ではかなり人気がありますが、Webアクセシビリティを深く扱う人たちとのつながりはありませんでした
      こういうツールは細部が重要なので、公平に言えばWAVEのほうがおそらくより正確である可能性が高いです

  • かなりきれいで気に入りました。私が開発中のテレビ番組メタデータページで試してみました
    ある要素は、それぞれ aria-label で内容を説明する span を含む div のまとまりなのですが、MacOSのVoiceOverは正しく読み上げ、Chromeのアクセシビリティツリーでも認識される一方で、このツールでは aria-label が表示されず、値が文字列としてただ並んで表示されます。また ::before { content: ", " / ""; } を , value として拾っていましたが、これは全体的にサポートがあまり良くありません

    • そのページのリンクをいただけますか？ 自分でテストして修正したいです

  • いいですね。私はアクセシビリティ対応に関心があります
    今ではWebサイトは主な仕事ではありませんが、以前は自分が担当するサイトが非常にアクセシブルになるよう常に気を配っていました

  • こうしたツールでは、ARIAロジックをUIから分離してほしいです。複雑なARIA関連の処理はライブラリに入れて、十分にテストされた共通コードベースの上に複数のUIを載せる形が望ましいでしょう
    宣伝も兼ねて: https://github.com/xi/aria-api

  • Chrome内蔵ツール(https://developer.chrome.com/docs/devtools/accessibility/ref...)と比べるとどうですか？

    • このツールを設計したとき、ARIAの役割や属性だけを表示するのではなく、スクリーンリーダーユーザーの体験を反映するようにしようとしました
      たとえばページはキーボードだけでナビゲートする必要があります。ドロップダウンがアクセシブルでなければ、ユーザーにはすぐに分かります。表も一度にセル1つとその見出しだけを表示します。実際のスクリーンリーダーユーザー体験に非常に近いと思います

  • 良いアイデアと実装です。サイドプロジェクトでぜひ使ってみます。ちょうどMandy MichaelのHTMLパフォーマンスとアクセシビリティの発表 [1] を見ていて、ブラウザ内蔵のアクセシビリティツリービューアより良いツールがあるのか気になっていたところでした

    1. https://youtu.be/cghb0VpCJqM?si=5pWNrkPOyUsohyGJ

  • 素晴らしいツールです。最近アクセシビリティをさらに掘り下げていて、特にスクリーンリーダーユーザー体験の改善に取り組んでいます
    経験豊富な方の中で、大規模なフォームや動的テーブルのような複雑なケースでこのツールを試した方はいますか？ そうしたケースで他のアクセシビリティツールと比べてどうなのか気になります。コツや知見があればありがたいです