ユーザビリティとは、特定の利用者が特定の状況で、目的を効果的、効率的に、満足して達成できる度合いのことです。ウェブアクセシビリティでは、障害のある人も情報を知覚し、理解し、移動し、操作できるかを確かめます。
会社サイトなら、製品を探し、仕様を読み、問い合わせを終えるまでを一組にして試してください。色や写真の好みだけで、使いやすいサイトと判断しないようにします。
ページの読み込みや応答を測る話は表示と応答の指標で扱います。ここでは、情報が出た後に読めるか、操作できるか、目的を終えられるかを点検します。
二つの言葉はどう違う？
W3Cの概念の整理は、両者に重なる部分があると説明しています。ユーザビリティの調査だけでは、障害のある人の必要を十分に扱えないことも指摘しています。
たとえば、社内担当がマウスで簡単に送信できるフォームでも、キーボードでは送信ボタンに移動できないかもしれません。普段の使い方で問題がないことと、別の操作でも利用できることを分けて確かめます。
反対に、ボタンがキーボードで押せても、何を送る窓口か分からなければ、依頼は進みません。技術上の条件と、読者が内容を理解できるかの両方が必要です。
私たちは暦の自社メディアで、FAQを構造化データにだけ入れ、画面に出していなかった失敗があります。出典は自社メディアの運営記録です。答えをデータとして持つだけでは、読者が確認できる説明になっていませんでした。
この経験はアクセシビリティの適合実績ではありません。公開画面に答えがあるか、その答えを異なる方法でも使えるかという順に、点検を進める理由です。
法律では何が変わった？
内閣府の改正法の説明によると、2024年4月1日から事業者による合理的配慮の提供も義務になりました。それまでは事業者について努力義務だったものです。
障害のある人から、障壁を取り除く対応が必要との意思が伝えられたときに、負担が重すぎない範囲で必要かつ合理的に対応します。内容は障害の特性や場面で変わり、対話しながら検討します。
サイト全体を前もって使いやすくする仕事は、この個別対応と区別します。デジタル庁の導入ガイドブックは、ウェブの取り組みを合理的配慮のための環境整備として説明しています。導入資料の6頁では、次のように記しています。
環境の整備として努力義務が課せられています。
合理的配慮の義務化を、すべての民間サイトが同じ日からJISへ一律に適合する義務、と読み替えないでください。ただし、環境整備が努力義務であることを理由に、個別の相談への対応まで不要とは扱えません。
資料が読めないという連絡を受けたときは、必要な情報と困っている方法を確認します。担当窓口へつなぎ、利用者と対応方法を検討できるようにします。
規格は何を使う？
JIS X 8341-3は、ウェブの情報や機能を利用できるようにする日本の規格です。2016年版はWCAG 2.0と一致する規格です。WCAGはW3Cのガイドラインで、WCAG 2.2も公開されています。
デジタル庁のアクセシビリティ方針は、JISの目標に加え、WCAG 2.2のうちJISに含まれない基準も挙げています。JISとWCAG 2.2を同じ版として扱わず、何を対象にするかを明記する例です。
制作を頼むときは、対象ページ、目標の規格と版、適合レベル、確認方法、納品する結果を決めます。「対応済み」という一語では、トップだけを見たのか、フォームまで試験したのか分かりません。
以下は最初の不具合を見つける簡易点検です。すべて終えても、規格の全基準を試験したことにはなりません。正式な適合の表明には、対象範囲と試験方法を決めた評価が別に必要です。
どのページを選ぶ？
トップだけでなく、主要な製品、仕様表、資料、問い合わせを選びます。製造業なら、設計者が対応材質を探し、必要な資料を確認し、技術相談を送る流れで試せます。
確認用の入力には、実際の顧客名や図面を使わないようにします。担当が受信を確かめられるテスト用の内容を用意し、送信試験をすることも社内へ伝えます。
記録する欄は、URL、使った端末とブラウザ、操作、止まった場所、期待する動作です。大きな画面だけでなく、狭い画面と拡大時も見ます。特定の画面で成功した結果を、別の端末の確認済みへ広げません。
キーボードで進める？
W3Cの簡易点検の手順を基に、マウスを置いて試します。端末の設定で、すべての操作部品へキーボード移動できる状態かも確認してください。
- Tabでリンクや入力欄へ順に移る
- ShiftとTabで逆向きにも戻る
- 今選ばれている場所を画面上で見分ける
- リンクやボタンを、EnterやSpaceなど対応するキーで操作する
- メニューやダイアログを開き、閉じて次へ移れるか確かめる
枠や強調表示が消えて現在位置が分からない、固定ヘッダーに隠れる、途中の部品から抜けられない、といった状態を記録します。Tabを押せたことだけで合格にしません。
メニューを開いた後に、製品を選び、資料へ進み、フォームへ移れるかまで続けます。ページ間で移動の順番が変わり、同じ操作を探し直す箇所も残してください。
画像の意味は伝わる？
画像が示す情報を、代替テキストや周囲の本文で確かめます。読み上げでは画像の見た目をそのまま受け取れないため、製品名、図の関係、ボタンの目的が分かる説明が必要です。
たとえば樹脂部品の不良箇所を矢印で示す写真なら、ファイル名だけの説明では足りません。何の部品のどこに、どんな状態があるかを、公開してよい範囲で書きます。複雑な図は、本文にも説明を置きます。
装飾の画像に説明を付け足す必要があるかも区別します。すべての画像へ同じ製品キーワードを入れると、読み上げで不要な繰り返しになります。書式と用途別の例は代替テキストへ進めます。
色だけに頼っていない？
文字と背景の色を、測定できる道具で調べます。WCAG 2.2の達成基準1.4.3では、通常の文字は原則4.5対1以上、大きな文字は3対1以上です。ロゴや装飾、非アクティブな部品などには例外があります。
薄いグレーの注意書きだけでなく、入力例、エラー文、ボタン、写真に重ねた文字を確認します。背景が写真なら、文字の背後で色が変わる場所も見る必要があります。担当者の目で濃く見えるかだけでは判定しません。
赤い項目が必須、緑なら対応可能という案内は、文字でも意味を伝えます。必須というラベルや対応状況の文を付け、色を見分けることだけを操作の前提にしないようにします。
入力と修正を終えられる？
各入力欄に目的の分かる名前があり、入力中も読めるかを見ます。必須項目を空欄にするなどしてエラーを起こし、どこをどう直すかが分かるかを試します。
エラーが出たら、キーボードで該当欄へ戻り、修正して送信します。最初から入力し直す必要がないか、通知が読み上げでも伝わるかも確認します。具体的なフォーム設計は問い合わせの導線に送ります。
試験で見つかった問題は、見た目、HTMLの構造、操作の処理、文章に分けて担当へ渡します。別の相談窓口を用意しても、フォームの問題を解消した扱いにはしません。個別の利用相談には対応しつつ、元の機能も直します。
修正後はどう確かめる？
止まった操作を、同じ条件で試し直します。共通メニューを変えたなら、製品ページや資料のページでも確認します。部品だけ動く状態と、相談まで終えられる状態を分けます。
自動検査の結果に加え、実際の操作と読み上げの確認を残してください。W3Cも簡易点検を完全な評価とはしていません。未確認の項目は、未確認のまま引き継ぎます。
サイト設計の相談には、対象URLと止まった操作、利用環境を渡します。作り直しが必要かを決める前に、既存のメニューやフォームで共通する不具合から修正範囲を決められます。
仕様・法令・出典の確認日：2026年10月23日。
