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

この章では、APIのresponseを利用者が触れる画面へ変換するときに必要な、フロントエンドとアクセシビリティの基本用語を集めた。画面状態、意味に合ったHTML、キーボード操作、ブラウザでの確認といった、研修の外でも使われる言葉を解説する。

フロントエンド

• 読み：フロントエンド（frontend）
• 一言で言うと：利用者が実際に触れる画面と、その画面の状態を扱う部分。
• くわしく：フロントエンドは、APIのresponseを画面に貼るだけの作業ではない。利用者が何を見て、何を判断し、どの操作を行い、今何が起きているかを理解できるようにする仕事である。同じAPIでも、画面状態やフォーム、エラー文、フォーカスが整っているかで使いやすさは大きく変わる。バックエンドが正しく動いていても、画面が分かりにくいと利用者の仕事は進まない。だからフロントエンドは、データ取得、表示、入力、保存、エラーを利用者が理解できる形にする。
• 具体例：支援ステータス機能では、メンターが担当受講者の状態を見て、要支援の人を見つけ、必要ならステータスやメモを更新できるように画面を組み立てる。
• つまずきやすい点：APIの値をそのまま並べただけでは画面要件にならない。各項目が利用者の判断にどう役立つかまで考える。
• 関連語：UI state（第12章）、コンポーネント（第12章）
• テキスト本文での登場箇所：第12章「フロントエンドは、利用者の行動を成立させる場所である」

UI state

• 読み：ユーアイステート（UI state）／日本語では画面状態
• 一言で言うと：読み込み中、空、入力中、保存中、成功、失敗など、画面が今どの状況にあるかを表す区分。
• くわしく：画面はいつも正常にデータを表示しているわけではない。最初の読み込み中、一覧が0件、取得失敗、保存中、保存成功、保存失敗など、いくつもの状況がある。これらを区別しないと、読み込み中なのに空に見えたり、保存中なのに何度もボタンを押せたりする。状態を分けると、画面に何を表示し、どの操作を許すかを決めやすくなる。状態の混同はバグだけでなく、設計不足としても起きる。
• 具体例：支援ステータス機能の一覧では loading／loaded／empty／filtered-empty／load-error を分け、更新フォームでは idle／editing／saving／saved／save-error を分ける。
• つまずきやすい点：正常表示だけ作り、loadingやempty、errorを後回しにしがち。担当者0件と絞り込み結果0件も別の状態として扱う。
• 関連語：loading / empty / error / success（第12章）、フロントエンド（第12章）
• テキスト本文での登場箇所：第12章「UI stateは、利用者が今の状況を理解するための設計である」

loading / empty / error / success

• 読み：ローディング／エンプティ／エラー／サクセス（loading / empty / error / success）
• 一言で言うと：画面状態としてよく使われる代表的な区分で、それぞれ読み込み中・空・失敗・成功を表す。
• くわしく：画面の状態を整理するとき、まず取得や保存が「読み込み中（loading）」「成功（loaded/saved）」「失敗（error）」「中身が空（empty）」のどれかを区別する。区別すると、各状態でどんな表示や操作を出すかを決められる。たとえば保存中は二重送信を防ぎ、失敗時は何が起きたかと再試行できるかを示す。空の状態でも、データがそもそも無いのか、絞り込み結果が0件なのかを分けると、利用者の理解が変わる。
• 具体例：支援ステータス機能では、保存中（saving）は保存ボタンを無効にし、保存失敗（save-error）は原因と再試行可否を表示し、絞り込み結果0件（filtered-empty）は「条件に合う受講者がいない」と伝える。
• つまずきやすい点：成功時の表示だけ作り、空・失敗・読み込み中を後回しにしやすい。担当受講者0件と絞り込み0件を同じ表示にしない。
• 関連語：UI state（第12章）、二重送信（第12章）
• テキスト本文での登場箇所：第12章「UI stateは、利用者が今の状況を理解するための設計である」

アクセシビリティ

