事前準備
HTMLをアップロードしてURLを発行したら、まずシークレットウィンドウで開いてログインなしで表示されることを確認します。次に実機のスマホブラウザでも同じURLを開き、タッチ操作でページ全体をスクロールしたときにフォントや画像が崩れないかを目視します。この2ステップを送付前に必ず行うことで、「開けない」「崩れている」という単純なクレームを未然に防げます。
共有前にHTMLソースを確認し、開発者のローカル環境パスや内部APIのエンドポイント、個人情報を含むサンプルデータが残っていないかを検索します。アクセシビリティレビュー担当者はソースを開いて調査することが多いため、不要な内部情報はレビュー前に除去しておかないと情報漏洩リスクになります。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
確認観点
HTMLに含まれる外部scriptやiframeがアクセシビリティに悪影響を与えていないか確認します。特に第三者が提供するチャットウィジェットや広告タグは、フォーカス順序を乱したりARIAライブリージョンを汚染したりすることがあります。レビュー版では不要な外部タグを除いてシンプルな状態にするか、影響範囲を担当者に事前に説明してください。
画像・CSS・JSのパスが公開環境で正しく解決されているかを確認し、アイコンや装飾画像のalt属性（空altか意味のあるaltかの判断）もあわせてリストアップしておきます。noindexと認証は別の概念であり混同しないよう、検索除外が必要であればnoindexを、閲覧制限が必要であれば認証を、それぞれ独立して設定してください。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
NG例
よくあるNGはARIAロールを付けただけで、実際の操作では意図どおりに動かないケースです。たとえば role='button' を付与したdivが、キーボードのEnterキーで発火しない実装は多くのレビューで指摘されます。HTMLを共有する前に、Tabキーでインタラクティブ要素をすべて移動できるか、各要素がEnter/Spaceで起動するかを自分で確認してから送付しましょう。
もう一つのNGは、本番環境のアセットURLをハードコードしたままレビュー版を送るケースです。本番CDNのCORSポリシーやHSTSが影響して、レビュー環境では画像が表示されないことがあります。アセットは相対パスで参照するか、レビュー用の同一オリジンに含めて配置すると問題を回避できます。
修正後の再共有
修正後のHTMLを差し替えアップロードしたら、変更点を「指摘No.と修正内容」の形で箇条書きにしてレビュー担当者へ送ります。アクセシビリティ修正は往々にして複数箇所に波及するため、aria-labelの修正がナビゲーション全体に影響したといった副作用も含めて報告すると再確認の方針が立てやすくなります。
再共有のタイミングで旧URLが有効かどうかを確認し、有効であれば期限を短縮して担当者に新URLのみを案内します。新旧が混在すると担当者がどちらのURLを確認すればよいか迷うため、再共有メールには「旧URLは無効化しました」の一文を必ず添えてください。
よくある質問
CSSのみで実装したカラーオーバーレイのコントラスト比はどのように確認するのが正確ですか？
ブラウザの開発者ツールでcomputed styleから実際の色値を取得し、WebAIM Contrast Checkerなどのツールに入力して計算します。スクリーンショットから目視で判断するのは精度が低く推奨できません。
アクセシビリティレビューを外注する場合、どの範囲のHTMLを共有すればよいですか？
依頼する機能・画面を網羅する最小のHTMLセットを共有します。関係のないページを含めると工数が増えるため、レビュー対象ページのURLをリスト化して渡すのが効率的です。
モーダルダイアログのフォーカストラップはレビュー前に自分でテストできますか？
TabキーとShift+Tabキーでモーダル内外のフォーカスが行き来しないことを実機で確認できます。スクリーンリーダーを使った確認は専門担当者に委ねるのが現実的です。