WCAG 1.3.6: 目的の特定

このルールの意味

\n

WCAG 1.3.6 — Identify Purpose（目的の特定）は、原則1（知覚可能）の下にあるレベルAAAの達成基準で、既存の構造とセマンティクスの要件を、より細かい粒度へと拡張したものです。具体的には、各ユーザーインターフェイスコンポーネント、アイコン、リージョン、および特定の入力フィールドの目的がプログラムによって判別可能であること、つまり、そのセマンティック情報がブラウザ、ブラウザ拡張機能、支援技術が読み取り・利用できる形で公開されていることを求めています。

\n

この達成基準は、1.3.1（情報及び関係性）と1.3.5（入力目的の特定）を直接的に土台としています。1.3.5が氏名、メール、電話番号などの一般的な個人情報入力フィールドに焦点を当てているのに対し、1.3.6は要件をナビゲーションランドマーク、アイコン、ボタン、インタラクティブウィジェットなど、すべてのユーザーインターフェイスのリージョンとコンポーネントへと拡大します。中核となる考え方は、ユーザーエージェントやパーソナライゼーションツールが、マークアップ内に埋め込まれた機械可読な目的データに基づいて、デフォルトのプレゼンテーションを差し替えられるようにすることです。たとえば、テキストラベルをシンボルに置き換えたり、煩雑なナビゲーションを簡略化したり、最も関連性の高いコントロールを強調表示したりできるようにします。

\n

実務的には、ページが1.3.6に適合しているとみなされるのは、HTML5のランドマーク要素（<header>、<nav>、<main>、<aside>、<footer>、<section> など）を使用し、ランドマーク要素を使っていない箇所には適切なARIAランドマークロールを適用し、アイコンやその他の非テキストUIコンポーネントの目的をアクセシブルネームやロールを通じて公開し、さらに該当する場合には、W3C Personalization Semantics仕様（旧称 COGA Semantics 提案）で定義されているような標準化された目的トークン（たとえば aui- 属性語彙を通じて）を使用している場合です。

\n

一方、ページが不適合となるのは、リージョンがセマンティックロールを持たない汎用的な <div> や <span> コンテナとして実装されている場合、アイコンが意味を持っているにもかかわらずアクセシブルネームや補助的なセマンティクスを持たない場合、またはインタラクティブコンポーネントが、その見た目以外に機能を示すプログラム的な手がかりを提供していない場合です。公式な例外も存在します。この要件は、期待される意味を特定するためのサポートがある技術を用いて実装されたコンテンツにのみ適用されます。特定の技術スタックにおいて、あるコンポーネントタイプに対応する支援技術や仕様が存在しない場合、そのコンポーネントにこの達成基準を合理的に適用することはできません。

\n\n

なぜ重要か

\n

WCAG 1.3.6の主な受益者は、ディスレクシア、注意欠如障害、自閉スペクトラム症、記憶障害、知的障害などの認知・学習障害のある人々です。世界保健機関によると、世界人口のおよそ6人に1人、10億人を超える人々が何らかの重大な障害とともに生活しており、その中でも認知障害は最大かつ最も支援が行き届いていないグループの1つです。多くのユーザーは、複雑なナビゲーション構造、テキストが密集したメニュー、セマンティックな手がかりのないアイコンのみのコントロールに苦労しています。

\n

具体的なシナリオを考えてみましょう。重度のディスレクシアがあるユーザーが、標準的なナビゲーションラベルを、自分が日常生活で使っているコミュニケーションボード由来の絵カードアイコンなど、個人的なシンボルセットに置き換えるブラウザ拡張機能に依存しているとします。この置き換えが機能するには、その拡張機能が、特定の <div> が実際にはナビゲーションランドマークであること、星形アイコンが「お気に入りに追加」を表していること、円形の矢印が「再読み込み」を表していることを判別できなければなりません。目的がプログラム的に判別できなければ、拡張機能はフックする対象を持てず、置き換えは何のエラーもなく失敗し、ユーザーは解釈できないインターフェイスのまま取り残されてしまいます。

\n

スイッチアクセスや音声コントロールツールに依存する運動障害のあるユーザーも大きな恩恵を受けます。目的を認識できるツールは、機能が機械可読なコントロールに対してのみショートカットオーバーレイや音声コマンドのマッピングを生成できるからです。スクリーンリーダーを通じて操作する視覚障害のあるユーザーは、明確にラベル付けされたランドマークリージョンから恩恵を受けます。これにより、<main> コンテンツへ直接ジャンプしたり、繰り返しのナビゲーションをスキップしたりできます。ブラウザのズームやカスタムスタイルシートを利用するロービジョンのユーザーも、ランドマーク構造によってコンテンツが予測可能な形でリフローされるため、利便性が向上します。

