悩み：「うちのサイト、アクセシビリティ大丈夫ですか？」に即答できない
ここ1年くらいで、納品後のクライアントから聞かれる質問が変わってきた。
「スマホでも見やすくしてください」ではなく、「うちのサイトってアクセシビリティ的に問題ないですか？」と、ストレートに聞かれることが増えた。障害者差別解消法の改正で事業者の合理的配慮提供が義務化された流れを受けて、発注側にも「対応しておかないとまずいらしい」という空気が広がっている。
正直に言うと、今まで「アクセシビリティ」は自分の中で優先順位が低かった。alt属性は一応つける、コントラストも極端に低くはしない、くらいの感覚でやってきた。でもいざ「診断してほしい」と言われると、何をどこまで見ればいいのか自分でも曖昧だった。
一人で全ページを手作業でチェックするのは現実的に無理な工数なので、AIを使ったアクセシビリティチェックツールに一次診断を任せられないか試してみた。
結論を先に言うと、AIチェックツールは「機械的に判定できる不備」を洗い出すのは驚くほど速いが、「実際に視覚障害のある人がそのサイトを使えるか」という体験レベルの判断は、結局スクリーンリーダーでの実機確認をしないと分からなかった。AIは一次スクリーニング役、最終判断は人力、という二段構えが今のところの現実的な落とし所だ。
TOI
「対応済み」と言うにはどこまでやればいいのか、実は誰も明確な線を教えてくれないんですよね……
なぜ今アクセシビリティが「無視できない話」になったか
細かい法解釈はここでは触れないが、ざっくり言うと以下のような流れがある。
- 事業者による合理的配慮の提供が義務化され、Webサイトも対象になり得る
- 官公庁・自治体の案件では、アクセシビリティ対応がすでに仕様書に明記されることが増えている
- 民間企業でも「うちは大丈夫か」と気にする発注担当者が増えてきた
つまり、これまでは「余裕があればやる」だった項目が、「聞かれたら答えられないとまずい」項目に変わりつつある。法律の話を持ち出さなくても、クライアントから直接聞かれる頻度が上がっている時点で、対応済みか説明できる状態にしておく必要があるということだ。
実際にAIチェックツールで診断してみた
使ったツール
無料で試せる範囲で、ブラウザ拡張機能の「axe DevTools」（AIによる自動チェックと補助機能つき）と、Chrome標準の「Lighthouse」アクセシビリティ監査の2つを使った。どちらもインストール不要かChromeに標準搭載されているので、非エンジニアでも手順さえ分かれば再現できる。
手順はシンプルで、
- 診断したいページをChromeで開く
- デベロッパーツール（F12キー）を開き、「Lighthouse」タブでAccessibilityのみチェックを入れて実行
- axe DevToolsを導入している場合は同じくデベロッパーツール内の「axe DevTools」タブで「Scan All of My Page」を実行
- 出てきたレポートの「Issues」を上から確認する
これだけで、実際に自社の制作実績サイト数ページと、許可を得たクライアントサイト1件で試してみた。
AIが一瞬で見つけたこと
正直、検出スピードには驚いた。1ページあたり数秒で、以下のような項目がリストアップされる。
- 画像のalt属性が空、または未設定
- 見出し（h1〜h6）の階層が飛んでいる（h2の次がいきなりh4になっている等）
- テキストと背景色のコントラスト比が基準（WCAG AA基準の4.5:1など）を下回っている
- フォームの入力欄にlabelが関連付けられていない
- リンクテキストが「こちら」「詳しくはこちら」だけで、リンク先が推測できない
これらは全部コードやCSSを見れば機械的に判定できる項目で、実際AIツールの指摘は的確だった。手作業でこれを1ページずつ目視チェックしていたら、1サイトで半日仕事になっていたと思う。それが数分で終わる。
AIが拾えなかったこと
一方で、実際にMacの読み上げ機能「VoiceOver」を有効にして、キーボードだけでサイトを操作してみたら、AIチェックでは「問題なし」判定だった箇所でいくつも引っかかった。
- タブキーでのフォーカス移動順序が、視覚的なレイアウトと合っていない（右側のナビゲーションに先に飛んでしまう等）
- モーダルウィンドウを開いたあと、フォーカスがモーダル内に移らず、背景のコンテンツを読み上げ続けてしまう
- パンくずリストがマークアップ上は正しくても、読み上げ順序だと「今どのページにいるか」が分かりにくい
これらはコードの静的な構造をチェックするだけでは検出できず、実際に「使う」体験を再現しないと分からない不備だった。AIツールのレポート上は緑色（問題なし）でも、実機で触ると引っかかる箇所があるという事実は、思っていた以上に多かった。
TOI
「レポートが緑だから安心」と思ってクライアントに報告しなくてよかった……危なかった。
結局どこまでAIに任せていいか：パターン別に整理する
これは相手が誰か、何を求められているかで答えが変わる。自分なりに以下のように切り分けている。
「うちのサイト大丈夫？」と軽く聞かれた程度の中小企業クライアントの場合
AIチェックツールでの一次診断結果をベースに、明らかな不備（alt属性・コントラスト比など）だけ直せば十分なことが多い。ここに何十時間もかけるのは費用対効果が合わない。
官公庁・自治体案件など、仕様書にアクセシビリティ対応が明記されている場合
AIチェックはあくまで一次スクリーニングとして使い、そのあと必ずキーボード操作とスクリーンリーダーでの実機確認を行う。JIS X 8341-3などの規格に沿った達成基準チェックリストと突き合わせる作業は、結局人力でやるしかない。
「アクセシビリティ対応済み」と対外的に明言したい場合
AIツールのレポートだけを根拠にするのは危険。第三者機関の診断や専門家のレビューを別途検討すべきラインだと考えている。
この3パターンのどこに自分の案件が当てはまるかを最初に見極めることで、「全部AIに任せて安心」でも「全部人力でやって工数が爆発」でもない、現実的な落とし所が見えてくる。
まとめ
- AIアクセシビリティチェックツール（axe DevTools・Lighthouse等）は、alt属性・コントラスト比・見出し構造などの機械的に判定できる不備を数分で洗い出せる
- 一方で、フォーカス移動順序やモーダルの挙動など「実際に使う体験」に関わる不備は、AIチェックでは検出できず、スクリーンリーダー等での実機確認が必要
- 対応レベルはクライアントの要求水準によって変わるため、「軽い確認」「仕様書対応」「対外公言」の3パターンで工数の配分を分けるのが現実的
- 次のアクションとしては、まず自社の制作実績サイトでaxe DevToolsを試し、指摘される不備のパターンに慣れておくと、実案件での一次診断がスムーズになる
コメント