カバレッジを顧客タスクを中心に組み立てる
価値を生むルートと成果を列挙する：サービスの発見、検索、アイテム追加、予約、サインイン、ヘルプ要請、支払いなど。各ルートについて形が変わったり壊れやすいコンポーネントを特定する：ナビゲーション、フィルター、カード、表、画像、バナー、フォーム、ドロワー、埋め込みウィジェットなど。テストは現在の端末モデルのカタログ化ではなく、コンテンツが制約を受け始める幅で行う。各ブレークポイントの直前、該当点、直後をテストする。
狭幅と中幅のスマホ、タブレットに近い幅、ラップトップ、広いデスクトップ、そしてタスクが変わる場合は横向きも含める。
長いタイトル、空の結果、バリデーションエラー、価格バッジ、完全な住所、長いラベルなど、実際に存在する状態で確認する。
リフロー、可読性、ズームを証明する
ページに適切な viewport 設定があることを確認し、ページレベルの横スクロールを探す。固定画像、幅の広いフィールド、負のマージン、オフキャンバスパネル、バナーがよく原因になる。W3CのWCAG 2.1 Reflow基準は、320 CSSピクセル相当の幅で縦スクロールのみになることを記述しており、400%ズーム時に1280ピクセルのビューポートを含む。もしその基準が対象なら、実際のズームシナリオでテストする。地図、動画、データ表は二次元レイアウトを必要とする場合があるが、そのスクロールはコンポーネント内に収め、周囲のページはリフローさせること。
ヘッダー、メインコンテンツ、フッター、スティッキーバー、ダイアログ、エラー要約を、テストするすべての境界で確認する。
狭い画面向けに情報を再構成しても、要件、価格の詳細、ヘルプ経路を黙って削除しないこと。
コンテンツとフォームに負荷をかける
コンテンツの運用はCSSリリースなしでもレスポンシブの失敗を引き起こす。最長の承認済見出し、複数のバッジ、欠如した画像、選択されたフィルター、大きな法的表示、ブラウザが自動入力したフィールドをテストする。カラムが積み重なる場合、読み順とキーボード順が論理的であることを確認する。実機の小さなデバイスで実際のフォームを完了する：コントロールを開き、エラーを修正し、送信する。サードパーティウィジェットはコンテナ、同意状態、フォント、スタイルで結果が変わるため、本番に近いページでテストする。
可能性のある最大長や組み合わせを反映するが、QA証拠に顧客や支払いデータを含めないこと。
通知、チャット、プロモーション、バリデーションメッセージを同時に開き、主要アクションやフォーカスされたフィールドを覆わないこと。
すべての入力経路を実行する
大画面だからマウスがあるとは限らず、小画面だからタッチだけとは限らない。hover（ホバー）メディア機能は主要入力がホバー可能かを判定するため、ホバーは説明やアクションの手段を強化するに留め、唯一のルートにしてはならない。デスクトップでのキーボードとポインタ操作、タッチ機器でのタップとスクロール、混在入力の機器をテストする。コンパクトなクローズボタン、ステッパー、チップ、カレンダー、アイコンアクションを確認する。WCAG 2.2 Target Size (Minimum) は24×24 CSSピクセルのターゲットサイズを規定し、間隔やインラインリンクなどの例外を定めている。これはすべての人に同じように簡単だと保証するものではなく、対象範囲と例外を持つ基準である。
ページをTabで移動する。フォーカスは見やすく、合理的な順序を保ち、メニューやダイアログへの出入りが予測可能であること。
必須のホバーによる表示はフォーカス、タップ、または目に見えるコントロールで代替できるようにし、初回タップで混乱する挙動を防ぐ。
制約下でのアセットとパフォーマンスを検証する
画像がコンテナに収まっていても、機器に対して適切なファイルでないことがある。メディアがコンテナ内に留まり、必要ならレイアウト空間を予約し、有用なトリミングを保ち、適切な候補を要求しているかを確認する。srcset と sizes はブラウザが与えられた画像ソースから選ぶための情報を提供するが、特定のリクエストを保証するものではない。DevTools のスロットリングは問題を早期に明らかにするが、CPU とネットワークの制御は開発用マシンに対する相対シミュレーションである。キーとなる経路は実機と実接続で再確認する。フォント、ヒーローメディア、カルーセル、クライアント側の作業、サードパーティスクリプトが遅延、レイアウトシフト、タップのブロックを引き起こしていないか検査する。
ルート、ビューポート、実機かシミュレーションかの接続条件、遅くまたは不安定になった要素を記録し、同等条件で比較する。
安全な範囲で非必須の埋め込みをテストビルドで遅延させ、コアタスクが使えるままであるかを確認する。
プロアクティブな稼働性（uptime）作業として是正する
Status Is UP の観点では、レスポンシブ準備はプロアクティブな稼働最適化である：ユーザーブロッキングな機器経路を特定し、その原因を修正し、修復を証明し、再発を防ぐ。それはモニタリングアラートがあらゆるレイアウトやインタラクション欠陥を評価できるという主張ではない。タスクの影響度と到達度で優先順位付けする。デプロイ前に隣接する幅や変更された経路を実機でテストする。共有ナビゲーション、スタイル、スクリプト、支払い、統合に変更がある場合はロールバック計画を立てる。リリース後は証明手順を繰り返し、証拠を変更記録に添付する。
ルート、デバイスまたはビューポート、向き、入力、状態、期待結果、実際の結果、編集済みのキャプチャを明記する。
ルート単独の回避策ではなく、コンポーネント、レイアウトルール、トークン、画像配信の修正を優先する。例外にはオーナーと削除計画を与える。