WCAG 4.1.2: 名前、役割、値

WCAG 4.1.2 は、すべてのユーザーインターフェイスコンポーネントに、プログラムによって判別可能な名前と役割があり、状態・プロパティ・値が支援技術によって読み取りおよび設定できることを求めています。これにより、スクリーンリーダーやその他のツールが、ページ上のあらゆる要素を正確に特定し、説明し、操作できるようになります。

このルールの意味

WCAG 4.1.2「名前 (Name)、役割 (Role)、値 (Value)」は、ロバスト (Robust) 原則の下にあるレベルAの達成基準です。これは、フォーム要素、ボタン、リンク、カスタムウィジェット、フレーム、インタラクティブなコントロールなど、あらゆるユーザーインターフェイスコンポーネントについて、次の3つの条件を満たすことを求めています。

名前 (Name): 各コンポーネントには、支援技術が音声読み上げや点字ディスプレイを通じて提示できるアクセシブルネームが必要です。名前は、要素の内容（例: <button> 内のテキスト）、label 要素、aria-label 属性、aria-labelledby 参照、または title 属性から取得できます。
役割 (Role): 各コンポーネントには、その目的を支援技術に伝える役割が必要です。ネイティブのHTML要素には暗黙のロールが付与されています（<button> には button ロール、<input type='checkbox'> には checkbox ロール）。<div> や <span> のような汎用要素から構築されたカスタムウィジェットは、ARIA の role 属性を使って明示的にロールを宣言しなければなりません。
値 (状態とプロパティ): チェックボックスがオンかどうか、ディスクロージャウィジェットが展開されているかどうか、フィールドが必須かどうかなど、ユーザーにとって意味のある現在の状態や値はすべて、プログラム的に公開されている必要があります。そうすることで支援技術がそれを報告でき、必要に応じてユーザーが変更できるようになります。

コンポーネントは、アクセシブルネームが空でなく、ロールが有効で意味的に適切であり、関連するすべての状態（aria-checked、aria-expanded、aria-required など）が正しく適用され、ビジュアルなUIと同期している場合、この基準に適合します。これら3つの要素のいずれかが欠落している、不正確である、または同期していない場合、コンポーネントは不適合となります。たとえば、見た目の色だけが変わり、aria-pressed の状態が更新されないカスタムトグルボタンなどです。

公式のWCAGの例外は、意図的にアクセシビリティAPIに公開されていないコンポーネントを対象としています。たとえば、純粋に装飾目的の要素や、aria-hidden='true' で隠されたコンテンツなどです。しかし、アクティブまたはフォーカス可能なコンテンツを aria-hidden で隠すこと（たとえば <body> 要素に適用すること）は、それ自体が違反です。ページのすべてのコンテンツをアクセシビリティツリーから削除してしまうためです。

なぜ重要か

世界保健機関によると、世界で約2.2億人が何らかの視覚障害を抱えています。JAWS、NVDA、VoiceOver などのスクリーンリーダーに依存する全盲およびロービジョンのユーザーにとって、すべてのインタラクティブコンポーネントのアクセシブルネームとロールは、そのコントロールが何を行い、どのように使うのかを理解するための主要な、そしてしばしば唯一の手段です。ボタンにアクセシブルネームがなければ、スクリーンリーダーユーザーは目的の分からない「button」という読み上げしか聞けません。カスタムドロップダウンにロールがなければ、ユーザーはそれを静的テキストと区別できません。

スイッチアクセス、Dragon NaturallySpeaking のような音声コントロールツール、キーボードナビゲーションを通じてソフトウェアを操作する運動障害のあるユーザーも、この基準に依存しています。音声コントロールソフトウェアは、話し言葉のコマンド（「Submit をクリック」など）をアクセシブルネームにマッピングします。ボタンのアクセシブルネームが可視ラベルと一致していない場合、音声コマンドは完全に失敗します。

