達成基準 2.5.3: ラベルを含む名前 (name) を理解する

達成基準 2.5.3 ラベルを含む名前 (name) (レベル A): ユーザインタフェース コンポーネントテキスト又は文字画像を含むラベルを持つ場合、視覚的に提示されたテキストが名前 (name) に含まれている。

ベストプラクティスは、ラベルのテキストを名前の最初に使用することである。

意図

この達成基準の意図は、コンポーネントに視覚的にラベルを付ける単語が、コンポーネントにプログラムにより関連付けられる単語でもあることを確実にすることである。これは、障害のある人がコンポーネントとやりとりする手段として可視ラベルを確実に信頼できるようにするのを助ける。

ほとんどのコントロールは、可視のテキストラベルを伴う。この同じコントロールには、アクセシブルな名前 (Accessible Name) とも呼ばれるプログラムの名前がある。コントロールの可視ラベルの単語及び文字が一致する、又はアクセシブルな名前 (accessible name) に含まれている場合、利用者は一般に、はるかに優れた体験が得られる。これらが一致するとき、音声入力の利用者 (すなわち、音声認識アプリケーションの利用者) は、画面に表示されるメニュー、リンク、ボタンなどのコンポーネントの可視のテキストラベルを話すことによってナビゲートできる。テキスト読み上げ (スクリーンリーダーなど) を使用する視力のある利用者も、聞こえるテキストが画面に表示されるテキストと一致する場合に、よりよい体験が得られる。

コンポーネントに可視のテキストラベルが存在しない場合、この達成基準はそのコンポーネントには適用されないことに注意する。

テキストラベルが存在し、確立されたオーサリングプラクティスを通じてユーザインタフェースコンポーネントに適切にリンクされている場合、ラベルと名前は通常一致する。それらが一致しない場合、ナビゲーション又は選択の手段として可視のテキストラベルを使用しようとする音声入力の利用者 (「パスワードに移動」など) は失敗する。利用者が話す可視ラベルが、音声入力コマンドとして有効であるアクセシブルな名前 (accessible name) と一致しない (又はその一部ではない) ため、音声ベースのナビゲーションは失敗する。さらに、アクセシブルな名前 (accessible name) が可視ラベルと異なる場合、音声入力の利用者によって誤って作動される可能性のある非表示のコマンドとして機能することがある。

コントロールの可視ラベルとプログラム名との間の不一致は、認知の問題も抱えている音声入力の利用者及びテキスト読み上げの利用者にとってさらに問題になる。不一致は、音声入力の利用者に余分な認知的負荷を引き起こす。その利用者は、コントロールに表示される可視ラベルとは異なる音声コマンドを言うことを忘れてはならない。また、テキスト読み上げの利用者が、可視ラベルと一致しない音声出力を吸収して理解するための追加の認知的負荷を引き起こす。

ラベルテキストとアクセシブルな名前 (accessible name) を一致させるには、まず画面上のどのテキストを与えられたコントロールのラベルと見なすかを決定する必要がある。多くの場合、ユーザインタフェースには、コントロールに関連する可能性のある複数のテキスト文字列がある。しかし、ラベルを近接したテキストのみであると保守的に解釈することが最良である理由がいくつか存在する。

ユーザインタフェース コンポーネントの伝統的なラベルは隣接するテキスト文字列である。左から右への言語の一般的な配置は次のとおりである:

これらの規則のいくつかの根本原理は、G162: 関係性を最大限に予測できるようにするためにラベルを配置するで説明されている。

テキストラベルを構成するものを自由に解釈すると、予測可能性の低下によりこの達成基準の価値が危険にさらされる可能性があるため、隣接するテキストのみをラベルとして扱うようにバイアスをかけることが重要である。コンポーネントに近接した単一の文字列にラベルを分離すると、開発者、テスター、およびエンドユーザがこの達成基準で評価の対象となるラベルを簡単に特定できるようになる。ラベル付けの予測可能な解釈により、音声認識技術の利用者は、伝統的な位置にあるラベルを通して要素とやりとりでき、画面読み上げ技術の利用者は、近くに表示されるラベルとコンポーネントの通知された名前との間の一貫性を得ることを可能にする。

