WCAG 1.3.3: 感覚的特徴

このルールが意味すること

WCAG 達成基準 1.3.3 — 感覚的な特徴 (レベル A) は、コンテンツを理解し操作するために提供される指示が、形状、サイズ、画面上の位置、向き、音などのコンポーネントの感覚的な特徴のみに依存してはならないと定めています。言い換えると、インターフェイスが、見た目だけ、画面上の位置だけ、または音だけを手がかりにしてユーザーに操作を指示している場合、その指示は、その特定の感覚的な属性を知覚できないユーザーにとっては意味をなさないということです。

ここでのキーワードは「のみ」です。この達成基準は感覚的な参照の使用を禁止しているのではなく、それを識別の唯一の手段とすることを禁止しています。「左側の丸い緑のボタンをクリックしてください」という指示は、ユーザーが緑色を識別できない場合、ボタンの形が見えない場合、あるいはリフローしたレイアウトのために左右が判断できない場合に破綻します。しかし、「送信ボタン（左側の丸い緑のボタン）をクリックしてください」であれば、テキストラベル「送信」が色や形、位置とは独立して機能する非感覚的な識別子を提供しているため、要件を満たします。

この達成基準の対象となる指示には、ユーザーに行動を促したり情報の場所を示したりするテキスト、音声、視覚コンテンツが含まれます。よくある不適合パターンには次のようなものがあります。

• 「続行するには右側のボタンをクリックしてください」 — 視覚的な位置のみに依存している。
• 「設定を開くには四角いアイコンを選択してください」 — 形状のみに依存している。
• 「必須フィールドは赤で表示されています」 — 色のみに依存している。
• 「チャイムが聞こえたら次のステップに進んでください」 — 音のみに依存している。
• 「大きいタイルをタップしてセクションを展開してください」 — サイズのみに依存している。

適合する指示には、必ず少なくとも 1 つの非感覚的な識別子 — 典型的にはテキストラベル、プログラム上の名前、見出しなど — が含まれます。これにより、支援技術に依存しているユーザーや、感覚的な手がかりが利用できない状況で操作しているユーザーも、指示に従うことができます。この達成基準は特に指示を対象としている点に注意してください。すべての UI 要素を再設計することを求めているわけではありませんが、それらの要素についてのテキストまたは音声による案内は、感覚的な識別なしでも知覚できるようにする必要があります。

1.3.3 自体には公式な例外は定義されていませんが、Understanding 文書では、非感覚的な識別子に加えて感覚的な特徴を用いているコンテンツは完全に適合していると明確にしています。また、この達成基準は 1.4.1（色の使用）を補完するものですが、別個のものであり、1.4.1 が色だけを扱うのに対し、1.3.3 はすべての感覚モダリティを対象とする、より広い範囲を持っています。

なぜ重要か

感覚情報のみに基づく指示は、幅広いユーザーにとって大きな障壁となります。影響を受ける各グループを考えてみましょう。

全盲およびロービジョンのユーザーは、スクリーンリーダーや拡大ソフトに依存しています。「右上のアイコンをクリックしてください」という指示があっても、タブ順や見出し構造でナビゲートしているスクリーンリーダーユーザーには、視覚レイアウト上の「右上」という概念がありません。同様に、重度のロービジョンで 400% までズームしているユーザーは、一度に画面の一部しか見えないため、「左のパネル」や「下部のセクション」といった位置に基づく参照はまったく信頼できません。世界保健機関によると、世界で約 22 億人が何らかの視覚障害を抱えており、これは最も大きな影響を受ける集団の 1 つです。

色覚障害のあるユーザー — 男性の約 12 人に 1 人、女性の約 200 人に 1 人に影響 — は、特定の色の組み合わせを識別できません。「赤でハイライトされたフィールドは必須です」という指示は、赤緑色覚障害のある人にとっては区別の手がかりとして機能しません。1.4.1 は UI 要素自体についてこれを扱いますが、1.3.3 は指示テキストにも代替手段を提供することを求めています。

ろう者および難聴のユーザーは、音声のみの手がかりによって影響を受けます。e ラーニングプラットフォームが「ベルが鳴ったら進んでください」と指示する場合、ベルが聞こえないユーザーは排除されます。このパターンは、インタラクティブなプレゼンテーション、動画ベースのチュートリアル、時間制限付きの評価などで見られます。

認知障害や学習障害のあるユーザーは、特に支援技術がコンテンツを視覚的な位置情報を取り除いた線形の形でレンダリングする場合、方向を示す言葉の理解に苦労することがあります。スイッチデバイスや視線入力システムを使用している人も、設計者が想定した 2 次元の空間レイアウトとは無関係な順序でナビゲートします。