\n

アクセシビリティを超えて、1.3.6が要求するセマンティクスを実装することは、測定可能なSEO上の利点ももたらします。検索エンジンクローラーは、ランドマークやスキーママークアップを用いてページ構造を理解し、コンテンツ階層をインデックス化し、リッチリザルトを生成します。意味のあるランドマークリージョンを備えた構造化の行き届いたページは、強調スニペットを獲得したり、関連性スコアが高くなったりする可能性が高まります。また、直接的なユーザビリティ上のメリットもあります。明確なセマンティック構造を持つページは、開発チームにとって保守・テスト・拡張が容易であり、長期的な技術的負債を減らします。

\n\n

関連する axe-core ルール

\n

WCAG 1.3.6には、あらゆる自動チェックに加えて手動テストが必要です。自動ツールはセマンティックマークアップの存在を検証できますが、そのマークアップが人間のテスターと同じように、すべてのコンポーネントの目的を正確かつ完全に伝えているかどうかを判断することはできません。以下の axe-core ルールは密接に関連しており、この達成基準の一部の側面に対する自動的な代替指標として機能します。

\n

\n
• region — ページ上のすべてのコンテンツがランドマークリージョン内に含まれているかをチェックします。認識されたランドマーク要素やARIAランドマークロールの外側にあるコンテンツを検出します。このルールは目的特定の正確さをテストするものではありませんが、1.3.6に必要な構造的な基盤が存在することを保証します。不適合の場合、重要なコンテンツがランドマークベースのナビゲーションから見えなくなっていることを意味します。
\n
• landmark-one-main — ページに <main> 要素、または role='main' を持つ要素がちょうど1つ含まれているかを検証します。メインコンテンツ領域は、その目的が特定可能でなければならない最も重要なリージョンの1つであるため、これは1.3.6の基盤となります。複数の、あるいは欠落した <main> ランドマークは、パーソナライゼーションツールが主要コンテンツを特定することを不可能にします。
\n
• landmark-complementary-is-top-level — <aside> 要素や role='complementary' のリージョンが、目的を誤って表現するような形でメインコンテンツ領域内にネストされていないかをチェックします。不適切なネストは、リージョン間の関係について支援技術を誤解させます。
\n
• aria-allowed-role および aria-valid-attr-value — 無効または不適切なARIAロールの割り当てを検出します。1.3.6は正確なロールセマンティクスに依存しているため、（たとえばボタングループに role='navigation' を付与するなど）誤ったロールを使用すると、目的の特定を積極的に損ない、これらのルールによってその不一致が表面化します。
\n
• button-name および link-name — インタラクティブなコントロールにアクセシブルネームがあるかを検証します。アクセシブルネームのないアイコンのみのボタンやリンクは、1.3.6における主要な不適合パターンです。名前のないコントロールの目的は特定できないからです。これらのルールは、aria-label、aria-labelledby、または可視テキストが欠如している場合に警告を出します。
\n

\n

手動テストが必要なのは、自動ツールでは、選択された目的トークンやセマンティックロールが、そのアプリケーションのコンテキストにおけるコンポーネントの実際の機能を正確に表しているかどうかを評価できないためです。ボタンにアクセシブルネームと有効なARIAロールがあっても、その名前が誤解を招くものであったり、ロールが実際の動作を反映していなかったりすれば、1.3.6には不適合となり得ます。

\n\n

テスト方法

\n