• 読み：アクセシビリティ（accessibility）。a11yと略すこともある
• 一言で言うと：多様な利用者や操作方法でも使えるようにする品質。
• くわしく：アクセシビリティは、専門家だけが最後に確認するものではない。実装者がまず見るべき基本がある。キーボードで操作できるか、フォーカスが見えるか、入力欄にラベルがあるか、エラーが色だけでなく言葉で伝わるかなどである。これらを整えると、目で見えにくい人、マウスを使えない人、支援技術を使う人を含めて、より多くの人が画面の目的を達成できる。最初から少しずつ確認するほうが、後でまとめて直すより楽である。
• 具体例：支援ステータス画面で、Tabキーで主要操作へ移動でき、selectやtextareaに到達でき、エラーがテキストでも分かることを確認する。
• つまずきやすい点：マウス操作だけ確認して、キーボード操作やフォーカス、ラベルの確認を飛ばしてしまう。
• 関連語：WCAG（第12章）、フォーカス（第12章）、スクリーンリーダー（第12章）
• テキスト本文での登場箇所：第12章「キーボード操作とフォーカスを確認する」

セマンティックHTML

• 読み：セマンティックエイチティーエムエル（semantic HTML）
• 一言で言うと：見た目ではなく意味に合うHTML要素を選ぶ考え方。
• くわしく：HTMLは見た目を作るためだけの記号ではない。画面の意味を、ブラウザ、支援技術、テスト、他の開発者へ伝える構造である。だから、主見出しなら h1、操作なら button、入力をまとめるなら form のように、意味に合う要素を選ぶ。見た目のためだけにクリックできる div を増やすと、キーボード操作や読み上げ、テストが難しくなる。意味で選ぶと、画面の構造がそのまま他の人や機械に伝わる。
• 具体例：支援ステータス画面では、画面タイトルを h1、絞り込み条件を label と select、入力のまとまりを form、絞り込み実行を button で表す。
• つまずきやすい点：属性名の暗記が目的ではない。ラベルがあるか、説明と入力欄が結びついているか、buttonの文言が操作を表すかをまず見る。
• 関連語：label（第12章）、form（第12章）、button（第12章）、アクセシビリティ（第12章）
• テキスト本文での登場箇所：第12章「セマンティックHTMLは、意味で要素を選ぶことである」

label

• 読み：ラベル（label）。HTMLの <label> 要素
• 一言で言うと：入力欄が何のためのものかを利用者や支援技術へ伝える要素。
• くわしく：入力欄だけがあっても、それが何を入力する場所か分からないことがある。labelは、入力欄に名前を与え、その対応を機械にも伝える。for 属性で入力欄の id と結びつけると、ラベルをクリックして入力欄に移動でき、スクリーンリーダーも何の入力かを読み上げられる。ラベルのない入力欄は、見た目では分かっても支援技術には伝わらない。
• 具体例：支援ステータス機能のフォームでは、select に「支援ステータス」、textarea に「支援メモ」のラベルを付け、for と id で結びつける。
• つまずきやすい点：placeholder（薄い案内文）をラベル代わりにしない。入力すると消えてしまい、何の欄か分からなくなる。
• 関連語：form（第12章）、セマンティックHTML（第12章）、Elements（第12章）
• テキスト本文での登場箇所：第12章「セマンティックHTMLは、意味で要素を選ぶことである」

form

• 読み：フォーム（form）。HTMLの <form> 要素
• 一言で言うと：入力と送信をひとまとまりの操作として扱うHTML要素。
• くわしく：formは、複数の入力欄と送信操作を一つのまとまりにする。まとめると、Enterキーでの送信や、入力欄とラベルと送信ボタンの関係が自然になる。フォームでは入力欄だけでなく、ラベル、説明、エラー、保存ボタン、保存中の状態をセットで考える。任意項目なら任意だと分かる説明を付け、エラーはどの入力欄に関係するか分かる場所に置く。
• 具体例：支援ステータス機能では、絞り込み条件の select と「絞り込む」ボタンを一つの form にまとめ、支援ステータスとメモの更新も form として扱う。
• つまずきやすい点：入力欄を並べただけでformにしないと、送信操作やエラー表示の置き場所が曖昧になる。
• 関連語：label（第12章）、button（第12章）、セマンティックHTML（第12章）
• テキスト本文での登場箇所：第12章「一覧、フォーム、エラー表示を設計する」

