第12章 フロントエンドとアクセシビリティ

Slide 01. フロントエンドとアクセシビリティ

第12章では、第11章で設計したAPIを、利用者が実際に触れる画面へ変えていきます。ここで扱うフロントエンドは、見た目を整えるだけの作業ではありません。一覧を見る、絞り込む、入力する、保存する、失敗したときに理由が分かる、キーボードでも操作できる。そうした使いやすさまで含めて、画面の基本品質として確認します。

Slide 02. この章で持ち帰ること

この章で持ち帰ってほしいのは、APIの約束ごとを、画面に必要なことへ置き換える考え方です。APIが返す項目をそのまま並べるのではなく、利用者が何を見て、何を操作し、今どんな状態なのかを分かるようにします。画面要件、状態、構造、実装メモ、確認ログまで残せると、次のテスト設計にもつながります。

Slide 03. 第7章、第11章との接続

第7章では、ブラウザで画面を開くとHTTP通信が起きることを見ました。第11章では、支援ステータス機能のAPI契約を書きました。第12章では、そのAPIを画面から呼び出します。Networkタブで見たrequest、つまり送った内容と、response、つまり返ってきた内容を、一覧、フォーム、エラー表示へつなげる章です。

Slide 04. フロントエンドの役割

フロントエンドの役割は、データを画面に出すことだけではありません。利用者が何を見ればよいか、どの操作をすればよいか、保存中なのか、失敗したのか、次に何を直せばよいのかを伝えます。バックエンドやデータベースが正しくても、画面で迷うなら利用者には価値が届きにくくなります。

Slide 05. アクセシビリティを基本品質に入れる

アクセシビリティは、最後に余裕があれば足す特別対応ではありません。ラベルがある、キーボードで操作できる、フォーカスの位置が分かる、エラーが色だけでなく言葉でも伝わる。こうした確認は、その画面を無理なく使えるかを確かめる基本です。ここでは専門規格を全部覚えるより、実装時にまず見る入口に絞ります。

Slide 06. API契約から画面要件へ

第11章のAPI契約は、画面要件を考える材料になります。たとえば担当受講者一覧を取得するAPIと、支援ステータスを更新するAPIがあるなら、画面には一覧、絞り込み、更新フォーム、保存結果、エラー表示が必要になります。APIを呼ぶだけでなく、利用者が画面で何をするかへ置き換えるのがポイントです。

Slide 07. 画面に必要な情報

画面に必要な情報は、APIの項目名だけで決めません。支援ステータス画面なら、受講者名、今の状態、支援メモ、更新日時が候補になります。ここで大事なのは、なぜその情報を見せるのかです。メンターが次の声かけを判断するために必要な情報を、優先度をつけて選びます。

Slide 08. 画面に必要な操作

次に、画面に置く操作を決めます。支援ステータスで絞り込む。受講者ごとに状態を変更する。支援メモを更新する。保存する。操作を増やしすぎると利用者は迷いやすくなります。主操作は何か、今回は対象外にする操作は何かを分けると、実装範囲もレビュー範囲もはっきりします。

Slide 09. HTMLは意味で選ぶ

HTMLは、見た目ではなく意味で選びます。ページの主見出しならh1、絞り込みならlabelとselect、一覧を表で見せたいならtable、状態を変更するならformやbuttonを使います。クリックできれば何でもdivでよい、とは考えません。意味が合っていると、アクセシビリティ、テスト、保守もしやすくなります。

Slide 10. CSSは情報を読みやすくする

CSSは、飾りだけのものではありません。余白、配置、文字サイズ、境界線、状態の見せ方を使って、情報のまとまりと優先度を伝えます。支援ステータス画面なら、受講者名、状態、メモ、更新日時、保存ボタンのどれが目立つべきかを考えます。読みやすさは、利用者が正しく操作するための土台です。

Slide 11. 色だけに依存しない

状態を色だけで伝えると、見落としや誤解が起きやすくなります。要支援を赤くするだけではなく、「要支援」というテキストやアイコン、補足文も一緒に使います。入力エラーも、枠を赤くするだけでなく、何を直せばよいかを言葉で出します。色は手がかりの一つであって、唯一の情報にしません。

Slide 12. 画面状態を設計する

画面は、いつも正常にデータを持っているわけではありません。読み込み中、0件、取得失敗、編集中、保存中、保存成功、保存失敗を分けて考えます。状態を分けないと、読み込み中なのに空に見えたり、保存中に何度も送信できたりします。利用者が今何が起きているか分かるように、先に状態を書き出します。

Slide 13. 保存中と保存後

保存操作には、押した瞬間から結果が返るまでの時間があります。この間は保存中であることを表示し、二重送信を防ぎます。成功したら保存できたことを伝え、失敗したら何が起きたか、次にどうすればよいかを伝えます。保存ボタンを置くだけでなく、保存中と保存後まで設計します。

Slide 14. API responseの変換

APIから返ってきたresponseを、そのまま利用者に見せるとは限りません。たとえばneeds_supportという内部の値は、画面では「要支援」と表示した方が分かりやすいです。APIの値、画面に出す言葉、フォームの初期値、エラーメッセージを分けて考えます。フロントエンドには、APIのデータを分かる表示へ直す役割もあります。

Slide 15. TypeScriptの入口

TypeScriptを使う場合は、APIから返ってくるデータの型と、画面の状態の型を分けると読みやすくなります。APIにはsupportStatusという内部名があり、画面には表示名、編集中の値、保存中かどうか、エラーがあるかがあります。同じデータに見えても、API側の都合と画面側の都合を混ぜすぎないことが大切です。

