1. レイアウトを選ぶ前にページの役割を決める
顧客やビジネスのタスクを担うページから始める：サービスページ、商品ページ、リードフォーム、予約、アカウント入力、カート、ヘルプ等。各ページについて「完了（completion）」の一文を作る。例：「初めての訪問者がこのサービスを理解し、関連する証拠を見て、電話を依頼できる」。ページに複数の役割がある場合は、どれを最初に見せるかを決める。
コンテンツを重要（essential）、補助（supporting）、任意（optional）に分類する。重要＝簡潔である必要はない：価格の文脈、適格性、配送詳細、比較情報などが必要なことがある。そうした資料には狭いレイアウトでも明確な導線を用意する。Googleはモバイルとデスクトップで同等の主要コンテンツを推奨し、タブやアコーディオンなど異なる提示は許容している。
狭い幅で、同僚がページが何を提供し、誰を助け、次の意味あるアクションは何かを言えること。
2. 狭い画面のベースラインを完結させる
デスクトップレイアウトを縮小するのではなく、動作する一列（シングルカラム）経路から始める。柔軟なコンテナを使い、テキストを折り返し、ブラウザがデバイス幅に合わせてレイアウトを調整できるように viewport 設定を含める。ズームを妨げない。メニュー、通知、画像、埋め込み、フォームエラーがビューポート内に収まることを確認する。意図しないページレベルの横スクロールは通常欠陥である。
読書やタスクの通常コンテンツの厳しい再フローチェックとして 320 CSS ピクセルを使う。WCAG 2.2 は、その幅で垂直コンテンツを情報や機能の損失、二次元スクロールなしに提示することを述べている。地図、チャート、データ表は独立したスクロール領域を必要とすることがあるが、それは周囲のページを横にスクロールさせてよい理由にはならない。
画像はコンテナに合わせ、ブラウザが読み込み前にスペースを予約できるように寸法を提供する。
3. ベース経路を脆弱にしないで拡張を加える
プログレッシブエンハンスメントとは、基本的なコンテンツと機能がベースラインとして動作し、能力のあるブラウザや大きな画面にのみ追加機能を与えることを意味する。住所、商品詳細、フォームのラベル、価格説明、送信経路がアニメーション、ホバー、後から読み込まれるスクリプトに依存してはならない。広いレイアウトは比較パネル、恒常的なナビゲーション、より豊富なフィルタリングを追加できるが、それでベースラインが不完全にならないようにする。
実装者に対しては、特定のデバイス名ではなくコンテンツが窮屈または無駄に見える地点でブレークポイントを追加するよう依頼する。ブレークポイントは単にレイアウト規則が変わる場所に過ぎない。狭いレイアウトでヘルプ文、ポリシー条項、レビュー、メタデータ、重要な構造化情報をひそかに削除してはいけない。
まず基本的なギャラリー画像と説明を表示し、スクリプトが利用可能になったらズームやスワイプ操作を追加する。
4. タッチ、明瞭さ、回復を考えたコントロール設計
タッチの人間工学は精密なマウスポインタではなく手で操作することを前提に設計することを意味する。ボタン、チェックボックス、閉じるアイコン、数量セレクタ、フォーム選択肢に誤タップを減らす十分なサイズと間隔を与える。意味が分かりにくいアイコンにはラベルを付ける。価格、サブメニュー、説明、アクションを表示する唯一の方法としてホバーを使ってはいけない。
WCAG 2.2 にはポインターターゲットに対する Level AA のターゲットサイズ基準として少なくとも 24×24 CSS ピクセルが含まれており、間隔やインラインリンクなどの例外が記載されている。それを最低の参照値として扱い、快適性の保証とは考えない。重要な操作はわかりやすいラベル、十分な間隔、取り消し可能な確認ステップを持つべきである。ハイリスクなジャーニーや正式な適合主張には、資格を持つアクセシビリティレビューを求める。
ラベルを表示したままにし、使える検証フィードバックを示し、エラー後に入力値が保持されること。
5. メディアと埋め込みを訪問者ジャーニーの一部として扱う
各画像が情報的（informative）、説得的（persuasive）、装飾的（decorative）のどれに当たるかを決める。情報的な画像は適切な代替テキストと、必要なディテールを保持する狭いレイアウト用のクロップを必要とする。レスポンシブ画像の選択肢を使えば、ブラウザが適切なリソースを選べるため、すべての訪問者に最大のデスクトップ資産をダウンロードさせる必要はない。ヒーロー画像やビデオがページ目的や主要アクションを覆い隠してはいけない。
地図、チャット、ビデオ、決済、スケジューリング、同意（consent）、レビューウィジェットを棚卸する。狭い画面ではそれらの読み込み状態、コントロールサイズ、境界を持つレイアウト、実用的なフォールバック経路を確認する。決済、本人確認、または規制対象データフローについては、資格を持つセキュリティ、プライバシー、コンプライアンスのレビュアーを関与させること。視覚的テストはセキュリティ評価の代わりにはならない。
各外部コンポーネント、その所有者、ビジネス機能、遅延または故障時の承認済みフォールバックを記録する。
6. リリース前にタスク経路をテストし、修復を計画する
ブラウザのレスポンシブモードを早期に使い、狭い幅・中間幅・広い幅を点検する。Chrome の Device Mode はビューポート、タッチ、向き、ネットワーク、CPU 条件を近似できるが、Chrome 自体が実際のデバイス実行の代替ではなく近似であると明記している。可能な限り重要な経路は実際の電話機と該当ブラウザで完了させる。
スクリーンショットだけでなくタスクをテストする：コールドロード、ナビゲーション、無効・有効なフォーム送信、向きの変更、ズーム、サードパーティ画面からの戻り。URL、ブラウザまたはデバイス、タスク、期待結果、担当者、ロールバック方針を記録する。主要なテンプレート、チェックアウト、CMS、依存関係の変更については、リリースをステージングし、圧力下で即興で対応するのではなく前の経路を復元できる準備をする。
重要なタスクが動作し、コントロールが使いやすく、ページレベルの横スクロールがなく、主要依存にフォールバックがある場合にのみ承認する。