サイトアイコン IT & ライフハックブログ|学びと実践のためのアイデア集

WCAG 2.2「1.3.3 感覚的な特徴」とは?Level Aの判断基準と実装例

programming codes screengrab

Photo by Myburgh Roux on Pexels.com

WCAG 2.2の達成基準1.3.3「感覚的な特徴」は、コンテンツを理解したり操作したりするための指示を、色、形、大きさ、位置、向き、音だけで伝えないことを求めるLevel Aの基準です。

色や位置を使うこと自体が禁止されているわけではありません。

「右上の青い『送信』ボタン」のように、見た目の手掛かりに加えて操作対象を名前でも特定できれば、指示を受け取る方法が一つに限定されません。

この記事では、達成基準の範囲、よくある失敗、HTMLの改善例、確認手順を順に整理します。

基準の原文と解釈は、W3Cの「Understanding Success Criterion 1.3.3」で確認できます。

1.3.3「感覚的な特徴」が求めること

感覚的な特徴とは、見た目や音で知覚する形、色、大きさ、視覚的な位置、向き、音などの手掛かりを指します。

達成基準が対象にするのは、コンテンツの理解や操作に必要な「指示」です。

これらの表現だけでは、画面を見ていない利用者や、色、形、位置関係を同じように把握できない利用者が、対象を特定できない場合があります。

一方、位置や色は操作対象を素早く見つける手掛かりにもなります。

そのため、感覚的な表現を削るのではなく、ボタン名や項目名などの識別情報を併記します。

指示の失敗例と改善例

感覚的な特徴に依存する指示の改善例
失敗例 問題 改善例
右上の青いボタンを押してください。 位置と色だけでは対象名が分かりません。 右上の青い「送信」ボタンを押してください。
丸いアイコンを選んでください。 形だけでは目的を判断できません。 丸い「ヘルプ」アイコンを選んでください。
上向きの矢印で前の画面に戻ってください。 向きと図形だけに依存しています。 上向きの矢印が付いた「前の画面」ボタンを選んでください。
ビープ音が鳴ったら次へ進んでください。 音を聞けない環境では進む時点が分かりません。 「準備完了」と表示されたら「次へ」ボタンを選んでください。

改善例では、感覚的な手掛かりを残しながら、文字でも対象や状態を特定できるようにしています。

画面の配置が変わっても、「送信」「ヘルプ」「前の画面」のような名前が一致していれば、利用者は対象を探しやすくなります。

HTMLで指示と操作対象を対応させる

ボタン名を指示に含める

次の例は、指示が色だけに依存しています。

<p>赤いボタンを選択してください。</p>
<button type='button'>送信</button>

指示に、画面上のボタンと同じ名前を含めます。

<p>フォームの内容を送るには、赤い「送信」ボタンを選択してください。</p>
<button type='button'>送信</button>

「赤い」という手掛かりを認識できなくても、「送信」という表示から操作対象を特定できます。

必須項目を色だけで示さない

「赤い背景の項目は必須です」という説明は、色を区別できない場合に必須項目が分からなくなります。

ラベルに「必須」と表示し、項目と説明を直接対応させます。

<label for='name'>名前(必須)</label>
<input id='name' name='name' type='text' required>

この例は操作の指示に関わるため1.3.3の確認対象になり、必須という情報を色だけで伝えていないかという点では1.4.1「色の使用」にも関係します。

達成基準を一つ満たしただけで、同じ表示に関係する別の達成基準まで満たしたことにはなりません。

音と同時に文字でも状態を伝える

音を合図として使う場合は、同じ時点を判断できる文字情報も表示します。

<p>準備が完了しました。「次へ」ボタンを選択してください。</p>
<button type='button'>次へ</button>

音を追加の手掛かりとして残しても、操作が音だけに依存しなければ、音を聞けない状況でも手順を進められます。

セマンティックHTMLとARIAの役割

1.3.3で最初に確認するのは、指示の文章から操作対象を特定できるかどうかです。

そのうえで、意味と役割に合ったHTML要素を選ぶと、ブラウザーや支援技術へ操作対象の役割を伝えやすくなります。

ボタンには見た目だけを整えた要素ではなく、原則として<button>要素を使います。

要素選びの考え方は、セマンティックHTMLの基本と実装ポイントで詳しく解説しています。

ARIAは、HTMLだけでは名前、状態、関係を十分に伝えられない場面を補う仕組みです。

ただし、aria-labelを付ければ感覚的な指示が自動的に解決するわけではありません。

画面に見える表示、支援技術が受け取る名前、説明文で使う名前を対応させる必要があります。

ARIAを使う場面と避けたい使い方は、ARIAの基本とアンチパターンも参照してください。

1.3.1から1.3.3までの関係は、1.3「適応可能」の達成基準と実装例で全体像を確認できます。

実装後の確認手順

  1. 指示を抽出する:ボタン操作、入力、移動、状態の確認を求める文章を一覧にします。
  2. 感覚的な語を探す:「右」「左」「上」「下」、色名、形、大きさ、向き、音を表す語を確認します。
  3. 感覚的な語を外して読む:その語を読めなくても、ボタン名や項目名から対象を一つに特定できるかを確かめます。
  4. 表示名を照合する:説明文の名前と、画面に表示されるラベルが一致しているかを確認します。
  5. 関連する基準を分けて確認する:色による情報伝達、HTMLの意味構造、名前や状態の伝達を、1.3.3だけで済ませず個別に確認します。

特に有効なのは、感覚的な語を一度取り除いて指示を読む確認です。

「右上の青い」を削った途端に対象が分からなくなるなら、その指示は感覚的な特徴だけに依存しています。

公開前のチェックリスト

1.3.3への対応は、色や位置を消す作業ではなく、別の方法でも同じ対象を特定できる指示に整える作業です。

視覚的な手掛かりと明確な名前を組み合わせれば、さまざまな利用者が迷いにくい説明になります。

Webアクセシビリティの改善を継続的に進めたい場合は、UUU ウェブアクセシビリティウィジェットツールの詳細もご覧ください。

モバイルバージョンを終了