最終更新:
アクセシビリティと文字数設計 - alt テキスト・ARIA ラベルの最適な長さ
Web アクセシビリティの実装において、文字数の設計は見落とされがちな要素です。alt テキストが長すぎればスクリーンリーダーのユーザーは情報の洪水に溺れ、短すぎれば画像の意味が伝わりません。ARIA ラベルやライブリージョンのテキストも同様で、適切な文字数を設計することがアクセシブルな体験の鍵を握ります。本記事では、WCAG ガイドラインの要件を踏まえつつ、各要素の最適な文字数と実装パターンを具体的に解説します。
alt テキストの文字数設計 - 125 文字の壁とその根拠
alt テキストの推奨文字数として広く知られているのが「125 文字以内」という基準です。この数値は WCAG の仕様書に明記されたものではなく、主要なスクリーンリーダーの挙動に由来します。JAWS (Job Access With Speech) は alt テキストが約 125 文字を超えると、テキストを分割して読み上げる場合があります。NVDA や VoiceOver では明確な分割は発生しませんが、長い alt テキストはユーザーの認知負荷を高めるため、簡潔さが推奨されます。
ただし、125 文字はあくまで目安であり、画像の種類によって最適な文字数は大きく異なります。以下の表は、画像の種類別に推奨される alt テキストの文字数をまとめたものです。
| 画像の種類 | 推奨文字数 | 記述のポイント | 例 |
|---|---|---|---|
| 装飾画像 | 0 文字 (空の alt) | alt="" を設定し、スクリーンリーダーに無視させる | alt="" |
| アイコン・ボタン | 5〜15 文字 | 機能や操作を端的に伝える | 「検索」「メニューを開く」 |
| 写真・イラスト | 30〜80 文字 | 画像の内容と文脈上の役割を説明する | 「会議室で 5 人のチームメンバーがホワイトボードを囲んで議論している」 |
| グラフ・チャート | 50〜125 文字 | データの傾向や結論を要約する | 「2024 年の月別売上推移。4 月に前年比 30% 増のピークを記録」 |
| インフォグラフィック | 125 文字 + longdesc | 概要を alt に、詳細は別途テキストで提供する | alt で概要、本文中に詳細な説明を配置 |
| ロゴ | 5〜20 文字 | 組織名を記述する。「ロゴ」という語は不要 | 「文字数カウントス」 |
| リンク内画像 | 10〜40 文字 | リンク先の内容を説明する (画像の見た目ではなく) | 「製品カタログをダウンロード」 |
| 数式・コード | 数式の読み上げテキスト | MathML や aria-label で代替テキストを提供する | 「E は m c の 2 乗に等しい」 |
装飾画像に空でない alt テキストを設定してしまうのは、よくある実装ミスです。背景パターンや区切り線の画像に「装飾」「イメージ」などと書いてしまうと、スクリーンリーダーが無意味な情報を読み上げ、ユーザー体験を損ないます。装飾画像には必ず alt="" を設定し、さらに可能であれば CSS の background-image で実装することで、DOM から完全に除外するのが理想です。
alt テキストの書き方 - 文脈依存の原則
同じ画像でも、配置される文脈によって最適な alt テキストは変わります。これは WCAG 2.2 の達成基準 1.1.1 (非テキストコンテンツ) が「同等の目的を果たす」代替テキストを求めているためです。たとえば、犬の写真が「ペットの健康管理」の記事に掲載される場合と、「写真撮影テクニック」の記事に掲載される場合では、伝えるべき情報が異なります。
前者では「体重計に乗るゴールデンレトリバー。適正体重は 25〜34 kg」のように健康情報を含めるべきですが、後者では「逆光で撮影されたゴールデンレトリバーのシルエット。絞り f/2.8 で背景がぼけている」のように撮影技法に焦点を当てます。文字数は結果として異なりますが、重要なのは文脈に応じた情報の取捨選択です。
エラーメッセージの設計と同様に、alt テキストでも「ユーザーが次に何をすべきか」を意識した記述が効果的です。EC サイトの商品画像であれば、色やサイズなど購買判断に必要な情報を含めることで、視覚に頼れないユーザーにも同等の購買体験を提供できます。
ARIA ラベルの文字数設計
ARIA (Accessible Rich Internet Applications) 属性は、HTML のセマンティクスだけでは伝えきれない情報をスクリーンリーダーに提供する仕組みです。中でも aria-label と aria-labelledby は最も頻繁に使用される属性ですが、その文字数設計には明確な指針が少なく、開発者の判断に委ねられている部分が大きいのが現状です。
| ARIA 属性 | 推奨文字数 | 用途 | 注意点 |
|---|---|---|---|
| aria-label | 5〜40 文字 | 要素の名前を直接指定する | 可視テキストがある場合は aria-labelledby を優先する |
| aria-labelledby | 参照先に依存 | 別要素のテキストを名前として参照する | 複数 ID をスペース区切りで指定可能 |
| aria-describedby | 20〜100 文字 | 補足説明を提供する | 名前ではなく説明として読み上げられる |
| aria-roledescription | 5〜20 文字 | ロールのカスタム説明 | 標準ロールの説明を上書きするため慎重に使用する |
| aria-live 領域のテキスト | 10〜60 文字 | 動的に変化するコンテンツを通知する | 頻繁な更新はユーザーの操作を妨げる |
aria-label の文字数が 40 文字を超えると、スクリーンリーダーのユーザーにとって認知負荷が高くなります。ナビゲーションのランドマークに aria-label="メインナビゲーション" と設定する程度であれば問題ありませんが、複雑な説明が必要な場合は aria-describedby で別要素を参照する方が適切です。
aria-label と可視テキストの不一致は、音声操作ユーザーにとって深刻な問題を引き起こします。たとえば、ボタンの可視テキストが「送信」なのに aria-label="フォームデータを送信する" と設定されていると、音声操作で「送信をクリック」と言ってもボタンが認識されない場合があります。WCAG 2.2 の達成基準 2.5.3 (ラベルを含む名前) は、アクセシブルな名前に可視テキストを含めることを要求しています。
スクリーンリーダーの読み上げ速度と文字数の関係
スクリーンリーダーのユーザーは、一般的に読み上げ速度を標準の 1.5〜3 倍に設定しています。熟練ユーザーの中には 5 倍速以上で使用する人もいます。この高速読み上げ環境では、テキストの長さが体験に直結します。
標準速度 (約 150 語/分、日本語では約 300 文字/分) で 125 文字の alt テキストを読み上げると約 25 秒かかります。3 倍速でも約 8 秒です。画像が 10 枚並ぶギャラリーページで各画像に 125 文字の alt テキストが設定されていると、スクリーンリーダーのユーザーはギャラリーを通過するだけで 80 秒以上を費やすことになります。
この問題を軽減するために、ギャラリーやカルーセルでは以下の戦略が有効です。
- 各画像の alt テキストは 30〜50 文字に抑え、詳細は個別ページで提供する
- ギャラリー全体に
aria-label="商品画像ギャラリー (12 枚)"のようなラベルを付与し、ユーザーがスキップできるようにする role="group"でグループ化し、ランドマークナビゲーションで飛ばせるようにする- 「すべての画像を表示」リンクを設け、詳細な説明付きの一覧ページに誘導する
フォームのアクセシビリティと文字数
フォーム要素のアクセシビリティは、ラベル、プレースホルダー、エラーメッセージ、ヘルプテキストの 4 層で構成されます。各層の文字数設計が、フォームの使いやすさを左右します。
| 要素 | 推奨文字数 | 役割 | 実装上の注意 |
|---|---|---|---|
| label 要素 | 5〜20 文字 | 入力フィールドの名前 | 必ず for 属性で関連付ける |
| placeholder | 10〜30 文字 | 入力例の提示 | ラベルの代替にしない。入力開始で消えるため |
| aria-describedby (ヘルプ) | 20〜60 文字 | 入力形式や制約の説明 | フォーカス時に読み上げられる |
| エラーメッセージ | 15〜50 文字 | 入力エラーの内容と修正方法 | aria-live="polite" で動的に通知する |
| 送信ボタン | 3〜10 文字 | 操作の内容を明示する | 「送信」より「注文を確定する」のように具体的に |
placeholder をラベルの代わりに使用するアンチパターンは、アクセシビリティの観点から特に問題があります。placeholder テキストは入力を開始すると消えるため、ユーザーが入力中にフィールドの目的を忘れてしまう可能性があります。また、多くのブラウザで placeholder のデフォルトカラーはコントラスト比が不十分 (約 2.5:1) であり、WCAG の最低基準 4.5:1 を満たしません。命名規則の文字数設計と同様に、フォームラベルも簡潔かつ明確であることが求められます。
ライブリージョンの文字数制御
ライブリージョン (aria-live) は、ページの動的な変更をスクリーンリーダーに通知する仕組みです。チャットメッセージの受信、フォームのバリデーション結果、カウントダウンタイマーの更新など、視覚的に変化するコンテンツをリアルタイムで伝えるために使用します。
ライブリージョンの文字数設計で最も重要なのは、更新頻度と文字数のバランスです。チャットボットのメッセージ設計でも触れられているように、短時間に大量のテキストが流れると、スクリーンリーダーのユーザーは情報を処理しきれなくなります。
| 更新頻度 | 推奨文字数 | aria-live の値 | 具体例 |
|---|---|---|---|
| リアルタイム (1 秒未満) | 5〜15 文字 | off (通知しない) | タイマー、株価ティッカー |
| 高頻度 (1〜5 秒) | 10〜30 文字 | polite | 検索結果件数、文字数カウンター |
| 中頻度 (5〜30 秒) | 20〜60 文字 | polite | チャットメッセージ、通知 |
| 低頻度 (30 秒以上) | 30〜100 文字 | polite | フォーム送信結果、ステータス更新 |
| 緊急 (即時通知が必要) | 10〜40 文字 | assertive | エラー通知、セッション期限切れ警告 |
aria-live="assertive" は現在の読み上げを中断して即座に通知するため、本当に緊急性の高い場面に限定すべきです。フォームのバリデーションエラーに assertive を使用すると、ユーザーが入力するたびに読み上げが中断され、操作が困難になります。バリデーションエラーには polite を使用し、ユーザーの現在の操作が完了してから通知するのが適切です。
WCAG 2.2 の達成基準と文字数の関連
WCAG 2.2 には文字数を直接規定する達成基準はありませんが、複数の基準が間接的に文字数設計に影響を与えます。
| 達成基準 | レベル | 文字数への影響 |
|---|---|---|
| 1.1.1 非テキストコンテンツ | A | alt テキストの提供を義務付け。短い説明か長い説明かの判断が必要 |
| 1.3.1 情報及び関係性 | A | ラベルと入力フィールドの関連付け。ラベルの明確さが求められる |
| 2.4.4 リンクの目的 | A | リンクテキストだけでリンク先が理解できる文字数が必要 |
| 2.4.6 見出し及びラベル | AA | 見出しとラベルが内容を説明する。簡潔かつ具体的な文字数設計 |
| 2.5.3 ラベルを含む名前 | A | aria-label に可視テキストを含める。文字数の整合性が必要 |
| 3.3.2 ラベル又は説明 | A | 入力フィールドにラベルまたは説明を提供する |
| 4.1.2 名前、役割、値 | A | カスタムコンポーネントにアクセシブルな名前を提供する |
達成基準 2.4.4 (リンクの目的) は、OGP テキストの最適化にも通じる考え方です。「こちら」「詳細」のような曖昧なリンクテキストは、スクリーンリーダーのユーザーがリンク一覧をナビゲーションする際に目的地を判断できません。「WCAG 2.2 の公式ドキュメントを読む」のように、リンクテキスト単体で目的が伝わる 15〜40 文字程度の記述が推奨されます。
多言語サイトにおけるアクセシビリティと文字数
多言語サイトでは、言語によって同じ内容でも文字数が大きく変動します。英語の alt テキストを日本語に翻訳すると文字数は約 60〜70% に縮まりますが、ドイツ語に翻訳すると約 130% に膨らむことがあります。この言語間の文字数差は、多言語テキストの文字数設計で詳しく解説されています。
アクセシビリティの観点で特に注意が必要なのは、aria-label の翻訳漏れです。HTML の可視テキストは翻訳されていても、aria-label や aria-describedby で参照されるテキストが原語のまま残っているケースは珍しくありません。i18n フレームワークを使用する場合は、ARIA 属性のテキストも翻訳対象に含めることを忘れないでください。
lang 属性の適切な設定も重要です。ページ全体の言語と異なる言語のテキストが含まれる場合、その要素に lang 属性を設定することで、スクリーンリーダーが正しい音声エンジンに切り替えて読み上げます。たとえば日本語ページ内の英語の引用には <blockquote lang="en"> を設定します。
実装チェックリスト - アクセシビリティ文字数の品質管理
アクセシビリティの文字数設計を継続的に品質管理するために、以下のチェックリストを開発プロセスに組み込むことを推奨します。
- alt テキスト: 装飾画像は
alt=""になっているか。情報画像は 30〜125 文字で文脈に応じた説明が書かれているか - aria-label: 可視テキストと矛盾していないか。40 文字以内に収まっているか
- フォームラベル: すべての入力フィールドに
label要素が関連付けられているか。placeholder をラベル代わりにしていないか - リンクテキスト: 「こちら」「詳細」だけのリンクがないか。リンクテキスト単体で目的が伝わるか
- ライブリージョン: 更新頻度に対して適切な文字数か。
assertiveの使用は本当に必要か - 見出し構造: 見出しが内容を正確に反映しているか。見出しだけを拾い読みしてページ構造が理解できるか
- エラーメッセージ: エラーの内容と修正方法が 50 文字以内で伝わるか。
aria-liveで通知されるか
自動テストツール (axe、Lighthouse、WAVE など) は構造的な問題を検出できますが、alt テキストの品質や ARIA ラベルの適切さは人間によるレビューが不可欠です。開発チームにアクセシビリティレビューのプロセスを組み込み、スクリーンリーダーでの実機テストを定期的に実施することが、真にアクセシブルなサイトへの近道です。
Web アクセシビリティに関する関連書籍は Amazon でも探せます。WCAG の達成基準を体系的に学ぶことで、文字数設計の判断力が格段に向上します。