Accessibility Visualizerを活用したアクセシビリティチェック

アクセシビリティ

Posted at 2025-08-26

Webページのアクセシビリティチェック用のツールとして、Accessibility Visualizerというものを作っています。これはブラウザ拡張として提供され、アクセシビリティに関係する情報をWebページに重ねて表示するというものです。Chrome向けとFirefox向けに提供しています。¹

Accessibility Visualizerは非常に機能が多いため、それらを網羅したユーザーズガイドを、GitHubに置いています。しかし、このドキュメントがあっても、初心者の方が「よし、アクセシビリティチェックをしてみよう」とは思えないのではないかと思っていました。

そこで、ユーザーズガイドとは別に、「Accessibility Visualizerの作者はどう使っているのか」をわかりやすく説明する記事を書いてみようと思います。

「基本」プリセットでひととおりのものを見る

画面上の要素ごとに表示される情報を、Accessibility Visualizerでは「チップ（tip）」と呼んでいます。チップの表示の対象となる要素は、「基本」「コンテンツ」「構造」というプリセットと、要素を自由に選べる「カスタム」から選べるようになっています。

「基本」には、どのWebページを見るときにも意識することの多いものを入れてあります。

ページ・言語

ブラウザのウィンドウ上部や、フレーム（<iframe> 要素など）の上部には、HTML全体の情報として、「タイトル」と「言語」が表示されます。

タイトルは、 <title> 要素で指定されるものです。各ページの主題または目的を説明し、ページを区別するのに役立つものがつけられていなければなりません。原則として各ページがそれぞれ別のタイトルであるべきです。

言語は、<html> 要素の lang 属性の値を表示します。日本語のページではほとんどの場合 ja が指定されます²。 lang 属性は <html> 要素へ指定することが推奨されており、指定が無かったり間違ったりしていると、スクリーンリーダーが違う言語で読み上げようとしたり、ブラウザがページを翻訳するためのUIを表示したりするなどの問題が発生します。

また、ページ内に他の言語で書かれた部分が存在する場合、その部分の要素には lang 属性を付けるべきです。たとえば、ドイツ語で書かれた部分があるなら、その部分の要素に lang="de" を付与します。

<title>要素や lang 属性がない場合、赤色のエラーメッセージが表示されます。

Accessibility Visualizer では 問題の存在と修正方法が明確であるものは、赤色のエラーメッセージとして表示します。まずはこういったエラーメッセージが表示されている箇所から直していくのが良いでしょう。

よくある失敗例

動的なWebサービスで、すべてのページのタイトルが同じになっている
フレームワーク等が初期に生成したコードのまま、日本語のページなのに lang="en" となっている

見出し

<h1> 〜 <h6> 要素などで作られる見出しには、「見出しレベル」と「見出しの内容」が表示されます。

見出しレベルは、ページの構成を把握する手がかりとなります。レベルの大小がページ内で使われている意味合いと一致していなかったり、あるいは見出しのように見える場所が見出しでなかったりすると、見出しを頼りに閲覧するユーザーが混乱してしまうおそれがあります。

見出しレベルのとなりに、見出しの内容が、緑色で人型のアイコンとともに表示されますが、これは「アクセシブルな名前」を意味しています。見出し以外でもこの緑色＋人型アイコンはたびたび登場します。スクリーンリーダーのような支援技術は、この「アクセシブルな名前」をユーザーに提示します。

よくある失敗例

<h1> 〜 <h6> 要素を装飾的に使い、見出しレベルがページの構造を表現していない
<h1> 〜 <h6> 要素の中に alt="" を指定した <img> 要素のみが置かれ、見出しの内容が空になっている

画像

画像にも「アクセシブルな名前」が表示されます。 <img> 要素の場合、 alt 属性によって指定される「代替テキスト」の内容が、ここに表示されます。axe-core（axe DevToolsやLighthouseなど）などの自動チェックツールでは、代替テキストの内容まではレビューできないため、Accessibility Visualizerを使って人間の目で確認することに大きな意味があります（そのためにツールを作ったと言っても過言ではありません）

意味をもたない装飾的な画像の場合、alt="" にする（alt 属性を空にする）ことが良いとされています。 alt="" となっている画像には、Accessibility Visualizerでは黄色い警告メッセージを表示しています。

alt="" の画像は、スクリーンリーダーのような支援技術からは無視されます。これは ユーザーは、画像の存在にすら気付くことができない ことを意味します。本当に alt="" であるべき画像かどうかは、慎重に判断するべきです。そのため、警告メッセージとしています。

なお、 alt 属性自体が無い場合には、エラーメッセージを表示します。

alt 属性値については、altディシジョンツリーも参考にしてください。

よくある失敗例