認知アクセシビリティも同様に重要です。一貫性があり予測可能なラベリングは、ディスレクシア、記憶障害、注意に関連する障害のあるユーザーの認知負荷を軽減します。モーダルが開く、フォームフィールドが必須になるといった状態変化が支援技術によってアナウンスされない場合、ユーザーは方向感覚を失い、タスクを完了できなくなることがあります。

具体的な実例を考えてみましょう。あるトルコのECプラットフォームが、「Add to Cart」ボタンを、クリックハンドラーとショッピングカートアイコンを持つ <div> として実装しているとします。見た目はボタンのように見えます。しかし、role='button'、アクセシブルネーム、tabindex='0' がないため、キーボードでナビゲートするスクリーンリーダーユーザーには何も存在しないかのように扱われ、その要素は支援技術から完全に見えません。ユーザーは商品をカートに追加できず、事実上ショッピング体験全体から排除されてしまいます。

アクセシビリティ以外にも、適切に名前付けされ構造化されたコンポーネントはSEOを改善します。検索エンジンクローラーは、ページ構造やインタラクティブな意図を理解するためにセマンティックマークアップに依存しているからです。また、自動テストフレームワークは、意味のあるロールやラベルを持つ要素をより確実に特定し操作できるため、テスト容易性も向上します。

テスト方法

axe DevTools または Lighthouse による自動スキャン: axe DevTools ブラウザ拡張機能（Chrome または Firefox）をインストールするか、Chrome DevTools の Accessibility タブで Lighthouse 監査を実行します。ページ全体のスキャンを実行し、結果を WCAG 4.1.2 タグでフィルタリングします。特に button-name、frame-title、aria-required-attr、aria-roles、aria-input-field-name の違反を探します。各検出結果には、問題の要素、失敗の説明、推奨される修正が含まれます。結果をエクスポートし、まずは重大度が Critical と Serious の項目を優先して対応します。
キーボードナビゲーションテスト: マウスを外し、Tabキーを使ってページ全体をナビゲートします。フォーカス可能なすべての要素が可視フォーカスを受け取ること、ブラウザのネイティブフォーカスインジケーター（またはカスタムのもの）が明確に見えること、Enter または Space で全てのコントロールを操作できることを確認します。画面を見ずにコンテキストだけでは正体を特定できない要素に到達した場合、それはアクセシブルネームの不備である可能性が高いことを示します。
NVDA と Firefox を用いたスクリーンリーダーテスト: NVDA（Windows、無料）を起動し、Firefox を開いて、Tabキーでインタラクティブ要素を移動し、NVDAの要素リスト（Insert+F7）でボタン、リンク、フォームフィールドを一覧します。各インタラクティブ要素について、NVDA が何をアナウンスするかを確認します。要素の名前、ロール、および関連する状態（例: 「Subscribe, button」や「Email address, required, edit text」）が読み上げられる必要があります。名前がない、またはロールが誤ってアナウンスされる要素があればフラグを立てます。
VoiceOver と Safari（macOS/iOS）を用いたスクリーンリーダーテスト: VoiceOver（macOSでは Command+F5）を有効にし、Safari を開いて VO+右矢印で要素をナビゲートします。VoiceOver Rotor（VO+U）を使って、すべてのフォームコントロールとボタンを一覧します。名前が説明的であること、ロールが適切であること、インタラクション時に状態が動的に更新されることを確認します（たとえば、カスタムアコーディオンをトグルすると、VoiceOver が「expanded」または「collapsed」とアナウンスする必要があります）。
JAWS と Chrome を用いたスクリーンリーダーテスト: JAWS を起動し、Chrome を開きます。Tabキーでインタラクティブ要素をナビゲートし、JAWS のバーチャルカーソル（フォームフィールド一覧は Insert+F3）を使ってラベルを確認します。ARIAで構築されたカスタムウィジェットに特に注意を払い、キーボード操作によってトリガーされる状態変化が、リアルタイムで JAWS のアナウンスに反映されているかを確認します。
カスタムウィジェットの状態検証: アコーディオン、タブパネル、コンボボックス、モーダルなどのカスタムウィジェットについて、キーボードのみを使って完全に操作します。各ステップで、スクリーンリーダーが正しい状態更新をアナウンスするかを確認します。たとえば、ディスクロージャウィジェットを開くと「expanded」、閉じると「collapsed」とアナウンスされる必要があります。視覚的な状態は変化しているのにスクリーンリーダーが何も伝えない場合、aria-expanded が欠落しているか、プログラム的にトグルされていないことを意味します。

