納品時に行うこと

2つの納品

このページで扱う納品には2つのものがあります。

プルリクエスト（以下、PR）またはmainブランチへのマージ
クライアントへの納品ファイル提出、または本番環境へのデプロイ

1と2の相違点は、1には「まだこのあと対応するものがある」という部分のみです。制作チーム内での納品もクライアントへの納品とクオリティに差が無いようにしてください。

静的テストは必ずパスする（合格させる）

ソースコードは静的テスト（lint、type check）をパスさせてください。また、静的テストはGitHubリポジトリ内で共有し、誰が対応しても同一の内容で実行できるようにします。
スターターキットとしてmonosus/lint-toolsを推奨します。lint-toolsに頼らずプロジェクト内で各種静的テストを設置するのでも構いません。最も重要なことは制作サイクルに自動的な静的テストが組み込まれていることです。

メディアやアセットの容量を確認する

ビルドステップを通して最終的にサーバーからブラウザへ配信されるファイルが不必要に大きすぎないか確認します。画像の圧縮のプロセスを導入している場合はちゃんと機能しているか確認しましょう。

「〇〇Kib以下」などの指標を設けることよりも、圧縮プロセスの一貫性を重要視してください。
PRのたびに段階的に確認する習慣をつけておくと突然容量が増えた場合に対処すべきかの判断ができます。

一度も容量を確認しない場合、ファイル容量の肥大化に気づくことはできません。

実機ブラウザで可能な限り確認する

mainブランチに取り込んでから、対象に対して「xxページ Safari対応」などのfix issueが発生するのは非効率です。少なくとも開発端末で複数ブラウザ、持っていれば、モバイルデバイス1つ程度は確認してください。

当然クライアントへの納品時は検証ブラウザすべてでの目視確認を実施します。

テキストサイズの拡大と画面サイズの拡大の両方で確認する

ブラウザの設定からテキストサイズを最大まで拡大した場合と、画面拡大（cmdと+、ctrlと+）で200%程度まで拡大した場合に横スクロールや、クリック領域に他のコンテンツがかかるなどといったことが起きていないか確認します。

アクセシビリティの機械テストを行う

Google Chromeのaxe拡張機能などでチェックします。アクセシブルなウェブサイトを制作することはオプションではなく非機能要件です。コーディングフェーズで修正が難しいもの（例：デザイン通りのコントラスト比がWCAGの閾値以下となっている）は、後述する気になるもののリストアップに含めましょう。

参考

キーボード操作を行う

アンカー要素とインタラクション要素にキーボードのみで到達可能か、操作可能か確認します。

マウスオーバーによって開閉するUIを実装している場合、キーボードのみの操作でも同様の情報やナビゲーションを得られるか確認してください。

基本はTabキーを使用して確認します。そのほかは以下も確認してください。

Tab UI → 矢印キーなどでも操作可能か
モーダル → フォーカストラップされているか、Escキーでモードレスへ戻ることができるか、モーダル→モードレス時に合理的なフォーカス位置に戻っているか（慣例としてモーダルを開いたボタン、またはモードレス時の次のフォーカス要素にフォーカスするべきです）
ポップアップ → Escキーで離脱可能か、ポップアップを閉じた際に合理的なフォーカス位置となっているか（モーダルと同様）

スクリーンリーダーで操作する

コンポーネントなど複数箇所で使用するものであればできるだけ確認してください。
OSに標準搭載されているもので構いません。一つのデバイスでよいのでスクリーンリーダーを使用して、制作した部分がスクリーンリーダーのみで閲覧可能・操作可能（を理解できる）状態か確認します。

観点は以下です。

冗長な読み上げがないか（例:「メインナビゲーションナビゲーション」など）
クリック可能であることや開閉状態が取得可能か
ランドマークが適切か

操作方法については、使用するスクリーンリーダー名＋チートシートなどで検索してみましょう。

気になる部分をリストアップし共有する

デザインやクライアントの要求が全てではありません。「使いづらい」、「分かりづらい」ものがあれば制作チーム内やクライアントへ確認を取ります。時間的/予算的な制約で対応がされなかったとしても共有することは有益です。
とはいえ、相手に闇雲なダメ出しと受け止められることはあまり有意義でないので、

リストアップして集約することが大切です
- 全部で8個のリストを1回提出した場合にすべて対応できるかもしれません。同じことを8回チャットでコミュニケーションする場合、全てに対応しないことへ繋がるかもしれません
コーディングだけで修正できるものかを伝えます
ユーザー視点に立つ。プロダクトをより良くするための指摘であることがわかるようにします

などを意識しましょう。コーディングはウェブ制作の中心となる業務です。そこで見つかった気になる部分はプロダクトをより良くするための共有事項になるため、クライアントへ伝えることは大切です。