button

• 読み：ボタン（button）。HTMLの <button> 要素
• 一言で言うと：利用者が実行する操作を表す要素。
• くわしく：buttonは、押すと何かが起きる操作を表す。<button> を使うと、Tabキーで到達でき、EnterやSpaceで実行でき、支援技術も操作だと分かる。見た目だけ似せたクリックできる div だと、キーボード操作や読み上げが効かないことがある。buttonの文言も大切で、「絞り込む」「保存」のように操作内容が分かる言葉にする。
• 具体例：支援ステータス機能では、絞り込みの「絞り込む」ボタンや支援ステータス更新の「保存」ボタンを <button> で作り、保存中は無効にして二重送信を防ぐ。
• つまずきやすい点：見た目のために div をクリック要素にすると、キーボード操作とフォーカスが効かない。操作はbuttonで表す。
• 関連語：form（第12章）、二重送信（第12章）、フォーカス（第12章）
• テキスト本文での登場箇所：第12章「セマンティックHTMLは、意味で要素を選ぶことである」

フォーカス

• 読み：フォーカス（focus）
• 一言で言うと：キーボード操作で、今どの要素が操作対象かを示す状態。
• くわしく：フォーカスは、今どこを操作しているかを示す印である。Tabキーで要素を移動すると、フォーカスが順番に移っていく。フォーカス表示を消すと、キーボード利用者は現在位置を見失う。だから、フォーカスが見えること、Tabで自然な順番に移動できること、保存後やエラー後に次に見る場所が分かることを確認する。
• 具体例：支援ステータス画面で保存ボタンを押した後、上部に成功メッセージを出すなら、利用者がそのメッセージに気づけるかを考える。エラー時はエラー文の近くか該当入力欄へフォーカスを戻す方針を決める。
• つまずきやすい点：見た目を整えるためにフォーカス表示（枠線など）を消すと、キーボード利用者が現在位置を失う。
• 関連語：キーボード操作（第12章）、アクセシビリティ（第12章）
• テキスト本文での登場箇所：第12章「キーボード操作とフォーカスを確認する」

キーボード操作

• 読み：キーボードそうさ（keyboard operation／keyboard navigation）
• 一言で言うと：マウスを使わず、キーボードだけで画面を操作できること。
• くわしく：すべての利用者がマウスを使えるとは限らない。キーボードだけで操作する人のために、Tabキーで自然な順番に移動でき、EnterやSpaceでbuttonを操作でき、selectやtextareaにたどり着けることを確認する。マウスでしか操作できない画面は、機能として動いていても一部の利用者には使えない。これはアクセシビリティの基本で、実装者が最初に確認できる項目である。
• 具体例：支援ステータス画面で、Tabキーで絞り込みselectから保存ボタンまで移動でき、EnterまたはSpaceで保存ボタンを実行できることを確認する。
• つまずきやすい点：マウス操作だけで確認を済ませてしまう。キーボードだけで一連の操作ができるかを必ず試す。
• 関連語：フォーカス（第12章）、アクセシビリティ（第12章）、button（第12章）
• テキスト本文での登場箇所：第12章「キーボード操作とフォーカスを確認する」

WCAG

• 読み：ダブリューシーエージー（WCAG。Web Content Accessibility Guidelinesの略）
• 一言で言うと：Webアクセシビリティの国際的な基準をまとめたガイドライン。
• くわしく：WCAGは、W3Cが定めるWebアクセシビリティの基準である。この章で全体を網羅する必要はない。ただし、WCAGが示す「知覚可能」「操作可能」「理解可能」「堅牢」という大きな考え方は、日常の画面確認にも使える。見えるか、操作できるか、理解できるか、壊れにくい構造か。この四つの問いに置き換えると、画面確認の入口になる。
• 具体例：支援ステータス画面で、要支援が色だけでなくテキストでも伝わるか（知覚可能）、キーボードで操作できるか（操作可能）、エラー文が分かりやすいか（理解可能）を確認する。
• つまずきやすい点：細かい達成基準の暗記を目指す必要はない。まず四つの大きな観点で画面を見る。
• 関連語：アクセシビリティ（第12章）、コントラスト比（第12章）
• テキスト本文での登場箇所：第12章「キーボード操作とフォーカスを確認する」