修正方法

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

<!-- Icon button with no accessible name: screen readers announce only "button" -->
<button>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

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

<!-- aria-label provides the accessible name when no visible text is present -->
<button aria-label='Search'>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

ロールや状態のないカスタムトグルウィジェット — 不適切な例

<!-- A div used as a toggle: no role, no state, not keyboard accessible -->
<div class='toggle' onclick='toggleDarkMode()'>
  Dark Mode
</div>

ロールや状態のないカスタムトグルウィジェット — 適切な例

<!-- role='switch' communicates purpose; aria-checked reflects current state;
     tabindex='0' makes it keyboard reachable; keydown handler enables Space/Enter -->
<div
  role='switch'
  aria-checked='false'
  tabindex='0'
  onclick='toggleDarkMode(this)'
  onkeydown='if(event.key==="Enter"||event.key===" "){toggleDarkMode(this);event.preventDefault();}'
>
  Dark Mode
</div>

<script>
function toggleDarkMode(el) {
  const isOn = el.getAttribute('aria-checked') === 'true';
  el.setAttribute('aria-checked', String(!isOn));
  document.body.classList.toggle('dark-mode', !isOn);
}
</script>

ラベルのない iframe — 不適切な例

<!-- iframe with no title: screen reader users cannot determine what is inside -->
<iframe src='https://maps.example.com/embed?q=istanbul'></iframe>

ラベルのない iframe — 適切な例

<!-- title describes the frame's content so users can decide whether to enter it -->
<iframe
  src='https://maps.example.com/embed?q=istanbul'
  title='Interactive map showing our Istanbul office location'
></iframe>

必須ARIA属性が欠落したカスタムプログレスバー — 不適切な例

<!-- role='progressbar' without aria-valuenow, aria-valuemin, aria-valuemax:
     screen readers cannot determine the current progress -->
<div role='progressbar' style='width:60%'></div>

必須ARIA属性が欠落したカスタムプログレスバー — 適切な例

<!-- All required attributes present; aria-label provides the accessible name -->
<div
  role='progressbar'
  aria-valuenow='60'
  aria-valuemin='0'
  aria-valuemax='100'
  aria-label='File upload progress'
>
  60%
</div>

よくある間違い

<div> に role='button' を付けながら tabindex='0' を追加しない — スクリーンリーダーにはボタンとしてアナウンスされますが、キーボードのTabナビゲーションでは到達できず、キーボードのみのユーザーには利用不可能になります。
非インタラクティブ要素に aria-label を適用する — ロールを持たない <div> や <span> に aria-label を追加しても効果はありません。要素にそれを名前付けするロールがないため、多くのブラウザはラベルを無視します。
ディスクロージャウィジェット実装後も aria-expanded を静的なままにしておく — HTMLで aria-expanded='false' を設定したまま、JavaScriptでトグルしない場合、最初のクリック以降、この属性は常に誤った状態を示し、スクリーンリーダーユーザーには逆の状態がアナウンスされます。
フォーカス可能な要素を含むコンテナに aria-hidden='true' を使用する — これはコンテナをアクセシビリティツリーから隠しますが、キーボードフォーカスからは隠しません。そのため、スクリーンリーダーユーザーは音声では何も聞こえない要素にTabで入ってしまい、極度の混乱を招きます。
<input> の唯一のラベルとして placeholder を使用する — プレースホルダーテキストは入力時に消え、すべてのスクリーンリーダーがラベルとして確実にアナウンスするわけではなく、フォームフィールドのアクセシブルネーム要件を満たしません。
role='widget' や role='structure' のような無効または抽象的なARIAロールを使用する — これらはARIA仕様における基底ロールであり、直接使用することを意図していません。意味のあるセマンティック情報を提供せず、支援技術によって無視されたりエラーの原因になったりする可能性があります。
aria-labelledby で存在しない要素IDを参照する — aria-labelledby が指すIDがDOM内に存在しない場合、アクセシブルネームの計算は失敗し、その要素には名前がない状態になります。
<input type='image'> に対して aria-label ではなく value を使用する — 画像入力ボタンのアクセシブルネームには alt 属性が必要です。画像入力においては、名前の計算に value 属性は使用されません。
サードパーティコンテンツを読み込む <iframe> 要素で title 属性を省略する — 開発者は、よく知られた埋め込み（地図、決済ウィジェット、ビデオプレーヤーなど）は自明だと考えがちですが、スクリーンリーダーユーザーは、そのフレームに入るかどうかを決める前に、その目的を知らされる必要があります。
コンテンツが変化したときにアクセシブルネームを動的に更新し忘れる — ボタンのラベルが見た目上「Play」から「Pause」に変わっても、aria-label が「Play」のままの場合、スクリーンリーダーユーザーには現在の状態とアクションについて誤った情報が伝えられます。

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