入力フィールド内のプレースホルダーテキストは、ラベルを提供する適切な手段とは見なされないことに注意する。HTML5 仕様 では、プレースホルダー属性を<label>の代わりに使用すべきでないと記述されている。しかし、その HTML5 ステートメントの "ラベル" はコードブラケット内にあり、label要素にリンクしていることに注意する。ラベルを含む名前 (name)の達成基準の目的のために、"ラベル" はそのようなプログラム的な意味で使用されないが、単にコンポーネントに視覚的に近接したテキスト文字列を指す。そのため、 (前述のリストで説明したように) 近くに他のテキスト文字列がない場合に、入力にプレースホルダーテキストが含まれているならば、そのようなテキストはラベルを含む名前 (name) の候補になることがある。これは、アクセシブルな名前の計算 (後で説明) と、可視ラベルが他に提供されない場合、音声入力の利用者が入力をともなうやりとりの手段としてプレースホルダーテキストの値を使用しようとする可能性があるという実際的な意味の両方でサポートされる。

「自然言語で何かを表現している」テキストラベル

記号的な文字

この達成基準のために、テキストは、WCAG のテキストの定義に従って直接自然言語で何かを表現しているものよりむしろ、記号的な方法で使用される場合、可視のラベルと見なされるべきでない。例えば、1.4.5 文字画像は、「記号的な文字」に関する考慮事項を説明している。文字画像の例では、「B」、「I」、及び「ABC」がテキストエディタのアイコンに表示される。これらは、それぞれ太字、斜体、およびスペルの機能を表すことを目的としている。そのような場合、アクセシブルな名前 (accessible name) は、表示されている記号的な文字ではなく、ボタンが提供する機能 (「スペルチェック」や「スペルをチェックする」など) とするべきである。同様のテキストエディタを次の図に示す。

見出し、太字、斜体、引用、コード、リンクなどのテキストを変換するためのアイコン、順序付き及び順序なしのリスト並びにその他のコントロールのアイコン
図 1 Github のリッチテキストエディタの詳細。文字に似たアイコンなど、ラベルのないさまざまなアイコンが表示されている。

同様に、コンテンツ制作者が大なり記号 (">") を使用して右向きの矢印の外観を模倣した場合、テキストは自然言語で何も伝えない。これは記号であり、このシナリオでは、「再生」ボタン又は「次へ」矢印に使用されるアイコンを模倣することを意図した可能性がある。

句読点及び大文字の使用

ラベルにおける句読点の使用及び大文字の使用も、同じ理由でオプションと見なされてもよい。例えば、入力ラベルの最後に従来追加されていたコロンは自然言語では何も表現せず、そしてラベルの各単語の最初の文字を大文字にしても、通常は単語の意味は変わらない。これは、主に音声認識の利用者を対象としているため、この達成基準のコンテキストに特に関係がある。利用者がコントロールとやりとりする手段としてラベルを話すとき、大文字及びほとんどの句読点は頻繁に無視される。

アクセシブルな名前 (accessible name) にコロン及び大文字を含めることは間違いなくエラーではないが、"First name" の計算された名前は、"First Name:" の失敗と見なされるべきではない。

同様に、ボタンに表示される "Next…" は、アクセシブルな名前 (accessible name) として "Next" を持つことができます。意味のある可視のラベルが存在するのか疑わしい場合、アクセシブルな名前 (accessible name) の文字列と正確に一致させる。

数式及び式