ARIA

• 読み：アリア（ARIA。Accessible Rich Internet Applicationsの略）
• 一言で言うと：HTMLだけでは伝えきれない意味や関係を、支援技術に補足するための属性群。
• くわしく：ARIAは、要素の役割や関係、状態を機械に伝える属性のまとまりである。たとえば、ある領域がどの見出しに対応するか、ある入力欄にどの説明文が結びつくかを示せる。ただし、ARIAは万能ではない。まず意味に合うHTML要素を使い、足りないところを補うために使うのが基本である。HTMLで表せることをわざわざARIAで置き換えるのは避ける。
• 具体例：支援ステータス画面で、section に aria-labelledby="support-heading" を付けて見出しと結びつけ、絞り込みフォームに aria-describedby で説明文を結びつける。
• つまずきやすい点：ARIAを足せばアクセシブルになるわけではない。セマンティックHTMLが先で、ARIAは補足。
• 関連語：セマンティックHTML（第12章）、アクセシビリティ（第12章）、label（第12章）
• テキスト本文での登場箇所：第12章「セマンティックHTMLは、意味で要素を選ぶことである」

スクリーンリーダー

• 読み：スクリーンリーダー（screen reader）。支援技術の一つ
• 一言で言うと：画面の内容を音声などで読み上げ、目で見えにくい利用者の操作を助けるソフト。
• くわしく：スクリーンリーダーは、画面に表示された文字や要素の意味を読み上げる。読み上げの手がかりになるのは、見た目ではなくHTMLの構造や属性である。だから、見出しが正しく付いているか、入力欄にラベルがあるか、buttonが操作として存在するかが、読み上げの質を左右する。セマンティックHTMLやARIAを整える理由の一つは、スクリーンリーダーなどの支援技術に意味を正しく伝えるためである。
• 具体例：支援ステータス画面のlabelとselectが正しく結びついていれば、スクリーンリーダーは「支援ステータスで絞り込む」と読み上げられる。
• つまずきやすい点：実機のスクリーンリーダーでの確認は手間がかかる。未確認なら、確認できていないことを正直にログへ残す。
• 関連語：アクセシビリティ（第12章）、セマンティックHTML（第12章）、ARIA（第12章）
• テキスト本文での登場箇所：第12章「セマンティックHTMLは、意味で要素を選ぶことである」

コントラスト比

• 読み：コントラストひ（contrast ratio）
• 一言で言うと：文字と背景の明るさの差を表す指標で、読みやすさに関わる。
• くわしく：文字と背景の色の差が小さいと、文字が読みにくくなる。コントラスト比は、その差を数値で表したもので、WCAGにも基準がある。色は情報を伝える手がかりの一つだが、色だけを唯一の情報源にしてはいけない。色の違いが分かりにくい利用者や、明るい場所で画面を見る利用者もいる。だから、色に加えてテキストやアイコン、位置で意味を伝える。
• 具体例：支援ステータス画面で「要支援」を目立たせるとき、色だけに頼らず「要支援」というテキストや補足も一緒に出す。
• つまずきやすい点：状態を色だけで伝えると、色の差が分かりにくい人に届かない。テキストや位置と組み合わせる。
• 関連語：WCAG（第12章）、アクセシビリティ（第12章）、CSS（第12章）
• テキスト本文での登場箇所：第12章「CSSは、情報の優先度と状態を伝える」

Network