alt 属性にファイル名が書かれていて、画像の内容を説明していない
すべての画像が一律に alt="" となっている
画像内に多くのテキストが書かれているが、代替テキストで説明しきれておらず、画像を見ずに得られる情報が極端に少ない
画像と代替テキストの内容が食い違っている
画像からは読み取れない内容まで代替テキストに書かれている

フォームコントロール

テキスト入力欄、セレクトボックス、チェックボックス、ラジオボタンなど、フォームを構成する要素をまとめて「フォームコントロール」と呼んでいます。

フォームコントロールでも「アクセシブルな名前」が重要な役割を果たします。入力欄などが何を示すものであるかを <label> 要素によって紐付けると、そこがアクセシブルな名前になります。ラベルを紐付けられていれば、入力欄に「アクセシブルな名前」が表示されます。

これができていれば、スクリーンリーダーのような支援技術でその入力欄が何の入力欄であるのかを知覚できるはずです。

ラベルがない、もしくは紐付けのできていない入力欄には、「名前（ラベル）なし」のエラーメッセージが表示されます。

また、入力欄と紐付けされていない <label> 要素にも、「入力欄等と紐付けされていない」という警告を表示します。 <label> 要素は入力欄と紐付けずに使っても、それだけでは大きな問題にはなりませんが、こういった <label> 要素が存在する場合は何かのミスであったり、マークアップをする上での何かの勘違いがあったりしそうです。

それ以外にも、キーボードによる操作に大きな支障のある「name属性がない」「同じ name 属性をもつラジオボタンが1つしかない」ものにエラーを表示したり、<label> 要素が for 属性で参照する id が存在しない場合に警告するなどの機能が入れてあります。

よくある失敗例

<label> 要素が一切使われていない
ラジオボタンの name 属性の指定の仕方を間違えており、キーボードの矢印キーで選択を変更することができない
<label> 要素の for 属性に指定された id をもつ入力欄が存在しない
見た目を工夫したチェックボックスやラジオボタンで、 <input> 要素が非表示になっている

リンク・ボタン

リンクやボタンは、通常は内部に書かれたテキストが「アクセシブルな名前」となり、この名前がなければ支援技術のユーザーはリンクやボタンをクリックしたら何が起きるのかを予測できなくなってしまいます。

よくあるのはアイコンなどの画像をリンクやボタンとしているようなケースで、画像の代替テキストが設定されておらず、リンクの名前がなくなってしまうパターンです。アイコンが <svg> 要素になっているため、 alt 属性のチェックをすり抜けてしまうような場合もあります。

よくある失敗例

サムネイルとタイトルが並び、それぞれがリンクになっているが、サムネイル側のリンク内には alt="" にした <img> 要素しかなく、リンクが無名になってしまう
アイコンだけで表示されたボタンが無名になってしまう
<div> 要素でボタンを作っており、キーボードで操作できず、支援技術からはボタンとして認識もされない
<a> 要素に href 属性を設定せず、JavaScriptによりクリック時に画面を切り替える処理をしている。キーボードでの操作ができず、支援技術からはリンクとして認識されない

WAI-ARIA

WAI-ARIAの属性（role属性、aria-*属性）は、どうしても必要なときのみ使用するべきです。Accessibility Visualizerでは、WAI-ARIAの属性を使用しているものはその内容を表示するようになっています。使用の是非や、適切な使われ方をしているかどうかを観察できるようにするためです。

たとえばQiitaの右上にあるボタンには、たくさんのWAI-ARIA属性がついていました

名前: 投稿するメニューを開く
警告: 参照されているIDが存在しません: PostDropDown (aria-controls)
ステータス: 折りたたまれている
aria-controls: PostDropDown
aria-expanded: false
aria-haspopup: dialog
aria-label: 投稿するメニューを開く

id 参照の警告が出ていますが、おそらく非表示になっているメニューの id なので、この場合は問題ないでしょう（Accessibility Visualizerで警告が出ないよう検討してもいいかもしれません）。「折りたたまれている」のように、aria属性で変更できるステートについてもAccessibility Visualizerで表示するようになっています（ほかにも、チェックボックスのチェック状態など）。

ここのメニューに関していえば

「何かが開く」ことは aria-expanded や aria-haspopup からわかるので、「投稿するメニューを『開く』」という aria-label を付けるのは冗長では
- 視覚的には「投稿する」ボタンなのだから、aria-label による上書きをするべきではないのでは
「メニュー」が開くのだから、aria-haspopup の値は "menu" が妥当では
WAI-ARIAを使用するのではなく、 <details> 要素による実装にできないだろうか

みたいなことを検討する余地があるはずです。

なお、role 属性を追加した要素には、要素名が表示されるようにもなっています。以下は、<div> 要素でボタンを作った例です（よい子は真似しないでね！）

