「アクセシビリティ対応をしなければ」とは言われるが、何をどう測ればいいのか
2024年4月、障害者差別解消法の改正で、民間事業者にも合理的配慮の提供が義務づけられました。それ以来、ホームページの制作現場でこういう会話が増えたのではないでしょうか。
「うちのサイト、アクセシビリティ対応してますか？」
「JIS X 8341-3って、結局なにをすれば満たしたことになるんですか？」
聞かれた側は困ります。何をどう直せば「対応した」ことになるのか、判断の材料がないからです。そして材料を手に入れようとして最初にぶつかるのが、測るための道具が驚くほど手に入りにくいという事実です。
僕はハンズバリュー株式会社の代表で、ITコーディネータとして中小企業や温泉旅館のホームページ活用を支援してきました。この「測れない」という壁に自分でぶつかったので、道具のほうを作りました。
つなぐアクセシビリティ（https://miekata.0797.jp）といいます。URLを1つ入れるだけで、
- 色の見え方が違う方（色弱の方）に、そのページがどう見えているか
- JIS X 8341-3:2016 のうち機械で判定できる範囲の点数と、日本語の改善点
の2つが、同じ画面に並んで出ます。無料・登録不要・ログインなしです。Windowsでも Mac でも、スマートフォンからでも動きます。
この記事では、なぜこれを作ったのか、何ができて何ができないのか、そして作る過程でどこに迷ったのかを、包み隠さず書きます。制作会社の方、Webデザイナーの方、社内でサイトを見ている担当者の方に、まず使ってみてほしいからです。
目次
なぜ作ったのか——無料で測れる道具が、日本語圏に無かった
企画の前に、既にあるものを調べました。「無いから作る」と言うためには、まず無いことを確かめないといけません。2026年8月末に実際に調べた結果が以下です。
総務省の miChecker は無料。ただしMacで動かない
日本語圏でアクセシビリティ検査といえば、まず総務省の miChecker が挙がります。無料で、公的機関が出していて、JIS X 8341-3 に正面から対応しています。
ただし Windows専用で、64bit版のJavaが必要です。Macでは動きません。
制作現場を思い浮かべてください。Webデザイナーの多くはMacを使っています。 つまり、日本で一番よく使われている無料の検査ツールが、日本で一番よくサイトを作っている人たちの手元では起動しないのです。ここが最初の空白でした。
色覚シミュレーターは「画像アップロード」ばかりで、URLを入れられない
色の見え方をシミュレーションするツールは、日本語のものがいくつもあります。ただ、調べてみるとほぼすべてが画像アップロード方式かスマホのカメラ方式でした。
- ある日本語ツールは名前こそ「Webサイト色覚シミュレーター」ですが、中身を確認すると画像アップロードのみでした
- 定番のスマートフォンアプリは、カメラで実物を映すためのものです
- URL入力に対応した色覚ビューアーは、英語圏に1つだけ見つかりました。ただし提供者自身が「まだ開発中」と明記しており、方式が古いためJavaScriptで組み立てる今どきのサイトでは表示が崩れます
つまり「サイトのURLを入れたら、そのページが色弱の方にどう見えるか出る」という、いちばん素直な形が日本語では空いていました。
URLを入れて点数が出るものは、有料しかない
一方、URLを登録すると自動でクロールして100点満点のスコアを出すサービスは存在します。ただし価格帯がこうです。
| ツール | 料金 |
|---|---|
| ISSO® | 要問い合わせ |
| WAIV2 | 90日 55,000円／1年 110,000円／無期限 220,000円 |
| axe Monitor | 要問い合わせ |
| miChecker（総務省） | 無料。ただしWindows専用＋Java必須 |
年商1〜20億円の中小企業が「とりあえず自社サイトの現状を知りたい」というだけで、11万円を払うでしょうか。払いません。だから測らないまま、「対応しなきゃいけないらしい」という不安だけが残ります。
Chrome DevToolsは正確だが、非エンジニアには到達できない
正直に書くと、本当の競合はChrome DevToolsです。 ブラウザに標準で入っていて、無料で、色覚エミュレーションも正確です。
しかしこの機能に辿り着くには、F12キーを押し、開発者ツールを開き、コマンドメニューを呼び出し、Rendering パネルを表示し、Emulate vision deficiencies を選ぶ必要があります。この5ステップは、非エンジニアには存在しないのと同じです。 そして中小企業でサイトを見ているのは、たいてい非エンジニアの担当者です。
結論——空白は「機能」ではなく「組み合わせ」にあった
調べ終わって分かったのは、色覚シミュレーター単体でも、点数単体でも、既にあるということでした。無かったのは組み合わせのほうです。
その2つが、1画面・日本語・URL入力だけ・無料・Macでも動く
この形が見つかりませんでした。だから作りました。差別化が効く順に並べると、①Macで動く（miCheckerの最大の弱点）②インストール不要 ③絵と数字が並ぶ ④山形・福島の中小企業や旅館という顧客文脈、の4つです。
つなぐアクセシビリティで何ができるか
原寸・P型・D型・T型の4面比較
URLを入れると、そのページのスクリーンショットを4枚並べて表示します。原寸と、色覚特性の3タイプです。
- P型（1型） ——赤の感じ方が弱いタイプ。日本人男性のおよそ1.5%が該当します
- D型（2型） ——緑の感じ方が弱いタイプ。もっとも多く、男性のおよそ3.5%が該当します
- T型（3型） ——青と黄の区別がつきにくいタイプ。まれですが男女差がありません
用語は日本のカラーユニバーサルデザイン機構（CUDO）の呼び方に合わせました。「1型2色覚」のような学術表記ではなく、現場で通じる言い方を選んでいます。
この4面を初めて見ると、たいていの方が同じところで手が止まります。「セール中」の赤いバッジが背景に沈んで読めない、必須項目の赤いアスタリスクが消えている、赤と緑で色分けしたグラフが1色に見える——このあたりです。日本人男性の20人に1人がこう見えていると知っていても、実際に自分のサイトで見るまでは実感が湧きません。
JIS X 8341-3 のうち機械で判定できる範囲の点数と改善点
同じ画面の下に、検査結果が出ます。検査エンジンには axe-core 4.13.0 を使っています。世界的に標準的に使われている検査エンジンで、ライセンス（MPL-2.0）に従って同梱しています。
出るものは3つです。
- 点数（100点満点）と A〜E の等級
- 重大度の高い順に並んだ改善点の一覧
- 機械では判定しきれず、人の目での確認が要る項目
点数の付け方も公開しておきます。指摘1件につき、重大度に応じて減点します。重大なら12点、大きいなら8点、中くらいなら4点、小さいなら2点。同じ指摘が3箇所以上あれば1.2倍、10箇所以上なら1.5倍にします。規格の要求ではない推奨事項は重みを半分にし、「人の目で確認が要る」項目は減点しません。
等級は、90点以上がA、75点以上がB、50点以上がC、25点以上がD、それ未満がEです。
「誰が困るか」「どう直すか」を日本語で書いた
ここが、この道具でいちばん手間をかけた部分です。
検査エンジンの出力をそのまま日本語にすると、こうなります。
alt属性が存在しなければなりません
規格の言い回しとしては正しいのですが、誰が困るのか、何をすれば直るのかが一言も書かれていません。 これでは受け取った人は動けません。
そこで、よく出る74ルールについて「誰が困るか」と「どう直すか」を自分たちで書き下ろした辞書を用意しました。たとえば、こう出ます。
文字と背景の明暗の差が足りない
誰が困るか：高齢の方や弱視の方、屋外の明るい場所では読み取れません。
どう直すか：本文は背景との明暗の差（コントラスト比）を4.5:1以上、24px以上の大きな文字は3:1以上にします。薄いグレーの文字、写真の上に重ねた白抜き文字、淡い色のボタンでよく起きます。
もう1つ、僕が旅館のサイトを見ていて何度も出会った項目です。
スマートフォンで拡大できないように設定されている
誰が困るか：小さい文字が読みにくい方が、指で広げて拡大できません。
どう直すか：ページの先頭にある viewport の指定から user-scalable=no と maximum-scale=1 を外します。旅館・宿泊施設のサイトで非常によく見つかります。
「誰が困るか」はお客様に説明するための言葉、「どう直すか」は制作者に渡すための言葉として書き分けています。この2つが分かれていると、診断結果をそのまま社内会議に持ち込めます。辞書に無いルールは検査エンジン同梱の日本語に自動で落ちるので、日本語が出ないことはありません。
検査エンジンが拾わない5件を、自分たちで足した
axe-coreは優秀ですが、日本の中小企業サイトでよく困る型のうち、拾ってくれないものがあります。当社独自の観点として5つ足しました。
| 独自チェック | なぜ足したか |
|---|---|
| 「こちら」だけのリンク | 読み上げでリンクだけを拾うと「こちら」「こちら」「こちら」と並び、どこへ行くのか分からない |
| 中身のない代替テキスト | alt="image001" のような、書いてあるのに意味が無いもの |
| 12px未満の文字が3箇所以上 | 規格の違反ではないが、実際に読めない人が出る |
| PDFリンクにその断りがない | 押した先が突然PDFだと、読み上げ環境では行き止まりになりやすい |
| リンクになっていない電話番号 | スマートフォンからタップできず、番号を覚えて打ち直す必要がある |
規格の条文には無いけれど現場では困る、という項目です。これらは「当社独自の観点」と明示して、規格由来の指摘とは区別して表示しています。
御社のホームページ、色の見え方が違う人にどう見えていますか？
まずは無料ツールで測ってみてください。登録不要で、色弱の方への見え方と機械判定できる範囲の改善点を確認できます。
点数について、正直に書いておきたいこと
無料ツールの記事で自分の道具の限界を書くのは損に見えるかもしれません。でもここを曖昧にすると、この道具が誤った根拠に使われます。 結果画面にも同じ断り書きを必ず出しています。
この点数は当社独自の指数です。JIS X 8341-3:2016 は達成基準ごとの適合／不適合を定めており、点数という考え方は規格にありません。
機械で判定できるのは達成基準全体のおよそ3〜4割です。100点でも「JISに準拠している」ことにはなりません。
逆に、指摘された箇所が必ずしも問題とは限りません（前後の文脈で妥当な場合があります）。最終的な判断には人の目による確認が必要です。
3つとも大事なので、ひとつずつ補足します。
JISに「点数」という考え方は無い
JIS X 8341-3:2016（＝ISO/IEC 40500:2012＝WCAG 2.0と一致）が定めているのは、達成基準ごとの適合か不適合かであって、総合点ではありません。「うちは78点だからB」という言い方は規格には存在しないのです。
では、なぜ点数を出すのか。数字がないと、社内で話が始まらないからです。 「指摘が23件あります」だけでは経営者は動きません。「78点でB評価、重大な指摘が2件」だと会議の議題になります。だから点数は付ける。付けたうえで、それが当社独自の指数であることを毎回明記する。この両方をやります。
100点は「準拠の証明」ではない
これが一番誤解されやすいところです。アクセシビリティの達成基準には、機械では原理的に判定できないものが多くあります。
たとえば画像の代替テキストです。機械は「altが書いてあるか」までは判定できますが、「その説明が画像の内容に合っているか」は判定できません。風景写真に alt="写真" と書いてあれば、機械のチェックは通ります。しかし読み上げで聞いている方には何も伝わっていません。
見出しの階層、リンク文言の妥当性、動画の字幕の正確さ、操作の分かりやすさ——このあたりは全部、人が見るしかない領域です。だから機械で判定できるのは全体の3〜4割にとどまります。100点が出たら「機械で見える範囲では問題が見つからなかった」という意味であって、そこがスタート地点です。
指摘されたものが必ずしも問題とは限らない
逆方向の誤解もあります。検査結果を「全部直さないといけない宿題リスト」だと受け取ると、前後の文脈では妥当な箇所まで直しにいって、かえって使いにくくなります。
装飾目的の画像に説明文を足す、意味のない見出しレベルを揃えるためにデザインを崩す——こういう「機械を満足させるための修正」は本末転倒です。困っている人がいるかどうかで判断してください。
点数の設計で1つだけこだわったこと
減点を箇所の数ではなくルールの数で行う設計にしました。
理由があります。共通ヘッダーのボタン1つにコントラスト不足があると、その誤りは全ページに現れます。箇所の数で引くと、ページ数の多いサイトほど不当に低い点数になります。 しかし実態としては、CSSを1行直せば全部消える性質の誤りです。1つの直しで全部消えるものは、点数のうえでも1件として扱うのが実態に合っています。
ただし影響範囲の広さを無視するのも違うので、3箇所以上・10箇所以上で係数を掛ける形にしました。設計は「どちらが正しいか」ではなく「どちらが直す人の役に立つか」で決めています。
作る過程で迷ったところ
ここからは実装の話です。同じようなものを作ろうとしている方の役に立つかもしれないので、判断の理由まで書きます。
iframeでは作れなかった
最初に思いつくのは「入力されたURLをiframeで埋め込んで、その上にフィルタをかける」という方法です。これは2つの理由で成立しません。
1つ目。多くのサイトが X-Frame-Options や CSP の frame-ancestors で埋め込みを拒否しています。しかもWordPressのセキュリティプラグインはたいていこれを立てます。 つまり、いちばん診断してほしい層のサイトほど失敗するのです。
2つ目。仮に表示できても、別ドメインの中身はJavaScriptから読めません。中身が読めなければコントラスト比が計算できません。 見た目だけ変えて数字が出ないものになります。
結論として、サーバー側でヘッドレスブラウザを常駐させ、実際にページを開いて撮る方式にしました。
スクリーンショット機能が付いた瞬間、SSRFは「写真で持ち出す攻撃」に化ける
ここが設計上いちばん神経を使ったところです。
任意のURLを取りに行くサービスには、SSRF（サーバー側リクエスト強制） という古典的な弱点があります。攻撃者が http://127.0.0.1:8902/ のような内部アドレスを入力すると、サーバーが自分の内側にアクセスしてしまう、というものです。
通常のSSRFは「反応の違いから内部構成を推測する」攻撃です。ところがスクリーンショット機能があると、内部画面をそのまま撮って攻撃者に返してしまいます。 推測する攻撃が、写真で持ち出す攻撃に化けるわけです。
そこで、この道具は本番サーバーとは物理的に別のマシンで動かしています。 当社の顧客データが入っているサーバーには一切相乗りさせていません。そのうえで、
- ブラウザを動かす専用ユーザーを作り、そのユーザーからプライベートIP帯（127.0.0.1、10.x、192.168.x など9帯域）への通信をネットワーク層で遮断
- アプリ側でも、URLの正規化・名前解決後の私設IP判定・リダイレクトのたびの再検証（最大3ホップ）
- データベースを置かない（保存しないので必要がない）
という二段構えにしました。「入力を検証する」だけでは足りません。 検証をすり抜けたときに、ネットワークがもう一度止める形にしています。
ログイン機能をつけなかった理由
「メールアドレスを登録してもらえばリードが取れるのでは」という発想は当然あります。つけませんでした。理由は4つです。
- 摩擦がリード獲得を殺す。 登録画面が出た瞬間、9割の人が帰ります
- パスワード管理・漏洩対応・退会処理の重さが、無料ツールと釣り合わない
- メールで結果を受け取りたい人には、入力欄を1つ置けば足ります。それはログインではありません
- 無料メールアドレスで回避されるので、連打対策にもなりません
「保存なし・登録なし」は制約ではなく、この道具の性格そのものだと考えています。入力されたURLと取得した画像を恒久的に保存することはありません。画像は再表示のために最長10分だけ一時保存し、そのあと自動的に削除されます。この「自動的に削除」は文章上の約束ではなく、サーバー上で定期的に消す仕組みが実体としてあります。
連打対策の基準を「回数」ではなく「異なるドメイン数」にした
無料公開ツールには必ず、機械的に大量アクセスしてくる相手がいます。普通は「1時間に何回まで」で制限しますが、この基準には副作用があります。
同じサイトを何十回も調べている人は、直している最中の人です。 つまり将来のお客様です。回数だけで弾くと、いちばん大事な人を追い返します。
そこで主要な基準を「同一IPが1時間に叩いた、異なるドメインの数」にしました。同じサイトを繰り返すのは歓迎、違うサイトを次々に叩くのはスキャン、という切り分けです。回数の上限も併用していますが、キャッシュから返した分は消費しない形にしてあります。
色の変換は、閲覧者のブラウザ側でやっている
色覚シミュレーションの変換は、サーバーではなく閲覧者のブラウザで行っています。SVGのフィルタ機能を使い、サーバーはスクリーンショットを1枚返すだけです。画像の実体は1枚しか持たず、4面はそれを参照して別々のフィルタをかけて表示しています。おかげでビューアーを足したことによるサーバー負荷の増加は実質ゼロで済みました。
変換式には Brettel／Viénot の方式を使い、線形RGB空間で計算しています。 ここは細かいようで重要です。sRGBの値のまま単純な色フィルタを掛けると、それらしく見えるだけの、実際とは違う絵になります。 見え方を伝えるための道具が違う絵を見せていたら本末転倒なので、ここは手を抜きませんでした。
公開した翌日、誰も診断できていなかった
最後に、いちばん書きにくい話を書きます。
このツールは2026年9月8日に公開しました。公開前の検査はひととおり通していました。それでも翌日まで、誰ひとり診断を実行できていませんでした。
原因は、ボット対策（Cloudflare Turnstile）の設定に入れたキーの転記ミスです。24文字のキーに、Aを1文字多く書いていました。 そのせいで認証ウィジェットが描画されず、画面には対策サービスのエラー用リンクだけが表示されていました。当社の代表がそれをクリックして「反応しない」と言い出して、ようやく発覚しました。
問題はミスそのものより、なぜ公開前の検査で捕まらなかったかです。振り返ると、検査の中身がこうなっていました。
- ✅ トークンなしで送信したら拒否されることを確認した（間違った経路が止まることの確認）
- ❌ 正しい経路で診断が通ることは、一度も確認していなかった
さらに悪いことに、「ウィジェットが表示されている」という確認は、HTMLの中にそのdiv要素が1個あることを数えただけでした。要素があることと、それが描画されて操作できることは別です。
この2つを、検査の項目として仕組みに足しました。「拒否されること」だけを測っている検査は、検査ではありません。 動くはずの経路が実際に動くところまで測って、初めて検査です。同じ型のミスは、たぶん多くの現場で起きています。フォームの送信、決済の完了、会員登録——「エラーになる場合」のテストは書かれているのに、「成功する場合」を人が一度も通っていない、という形です。
使い方は3ステップ
- https://miekata.0797.jp を開く
- 調べたいページのURLを入れる（
https://は省略できます。トップページでも下層ページでもかまいません） - 「見え方を調べる」を押す
十数秒で、4面比較と点数と改善点が出ます。会員ページなどログインが必要なページは調べられません。また、自動アクセスを拒否しているサイトは取得できないことがあります。
他人が管理するサイトを無断で調べる用途には使わないでください。 自社サイト、自分が制作を担当しているサイト、あるいは許可を得たサイトでお使いいただく前提の道具です。
診断のあと、どこまでを自分でやるか
無料ツールで測ったあと、進み方は3つに分かれます。
その1：自分で直す。 出てきた改善点のうち、コントラスト比の調整、alt属性の追加、viewportの指定を外すあたりは、CSSとHTMLが触れる方なら自分で直せます。この記事を読んでいるWebデザイナーの方なら、たぶん半日仕事です。まずはここまで自力でやってみてください。 そのために「どう直すか」を全部日本語で書いてあります。
その2：人手の診断を依頼する。 機械で測れるのは3〜4割なので、残りは人が見るしかありません。市場の相場は、簡易診断（ツール中心）で10ページ5万〜20万円、手動診断で20万〜30万円、改善込みだと40万円〜というあたりです。当社もこの帯で承っています。
その3：直したあと、崩れないようにする。 アクセシビリティ対応でいちばんもったいないのは、一度直したのにテーマ更新やページ追加で元に戻ってしまうことです。当社のつなぐWPガーディアンは、WordPressサイトのセキュリティと稼働を継続監視するサービスですが、ここに検査項目を足していく設計にしています。
無料ツールを商品にするつもりはありません。道具は入口で、商品はその下流にあります。 だから真似されても困りませんし、むしろ使い倒してもらったほうがいい。この記事を書いている理由もそこにあります。
まとめ
- 2024年4月の法改正以降、アクセシビリティ対応の必要性は共有されたのに、測る道具が手に入りにくい状態が続いています
- 総務省のmiCheckerは無料ですがWindows専用、URL入力で点数が出るサービスは11万円〜、色覚シミュレーターは画像アップロード方式ばかりでした
- つなぐアクセシビリティは、URLを1つ入れるだけで「色弱の方への見え方（P型・D型・T型）」と「JIS X 8341-3のうち機械判定できる範囲の点数・改善点」を1画面に出します。無料・登録不要・Macでも動きます
- 改善点は「誰が困るか」「どう直すか」の2つに書き分けた日本語で出ます。74ルール分を書き下ろしました
- 点数は当社独自の指数であって、JIS準拠の証明ではありません。 機械で判定できるのは達成基準の3〜4割です
- 設計上いちばん気をつけたのは、スクリーンショット機能とSSRFの組み合わせです。本番サーバーとは物理的に別のマシンで動かしています
- 公開翌日に「誰も診断できていない」不具合が見つかりました。原因は「拒否されること」しか検査していなかったことです
まずは自社サイトのURLを入れてみてください。20人に1人の男性がどう見ているか、たぶん想像とは違うはずです。
関連記事
アクセシビリティ改善の優先順位を整理しませんか？
無料ツールの結果を踏まえ、どこから直すべきかを一緒に整理します。まずはお気軽にご相談ください。
著者：島田慶資（ハンズバリュー株式会社 代表取締役／ITコーディネータ）