架空の設備会社では、顧客が製品P01の仕様を読み、保守の相談を送ります。担当者がトップページを眺めるだけでは、この仕事を完了できるか分かりません。点検担当は製品一覧、仕様、問い合わせ、確認・完了までのページと操作を並べます。

顧客にはキーボードで移動する人、画面を拡大する人、スクリーンリーダーで内容を聞く人がいます。明るい外でスマートフォンを見る場合や、片手で操作する場合にも困り方が変わります。「障害のある人専用の別ページ」を先に作るより、実際の経路の障壁を確認します。

W3CのEasy Checksは初期点検の入口で、WCAG 2.2は具体的な成功基準を示します。ここで紹介する操作は一部です。サイト全体の適合を求める場合は、対象範囲と基準、評価方法を専門担当と決め、簡易確認だけで完了としないようにします。

この章の根拠：出典1出典2

点検担当はマウスを置き、Tabでリンクと入力欄へ移動します。フォーカスは、今操作対象になっている場所を示す印です。印が消える、背景と同じ色で見えない、固定ヘッダーに隠れる場合は、顧客が今どこにいるか分かりません。

Enter等でメニューやリンクを使い、開いたダイアログを閉じて元の操作へ戻れるかを確かめます。メニューに入ったまま外へ出られない状態は、キーボードで使う顧客を止めます。操作が複雑な部品では、標準のキー以外が必要なら説明の有無も確認します。

見た目だけボタンで、キーボードでは到達できない部品も点検します。担当者は「お問い合わせボタンが使えない」とだけ書かず、「仕様P01からTabを5回押してもボタンへ到達しない」と条件を残します。回数はこの架空例の記録で、全サイト共通の基準ではありません。

この章の根拠：出典1出典2

大きい文字にしただけの段落と、HTMLの見出しは同じではありません。点検担当はページの主題と章の関係を確認します。製品名の見出しの下に対応条件、価格の説明、相談方法が並ぶなら、その関係を見出しでも伝えます。文字サイズだけで重要度を表さないようにします。

図に「青が合格、赤が不合格」しかないと、色を区別しにくい読者には意味が伝わりません。文字や記号も加え、本文に判断の説明を残します。画像のaltは何を示すかを説明しますが、長い帳票の全内容をaltへ詰めるより、必要な数値をHTMLの表でも読めるようにします。

装飾画像と情報画像では役割が違います。背景の雰囲気だけの写真に本文と同じ説明を重複させる必要はありません。一方、型番の対応図には「P01は屋内用、P02は屋外用」といった図の結論が必要です。点検担当は画像が消えても必要な条件が本文に残るかを確かめます。

この章の根拠：出典1出典3

入力欄の薄い見本文字だけをラベルにすると、入力後に項目名が消えることがあります。問い合わせフォームでは、会社名、返信先、相談内容などの名前を常に確認できるようにします。HTMLでもラベルと入力欄が対応することを制作担当が確認します。

必須項目は記号だけでなく説明を付けます。送信時に「エラーです」だけでは、顧客はどこを直すか分かりません。「返信先の形式を確認してください」と対象欄と理由を示し、修正できる位置へ進めるようにします。入力内容を無条件に消すと、再入力の負担が増えます。

点検担当は正常な入力、未入力、形式違いを架空の情報で試します。フォーム試験は実送信される場合があるため、許可された試験先やテスト環境を使います。この制作作業は顧客への実送信を行う指示ではありません。完了表示と二重送信への扱いも担当者へ確認します。

入力の試験では、文字を空にした場合と誤った形式にした場合を分けます。エラー文が表示されても、どの欄をどう直すか分からなければ、顧客は目的を終えられません。点検担当は修正後に入力を保ったまま先へ進めるかも確認し、見た目と操作の結果を別に残します。

この章の根拠：出典1出典2

点検担当は文字を200％へ拡大し、見出し、図の補足、入力欄、ボタンを確認します。固定された高さの箱から文章がはみ出す、ボタンと文章が重なる、長い社名が切れる場合は、読める大きさへ変えた顧客が困ります。画面の拡大と文字だけの拡大は挙動が異なるため、条件を残します。

文字と背景の色の差も確認します。WCAG 2.2のAAの最低コントラストには、一般の文字4.5対1、大きな文字3対1等の条件と例外があります。肉眼で「大丈夫」と判断せず、担当者が適用する基準と測定結果を確認します。ここで比率を示すだけで全体適合とは言いません。

修正後は問題が起きた同じ幅と拡大率で試します。PCで読めても、スマートフォンの長い型番や表は別の問題を起こすことがあります。横スクロールが必要な表には目的が分かる案内を付け、操作が必要なボタンを隠さないようにします。

この章の根拠：出典1出典2

アクセシビリティの点検は、顧客が製品を理解し、相談を送れる経路を確かめるところから始めます。キーボード、見出しと画像、入力、拡大を別々に試すと、見た目だけでは気付かない問題を担当者へ伝えられます。経営者は点検の目的と範囲を決めます。

下のメモには「問題なし」だけを書かず、試した条件と結果を書いてください。未確認のスクリーンリーダー操作やページは未確認のまま残します。確認した範囲が分かれば、専門担当に追加評価を依頼する判断もできます。

修正後は同じ操作で再確認し、変更で別の操作が壊れていないかを見ます。実際の顧客や支援技術を使う利用者の確認は、社内の簡易点検とは別に計画します。テストツールの高得点を「誰でも使える」の証明として宣伝しないことが、誠実な説明につながります。

この章の根拠：出典1出典2出典3