WCAG 2.2「1.3.6 目的の特定」とは？Level AAAの要件と実装例

WCAG 2.2の達成基準1.3.6「目的の特定」は、マークアップ言語で実装したコンテンツについて、ユーザーインターフェースコンポーネント、アイコン、領域の目的をプログラムで判別できるようにするLevel AAAの基準です。

見た目や表示テキストだけに意味を持たせず、ブラウザや支援技術がコードから目的を取り出せる状態を目指します。

これにより、利用者が理解しやすい記号や表現へ置き換える機能や、必要な領域を強調して不要な領域を隠す機能を提供しやすくなります。

達成基準1.3.6が対象とする情報

WCAG 2.2の達成基準1.3.6は、次の三つの対象について目的をプログラムで判別できることを求めています。

• ユーザーインターフェースコンポーネント：ボタン、リンク、入力欄など、利用者が一つの機能として認識する操作要素です。
• アイコン：検索、ホーム、印刷などの機能や情報を視覚的に示す図記号です。
• 領域：ヘッダー、ナビゲーション、メインコンテンツ、補足情報など、ページ内で役割を持つまとまりです。

プログラムで判別できるとは、制作者がマークアップに与えた情報を、異なるブラウザや支援技術が取得して利用者へ提示できる状態を指します。

色、位置、形だけで目的を伝えている場合は、ソフトウェアがその意味を取り出せないため、この考え方を満たしません。

スクリーンリーダー対応だけを指す基準ではない

適切なマークアップはスクリーンリーダーによる理解や移動を助けますが、達成基準1.3.6の狙いは読み上げ対応だけではありません。

W3Cの達成基準1.3.6解説は、認知や学習に障害のある利用者が、慣れた語句や記号で操作できるようにするパーソナライズも目的として挙げています。

そのため、画面上の名前がわかりやすいかという確認と、目的を機械が再利用できる形で示しているかという確認を分ける必要があります。

ページ領域はセマンティックHTMLで示す

ページの主要な領域には、最初にHTMLの意味を持つ要素を使います。

<header>、<nav>、<main>、<aside>、<footer>は、適切な位置で使うとページ内の役割を支援技術へ伝えられます。

<header>
  <a href="/">ウェブアクセシビリティガイド</a>
</header>

<nav aria-label="主要ナビゲーション">
  <ul>
    <li><a href="/guide/">基礎ガイド</a></li>
    <li><a href="/checklist/">確認項目</a></li>
  </ul>
</nav>

<main id="main-content">
  <section aria-labelledby="section-title">
    <h2 id="section-title">実装例</h2>
    <p>主要な内容をここに置きます。</p>
  </section>
</main>

<footer>
  <p>お問い合わせ先を掲載します。</p>
</footer>

この例では、要素の種類が領域の役割を示し、aria-labelとaria-labelledbyがナビゲーションやセクションの名前を補っています。

同じ種類のナビゲーションが複数ある場合は、「主要ナビゲーション」「記事内ナビゲーション」のように区別できる名前を付けます。

HTML要素がすでに適切なランドマークを持つ場合、同じ意味のroleを重ねる必要はありません。

詳しい領域設計は、サイト内のランドマークとナビゲーションの設計ガイドでも確認できます。

アイコンには操作の名前を与える

アイコンだけを表示するボタンには、操作内容を伝えるアクセシブルな名前が必要です。

<button type="button" aria-label="検索">
  <img src="search-icon.png" alt="">
</button>

この例では、ボタンのaria-labelが「検索」という操作名を示し、画像の空のaltは同じ名前が二重に伝わることを避けます。

画像そのものがリンク先や操作内容を担い、親要素に名前がない場合は、画像のaltに目的を簡潔に記述します。

ただし、アクセシブルな名前を付けただけで、達成基準1.3.6が意図するパーソナライズ可能な目的情報まで必ず満たせるとは限りません。

採用する技術に目的を表す語彙やメタデータの仕様がある場合は、その仕様に従って機械が再利用できる情報を追加します。