具体的な現実のシナリオを考えてみましょう。トルコ政府の電子行政ポータルが、市民に対して「青で囲まれたフィールドに入力し、三角形のボタンを押して申請を送信してください」と指示しているとします。フォームフィールドでナビゲートしている全盲のユーザーは、スクリーンリーダーを通じてフィールドラベルを聞くことはできますが、どのフィールドが青で囲まれているかを知る手段がなく、ボタンを三角形の形で識別することもできません。申請プロセスは事実上ブロックされます。「氏名、ID 番号、生年月日は必須です」といった実際のフィールドラベルと、ボタンのテキストラベル（「申請を送信」など）を追加するだけで、この障壁は即座に解消されます。

アクセシビリティの観点を超えても、感覚情報のみに基づく指示を取り除くことは、すべての人にとってのユーザビリティ向上につながります。レスポンシブデザインではコンテンツがリフローされるため、位置に基づく参照はモバイルでは不正確になります。ダークモードやハイコントラストテーマでは色の表示が変わります。ページの指示を音声アシスタントが読み上げると、視覚的な文脈はすべて失われます。一時的な感覚的属性ではなく、安定したプログラム上のラベルに基づいて指示を構築することで、あらゆるデバイスやコンテキストにおいてコンテンツがより堅牢になり、SEO や保守性の面でも直接的なメリットがあります。

関連する axe-core ルール

WCAG 1.3.3 には手動テストが必要です。なぜなら、自動化ツールは自然言語による指示の意味や意図を信頼性高く解釈することができないからです。静的解析エンジンはボタンの存在や色の使用を検出することはできますが、指示文の段落を読み、その文がボタンを参照していることを理解し、その参照が感覚的な特徴のみに基づいているかどうかを判断することはできません。これは意味と文脈に基づく判断であり、人によるレビューが必要です。

• 手動レビューが必須 — 1.3.3 専用の axe-core ルールは存在しません。 color-contrast や label などの axe-core ルールは（たとえばアクセシブルネームのないボタンなど）関連する問題を表面化させることがありますが、別の達成基準を扱っています。1.3.3 については、人間のテスターがページ上のすべての指示文を読み、感覚的な参照（形、色、サイズ、位置、向き、音）を特定し、それぞれの参照に少なくとも 1 つの非感覚的な識別子が伴っているかを確認する必要があります。「下の緑のボタンをクリックしてください」といった文を、自動ツールが違反としてフラグ付けすることはありません。自然言語の意図を解析することは、現在のルールベースの自動化の範囲を超えているからです。
• ここで自動化が失敗する理由: 「大きいボタンをクリックしてください」という文には「ボタン」という単語が含まれており、自動ツールはこれをアクセシブルロールへの参照と解釈するかもしれません。しかし、この指示は依然としてサイズ（「大きい」）だけに頼って他のボタンと区別しています。自動ツールは、「大きい」が唯一の識別特性なのか、それともページ上にボタンが 1 つしかなく（その場合「大きい」という表現は冗長ではあるが有害ではないのか）を判断できません。こうした文脈依存のニュアンスを評価するには、人間の判断が不可欠です。
• 手動レビューと併用すべき補完的な axe ルール: color-contrast、label、button-name、aria-label のチェックを実行することで、指示で参照されている UI 要素に実際にプログラム上の名前が付いているかを確認できます。これは、非感覚的な指示を書くための前提条件です。ボタンにアクセシブルネームがなければ、感覚的な手がかりに頼らずに意味のある形でそのボタンを指示で参照することはできません。

テスト方法

