「アクセシビリティ対応として、ボタンやリンクに aria-label をたくさん付けました」——受託でアクセシビリティ改善を引き受けると、こうした“対応済み”のサイトに出会います。ところが実際にスクリーンリーダーで聞いてみると、「ナビゲーション、メインナビゲーション、ナビゲーション」と同じ言葉が重なって読み上げられたり、本来の見出しテキストが aria-label で上書きされて消えていたりする。良かれと思って付けたラベルが、かえって聞き取りにくさを生んでいるのです。アクセシビリティは「ARIA をたくさん付けること」だと誤解されがちですが、実際は逆で、付けすぎは害になります。
この誤解を解く具体例として、CSS-Tricks の There’s no need to include ‘navigation’ in your navigation labels（CSS-Tricks） が分かりやすい。<nav aria-label="メインナビゲーション"> のように「ナビゲーション」という語をラベルに入れると、スクリーンリーダーは要素の種類（ナビゲーション）を自動で読み上げたうえに、ラベルの「ナビゲーション」も読むため、二重になる——という指摘です。本記事では、こうした「名前」の作られ方を理解し、冗長なラベルと足りないラベルの両方を整える方法を、制作の立場から整理します。
スクリーンリーダーが読む「名前」はどう決まるのか
ボタンやリンク、入力欄には、スクリーンリーダーが読み上げるアクセシブルネーム（accessible name、要素の「名前」）があります。これは一つの属性で決まるのではなく、決まった優先順位で組み立てられます。おおまかには次の順で、上にあるものが勝ちます。
| 優先 | 名前の出どころ | 例 |
|---|---|---|
| 高 | aria-labelledby（別要素を名前にする） | 見出しIDを参照 |
| ↓ | aria-label（直接指定する名前） | aria-label="検索" |
| ↓ | 要素自身のテキスト・<label> | ボタンの中の文字 |
| 低 | title や alt などの補助 | 画像の alt |
ここで大事なのは、**aria-label は要素本来のテキストを「上書きする」**という点です。<button>送信</button> に aria-label="フォームを送る" を付けると、スクリーンリーダーは「送信」ではなく「フォームを送る」と読みます。見えている文字と読み上げが食い違うと、音声操作（「送信、をクリック」）が通じなくなるなど、かえって使いにくくなる。aria-label は「テキストで名前を付けられないときの最終手段」であって、足せば足すほど良いものではありません。要素の状態や変化を支援技術に伝える別の仕組みについては、aria-live で動的な変化を読み上げる記事で扱っています。名前（何であるか）と通知（何が起きたか）は役割が違う、と分けて考えると整理しやすいでしょう。
よくある「冗長」のパターン
付けすぎによる冗長は、次の三つが定番です。
第一に、役割名の重複です。<nav aria-label="ナビゲーション"> や <button aria-label="ボタン: 送信"> のように、要素が自動で読み上げる種類（ナビゲーション、ボタン）をラベルにも書いてしまう。スクリーンリーダーは「メインナビゲーション、ナビゲーション」と二重に読みます。ラベルには種類を含めず、aria-label="メイン" のように区別だけを書けば十分です。
第二に、テキストの二度づけです。中に文字があるリンクに、同じ内容の aria-label を重ねて付ける。名前はラベルが勝つので、テキストと違えば食い違い、同じなら無駄です。テキストがあるなら、原則ラベルは要りません。
第三に、画像 alt と隣接テキストの重複です。「会社ロゴ」という alt を付けた画像の隣に「会社名」のテキストがあると、同じことを二度読みます。装飾やテキストで補える画像は、alt="" にして読み上げから外すのが適切な場合もあります。
よくある「欠落」のパターン
逆に、名前が足りずに「ボタン」「リンク」としか読まれない欠落も多い。
最も多いのが、アイコンだけのボタンです。<button>✕</button> や SVG アイコンだけのボタンは、文字情報がないと「ボタン」としか読まれず、何のボタンか分かりません。ここは aria-label="閉じる" のように、テキストで名前を補うべき正しい使いどころです。同様に、「詳しくはこちら」というリンクが並ぶと、どれも同じ名前になり区別できません。リンク先が分かる文言にするか、文脈を補う必要があります。
<!-- 悪い例：何のボタンか読まれない / 役割名が重複 -->
<button><svg ...></svg></button>
<nav aria-label="ナビゲーション">...</nav>
<!-- 良い例：アイコンには名前を、navには区別だけを -->
<button aria-label="メニューを開く"><svg aria-hidden="true" ...></svg></button>
<nav aria-label="メイン">...</nav>つまり、アイコンには名前を足し、テキストがある要素には足さない——この使い分けが基本です。
受託で組み込むときの落とし穴
弊社がアクセシビリティ改善を引き継いだあるコーポレートサイト（社名は伏せます）では、前の制作会社が「対応のために」ほぼすべてのリンク・ボタン・領域に aria-label を付けていました。スクリーンリーダーで通して聞くと、見出しの文字が aria-label で上書きされて別の言葉に化け、ナビゲーションは役割名が重なって冗長で、肝心のアイコンボタンだけは名前が無い、というちぐはぐな状態でした。「付けた数」は多いのに、使いやすさはむしろ下がっていたのです。
私たちはまず、不要な aria-label を引き算するところから始めました。テキストがある要素のラベルを外し、役割名の重複を消し、見出しの上書きを解除する。そのうえで、本当に名前が無いアイコンボタンにだけラベルを足しました。実機のスクリーンリーダーで一つずつ読み上げを確認し、見えている文字と読み上げが一致するよう揃えていきます。結果、読み上げは短く正確になり、音声操作も通じるようになりました。やったのは、足し算ではなく引き算と、必要な箇所への一点足しです。
この案件で一番効いたのは、実際に読み上げて確かめることでした。ARIA は「付けたつもり」と「正しく伝わる」が食い違いやすく、画面を見ているだけでは気づけません。アクセシビリティを全体としてどう底上げするかは、Webアクセシビリティの基礎ガイドで扱った観点とあわせて、名前・状態・操作の三つを分けて点検すると漏れが減ります。文字サイズや拡大への耐性と同じく、名前の正しさも「実際に使う条件で確かめる」ことでしか担保できません。表示の頑健性についてはフォントスケーリング耐性の記事も参考になります。
どこから着手するか
アクセシビリティ対応を「ARIA をたくさん付けること」と捉えるのをやめ、「スクリーンリーダーが読む名前を、過不足なく整えること」と捉え直すところから、サイトは本当に使いやすくなります。役割名の重複やテキストの上書きを引き算し、アイコンボタンなど名前の無い箇所にだけ足す——この引き算と一点足しが基本です。
最初の一歩としては、サイトのアイコンだけのボタンに正しい名前が付いているか、そして既存の aria-label が要素のテキストを不要に上書きしていないかを、実機のスクリーンリーダーで聞いて確認することをお勧めします。
aria-label をたくさん付けたのに読み上げが冗長で不安、アイコンボタンが何のボタンか伝わっていない、アクセシビリティ対応を「正しく伝わる」状態にしたい——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。現行サイトを実機のスクリーンリーダーで点検し、名前の冗長と欠落を切り分けたうえで、過不足のない形に整えます。
