達成基準 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 ワーキンググループが達成基準の失敗例とみなした、よくある間違いである。

重要な用語

文字画像 (image of text)

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

注記

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

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

ラベル (label)

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

注記

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

注記

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

名前 (name)

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

注記

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

注記

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

テキスト (text)

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

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

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

注記

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

注記

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

注記

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

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


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