数式は、記号文字に関する前のサブセクションの例外である。数学記号はラベルとして使用することができる。例えば、"11×3=33" 及び "A>B" は意味を伝える。ラベルはアクセシブルな名前 (accessible name) で上書きすべきでなく、同じ方程式を表現する方法は複数あるため、式が使用されている単語の置換は避けるべきである。例えば、"11×3 は 33 に相当する" という名前 (name) を付けると、"11×3 は 33 に等しい" と言う利用者は一致しない可能性がある。ラベルで使用されている式をそのままにして、一致を達成するために利用者が音声ソフトウェアに精通していることを期待するのが最善である。さらに、数式のラベルを、スペルアウトされた同等のアクセシブルな名前 (accessible name) に変換すると、翻訳の問題が発生する可能性がある。名前 (name) は、ラベルの数式テキストと一致すべきである。コンテンツ制作者にとっての考慮事項は、数式で適切な記号を使用することであることに注意する。例えば、11x3 (小文字又は大文字のX)、11*3 (アスタリスク記号をもつ)、及び 11×3(&times; 記号をもつ)は全て、目の見える利用者にとって同じ式を意味するものとして解釈するのは簡単であるが、音声認識ソフトウェアによって全てが "11×3" に一致するとは限らない。適切な演算子記号 (この場合は乗算記号) を使用すべきである。

Accessible Name and Description Computation 仕様

アクセシブルな名前 (accessible name) がどのように派生するかを理解することが重要である。Accessible Name and Description Computation 1.1 及び HTML Accessibility API Mappings 1.0 は、アクセシブルな名前 (accessible name) の計算方法を説明する。これには、計算で考慮される属性や優先順位などが含まれる。コンポーネントに、アクセシブルな名前 (accessible name) に使用できる複数の属性値がある場合、それらの値の中で最も優先されるものだけが計算される。他のあまり好ましくない値は名前 (name) の一部にはならない。ほとんどの場合、ラベルとコントロールの間に確立された既存のプログラム上の関係が仕様によって強化されている。

1.3.1: 情報及び関係性を満たすように正しくコーディングされた画面に表示されるその他のテキストは、通常、作成者の介入なしに(ARIAラベル付け手法を通して)UI コンポーネントのアクセシブルな名前 (accessible name) の計算に考慮されない。これらの中で最も一般的なものは次のとおり:

  • 見出し及び指示
  • コンポーネントのセットのグループラベル (すなわち、legend/fieldset で使用される、又は group もしくは radiogroup の役割 (role) で使用される)

そのようなテキスト情報は、コンポーネントの説明の一部を構成する場合がある。したがって、プログラムの観点からと、ラベルを「隣接するテキスト」と見なすという保守的な戦術の両方から、通常、見出し、指示、グループの「ラベル」のいずれも、この達成基準の目的のラベルと見なされるべきではない。

この仕様では、作成者がネイティブセマンティクスによって計算された名前 (name) を上書きできることに注意することが重要である。名前 (name) の計算では、aria-labelaria-labelledby の両方が優先され、表示されるテキストラベルがプログラムでコントロールに関連付けられている場合でも、アクセシブルな名前 (accessible name) として表示されるテキストが上書きされる。このため、可視ラベルがすでに存在する場合、aria-label を避ける又は慎重に使用すべきであり、aria-labelledby は注意して補足として使用すべきである。

最後に、aria-describedby はアクセシブルな名前 (accessible name) 計算には含まれない(代わりに、アクセシブルな説明の計算の一部となる)。慣例により、aria-describedby によってコントロールに関連付けられたテキストは、スクリーンリーダーによってアクセシブルな名前 (accessible name) の直後に通知される。したがって、見出し、指示、及びグループラベルのコンテキストは、音声認識ソフトウェアを用いてナビゲートする利用者のエクスペリエンスに影響を与えることなく、スクリーンリーダーの利用者を支援するために、アクセシブルな説明を通して提供される。

メリット

事例

関連リソース

リソースは、情報提供のみを目的としており、推奨を意味するものではない。