トルコの大統領通達 2025/10は、2025年6月21日付官報第32933号で公布され、WCAG 2.2 に整合した必須のデジタルアクセシビリティ要件を定めています。WCAG 4.1.2「名前、役割、値」はレベルAの基準であり、適合の最も基本的な層に位置します。この通達の下では、レベルAの適合は任意ではなく、すべての対象組織が達成しなければならないベースラインです。

この通達は、トルコで事業を行う幅広い組織形態に適用されます。公共機関（省庁、自治体、国家機関を含む）は、通達の公布日から1年以内に適合を達成しなければなりません。民間部門の組織（ECプラットフォーム、銀行・金融機関、病院・民間医療提供者、20万以上の加入者を持つ通信会社、旅行代理店、民間輸送会社、国民教育省（MoNE）に認可された私立学校を含む）は、2年以内に適合を達成する必要があります。

WCAG 4.1.2 は、トルコの組織にとって特に重要です。多くの現代的なトルコのウェブサイトが、商品カルーセル、アコーディオン形式のFAQ、ステップバイステップのチェックアウトフロー、バンキングダッシュボードなどのカスタムインタラクティブコンポーネントに依存しており、それらが適切なARIAロール、名前、状態管理なしに実装されていることが非常に多いためです。アクセシブルネームのないカスタムチェックアウトボタンや、aria-valuenow を持たないローン計算機のスライダーは、単なるユーザー体験の不備ではありません。この通達の下では、法的なコンプライアンス違反に該当します。

通達の対象となる銀行やECプラットフォームにとって、支払いフォーム、認証モーダル、アカウントダッシュボードなど、取引に不可欠なフローにおける WCAG 4.1.2 の違反は、特にリスクが高いものです。適切なARIAマークアップを欠いた、視覚的にスタイリングされたカスタムコンボボックス（銀行支店の選択用など）は、スクリーンリーダーユーザーが取引をまったく完了できない状況を生み出し、規制当局による措置や差別に関する訴えの両方に組織をさらすことになります。

Accsible overlay SDK を利用する組織は、多くの「名前・役割・値」の違反について、自動検出と実行時の是正の恩恵を受けることができます。これには、欠落しているアクセシブルネームの挿入、既知のウィジェットパターンにおける無効なARIAロールの修正、インタラクティブコンポーネントの状態属性の同期などが含まれます。しかし、特に複雑なカスタムウィジェットについては、プログラム的な状態管理をアプリケーションロジックに最初から組み込む必要があるため、自動オーバーレイのサポートは、適切なセマンティックHTML開発の代替ではなく補完として扱うべきです。

出典と参考資料

AWCAG 1.1.1: 非テキストコンテンツ AWCAG 1.2.1: 音声のみおよび映像のみ（事前録画）AWCAG 1.2.2: キャプション（事前録画）