WCAG 達成基準 · Level AA
WCAG 3.2.4: 一貫した識別
WCAG 3.2.4 は、ウェブサイト全体で同じ機能を果たすコンポーネントが一貫して識別されること、つまり表示されるたびに同じラベル、名前、または代替テキストを使用することを求めています。これは、ナビゲーションやデジタルインターフェースの理解において、一貫したパターンに依存しているユーザーが混乱するのを防ぐためです。
- Level AA
- Wcag
- Wcag 2 2 aa
- 理解できる
- アクセシビリティ
このルールの意味
WCAG達成基準 3.2.4「一貫した識別」は、一連のウェブページ内で同じ機能を持つコンポーネントは一貫して識別されなければならない、と定めています。これは、インタラクティブ要素や画像が同じ機能を果たす場合、サイト全体でその要素が現れるたびに、同じアクセシブルネームまたはラベルを持つべきであることを意味します。
この文脈での「識別される」とは、コンポーネントが支援技術およびユーザーにどのように提示されるかを指します。これには、目に見えるラベルテキスト、aria-label や aria-labelledby 属性、画像の alt テキスト、title 属性、あるいはブラウザのアクセシビリティツリーによって算出されるアクセシブルネームが含まれます。検索ボタンがサイトのすべてのページに表示される場合、その名称は常に「Search」でなければなりません。ホームページでは「Search」、商品一覧ページでは「Find」、チェックアウトページでは「Go」といった具合に変えてはいけません。
この達成基準は一連のウェブページに適用されます。WCAGはこれを、共通の目的を共有し、同じ作成者によって制作されたページの集合と定義しています。これは、1つのウェブサイト、ウェブアプリケーション、または複数のURLにまたがる複数ステップのフォームを含みます。見た目が似ているだけで異なる機能を果たすコンポーネントは、同じ名前を共有する必要はありません。この要件は、機能が同一であることに特に結びついています。
適合とみなされる例: ハンバーガーメニューを開くナビゲーションアイコンが、すべてのページで一貫して「Open navigation menu」(または同等の表現)とラベル付けされている。ショッピングカートアイコンが常に「Shopping cart」というaltテキストまたはアクセシブルネームを持っている。ログアウトボタンが常に「Log out」とラベル付けされている。同じ機能に対する文言のばらつきは不適合となります。
不適合とみなされる例: 登録フォームでは「Submit」とラベル付けされた送信ボタンが、問い合わせフォームでは「Send」とラベル付けされている場合で、どちらのボタンもユーザーが入力したデータを送信するという同じ機能的目的を持っているケース。虫眼鏡アイコンのボタンがほとんどのページでは「Search」とラベル付けされている一方で、翻訳されたサブページの1ページだけ「Ara」となっており、一貫した言語戦略が存在しないケース。
公式な例外: WCAGは、同じアクセシブルネームを持ちながら異なる機能を果たす2つのコンポーネントが存在してもよいと明示しています。この場合は、機能の違いそのものが両者を区別します。この達成基準が問題となるのは、機能が同一であるにもかかわらず命名が一貫していない場合に限られます。
なぜ重要か
一貫しない識別は、非視覚的またはパターンベースのナビゲーション戦略に依存するユーザーに過度の負担を与えます。最も深刻な影響を受けるグループには、スクリーンリーダーユーザー、認知障害のあるユーザー、音声コントロールソフトウェアに依存する運動障害のあるユーザーが含まれます。
スクリーンリーダーユーザーは、タブ移動やランドマークによるブラウズを通じて要素名を聞くことで、ウェブサイトのメンタルモデルを構築します。前のページで同じ機能を果たしていたボタンが、別の名前になっていると、ユーザーは立ち止まり、調べ、再び状況を把握し直さなければならず、時間がかかりフラストレーションのたまる体験になります。世界保健機関によると、世界で約2.2億人が何らかの視覚障害を抱えています。その一部でも、一貫性のないラベル付けがされたサイトを利用すれば、重大な障壁に直面することになります。
認知障害のあるユーザー(ディスレクシア、注意欠如障害、記憶障害などを含む)は、認知負荷を減らすために予測可能な命名に大きく依存しています。見慣れたアイコンやコントロールが別の名前で現れると、再学習を強いられ、不安を引き起こします。一貫したラベリングは、サイトを継続的に利用する際に手続き記憶を構築するために必要な労力を減らします。
音声コントロールユーザー(Dragon NaturallySpeaking や AppleのVoice Controlなどのツールを使用)は、コントロールの名前を話してそれを起動します。ボタンのアクセシブルネームが、サイトでの過去の経験に基づいて期待しているものと異なる場合、音声コマンドは何の反応もなく失敗します。ソフトウェアが一致するものを見つけられないためです。その瞬間、そのインターフェースは事実上利用不能になります。
具体的な実世界のシナリオ: 衣料品を販売するトルコのECプラットフォームを考えてみましょう。商品グリッドページでは、各商品にハートアイコンのボタンがあり、そのアクセシブルネームは「Add to favourites」です。商品詳細ページでは、同じハートアイコンのアクセシブルネームが「Kaydet」(トルコ語で「保存」)になっています。グリッドページでハートボタンを名前で起動することを学んだスクリーンリーダーユーザーは、詳細ページで同等のコントロールを見つけるために徹底的に探索しない限り、見つけられません。その結果、サイトの利用を完全に諦めてしまうかもしれません。
アクセシビリティにとどまらず、一貫したラベリングはSEOにも有益です。検索エンジンは、ページ内容を理解するためにアクセシブルネームやリンクテキストを解析します。機能的に同一のリンクに対して一貫しないラベリング(例: 記事詳細ページへのリンクに「Read more」「Continue reading」「Learn more」など異なる文言を使う)は、キーワードシグナルを希薄化し、クローラーがサイト構造を理解することを難しくします。
関連する axe-core のルール
WCAG 3.2.4は、ページをまたいだ意味的意図を自動ツールが判断できず、名前の異なる2つのコンポーネントが同じ機能を果たしているかどうかを知ることもできないため、手動テストが必要です。この達成基準に直接対応するaxe-coreルールは存在しません。ここでは、自動化が不十分な理由と、テスターが代わりに行うべきことを説明します。
- 手動テストが必要 — ページ間の一貫性: Axe-coreは単一ページを個別に評価します。ホームページの「Search」ボタンのアクセシブルネームと、商品ページの「Find」ボタンのアクセシブルネームを比較する仕組みはありません。コンポーネント名のページ横断的なインベントリを保持しないためです。人間のテスターが、繰り返し現れる機能的要素を一覧化し、それらが現れるすべてのページで命名が統一されているかを確認する必要があります。
- 手動テストが必要 — アイコンおよび画像のaltテキストの一貫性: 自動ツールは(
image-altルールを通じて)altテキストの欠如を検出できますが、同じ目的を果たす2つの画像が、異なるページにわたって同じaltテキストを持っているかどうかを判断することはできません。例えば、領収書ページのプリンターアイコンと請求書ページの同じプリンターアイコンは、どちらもaltテキストを持っているかもしれません。しかし、一方が「Print」、もう一方が「Print this page」となっている場合、これが3.2.4における不一致に該当するかどうかは、人間が判断しなければなりません。 - 手動テストが必要 — ARIAラベルの一貫性: Axe-coreはARIAラベルが存在し空でないことを確認しますが、同じコンポーネントタイプに対する
aria-labelの値が、ページ全体で一貫しているかどうかを監査することはありません。テスターは複数のページでアクセシビリティツリーを確認し、機能的に同一のコントロールの名前を比較する必要があります。 - 手動テストが必要 — フォームコントロールのラベル:
labelのような自動ルールは、入力欄がラベルと関連付けられているかを検証しますが、ログインページの「Username」フィールドが、アカウント復旧ページでも「Username」とラベル付けされているか(同じタイプの入力を受け付け、同じ機能的役割を果たしているにもかかわらず「Email」や「User ID」となっていないか)までは確認しません。
テスト方法
- 自動プリスキャン: 各ページでaxe DevToolsまたはLighthouseを実行し、アクセシブルネームの欠如(
image-alt、button-name、link-nameなど)といった関連する違反を洗い出します。まずこれらを解消します。名前が存在しなければ、一貫性を評価できないためです。スキャン結果から、繰り返し現れるコンポーネントに報告されているアクセシブルネームをメモします。 - コンポーネントインベントリの作成: ページをまたいで繰り返し現れるすべての機能的コンポーネント(ナビゲーションメニュー、検索入力、送信ボタン、アイコンボタン、パンくずリンク、ソーシャルメディアリンク、印刷/共有ボタン、ページネーションコントロール)を手動で一覧化します。Chrome DevToolsのAccessibilityパネル(Elements > Accessibility)やFirefox Accessibility Inspectorを使って、それぞれのインスタンスのアクセシブルネームを記録します。
- ページ間で名前を比較: インベントリ内の各コンポーネントタイプについて、すべてのインスタンスが同じアクセシブルネームを持っているか確認します。差異があればフラグを立てます。特に、ページヘッダー、フッター、サイドバーに現れるコンポーネントに注意してください。これらはテンプレート間でラベルが不一致になりやすい部分です。
- NVDA + Firefoxによるスクリーンリーダーテスト: ホームページに移動し、NVDAの要素リスト(Insert + F7)を使ってボタンとリンクのリストを開きます。繰り返し現れるコントロールの名前を確認します。その後、代表的な3〜4ページに移動して同じ操作を繰り返します。機能的に同一のコントロールで名前の変化がないかを聞き分けます。
- VoiceOver + Safari(macOS/iOS)によるスクリーンリーダーテスト: 各ページでRotor(VO + U)を使ってボタンまたはリンクのリストを表示します。繰り返し現れる要素の名前を比較します。iOSでは、同等のページ上のインタラクティブ要素をスワイプで移動し、命名の違いがないか確認します。
- JAWS + Chromeによるスクリーンリーダーテスト: JAWSの仮想カーソルと、フォームフィールドのリスト(Insert + F5)、リンクのリスト(Insert + F7)を複数ページで使用します。サイト全体で、同一のコントロールが同一の名前を共有していることを確認します。
- 音声コントロールテスト: Windows Voice AccessやDragon NaturallySpeakingを使用し、あるページで繰り返し現れるコントロールの名前(例: 「Click Search」)を発話します。別のページに移動して同じコマンドを発話します。動作しない場合、機能的観点から名前が一貫していないことを意味します。
修正方法
検索ボタンのラベルが一貫していない — 不正
<!-- Homepage -->
<button type='submit' aria-label='Search'>
<svg aria-hidden='true'>...</svg>
</button>
<!-- Product listing page -->
<button type='submit' aria-label='Find products'>
<svg aria-hidden='true'>...</svg>
</button>
<!-- Blog page -->
<button type='submit' aria-label='Go'>
<svg aria-hidden='true'>...</svg>
</button>
検索ボタンのラベルが一貫していない — 正
<!-- Homepage, product listing page, and blog page all use the same label -->
<!-- Consistent aria-label across all pages ensures assistive technologies
always announce the same name for this functionally identical button -->
<button type='submit' aria-label='Search'>
<svg aria-hidden='true'>...</svg>
</button>
同じアクションに使うアイコン画像のaltテキストが異なる — 不正
<!-- Order history page -->
<a href='/print/order/123'>
<img src='/icons/print.svg' alt='Print order' />
</a>
<!-- Invoice page -->
<a href='/print/invoice/456'>
<img src='/icons/print.svg' alt='Print this document' />
</a>
<!-- Receipt page -->
<a href='/print/receipt/789'>
<img src='/icons/print.svg' alt='Yazdir' />
</a>
同じアクションに使うアイコン画像のaltテキストが異なる — 正
<!-- All print links across the site share the same alt text.
The destination URL differentiates which document is printed;
the control's accessible name remains consistent. -->
<a href='/print/order/123'>
<img src='/icons/print.svg' alt='Print' />
</a>
<a href='/print/invoice/456'>
<img src='/icons/print.svg' alt='Print' />
</a>
<a href='/print/receipt/789'>
<img src='/icons/print.svg' alt='Print' />
</a>
ナビゲーションの閉じるボタンの名前が一貫していない — 不正
<!-- Mobile menu on homepage -->
<button aria-label='Close menu' aria-expanded='true' aria-controls='nav-menu'>
<svg aria-hidden='true'>...</svg>
</button>
<!-- Mobile menu on product page (different developer implemented it) -->
<button aria-label='Dismiss navigation' aria-expanded='true' aria-controls='nav-menu'>
<svg aria-hidden='true'>...</svg>
</button>
ナビゲーションの閉じるボタンの名前が一貫していない — 正
<!-- A shared component/template ensures the label is identical everywhere.
Using a single reusable component or design token for the label
eliminates the risk of developer-introduced inconsistencies. -->
<button aria-label='Close navigation menu' aria-expanded='true' aria-controls='nav-menu'>
<svg aria-hidden='true'>...</svg>
</button>
ソーシャル共有リンクの名前がばらついている — 不正
<!-- Article page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
<svg aria-hidden='true'>...</svg>
</a>
<!-- Video page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Tweet this'>
<svg aria-hidden='true'>...</svg>
</a>
ソーシャル共有リンクの名前がばらついている — 正
<!-- Both pages use the same accessible name for the functionally
identical sharing action. The URL parameter carries the context;
the control name stays uniform. -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
<svg aria-hidden='true'>...</svg>
</a>
よくある間違い
- 同じコンポーネントに対してテンプレートごとに異なる
aria-label値を使う: 共有コンポーネントライブラリなしに、別々の開発者がページテンプレートを個別に構築すると、閉じる、検索、カートなどのアイコンボタンに場当たり的なラベルが付けられがちです。繰り返し現れるすべてのインタラクティブ要素に対してデザインシステムのトークンや共有コンポーネントを用意し、アクセシブルネームを一度定義してどこでも再利用するようにします。 - 多言語ページ間でアクセシブルネームを一貫せずに翻訳する: サイトが英語では検索ボタンを正しく「Search」とラベル付けしていても、トルコ語版ではページテンプレートごとにローカライズされたタイミングに応じて、「Ara」だったり「Arama Yap」だったりと不一致な訳語を使っている場合があります。コンポーネントラベルごとに単一の翻訳キーを維持し、すべてのロケールファイルでそれを徹底します。
- 本質的には同一のコントロールに文脈固有の接尾辞を付ける: コア機能(カートに追加)が同じであるにもかかわらず、「Add to cart — Blue T-Shirt」「Add to cart — Red Dress」などとボタンにラベル付けすることは、自動的に3.2.4違反になるわけではありません。WCAGは識別のための差別化を認めています。しかし、あるときは接尾辞付き、あるときはなしといった不一致な運用は混乱を招きます。どちらか一方のパターンを選び、統一して適用してください。
- 見えるテキストラベルの一貫性だけに頼り、
aria-labelの上書きが異なることを見落とす: ボタンの見た目のテキストが「Search」であっても、あるテンプレートではaria-label='Search the site'を追加し、別のテンプレートではaria-labelを付けず(そのためアクセシブルネームは可視テキストからのみ算出される)にしていると、見た目は同じでもスクリーンリーダーが読み上げる名前は異なります。可視ラベルだけでなく、アクセシブルネームの算出全体を監査してください。 - CMSの編集者にアクセシビリティガバナンスなしでボタンテキストを自由に変更させる: ボタンラベルを編集可能なフィールドとして公開しているコンテンツ管理システムでは、編集者が個人的な好みに基づいて「Submit」を「Send」や「Gönder」に変更できてしまいます。機能的なUIコンポーネントのラベル編集を制限するか、標準から逸脱したラベルが提案されたときに警告するバリデーションを追加してください。
- サードパーティウィジェットや埋め込みコンポーネントの監査を怠る: チャットウィジェット、クッキー同意バナー、サードパーティが挿入する決済iframeなどには、ホストサイトの慣例とは異なるラベルのボタンが含まれていることがよくあります。可能な限り、サードパーティのアクセシブルネームを見直し、自サイトの命名規則に合わせて設定するか、例外として文書化してください。
- 一部のインスタンスではツールチップテキスト(
title属性)だけをアクセシブルネームとして使い、他ではaria-labelを使う:title属性はすべての支援技術で確実に読み上げられるわけではなく、弱いアクセシブルネームの情報源と見なされています。繰り返し現れるコンポーネントの一部がtitleを使い、他がaria-labelを使っていると、ブラウザやスクリーンリーダーの扱いの違いにより、算出される名前が異なる可能性があります。 - ページ番号が異なるからといってページネーションコントロールは対象外だと考える: 「Next page」と「Previous page」のコントロールは、ラベルにページ番号(例: 「Go to page 3」)が含まれていても、一貫したパターンを適用しなければなりません。同じページネーションコントロールに対して、あるページでは「Next」、別のページでは「Next page」や「İleri」といった具合に混在させると、3.2.4に違反します。
- すべての異なるページテンプレートでヘッダーとフッターコンポーネントをテストしない: サイトには、ホームページ、カテゴリーページ、記事ページ、チェックアウトページなど、複数のページテンプレートが存在することがよくあります。ヘッダーとフッターコンポーネントはテンプレートごとにわずかに異なるレンダリングをする場合があります。1〜2種類のテンプレートしか確認しないテスターは、テンプレート固有の上書きによって生じた不一致を見逃す可能性があります。
- 3.2.4と3.2.3(一貫したナビゲーション)を混同する: チームは、ナビゲーションの順序が一貫していれば(3.2.3)、命名も一貫しているはずだと考えてしまうことがありますが、これは別個の要件です。すべてのページで同じ位置にナビゲーションバーがある(3.2.3に適合している)場合でも、リンクのラベルがページごとに異なっていれば3.2.4に違反します。QAプロセスでは、両方の達成基準に明示的に対処してください。
トルコのアクセシビリティ規制との関係
トルコの大統領通達 2025/10は、2025年6月21日付官報第32933号で公布され、幅広い公共・民間のデジタルサービスに対して拘束力のあるアクセシビリティ要件を定めています。この通達は、国際的に認められたアクセシビリティ標準への適合を義務付けており、実務上はWCAG 2.2 レベルAAとの整合を意味します。また、この適合は、家族・社会サービス省(Aile ve Sosyal Hizmetler Bakanlığı)が発行するアクセシビリティロゴ(Erişilebilirlik Logosu)と結び付けられています。
WCAG 3.2.4 一貫した識別はレベルAAの達成基準であり、これは、Erişilebilirlik Logosuの取得または維持を目指す組織にとって、任意の推奨事項ではなく必須要件であることを意味します。デジタルサービス全体で一貫した識別を実装できていない場合、完全なAA適合ができず、その結果としてロゴの取得資格を満たせません。
この通達は、次のような主体を明示的に対象としており、いずれもウェブおよびモバイルインターフェースにおいてWCAG 3.2.4に対応しなければなりません。公共機関および政府機関、銀行および金融サービス提供者、病院およびヘルスケアプラットフォーム、20万以上の加入者を持つ通信事業者、ECプラットフォーム、旅行代理店および予約サービス、民間の交通事業者、国民教育省(Milli Eğitim Bakanlığı)に認可された私立学校です。
これらの組織にとって、その実務的な意味合いは大きいものです。銀行のインターネットバンキングポータル、病院の予約システム、大学の学生情報システムなど、大規模な機関のウェブサイトは、通常何百ものページにまたがり、複数の開発チームによって長年にわたり構築されています。これらのページ全体で、繰り返し現れるコントロール(口座操作ボタン、検索バー、ナビゲーションアイコン)のラベリングが一貫していないことは、一般的で見落とされやすい失敗パターンです。コンプライアンスプログラムには、単一ページの自動スキャンだけでなく、ページをまたいだ一貫性の監査を専用のテストフェーズとして含める必要があります。
Erişilebilirlik Logosuの取得を目指すトルコの組織は、WCAG 3.2.4のチェックをデザインシステムのガバナンス、コンテンツ管理ワークフロー、QAパイプラインに統合すべきです。具体的には、すべての再利用可能なUIコンポーネントについて、そのアクセシブルネームをデザインシステムレベルで編集不可の定数として定義し、翻訳キーを中央管理することで、トルコ語およびその他の言語バリアントが、そのコンポーネントが現れるすべてのページとテンプレートにわたって一貫性を保つようにします。