Accessibility Visualizerの作者の立場としては、WAI-ARIAに関しては、Accessibility Visualizerを補助的なツールとして考えていただきたいです。No ARIA is better than Bad ARIA（悪いARIAよりもARIA無しのほうが良い）という言葉もあるとおり、WAI-ARIAの使い方を誤るとアクセシビリティを大きく低下させるおそれがあります。WAI-ARIAの属性を使うのであれば、実際の、なるべく複数の支援技術での動作確認を行うようにしてください。

よくある失敗例

ロールに対して不適切な aria-* 属性を使用してしまう
暗黙のロールをもつ要素に対して冗長な role 属性をつけてしまう
WAI-ARIAを使わずに実装できるものをWAI-ARIAで実装してしまう
role 属性を指定した要素がロールの要求を満たす挙動になっていない
支援技術による動作確認を行っていない

構造

「構造」はおもに、Webサイトのテンプレートを作るようなときに見るようなものを入れてあります。

「構造」にあるもののうち、「セクション」以外は「基本」にも含まれています。

セクション

「セクション」では、HTMLの <section> <main> <header> などのセクショニング要素や、banner main navigation などのランドマークロールを対象としています。ランドマークとなる要素やロールは、見出しと同じくページ構造を掴むための手がかりとなるので、正しく設定するべきです。

ランドマークとなっている場所には黄緑色の旗のアイコンが表示されます。たとえば、Qiitaの記事ページを見ると、上部には banner search navigation ロールがあり、その下の main ロール内に記事本文が article ロールとして配置されていることがわかります。

<section> 要素は、ただ置いただけではランドマークにならないため、とりあえず <section> 要素であることがわかるように要素名を表示しています。

よくある失敗例

ランドマークロールが使用されていない
ランドマーク要素の使用方法を間違えている

コンテンツ

「基本」ほど出番のなさそうなものを入れてあります。たまに役に立つこともあるかなくらいの状態です。

リストの種類や項目数が表示されます。この機能だけではあまり問題を発見することは少ないですが、なぜか <ul> の直下に <li> ではなく <div> が置かれているなどの、変なマークアップを見つけるのに役立つことがあります。

テーブル

テーブルの大きさや座標、対応する見出しセルを表示できます。ここを作るのがAccessibility Visualizerを作るうえでいちばん大変だったんですが、労力の割にはあんまり役に立ったことがありません。そもそもテーブルの上にいろいろモノを表示するとゴチャゴチャして使いづらいということがわかった。

ライブリージョン

「ライブリージョンをアナウンス」にチェックを入れておくことで、aria-live 属性や <output> 要素によるライブリージョンの更新を視覚的に見ることができます。スクリーンリーダー以外でライブリージョンを確認する方法は、Accessibility Visualizerを使うくらいしかないんじゃないかと思います。あったら知りたいです。

しかし、日本国内ではまだあまりライブリージョンが一般的ではない様子です。GitHubなどを操作していると、操作のフィードバックが表示され、楽しむことができます。

テクニック

有効・無効

Accessibility Visualizerの表示を完全にオフにするチェックボックスが、ポップアップの右上にあります。

無効にすると目を閉じます。かわいいですね。

インタラクティブモード

Accessibility Visualizerは、デフォルトで「インタラクティブモード」が有効になっています。これは、マウスポインタをかざした要素以外はチップをアイコンだけにして、さらに不透明にして目立たせなくしておくモードです。

ほとんどの場合はこれでいいのですが、インタラクティブモードではマウスオーバーのイベントを拾うための要素をいっぱい配置します。そのため、「マウスオーバーでメニューが開いていく」ようなWebページの機能とは相性が悪いことがあります。その場合はインタラクティブモードをオフにするか、Accessibility Visualizerを無効にするしかありません……。

ちなみにインタラクティブモードをオフにした状態は、スクリーンショットを撮るときにも便利だったりします。上の「セクション」のところのスクリーンショットは、インタラクティブモードをオフにして不透明度を100%にして撮影しています。

設定

Accessibility Visualizerの設定は、サイトのホストごとに保存されるようになっています。これはWebサイトの開発に使うことを想定して、画面を遷移しても同じ設定を使えたり、開発対象のWebサイトでだけ常に有効にしておくことを意図したものです。

新しいホストに移動したときには、拡張機能のオプション画面で設定された内容が使用されます。なので、ここで控えめな設定にしておいて、ヨソのサイトではあまり情報を表示せず、開発対象でだけたくさん表示するみたいなこともできます。

実はEdge版もありますが、ストアの反映が遅いので、たまに最新版の提供ができていないことがあります。Chrome/Firefox版の利用をおすすめします。 ↩
lang 属性にはIETF BCP47の言語タグが使用できます。 ja-JP でも良いですが、日本以外で話される日本語と区別する必要はほとんどないため、 ja が良いでしょう。 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up