• 読み：ネットワーク（Network）。ブラウザ開発者ツールのパネル
• 一言で言うと：ブラウザがどんなHTTP requestを送り、どんなresponseを受け取ったかを確認する場所。
• くわしく：Networkパネルでは、送ったrequestのmethod、URL、status code、request body、response bodyを確認できる。画面が表示されていても、思った通りのrequestが送られているとは限らない。絞り込みやエラー時に、想定したrequestやerror responseになっているかを目で確かめられる。フロントエンドとAPIのつなぎ目を調べる、最初の手がかりである。
• 具体例：支援ステータス機能で、絞り込み時に supportStatus=needs_support が送られているか、更新時に PATCH /api/mentor/learners/{learnerId}/support-status が呼ばれているかをNetworkで確認する。
• つまずきやすい点：画面が表示されたことだけで確認済みにしない。実際のrequestとresponseをNetworkで見る。
• 関連語：status code（→第7章）、HTTP request / HTTP response（→第7章）、Console（第12章）
• テキスト本文での登場箇所：第12章「ブラウザで、見た目以外も確認する」

Console

• 読み：コンソール（Console）。ブラウザ開発者ツールのパネル
• 一言で言うと：ブラウザでJavaScriptのエラーや警告を確認する場所。
• くわしく：Consoleパネルには、JavaScriptの例外や警告メッセージが表示される。画面は一見正常に見えても、内部で例外が出て処理が途中で止まっていることがある。だから、操作後にConsoleを見て、重大なエラーや警告がないかを確認する。エラーがあれば、操作、時刻、メッセージ、stackの概要を記録しておくと、原因調査につながる。
• 具体例：支援ステータス画面で保存操作をした後、Consoleにエラーが出ていないかを確認し、出ていれば内容を記録に残す。
• つまずきやすい点：見た目が正常でも内部で例外が出ていることがある。操作のたびにConsoleを確認する。
• 関連語：Network（第12章）、Elements（第12章）
• テキスト本文での登場箇所：第12章「ブラウザで、見た目以外も確認する」

Elements

• 読み：エレメンツ（Elements）。ブラウザ開発者ツールのパネル
• 一言で言うと：ブラウザで、実際に表示されているHTML構造や属性、要素の関係を確認する場所。
• くわしく：Elementsパネルでは、ブラウザが解釈した後のHTML構造を見られる。これにより、labelと入力欄が結びついているか、buttonが操作として存在するか、見出し構造が極端に飛んでいないか、エラー文が入力欄の近くにあるかを確認できる。コードに書いたつもりでも、実際の構造が違うことがある。意味とアクセシビリティの基本を、表示後の構造で確かめられる。
• 具体例：支援ステータス画面で、label の for と select の id が一致しているか、保存操作が button になっているかをElementsで確認する。
• つまずきやすい点：ソースコードだけでなく、ブラウザが解釈した後の構造をElementsで見ると、結びつきの抜けに気づける。
• 関連語：label（第12章）、セマンティックHTML（第12章）、Console（第12章）
• テキスト本文での登場箇所：第12章「ブラウザで、見た目以外も確認する」

コンポーネント

• 読み：コンポーネント（component）
• 一言で言うと：画面の一部を役割ごとに分けた部品。
• くわしく：コンポーネントは、画面を役割ごとに小さく分けた単位である。分けると、データ取得、絞り込み、一覧表示、入力、保存、エラー表示の責務が読みやすくなる。ただし、細かく分ければよいわけではない。小さすぎる分割は、かえって読む場所を増やす。変更理由と確認範囲を説明しやすい単位を選ぶのがよい。
• 具体例：支援ステータス画面を、ページ（LearnerSupportPage）、フィルタ（SupportStatusFilter）、一覧（LearnerSupportTable）、フォーム（SupportStatusForm）、エラー表示（ErrorMessage）に分ける。
• つまずきやすい点：分割そのものが目的化しやすい。小さすぎる部品は読みにくくなるので、責務で区切る。
• 関連語：フロントエンド（第12章）、UI state（第12章）
• テキスト本文での登場箇所：第12章「フロントエンド実装方針を書く」

レスポンシブ