達成方法

この節にある番号付きの各項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組み合わせを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。その他の達成方法についての詳細は、WCAG 達成基準の達成方法を理解するの「その他の達成方法」を参照のこと。

十分な達成方法

参考達成方法

適合のために必須ではないが、コンテンツをよりアクセシブルにするために、次の追加の達成方法を検討することが望ましい。ただし、すべての状況において、すべての達成方法が使用可能、又は効果的であるとは限らない。

失敗例

以下に挙げるものは、WCAG ワーキンググループが達成基準の失敗例とみなした、よくある間違いである。

重要な用語

ASCII アート (ASCII art)

文字又はグリフの空間的配置によって作られた図画 (典型的には、ASCII で定義されている 95 の印字可能文字から作られる)。

支援技術 (assistive technology)

障害のある利用者の要件を満たすために、主流のユーザエージェントが提供する機能を超えた機能を提供するような、ユーザエージェントとして動作する、又は主流のユーザエージェントと共に動作するハードウェア及び/又はソフトウェア。

注記

支援技術が提供する機能としては、代替の提示 (例: 合成音声や拡大表示したコンテンツ)、代替入力手法 (例: 音声認識)、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換 (例: テーブルをよりアクセシブルにするもの) などを挙げることができる。

注記

支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。

注記

主流のユーザエージェントと支援技術との区別は、絶対的なものではない。多くの主流のユーザエージェントは、障害者を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者に特化した、よりニーズに適したものである。主流のユーザエージェントは、プログラムオブジェクトからのウェブコンテンツの抽出、マークアップの識別可能な構造への解釈といった、重要な機能を支援技術に対して提供する場合がある。

この文書の文脈において重要な支援技術としては、以下のものが挙げられる:

  • 画面拡大ソフト及びその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、及び読書困難などの障害のある人が、レンダリング後のテキスト及び画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。
  • スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。
  • 音声変換ソフトウェア。認知障害、言語障害、及び学習障害のある人が、テキストを合成音声に変換するために使用している。
  • 音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。
  • 代替キーボード。特定の身体障害のある人がキーボード操作をシミュレートするのに使用している (ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、及びその他の特別な入力デバイスを使った代替キーボードを含む)。
  • 代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンの動きをシミュレートするのに使用している。
コンテンツ (content)

構造、提示、及びインタラクションを定義するコード又はマークアップも含めて、ユーザエージェントによって利用者に伝達される情報及び感覚的な体験。

自然言語 (human language)

人間とコミュニケーションをとるための言語で、話される、書かれる、又は (視覚的あるいは触覚的な手段で) 手話にされるもの。

注記

手話も参照。

文字画像 (image of text)

特定の視覚的効果を得るために非テキスト形式 (例えば画像) でレンダリングされたテキスト。

注記

テキスト以外の部分が重要な視覚的コンテンツである場合、画像に含まれるテキストは該当しない。

写真に写っている人の名札にある人名。

ラベル (label)

テキスト、又はテキストによる代替を伴うコンポーネントで、ウェブコンテンツ内のコンポーネントを識別するために利用者に提示されているもの。

注記

名前 (name) は隠されていて、支援技術に対してだけ公開される場合がある一方で、ラベルはすべての利用者に提示される。多くの場合 (すべてではないが)、名前 (name) とラベルは同じである。

注記

ラベルという用語は、HTML における label 要素だけに限定されない。

名前 (name)

ソフトウェアが、ウェブコンテンツのコンポーネントを利用者に識別させることができるテキスト。

注記

ラベルはすべての利用者に提示される一方で、名前 (name) は隠されていて、支援技術に対してだけ明らかにされる場合もある。多くの場合 (すべてではないが)、ラベルと名前 (name) は同じである。

注記

これは、HTML の name 属性とは関係がない。

非テキストコンテンツ (non-text content)