ARIAの役割と名前の使い分けは、サイト内のARIAの実装と注意点も参考になります。

目的、名前、状態を混同しない

元の実装例にあったaria-requiredとaria-invalidは有用ですが、どちらも入力欄の目的ではなく状態を示す属性です。

一つの属性ですべてを表そうとせず、要素の役割、名前、状態、入力目的をそれぞれ適切なHTMLとARIAで示します。

フォームでは入力目的と状態を分ける

メールアドレスを入力する欄なら、ラベル、入力型、入力目的、必須状態を別々にマークアップします。

<form action="/contact/" method="post">
  <label for="email">メールアドレス</label>
  <input
    type="email"
    id="email"
    name="email"
    autocomplete="email"
    required>
</form>

autocomplete="email"は入力する情報の目的を示し、requiredは入力が必須であることを示します。

入力エラーが生じたときだけaria-invalid="true"を設定し、利用者が修正方法を理解できるエラーメッセージと関連付けます。

この区別を理解すると、状態を表す属性だけを追加して「目的を特定できた」と判断する誤りを避けられます。

実装から確認までの手順

1. 対象を洗い出す：ページ内のボタン、リンク、入力欄、アイコン、主要領域を一覧にします。
2. 意味を持つHTMLを選ぶ：見た目に合わせた<div>ではなく、目的に合う要素を優先します。
3. 名前と状態を補う：目に見えるラベルだけでは伝わらない情報を、必要に応じてHTMLまたはARIAで補います。
4. 目的のメタデータを確認する：採用技術に共通の目的語彙がある場合は、独自の属性名ではなく仕様に沿った値を使います。
5. コードから取得できるかを調べる：ブラウザのアクセシビリティツリーや支援技術で、役割、名前、状態、領域が意図どおり伝わるかを確認します。
6. 実際の操作で確かめる：キーボード操作と読み上げ順を含め、目的を理解して操作できるかを確認します。

スクリーンリーダーの仕組みと確認項目を先に押さえたい場合は、スクリーンリーダーの基本と実装ポイントを参照してください。

よくある実装上の誤解

すべての領域にrole属性を付ける

セマンティックHTMLがすでに同じ役割を持つ場合、重複するroleを追加しても目的情報は増えません。

まず適切なHTML要素を選び、同種の領域を区別する名前が必要なときにaria-labelまたはaria-labelledbyを使います。

アイコンのaltを必ず埋める

装飾画像や、親のボタンですでに操作名を示している画像では、空のaltが適切な場合があります。

画像が単独で意味を担うのか、親要素の操作を視覚的に補っているだけなのかを判断して設定します。

必須とエラーの状態だけで目的を示せる

requiredやaria-invalidからは、入力が必須か、現在エラーかはわかりますが、氏名、住所、メールアドレスのどれを入力する欄かは判別できません。

ラベル、入力型、autocompleteなどを組み合わせ、目的と状態を別々に伝えます。

確認に使える公式資料

• WCAG 2.2 達成基準1.3.6「Identify Purpose」
• Understanding Success Criterion 1.3.6
• ARIA11「ARIAランドマークでページ領域を識別する」
• Understanding Success Criterion 1.3.5

実装時は、達成基準の本文だけでなく、意図、十分な達成方法、採用技術の対応状況を合わせて確認します。

目的を再利用できるマークアップへ

達成基準1.3.6への対応は、画面にわかりやすい名前を表示するだけでは終わりません。

領域には適切なランドマークを与え、操作要素には名前と状態を与え、利用できる仕様がある場合は目的を機械が再利用できるメタデータとして示します。

この切り分けにより、支援技術とパーソナライズ機能が情報を解釈しやすくなり、利用者が目的を理解して操作できる画面へ近づきます。

当社では、Webアクセシビリティの導入と改善を支援するUUU ウェブアクセシビリティを提供していますので、対応方法を検討している方は詳細をご覧ください。