「アクセシブルな名前」とはどんなものなのか考える

こんにちは、上條（mk-0A0）です。
前回書いた『アクセシビリティツリーを調べてみた』ではタイトルの通りアクセシビリティツリーについて調べたのですが、全体を捉えることに重きを置いていて深堀りがあまりできませんでした。そのため、今回は name（アクセシブルな名前）に注目して調べてみました。

改めて name とは

WCAG では次のように記載されています。

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

名前 (name) | Web Content Accessibility Guidelines (WCAG) 2.1 (日本語訳)

スクリーンリーダーなどの支援技術が利用者に伝えるテキストを name またはアクセシブルな名前と呼びます。要素内のテキストや aria-label / aria-labelledby / alt / title / placeholder などが name として認識されます。どの属性から name が決まるかは要素や HTML 構造によって異なりますが、基本的には aria 属性のような明示的な指定が優先され、それらがなければ要素内のテキストをもとに決定されます。
Name and Description | Accessible Name and Description Computation 1.2

name の概要が分かったところで、次に気になるのはテキストの内容です。name と認識される属性として aria 属性や alt などを挙げました。これらは自分で指定する必要がありますが、どのようなテキストが適切なのでしょうか？

name の達成基準

WCAG による name の達成基準は以下となります。いずれもレベルAです。

• 可視ラベルとテキストが一致している
• 可視ラベルの一部が含まれている

達成基準 2.5.3 ラベルを含む名前 (name) | WCAG

可視ラベルとは実際に画面に表示されているテキストで、name は可視ラベルを支援技術に伝えるためのものだということが分かります。
詳しくは後述しますが、それぞれのテキストが異なるとユーザーを混乱させてしまう可能性があるため、name は可能な限り aria 属性などを使わずにネイティブセマンティクスで提供されるのが望ましいとされています。

name を付けるべきケース

可能な限りネイティブセマンティクスを使うべきと言いましたが、明示的に指定が必要なケースももちろんあります。よくあるケースをいくつか挙げてみました。

ラベルのないアイコン

ラベルのないアイコンはどんな機能を表しているのかが伝わりません。以下は GitHub の PR 作成時のエディターです。私たちエンジニアには見慣れたボタンたちですが、ラベルが無いため初めて触る人にとっては何を表しているのか理解に時間がかかると思います。支援技術も同じで、name が指定されていなければボタンがあるのは分かるけど何をするボタンなのか分からないという状態になってしまいます。
対策として視覚的には hover でツールチップを表示し、<button> 要素に aria-labelledby を使って name を設定しています。

紐づいていない input と ラベルテキスト

以下のように視覚的には紐づいているように見えても、<label> 要素が使えないなどなんらかの理由で input とラベルが紐付ていないケースもあるかもしれません。

<div>
  <input type="checkbox" />
  <p>個人情報の取扱に同意します</p>
</div>

この場合も GitHub の PR のエディターと同様に、ラベルに id を付与して input に aria-labelledby を指定することで紐づけられます。

<div>
  <input aria-labelledby="checkbox-label" type="checkbox" />
  <p id="checkbox-label">個人情報の取扱に同意します</p>
</div>

name を付けても意味がないケース

よかれと思って明示的に指定しても、残念ながら無意味になるケースもあります。

input のラベルがネイティブで紐づいている

「input とラベルを aria-labelledby で紐づけられる」と先述しましたが、<label> 要素が使えるならそちらが適切です。ネイティブセマンティクスで提供されるべきとの考え方に基づいて、基本的には <label> 要素を使うのがベターです。

<a> 要素・<button> 要素

<a> 要素 と <button> 要素はデフォルトで要素内のテキストが name として認識されるため、明示的な指定は不要です。厳密には <a> 要素が持つ link ロールと <button> 要素が持つ button ロールの仕様となります。aria 属性での明示的な指定も可能ですが、ネイティブのテキストを上書きしてしまうため推奨されていません。

間違った使い方をしているケース・注意点

placeholder を積極的に name として使用する

placeholder は name の候補になる属性ですが、name として使用するには適切ではありません。name が表すべきである可視ラベルとは要素に隣接しているテキストを指しており、placeholder はそれに該当しないためです。他に優先される可視ラベルが無い場合の最終手段として使用される可能性がありますが、積極的に使うものではないので注意が必要です。

見えるテキストと聞こえるテキストが違う

「name の達成基準」で少し触れましたが、可視ラベル（見えるテキスト）と name（聞こえるテキスト）が違うとユーザーを混乱させてしまいます。例えば、動画を見ていて演者が話している内容と字幕が違うとどちらが正しいのか混乱するのではないでしょうか。「可視ラベルと name が違う」というのはそれと同じことだと思っています。差異が出ないようにするには可視ラベルをそのまま使うのが確実です。そのため、ネイティブセマンティクスでの提供が推奨されています。
WCAG には以下のようなサンプルが掲載されており、この場合の可視ラベルは「Go」、name は「Find in this site」となります。

<button id="sitesearch" aria-label="Find in this site">Go</button>

F96: 達成基準 2.5.3 の失敗例 – アクセシブルな名前 (accessible name) が可視ラベルのテキストを含んでいない | WCAG

命名の仕方

せっかく name を設定してもユーザーに正しく伝わらなければ意味がありません。そのため、私はできるだけその要素が持つ「役割」を意識して命名するようにしています。
例えばカルーセルやリンクなどでよく使われる > アイコンを例として考えてみます。これに対して「arrow」「矢印」のようなアイコンの見た目を表した命名を見かけますが、これだとアイコンの見た目は分かってもなんの機能を持つアイコンなのかが分かりません。そのため「右に移動」「リンク先に移動」のようにアイコンが持つ機能を命名するとより意味が伝わりやすくなります。
これはアイコンに限った話ではなく alt にも通ずる考え方だと思うので特に意識したいところです。

まとめ

ここまで name について深堀りしてきました。ただ付ければいいというわけではなく、サポートを必要としているユーザーの手助けになってこそ意味を成すことに気づけたのが大きかったです。また、「ネイティブセマンティクスで提供するべき」という考え方は WAI-ARIA でもよく言われる「できるだけ WAI-ARIA を使わない」と通じます。付けた数だけ効果が得られると勘違いしてしまいがちですが、この「使わない」原則に従ってなるべく name を使わなくていいように実装することを心がけていきたいです。