• 読み：レスポンシブ（responsive）
• 一言で言うと：画面幅が変わっても、主要な情報と操作が崩れないようにする考え方。
• くわしく：画面は、デスクトップとスマートフォンなど、さまざまな幅で見られる。デスクトップで横並びに見える表が、モバイル幅では文字が切れたり、保存ボタンが画面外へ出たりすることがある。高度なレスポンシブ設計まで作り込まなくても、主要な情報と操作が幅を変えても壊れていないことは必ず確認する。幅を変えて見るだけでも、多くの崩れに気づける。
• 具体例：支援ステータス画面を、デスクトップ幅とモバイル幅の両方で開き、受講者名・支援ステータス・保存ボタンなど主要導線が崩れていないか確認する。
• つまずきやすい点：デスクトップ幅だけで確認しがち。モバイル幅でも主要な情報と操作が見えるかを試す。
• 関連語：CSS（第12章）、フロントエンド（第12章）
• テキスト本文での登場箇所：第12章「CSSは、情報の優先度と状態を伝える」

CSS

• 読み：シーエスエス（CSS。Cascading Style Sheetsの略）
• 一言で言うと：余白や配置、色などで、情報のまとまりと優先度、状態を伝える仕組み。
• くわしく：CSSは、装飾だけのものではない。余白、配置、文字サイズ、境界線、色、状態表示を使って、情報のまとまりや優先度を伝える。画面の目的に合わせて、見つけやすくすべき情報を目立たせる。ただし、目立たせるために色だけへ依存してはいけない。色の違いが分かりにくい利用者もいるので、テキストや補足と組み合わせる。
• 具体例：支援ステータス画面で、要支援の受講者を見つけやすくするとき、色に加えて「要支援」のテキストや補足も一緒に表示する。
• つまずきやすい点：状態を色だけで伝えると一部の利用者に届かない。CSSは見た目だけでなく、情報の優先度を伝える道具と考える。
• 関連語：コントラスト比（第12章）、レスポンシブ（第12章）、アクセシビリティ（第12章）
• テキスト本文での登場箇所：第12章「CSSは、情報の優先度と状態を伝える」

二重送信

• 読み：にじゅうそうしん（double submission）
• 一言で言うと：同じ送信操作が短時間に二回以上行われ、更新が重複してしまうこと。
• くわしく：保存ボタンを押してから結果が返るまでの間に、もう一度押せると、同じ更新が重複して送られることがある。後から返ったresponseで画面が古い状態に戻ることもある。これを防ぐには、保存中はボタンを無効にし、文言を「保存中」に変え、保存が終わるまで再送信できないようにする。これは見た目の工夫ではなく、状態を安定させるための設計である。
• 具体例：支援ステータス機能の保存処理で、saving 状態の間は保存ボタンを無効にし、二重送信を防ぐ。
• つまずきやすい点：保存中にボタンを押せる状態のままにすると、重複更新や古い状態への巻き戻りが起きる。
• 関連語：UI state（第12章）、button（第12章）、loading / empty / error / success（第12章）
• テキスト本文での登場箇所：第12章「保存処理では、二重送信と結果の反映を見る」

table / list

• 読み：テーブル／リスト（table / list）
• 一言で言うと：情報の並べ方を表すHTML要素。表形式の table と、項目の並びの ul／ol（list）。
• くわしく：複数の項目を見せるとき、行と列で比較する情報なら table、一人ずつ順に読む情報なら list（ul／ol）が合う。見た目ではなく意味に合う要素を選ぶと、支援技術が構造を正しく伝えられる。見出しのある表なら th を使うなど、要素の役割を正しく使う。
• 具体例：支援ステータス一覧で、受講者ごとに名前・状態・最終ログを列で比較するなら table。お知らせを並べるだけなら list が自然である。
• つまずきやすい点：見た目を整えるためだけに table を使う、または本来表で比べる情報を div の羅列にする。意味で選ぶ。
• 関連語：セマンティックHTML（第12章）、アクセシビリティ（第12章）、コンポーネント（第12章）
• テキスト本文での登場箇所：第12章「セマンティックHTMLは、意味で要素を選ぶことである」「一覧、フォーム、エラー表示を設計する」