Slide 16. フォーム設計

フォームは、入力欄を置けば完成ではありません。ラベル、説明、必須か任意か、入力補助、エラー表示、送信ボタン、送信中の状態、保存後の表示まで含めて設計します。画面側では早めに誤入力を伝えますが、API側の検証も必ず残します。画面で入力を助け、最後はAPI側でも不正な入力を止める、という役割分担です。

Slide 17. 入力エラー

入力エラーは、利用者が次に何を直せばよいか分かる言葉にします。「エラーです」だけでは足りません。たとえば「支援ステータスを選択してください」「メモは500文字以内で入力してください」のように、対象と直し方を示します。エラーの位置も、入力欄と関係が分かる場所に置きます。

Slide 18. 二重送信を防ぐ

保存中に同じボタンを何度も押せると、同じ更新が重複したり、後から返った結果で画面状態がずれたりします。保存中はボタンを無効にする、表示を「保存中」に変える、完了したら保存できたかどうかを表示する。このように、操作できる状態とできない状態を明確にすると、利用者も実装も安定します。

Slide 19. キーボード操作

画面はマウスだけでなく、キーボードでも操作できるか確認します。Tabで自然な順番に移動できるか。EnterやSpaceでボタンを押せるか。プルダウンのselectや、複数行入力のtextareaにたどり着けるか。これは特別な人だけのためではありません。手元の状況や入力方法が違っても、同じ目的を達成できるかを見る基本確認です。

Slide 20. フォーカス

フォーカスは、今どこを操作しているかを示す印です。フォーカスが見えないと、キーボード操作中に現在位置が分からなくなります。エラー後にどこへ戻るか、保存後にどこを見ればよいかも大切です。フォーカスは細かい見た目の話ではなく、利用者が画面の中で迷子にならないための手がかりです。

Slide 21. ラベルとエラーの関係

入力欄には、何を入力する場所か分かるラベルを付けます。支援ステータス、支援メモ、絞り込み条件のように、見れば目的が分かる名前にします。エラーが出たときも、どの入力欄に関係するのかを近くに置きます。ラベルとエラーの関係が分かると、目で見ても、画面読み上げソフトなどの支援技術でも、意味が伝わりやすくなります。

Slide 22. ブラウザ確認

画面を目で見るだけでは、確認として足りないことがあります。操作したら、ブラウザの開発者ツールで3か所を見ます。NetworkではAPIに何を送り、何が返ったかを見ます。Consoleではエラーが出ていないかを見ます。Elementsではlabelやformの形を見ます。見た目が自然でも、ここでエラーが出ていればまだ直す余地があります。

Slide 23. 画面幅を変える

画面幅を変えたとき、情報が重ならないか、ボタンが押しにくくならないかを確認します。大きな画面では見えていた項目が、小さい画面で切れてしまうことがあります。最初から完璧なレスポンシブ設計を目指す必要はありませんが、主要な情報と操作が崩れないかは必ず見ます。

Slide 24. コンポーネント分割

画面が大きくなると、一つのファイルに全部を書くと読みにくくなります。担当受講者一覧、絞り込み、支援ステータスフォーム、エラー表示のように、役割ごとに分けると確認しやすくなります。ただし、細かく分けすぎる必要はありません。変更理由と確認範囲を説明しやすい単位を目指します。

Slide 25. AIに画面実装を頼む

AIには、画面構成案、コンポーネント案、フォーム実装案、アクセシビリティ確認観点の初稿を頼めます。頼む前にはAPI契約と画面状態を渡します。採用する前には、ラベル、button、エラー文、保存中の二重送信、キーボード操作をブラウザで確認します。PR前には、AI案をどこまで使い、何を自分で直したかを説明できるようにします。

Slide 26. 個人開発課題への接続

個人開発課題では、自由テーマでも、利用者が触る画面が必要になります。この章で作るものは、画面要件メモ、状態メモ、画面構造メモ、実装メモ、確認ログです。英語名ではscreen-requirementsやui-state-modelなどと呼びます。まずは何を作り、どう確認したかを残します。それが後続章のテストや発表の材料になります。

Slide 27. Exercise 1

演習1では、第11章のAPI契約から、画面要件メモ、screen-requirementsを書きます。画面名、利用者、目的、表示する情報、操作、画面状態、今回は対象外にすることを整理します。ここでは実装を急がず、まずメンターが何を見て、何を操作できる必要があるのかを言葉にします。

Slide 28. Exercise 2-3

演習2では、状態メモ、ui-state-modelを書きます。読み込み中、0件、取得失敗、保存中、保存成功、保存失敗を分け、画面に何を表示するかを書きます。演習3では、画面構造メモ、screen-structureを書きます。見出し、一覧、フォーム、ラベル、エラー表示、キーボード操作の確認点を実装前に整理します。

Slide 29. Exercise 4-5

演習4では、実装メモ、frontend-implementation-noteを書きます。API接続、表示変換、部品分割、保存、エラー処理、AI案の確認を整理します。演習5では、確認ログ、frontend-check-logを書きます。画面表示、通信、エラー、キーボード操作、ラベルとエラー表示を、PRで説明できる形に残します。

Slide 30. 第13章への接続

第12章の成果物は、第13章のテスト設計へつながります。画面要件、状態、フォーム、エラー、ブラウザ確認ログがあると、何を自動テストにするか、何を手動確認に残すかを決めやすくなります。フロントエンドを作って終わりではなく、あとで安心して直せる状態へ進みます。