Webアクセシビリティチェックツールは、サイト内の問題を機械的に探し、修正の手掛かりを示すための道具です。
ただし、スコアが高いことと、障害のある人を含む利用者が支障なく使えることは同じではありません。
まず自動チェックで候補を絞り、キーボード操作、読み上げ、文章の分かりやすさなどを人が確認する必要があります。
この記事では、無料で始めやすい4つのツールと、診断や支援機能を既存サイトへ加えるUUUの役割を分けて整理します。
Webアクセシビリティチェックツールで分かること
Webアクセシビリティとは、年齢、障害、利用環境などにかかわらず、ウェブ上の情報や機能を利用できる状態を目指す考え方です。
チェックツールは、HTMLや画面表示を調べ、機械で判定しやすい問題を見つけます。
- 画像に代替テキストを指定する属性があるか
- フォームの入力欄とラベルが対応しているか
- 文字と背景のコントラストが基準を満たすか
- 見出しやランドマークの構造に不自然な点がないか
- ARIA属性の名前、値、役割の組み合わせが妥当か
一方、代替テキストが画像の意味を正しく伝えているか、操作の順序が理解しやすいか、エラーから立て直せるかといった点は、機械判定だけでは確定できません。
デジタル庁の導入ガイドブックも、ツールで機械的に確認できる達成基準は一部にとどまると説明しています。
チェック結果は合否証明ではなく、人が詳しく調べる場所を絞るための入口として扱います。
無料で始めやすい4つのツール
| ツール | 向いている場面 | 結果の特徴 | 注意点 |
|---|---|---|---|
| miChecker | JIS X 8341-3:2016に沿った検証を進めたいとき | 自動判定と、人が確認する項目を組み合わせて検証できる | 配布元の注意事項を確認し、最新版を使う |
| Lighthouse | Chromeで開発中または公開済みのページを素早く確認したいとき | 監査結果とアクセシビリティスコアを一覧で確認できる | スコアに含まれない手動確認項目がある |
| axe DevTools | 開発者が問題のある要素と修正の手掛かりを確認したいとき | ブラウザの開発者ツール内で問題箇所を調べられる | 無料版の自動検査だけで検証を完了させない |
| WAVE | 画面上のどこに問題や確認点があるかを視覚的に把握したいとき | ページにアイコンを重ね、構造や代替テキストを確認しやすくする | エラーが表示されなくても、適合や使いやすさは保証されない |
miChecker
miCheckerは、JIS X 8341-3:2016に基づく取り組みを支援するために総務省が提供している評価ツールです。
自動で見つけられる問題だけでなく、人が判断する項目も確認できるため、JISに沿った検証の手順を学びながら進めたい場合に向いています。
2026年7月には脆弱性に関する注意が公開されています。
利用前に配布元の案内を読み、修正を反映した最新版であることを確認してください。
Lighthouse
LighthouseはChromeの開発者ツールから実行でき、ページ単位の監査結果とスコアを表示します。
ラベル、アクセシブルな名前、コントラスト、見出し構造など、実装時に起きやすい問題を短時間で探す用途に適しています。
スコアは自動監査の加重平均であり、キーボード操作などの手動監査は点数に含まれません。
修正前後の変化を見る指標にはなりますが、100点を適合証明として扱うことはできません。
axe DevTools
axe DevToolsは、Chrome、Edge、Firefoxで利用できるブラウザ拡張です。
問題がある要素、影響、修正に必要な情報を開発者ツール内で確認しやすいため、ページやコンポーネントの実装中に役立ちます。
無料版は一ページずつの自動検査が中心です。
フォームの操作手順や表示変化を伴う機能は、実際に操作して確かめます。
WAVE
WAVEは、URLを入力するオンライン版とブラウザ拡張を提供しています。
元のページ上にアイコンを重ねて、エラー、注意点、構造、ARIA、コントラストを確認できるため、コードを直接読まない担当者も問題の位置を共有しやすい点が特徴です。
WAVE自身も、自動ツールだけではページがアクセシブルかどうかを判定できないと説明しています。
表示された代替テキストが画像の目的に合うかなど、結果を人が読み解く作業までを一組にします。
最初の15分で行うチェック手順
- 対象ページを一つ決める：問い合わせ、予約、購入など、利用者の目的に直結するページを優先します。
- LighthouseまたはWAVEを実行する：最初から全ページを調べず、一ページの結果で操作と見方を覚えます。
- 同じ種類の指摘をまとめる：代替テキスト、ラベル、コントラスト、見出し構造などに分類します。
- 影響と修正範囲で優先順位を付ける：操作できない問題を先に扱い、共通部品の修正で複数ページへ反映できるものを見つけます。
- 修正後に再検査する：指摘が消えたことだけでなく、見た目や操作に別の問題が生じていないかも確認します。
例えば、問い合わせフォームで入力欄のラベル不足が見つかった場合は、まず送信に必要なすべての項目を直します。
その後、同じフォーム部品を使う資料請求や会員登録の画面にも修正が反映されるかを確認すると、場当たり的な対応を避けられます。
自動チェック後に人が確認する項目
自動検査が終わったら、少なくとも次の項目を手動で確認します。
- キーボード操作：Tabキーで操作対象へ移動でき、現在位置を見失わず、EnterキーやSpaceキーで実行できるか
- 読み上げ：ページ名、見出し、リンク、ボタン、入力欄、エラーが目的を理解できる順序で伝わるか
- 拡大表示：文字や画面を拡大しても内容が欠けず、横方向への過度な移動を求められないか
- 文章とラベル：専門用語、リンク文言、ボタン名、入力案内が、前後を読まなくても理解できるか
- 操作の完了：入力ミスの場所と直し方が分かり、時間制限や表示変化によって作業を続けられなくならないか
キーボード操作とフォーカス表示の確認方法では、操作順と見た目を点検する手順を詳しく解説しています。
JIS、WCAG、合理的配慮の関係
WCAGは、ウェブコンテンツをアクセシブルにするための国際的なガイドラインです。
JIS X 8341-3:2016は、日本でウェブコンテンツのアクセシビリティを考える際の基準で、試験方法や対応度の表記にはWAICの関連文書が使われます。
基準の全体像から確認したい場合は、Webアクセシビリティの基本と最初に直す領域も参考になります。
障害者差別解消法の改正により、2024年4月1日から事業者による合理的配慮の提供が義務化されました。
合理的配慮は、障害のある人から社会的な障壁を取り除くための対応を求められたとき、過重な負担にならない範囲で、個別の状況に応じて対応する考え方です。
したがって、「改正法が施行されたので、すべての民間サイトが一律にJISへ適合しなければならない」という説明は正確ではありません。
一方で、利用できない障壁を把握し、改善を続けることは、申し出に対応するための土台になります。
UUUはチェックツールとどう使い分けるか
UUUウェブアクセシビリティサービスは、既存サイトに導入できるウィジェットと、Webページの改善点を自動で診断する機能を提供する導入型サービスです。
文字サイズやコントラストの調整、音声読み上げ、ふりがな、翻訳などの利用支援に加え、画像の代替テキストやWAI-ARIA属性の付与を支援する機能が案内されています。
ただし、ウィジェットや属性の補助が、元の文章、情報設計、キーボード操作、業務フローの問題をすべて直すわけではありません。
UUUを検討するときも、次の三つを分けて判断します。
- サイト全体へ共通して提供したい利用支援機能
- HTMLや共通部品を修正すべき問題
- 人が操作して確認すべき画面と手続き
制作現場での使い分けは、UUUの補助機能と確認ポイントでも整理しています。
料金、対象ページ数、利用できる機能、導入方法は変更される可能性があるため、契約前に公式サイトで最新条件を確認してください。
チェックを一度で終わらせない運用
アクセシビリティは、新しい記事、画像、フォーム、機能を追加するたびに変化します。
公開前と定期点検で同じ手順を繰り返せるよう、担当者と記録方法を決めておきます。
- 公開前にLighthouseまたはaxe DevToolsで自動検査する
- キーボード操作と主要な読み上げ内容を人が確認する
- 検出事項を「すぐ直す」「計画して直す」「確認が必要」に分ける
- 修正内容、対象ページ、再検査結果を記録する
- 共通部品や更新ルールへ反映し、同じ問題の再発を減らす
ページを更新する担当者向けには、公開後のアクセシビリティを守る更新ルールも用意しています。
よくある質問
無料ツールは一つだけ使えば十分ですか
最初は一つで構いませんが、目的に応じて使い分けます。
短時間の点検にはLighthouse、画面上での共有にはWAVE、実装者の調査にはaxe DevTools、JISに沿った検証支援にはmiCheckerが候補になります。
アクセシビリティスコアは何点を目指すべきですか
固定の点数だけを目標にすると、点数に含まれない操作上の問題を見落とします。
まず重大な指摘を直し、同じ条件で再検査し、手動確認の結果と合わせて改善を判断します。
自動で付けた代替テキストやARIA属性はそのまま使えますか
候補として利用しても、ページの目的と表示内容に合うかを人が確認します。
不適切な代替テキストやARIA属性は、情報を補うどころか、読み上げを分かりにくくする場合があります。
最初に確認するページはどこですか
問い合わせ、申込、予約、購入、ログインなど、利用者が目的を完了するために欠かせないページを優先します。
次に、アクセス数が多いページと共通のヘッダー、メニュー、フォーム部品を確認すると、改善の影響範囲を広げやすくなります。
チェックツールを改善の入口にする
Webアクセシビリティチェックツールは、問題を素早く見つけ、担当者間で修正点を共有するために役立ちます。
実務では、自動検査、手動確認、修正、再検査、運用ルールへの反映を一続きの作業にします。
最初からサイト全体を完璧にしようとせず、利用者の目的に直結する一ページを選び、操作できない問題から直してください。
参考情報
- 政府広報オンライン：事業者による合理的配慮の提供
- ウェブアクセシビリティ基盤委員会：JIS X 8341-3:2016関連ガイドライン
- デジタル庁：ウェブアクセシビリティ導入ガイドブック
- Eclipse Accessibility Tools Framework：miCheckerについて
- 株式会社greeden：UUUウェブアクセシビリティサービスの案内
この記事に関連する株式会社greedenの取り組み
Webアクセシビリティは、診断結果を得るだけでなく、優先順位を決めて修正と確認を続ける取り組みです。株式会社greedenは、UUUのウィジェットと自動診断を通じ、既存サイトの改善を始めたい企業の一歩を支援しています。