1. まず自動スキャンを実行する（axe DevTools または Lighthouse）: Chrome でページを開き、axe DevTools 拡張機能を有効にして、ページ全体のスキャンを実行します。1.3.3 に直接対応するルールはありませんが、「color」「label」「name」カテゴリでフラグ付けされた問題を確認します。これらの結果はベースラインを提供します。UI 要素にアクセシブルネームがない場合、それを参照する指示テキストはほぼ確実に感覚的な手がかりに依存しています。結果をエクスポートし、プログラム上のラベルがないすべてのインタラクティブ要素を記録します。
2. すべての指示テキストを手動で特定する: ユーザーに行動を促したり情報の場所を示したりするページ上のすべての文を読みます。これには、ヘルプテキスト、フォームのヒント、ツールチップ、チュートリアルのオーバーレイ、エラーメッセージ、オンボーディングフローが含まれます。各指示のリストを作成し、感覚的な参照をハイライトします。色を表す語（red, blue, green）、形を表す語（round, square, triangular）、サイズを表す語（large, small, big）、位置を表す語（left, right, top, bottom, above, below, corner）、向きを表す語（horizontal, vertical）、音を表す語（chime, beep, alert sound）などです。
3. 各感覚的参照に追加の非感覚的識別子があるか評価する: 見つかった各感覚的参照について、非感覚的な識別子も存在するかどうかを判断します。非感覚的な識別子には、要素の可視ラベルまたはアクセシブルネームと一致するテキストラベル、見出し、番号付きステップ、固有のプログラムロール、ARIA ラベルなどが含まれます。参照されている要素を識別する唯一の方法が感覚的な知覚である場合、その指示は 1.3.3 に不適合です。
4. スクリーンリーダー（NVDA + Firefox）でテストする: キーボードと NVDA のみを使用してページをナビゲートします。すべてのインタラクティブ要素を Tab キーで移動し、NVDA がそれぞれをどのようにアナウンスするかを聞きます。そのうえで、ページ上の指示テキストを読み、「これらのアナウンスだけを聞いているユーザーが指示に従えるか」を自問します。指示が「右側のアイコンをクリックしてください」となっていても、NVDA がその要素を「設定、ボタン」とアナウンスするのであれば、位置の参照は余分ではあるものの、ラベルによって指示はナビゲート可能です。一方、NVDA がその要素を名前なしの「ボタン」とだけアナウンスする場合、視覚的な位置に依存した指示は完全に破綻します。
5. VoiceOver + Safari（macOS/iOS）でテストする: VoiceOver を有効にし、ページをナビゲートします。ローターを使ってボタン、リンク、フォームコントロールごとに移動します。指示で参照されているすべての要素が、視覚レイアウト上の位置に頼ることなく、アナウンスされる名前だけで到達・識別できることを確認します。
6. JAWS + Chrome でテストする: Chrome でページを開き、JAWS を有効にします。フォームモードを使って入力欄をナビゲートし、フィールドのアナウンスを聞きます。色や位置を使って必須フィールドを示しているフォームレベルの指示と照らし合わせて確認します。
7. ハイコントラストモードとダークモードでテストする: OS をハイコントラストモードに切り替え、ページを再読み込みします。特定の色を参照する色分けされた指示は、色の表示が変化すると曖昧になったり見えなくなったりする可能性があります。これにより、唯一の感覚的手がかりとして色に依存している箇所が浮き彫りになります。
8. ズームまたはリフローしたモバイルビューでテストする: ブラウザウィンドウを幅 320px にリサイズするか、モバイルデバイスを使用します。「左サイドバー」や「上部ナビゲーション」といった位置に基づく言葉を使った指示が、レイアウトが 1 カラムにリフローした後でも意味を持つことを確認します。

修正方法

色のみで必須フィールドを示す指示 — 不適切な例

<p>Fields shown in red are required.</p>
<label for='email'>Email Address</label>
<input type='email' id='email' style='border-color: red;' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

色のみで必須フィールドを示す指示 — 適切な例

<!-- The instruction now uses a text marker AND color, not color alone.
     The asterisk and the word "required" provide non-sensory identification. -->
<p>Fields marked with an asterisk (*) are required.</p>
<label for='email'>Email Address <span aria-hidden='true'>*</span></label>
<input type='email' id='email' aria-required='true' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

位置だけでボタンを参照する指示 — 不適切な例

<p>To save your work, click the button on the right side of the toolbar.</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

位置だけでボタンを参照する指示 — 適切な例

<!-- The instruction now references the button by its visible text label "Save",
     which matches the button's accessible name. Position is still mentioned
     but is no longer the sole identifier. -->
<p>To save your work, click the <strong>Save</strong> button (located on the right side of the toolbar).</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

形だけでアイコンナビゲーションを示す指示 — 不適切な例

<p>Tap the circular icon to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

形だけでアイコンナビゲーションを示す指示 — 適切な例

<!-- The button now has an accessible name via aria-label.
     The instruction references "Home" by name, not just by shape. -->
<p>Tap the <strong>Home</strong> button (the circular icon) to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home' aria-label='Home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

音だけで進行状況を示す手がかり — 不適切な例

<p>Listen for the beep to know when the upload is complete.</p>
<button type='button' id='upload-btn'>Upload File</button>
<audio id='complete-chime' src='chime.mp3'></audio>

音だけで進行状況を示す手がかり — 適切な例

<!-- A visible and screen-reader-accessible status message supplements the audio cue.
     Deaf users and users in silent environments now receive the same information. -->
<p>When the upload is complete, you will hear a chime and a <strong>"Upload Complete"</strong> message will appear below.</p>
<button type='button' id='upload-btn'>Upload File</button>
<div role='status' aria-live='polite' id='upload-status'></div>
<audio id='complete-chime' src='chime.mp3'></audio>
<!-- JavaScript sets #upload-status text to "Upload Complete" on success -->

よくある間違い