\n
1. axe DevTools または Lighthouse で自動スキャンを実行する。ページをChromeで開き、axe DevTools拡張機能を有効にして、ページ全体のスキャンを実行します。結果を、上記の region、landmark-one-main、button-name、link-name ルールでフィルタリングします。違反とその影響度を記録します。Lighthouseでは、Accessibility監査を実行し、ランドマークとARIAのセクションを確認します。すべての不適合をベースラインとして文書化しますが、これらは1.3.6適合の一部に過ぎないことを理解しておきましょう。
\n
2. ブラウザの開発者ツールを使ってランドマーク構造を手動で確認する。DevToolsを開き、Accessibility Treeパネル（Chrome）または Accessibility Inspector（Firefox）に移動し、ページが一貫したランドマーク階層を公開しているかを確認します。トップレベルに1つの <header>、1つの <main>、少なくとも1つの <nav>（複数ある場合は識別用ラベル付き）、および <footer> があることを確認します。意味のあるコンテンツリージョンが、汎用的な <div> や <span> だけでラップされていないことも確認します。
\n
3. NVDA と Firefox でテストする。NVDAを起動し、Firefoxでページを開き、D キーを押してランドマーク間を移動します。各ランドマークが意味のあるロールでアナウンスされ、同じタイプのランドマークが複数ある場合は一意のラベルが付いていることを確認します。Tabキーでアイコンのみのボタンに移動し、NVDAが空文字列やファイル名、「button」のような汎用ラベルではなく、説明的なアクセシブルネームを読み上げることを確認します。
\n
4. VoiceOver と Safari（macOS/iOS）でテストする。VoiceOverを有効にします（macOSでは Cmd+F5）。ローター（Vo+U）を使ってランドマークリストを開き、想定されるすべてのリージョンが表示されることを確認します。インタラクティブなコントロールをTabで移動し、意味のある説明が読み上げられるかを確認します。iOSでは、3本指スワイプで見出しやランドマーク単位に移動し、それぞれのリージョンの目的が正しくアナウンスされることを確認します。
\n
5. JAWS と Chrome でテストする。JAWSを起動した状態でChromeでページを開きます。R キーを押してリージョン間を移動し、各リージョンのロールとラベルが正確であることを確認します。JAWSのバーチャルカーソルを使ってアイコンボタンを読み上げ、その目的が伝わっているかを確認します。JAWSのリンクリスト（Insert+F7）を使って、すべてのリンク名が意味のあるものかを確認します。
\n
6. パーソナライゼーションセマンティクス（実装されている場合）をテストする。ページで W3C Personalization Semantics 語彙（例：data-purpose や aui- 属性）を使用している場合は、Personalization Semantics test tool や、仕様をサポートするユーザーエージェントと互換性のあるブラウザ拡張機能を使って、目的トークンが正しく適用され、機械可読になっているかを検証します。
\n
7. コンポーネントごとの目的監査を実施する。ページ上のすべてのインタラクティブコンポーネントとアイコンについて、「このコンポーネントの目的は視覚的な文脈なしに判別できるか？」と自問します。すべてのCSSと画像を取り除いても、DOMとARIA属性だけからコンポーネントの目的が明確であれば適合です。目的が視覚的な表現だけで伝えられている場合は不適合です。
\n

\n\n

修正方法

\n\n

ランドマークのない汎用 div リージョン — 不適切な例

\n

<div class='site-header'>\n  <div class='logo'>Accsible</div>\n  <div class='main-nav'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </div>\n</div>\n<div class='main-content'>\n  <p>Welcome to our platform.</p>\n</div>\n<div class='sidebar'>\n  <p>Related articles</p>\n</div>\n<div class='site-footer'>\n  <p>© 2025 Accsible</p>\n</div>

\n\n

ランドマークのない汎用 div リージョン — 適切な例

\n

<!-- ブラウザと支援技術が各リージョンの目的を\n     プログラム的に特定できるよう、ネイティブのHTML5ランドマーク要素を使用する -->\n<header>\n  <a href='/' aria-label='Accsible home'>\n    <img src='logo.svg' alt='Accsible' />\n  </a>\n  <nav aria-label='Primary navigation'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </nav>\n</header>\n<main>\n  <p>Welcome to our platform.</p>\n</main>\n<aside aria-label='Related articles'>\n  <p>Related articles</p>\n</aside>\n<footer>\n  <p>© 2025 Accsible</p>\n</footer>

\n\n

アクセシブルネームのないアイコンのみのボタン — 不適切な例

\n

<!-- 目的がプログラム的に判別できないアイコンボタン。\n     アクセシブルネームがまったくない -->\n<button class='btn-icon'>\n  <svg viewBox='0 0 24 24' width='24' height='24'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

アクセシブルネームのないアイコンのみのボタン — 適切な例

\n

<!-- aria-label によってボタンにプログラム的に判別可能な\n     目的を与える。ラベルで意味が伝わるため、SVGは支援技術から隠す -->\n<button class='btn-icon' aria-label='Add to favourites'>\n  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

識別ラベルのない複数のナビゲーションランドマーク — 不適切な例

\n

<!-- 2つの nav 要素が同一のロールを持つがラベルがないため、\n     スクリーンリーダーはそれぞれの目的を区別できない -->\n<nav>\n  <a href='/home'>Home</a>\n  <a href='/about'>About</a>\n</nav>\n\n<nav>\n  <a href='/page1'>Chapter 1</a>

(Content truncated due to token limit — please retry this article.)