AI検索最適化のためのSEO・アクセシビリティ点検と回答検証
AI検索が文書を見つけて回答を作成する仕組みを踏まえ、SEOとウェブアクセシビリティの役割を説明します。架空の料金案内ページをもとに、クロール経路と情報の正確性を確認し、チェックリストとLLMによるレビューをCMS運用に取り入れる方法を見ていきます。
タグ
6件の記事
AI検索が文書を見つけて回答を作成する仕組みを踏まえ、SEOとウェブアクセシビリティの役割を説明します。架空の料金案内ページをもとに、クロール経路と情報の正確性を確認し、チェックリストとLLMによるレビューをCMS運用に取り入れる方法を見ていきます。
横方向の基準合格が縦方向の読みやすさまで保証しないことを、実測の数字で確かめた。損失が画面の高さに応じて減らない絶対値であることを軸に、その正体を一つずつ分解した。
role="dialog"とaria-modal="true"を備えた「正しく見える」モーダルで、Tabを3回押すとフォーカスがオーバーレイの裏へ抜けた。axeの違反は0件。同じマークアップをaria-hidden、inertに切り替えながら、キーボードフォーカスが実際にどこへ落ちるかを記録した。
指先が滑る22×22のボタンに、Lighthouseはアクセシビリティ92点を出した。WCAG 2.2が新設したSC 2.5.8(最小24×24)をサンドボックスに仕込み、自作スクリプトとLighthouseで二度測った。自動ツールはサイズ違反こそ捕まえるが、例外判定は人間に丸投げする。24pxの円が重なるかを計算するスペーシング例外まで、実測ログとCSS修正で整理する。
チェックアウトページ一枚にWCAG違反を八つわざと埋め込み、axe-coreで走らせた。ルール型の四つは捕まったが、人間の判断が要る四つは緑の裏にそのまま残った。自動化が構造的に見られないものと、その穴を埋める手動レビューのチェックリストを、実測ログとともにまとめる。
ボタンにaria-labelを付けたのに、アクセシビリティツリーは画面に出ていない文字を読んでいる。WCAG 2.5.3 Label in Nameの違反をサンドボックスで再現してツリーで確認し、Lighthouse 13.3.0の新カテゴリAgentic Browsingで0点が100点に変わる過程を実測した。