• 「赤いボタン」や「緑のフィールド」といった表現を唯一の識別子としてフォームの指示やヘルプテキストに用い、ボタンの可視ラベルやフィールド名を併記しない — これは 1.3.3 と 1.4.1 の両方に不適合です。
• 「左側のメニュー」や「上部のパネル」といった位置を示す表現をヘルプドキュメントやオンボーディングフローで使用しながら、メニューやパネルの名前を示さないため、レスポンシブリフローでレイアウトが 1 カラムに折りたたまれた後には指示が役に立たなくなる。
• アイコンを形だけで説明する（「三角形の再生ボタンをクリックしてください」など）一方で、スクリーンリーダーユーザーがキーボードナビゲーションで実際に見つけられるようなアイコンのアクセシブルネームやラベルを使用しない。
• 必須フォームフィールドを枠線や背景色だけで示すインライン指示（「オレンジ色のフィールドは必須です」など）を用いながら、同じ情報をプログラム的に伝える記号、ラベルの接尾辞、aria-required='true' 属性などを付与しない。
• インタラクティブな処理に対して音声のみのフィードバックを配置し（ファイルアップロード、フォーム送信、タイマーの終了など）、role='status' や aria-live='polite' を用いた対応する可視テキストのステータス更新を提供しない。
• サイズを唯一の識別手がかりとして使用する — 「大きいカードをクリックして展開してください」といった指示は、ユーザーがズームした場合、小さいビューポートでカードが同じサイズでレンダリングされる場合、あるいはスクリーンリーダーユーザーが DOM 上の相対的なカードサイズの概念を持たない場合に破綻します。
• 「横にスワイプしてナビゲートしてください」といった向きに基づく手がかりに依存し、説明しているカルーセルやスライダーに対して、代替の操作方法や向きに依存しないラベルを提供しない。
• エラーメッセージも指示であることを忘れる — 「下のハイライトされたフィールドに誤りがあります」といったエラーは、視覚的なハイライトと位置的な近接に依存しており、各誤りフィールドがエラーメッセージ内で明示的に名前を挙げられていない限り、スクリーンリーダーユーザーには役に立ちません。
• アイコンに alt テキストを追加すれば指示が修正されると誤解する — 指示文が依然として「丸いアイコンをクリックしてください」としか述べていない場合、画像要素に alt テキストが付いていても、その指示文が適合になるわけではありません。指示文自体に非感覚的な識別子を含める必要があります。
• シングルページアプリケーションで動的に挿入される指示を見落とす — JavaScript によって挿入されるツールチップ、モーダル、ウィザードステップには、静的ページの監査では見落とされがちな感覚情報のみのガイダンスが含まれていることがよくあります。

トルコのアクセシビリティ規制との関係

トルコの大統領通達 2025/10 は、2025 年 6 月 21 日付官報第 32933 号で公布され、トルコで事業を行う幅広い公的・民間組織に対して、ウェブアクセシビリティ要件を義務付けています。この通達は、WCAG 2.1 レベル AA への適合をベースライン標準として義務付けており、レベル A の達成基準である WCAG 1.3.3 も、対象となるすべての組織にとって完全に必須となります。

通達の対象となる組織には、公的機関・行政機関、e コマースプラットフォーム、銀行・金融機関、病院・医療提供者、20 万人以上の加入者を持つ通信会社、旅行代理店、民間の交通事業者、国民教育省（MoNE）に認可された私立学校が含まれます。公的機関は通達の公布日から 1 年以内に完全な適合を達成しなければならず、民間セクターには 2 年の猶予期間が与えられています。

WCAG 1.3.3 は、トルコのデジタルサービスにとって特に重要です。トルコの電子政府ポータル、バンキングアプリケーション、e コマースのチェックアウトフローでは、色分けされたフォームガイダンスやアイコンのみのナビゲーションパターンが広く使われているからです。たとえば、ある公的機関のオンライン申請フォームが、市民に対して「赤でマークされたフィールドに入力し」「右下のボタンを押して」送信するよう指示している場合、これは 1.3.3 に明確に違反しており、大統領通達への不適合となります。同様に、複数ステップの取引を位置や色の手がかりだけで案内している銀行のモバイルウェブインターフェイスも、民間セクターに与えられた 2 年の期限までに改訂する必要があります。

トルコのデジタルアクセシビリティを取り巻く規制環境が成熟するにつれ、不適合は評判面および法的なリスクを伴います。対象組織は、1.3.3 への適合を単なる軽微な編集上の修正ではなく、すべての指示コンテンツ — ヘルプテキスト、エラーメッセージ、オンボーディングフロー、サポートドキュメントを含む — を体系的に見直し、感覚的な参照には常に安定したプログラム上のテキストベースの識別子を併記することを確認する取り組みとして捉えるべきです。Accsible のオーバーレイ SDK は、多くの関連問題の検出と修正を支援できますが、1.3.3 が要求する手動でのコンテンツレビューは、最終的には自動化ツールと連携して作業する資格を持つ人間の監査者によって実施されなければなりません。