プログラムによる解釈が可能な文字の並びではないコンテンツ、又は文字の並びが自然言語においても何をも表現していないコンテンツ。

注記

これには、 (文字による図画である) ASCII アート、顔文字、 (文字を置き換える) リートスピーク、文字を表現している画像が含まれる。

提示 (presentation)

利用者が知覚できる形式でコンテンツをレンダリングすること。

プログラムによる解釈 (programmatically determined)

支援技術を含む様々なユーザエージェントが抽出でき、利用者に様々な感覚モダリティで提示できるような形のデータがコンテンツ制作者によって提供されたとき、そのデータがソフトウェアによって解釈されること。

マークアップ言語で、一般に入手可能な支援技術が直接アクセスできる要素と属性から解釈される。

非マークアップ言語の技術特有のデータ構造から解釈され、一般に入手可能な支援技術がサポートするアクセシビリティ API を通じて支援技術に提供される。

手話 (sign language)

意味を伝えるために、手と腕の動き、顔の表情又は身体の姿勢の組み合わせを用いる言語。

構造 (structure)
  1. ウェブページの各部を相互の関係性によりまとめる方法論。及び、
  2. 一連のウェブページをまとめる方法論。
テキスト (text)

プログラムによる解釈が可能な文字の並びで、自然言語で何かを表現しているもの。

テキストによる代替 (text alternative)

非テキストコンテンツとプログラムで関連付けられるテキスト、又は非テキストコンテンツとプログラムで関連付けられるテキストから参照されるテキスト。プログラムで関連付けられたテキストとは、その場所を、非テキストコンテンツからプログラムによる解釈が可能なテキストである。

チャートの画像があり、その直後の段落にテキストによる説明がある。チャートに対する短いテキストによる代替で後に説明があることを示している。

注記

より詳細な情報は、テキストによる代替を理解する を参照。

ユーザエージェント (user agent)

ウェブコンテンツを取得して利用者に提示するあらゆるソフトウェア。

ウェブコンテンツの取得、レンダリング及びインタラクションを支援する、ウェブブラウザ、メディアプレーヤ、プラグイン、及びその他のプログラム (支援技術も含む)。

ユーザインタフェース コンポーネント (user interface component)

コンテンツの一部分で、特定の機能を実現するための単一のコントロールとして利用者が知覚するもの。

注記

複数のユーザインタフェース コンポーネントが、単一のプログラム要素で実装されることもある。ここでいう「コンポーネント」は、プログラムの手法と結びついたものではなく、利用者が別々のコントロールとして知覚するものを指す。

注記

ユーザインタフェース コンポーネントには、フォーム要素、リンクだけでなく、スクリプトで生成されるコンポーネントが含まれる。

注記

ここでの「コンポーネント」又は「ユーザインタフェース コンポーネント」は、「ユーザインタフェース要素」とも呼ばれる。

アプレットには、コンテンツ内を行単位、ページ単位、又はランダムアクセスで移動するために用いられる「コントロール」がある。これらには、いずれも名前 (name) を割り当て、個別に設定できるようにする必要があるため、それぞれが「ユーザインタフェース コンポーネント」となる。

ウェブページ (web page)

単一の URI から HTTP で得た埋め込まれていないリソースに加え、レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。

注記

どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。

注記

このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。

単体のウェブリソースであり、埋め込まれている画像及びメディアのすべてを含んだもの。

Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mail に存在しているが、受信トレイ、連絡先、カレンダーがある。受信トレイ、連絡先、又はカレンダーを表示するリンク又はボタンが提供されているが、全体としてページの URI は変更されない。

カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツモジュールのセットから表示させるコンテンツを選択できるようなもの。

ブラウザで "http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは 1 ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの 1 ページなのかもしれない。


訳注: このページは、2022 年 9 月 2 日版の Understanding WCAG 2.1 の翻訳です。2022 年 9 月 2 日版の原文は WAIC の管理するレポジトリから入手可能です。