全盲・スクリーンリーダー利用者に配慮したWebサイトの作り方

画面には「予約する」と表示されているのに、音声では「ボタン」としか読まれない。入力エラーが画面上に出ても、読み上げでは何も通知されない——。見た目では問題なく使えるサイトでも、スクリーンリーダーでは内容や操作方法が伝わらないことがあります。

全盲の方へのWebアクセシビリティは、文章を音声に変換する機能を追加するだけでは実現できません。情報の構造や、リンク・ボタンの名前と役割をHTMLで正しく伝え、キーボードやタッチ操作で目的を達成できることが重要です。

この記事では、スクリーンリーダー利用者に配慮するための基本と、補助ツールでできること・できないことを具体的に解説します。

全盲の人はどのようにWebを利用するのか

スクリーンリーダーは、画面上の情報を音声や点字ディスプレイへ出力する支援技術です。利用者は、キーボードやタッチジェスチャーなどを使い、次のような単位でページを移動します。

• 見出しから見出しへ移動し、ページの構成を把握する
• リンクやボタンの一覧から目的の操作を探す
• フォームのラベルを確認して入力する
• 表の行・列見出しを手がかりに内容を読む
• メイン領域やナビゲーションなどのまとまりへ移動する

スクリーンリーダーは、見た目そのものを説明するのではなく、主にHTMLから取得できるテキスト、構造、部品の名前・役割・状態を利用します。そのため、文字の大きさや位置だけで意味を表現しても、その関係がコードに含まれていなければ伝わりません。

また、全盲の人だけがスクリーンリーダーを使うわけではありません。ロービジョンの人や、文字を目で追うことに困難がある人が、画面表示と読み上げを併用することもあります。

スクリーンリーダーで使いにくいサイトの特徴

「読まれるか」だけでなく、内容を理解し、操作を完了できるかまで確認する必要があります。

問題	読み上げ・操作で起こること
情報を伝える画像に代替テキストがない	画像の内容や目的がわからない
見出しを文字サイズや太字だけで表現している	セクション単位で移動できず、構成を把握しにくい
リンク名が「こちら」「詳しく」だけ	リンク一覧では行き先を区別できない
divやspanだけで独自ボタンを作っている	ボタンとして認識・操作できないことがある
入力欄にラベルが関連づけられていない	何を入力する欄なのかわからない
エラーを赤い枠だけで示している	エラーの発生や修正方法が伝わらない
ポップアップを開いた後のフォーカス管理がない	背後のページを読み続け、開いた内容へ移動できない
検索結果や保存完了を画面表示だけで知らせる	更新が起きたことに気づけない
キーボード操作中にフォーカスが閉じ込められる	先へ進むことも戻ることもできない

自動チェックツールで見つけられる問題もありますが、読み上げる順序や操作のわかりやすさは、人による確認が必要です。

代替テキストは「画像の役割」に合わせる

画像にはすべて同じような説明をつければよいわけではありません。そのページで画像が果たす役割に応じて、代替テキストを考えます。

画像の種類	対応例
情報を伝える画像	内容や、本文を理解するために必要な情報をaltへ入れる
リンク・ボタンとして使う画像	見た目ではなく「トップページへ」「検索」など機能を伝える
本文と同じ内容を繰り返す画像	重複して読ませないよう、状況に応じて空のaltを使う
装飾だけの画像	alt=""として読み上げの対象から外す
複雑なグラフや図	短い代替テキストに加え、本文や表で要点・数値を説明する

たとえば、医師の写真にalt="画像"やalt="doctor01.jpg"と入れても、意味は伝わりません。その人物を紹介するために必要な写真ならalt="院長 山田太郎"、近くに同じ氏名があり写真が装飾的ならalt=""とするなど、前後の文脈で判断します。

代替テキストは「写真を細かく描写する欄」ではありません。画像がなくても同じ情報や操作目的が伝わる、簡潔な表現を目指します。

見出し・リンク・フォームを正しい構造で作る

スクリーンリーダーがページを効率よく読み取れるよう、見た目とHTMLの構造を一致させます。

1. 見出しでページの骨組みを示す

ページタイトルや各セクションには、内容の階層に合ったh1〜h6を使います。単に文字を大きくする目的で見出しタグを使ったり、見出しに見える文字をdivだけで作ったりしないようにします。

header、nav、main、footerなどのHTML要素も、ページ内のまとまりへ移動する手がかりになります。ページの先頭には、繰り返しのナビゲーションを飛ばして本文へ移れる「本文へスキップ」リンクを用意すると便利です。

2. リンクとボタンの目的を名前で伝える

リンクは、周囲の文脈を含めて行き先や目的がわかる文言にします。同じページに「詳しくはこちら」が何度も並ぶ場合は、「料金プランを見る」「対応機能を確認する」のように区別します。

ページ移動にはa要素、処理の実行にはbutton要素など、役割に合った標準HTMLを優先します。標準要素には、支援技術へ役割や状態を伝え、キーボードで操作する仕組みがもともと備わっています。独自部品を作る場合は、名前・役割・状態・操作方法を適切に実装する必要があります。

3. フォームの入力欄とラベルを関連づける

入力欄には、画面に表示されるラベルを用意し、label要素などで入力欄と関連づけます。入力例を示すプレースホルダーだけをラベル代わりにすると、入力後に項目名がわからなくなるため避けます。

必須項目、入力条件、エラー内容も、色や位置だけでなくテキストで伝えます。エラーが発生したときは、次の点を確認します。

• エラーが発生したことを通知できる
• どの項目に問題があるか特定できる
• 修正方法が具体的に書かれている
• エラーメッセージと該当する入力欄がコード上でも関連づいている

キーボードとフォーカスを正しく扱う

スクリーンリーダー利用者の中には、キーボードを中心に操作する人がいます。また、キーボード対応は、運動機能に制約のある人や音声入力を使う人にも重要です。

すべての操作を単純にTabキーとEnterキーだけで行うとは限りません。チェックボックスではSpaceキー、選択肢や複合部品では矢印キーなど、部品に応じた一般的な操作があります。標準HTMLを使うと、こうした操作へ対応しやすくなります。

確認したいポイントは次のとおりです。

• リンク、ボタン、入力欄など、すべての操作要素へキーボードで移動できる
• フォーカスの順序が内容や操作の流れに沿っている
• フォーカスが見た目でも確認できる
• メニューや部品の中にフォーカスが閉じ込められない
• ダイアログを開いたら内部へフォーカスを移し、閉じたら元の操作位置へ戻す
• 画面の外や非表示部分へフォーカスが移動しない
• 自動的な画面遷移や別ウィンドウの表示で利用者を混乱させない

CSSでフォーカスの枠線を消したり、見た目の都合でtabindexに大きな正の値を設定したりすると、操作順がわかりにくくなります。原則としてHTMLの並び順を論理的にし、自然なフォーカス順を利用します。

動的な更新も読み上げで伝える

検索結果の件数、カートへの追加、フォームの保存完了、読み込み中といった情報は、画面を見ていれば変化に気づけます。しかし、フォーカスが別の場所にあるスクリーンリーダー利用者には、自動で伝わらないことがあります。

重要な状態変化は、HTMLの適切な要素やWAI-ARIAの属性を使い、フォーカスを不必要に移動させなくても通知できるようにします。ただし、ARIAを追加するだけで自動的に使いやすくなるわけではありません。標準HTMLで表現できるものは標準HTMLを使い、必要な場合に限ってARIAを補います。

通知が多すぎると操作を妨げるため、読み込みの細かな変化をすべて読み上げるのではなく、利用者が次の行動を判断するために必要な結果を伝えます。

補助ツールでできること・できないこと

ここは特に誤解されやすい点です。文字サイズや色を変更するオーバーレイ型の補助ツールは、ロービジョンや色覚特性のある人に役立つ場合があります。しかし、全盲・スクリーンリーダー利用者への対応を根本的に解決するものではありません。

後付けの補助ツールだけでは、次のような問題を確実には直せません。

• 画像の目的に合った代替テキストがない
• 見出しやフォームの構造が正しくない
• 独自ボタンの名前・役割・状態が伝わらない
• キーボードで操作できない
• エラーや動的な更新が通知されない

サイト独自の「読み上げ機能」と、OSやブラウザと連携してページ全体を操作するスクリーンリーダーは別のものです。読み上げボタンがあるだけで、スクリーンリーダー対応が完了したことにはなりません。

全盲の方への配慮では、まずサイト本体を正しいHTMLで作り、実際のスクリーンリーダーとキーボードで確認することが基本です。補助ツールは、サイト本体の実装を妨げず、ほかの利用者にも明確な利点がある場合に、補完として検討します。

公開前に確認したい5つのポイント

1. 見出しだけでページの内容を把握できるか

スクリーンリーダーの見出し一覧を使い、見出しの文言と階層だけで、ページの構成を理解できるか確認します。

2. リンク・ボタンの名前だけで目的がわかるか

リンクや操作部品の一覧を確認し、「こちら」「ボタン」のような名前だけが並んでいないか、同じ名前で異なる動作をする部品がないかを確認します。

3. フォームを入力からエラー修正まで完了できるか

ラベル、必須条件、入力方法、エラー、送信結果が読み上げられ、マウスを使わずに送信まで進めるか確認します。

4. メニューやダイアログから抜け出せるか

キーボードだけでページを操作し、フォーカスが閉じ込められたり、開いたダイアログやメニューを閉じられなくなったりしないか確認します。

5. 自動チェックに加えて実機で確認したか

自動チェックでHTML上の問題を探したうえで、スクリーンリーダーを使い、問い合わせ・予約・購入などの主要な操作を最初から最後まで試します。可能であれば、実際の利用者による確認も行いましょう。

まとめ：読み上げの有無ではなく、目的を達成できるか

スクリーンリーダー利用者への配慮では、次の点が土台になります。

• 画像の役割に合った代替テキストを用意する
• 見出しやフォームの関係をHTMLで正しく示す
• リンクやボタンの名前・役割・状態を伝える
• キーボードで論理的に操作できるようにする
• エラーや動的な更新を読み上げでも通知する

確認のゴールは、文章が音声になったかではありません。利用者が内容を理解し、問い合わせ、予約、購入などの目的を自力で達成できるかです。まずは利用者にとって重要なページから、正しいHTMLと実機テストを積み重ねていきましょう。

サイト本体の改善を土台に

スクリーンリーダーへの対応は、代替テキスト、見出し・フォームの構造、キーボード操作など、サイト本体を正しく作ることが基本です。この領域は、後付けのツールだけで置き換えることができません。

そのうえで、ロービジョンや色覚特性など、視覚表示の調整が役立つ利用者に向けては、閲覧者側で文字サイズ・文字間隔・色彩・配色コントラストなどを変更できる手段を加えると、選択肢を広げられます。

MyLikingは、サイトに1行のタグを追加することで、こうした表示調整を含む約20の補助機能を導入できるツールです（月1,650円／年19,800円・税込）。本格改修の前に取り組める、低コストな補助策の一つとして活用できます。

※ MyLikingの導入だけで、障害者差別解消法への対応や、WCAG・JISへの適合が保証されるものではありません。代替テキスト、見出し・フォームの構造、独自部品の操作性など、サイト本体の問題を自動修正するものでもなく、スクリーンリーダー対応を保証するものでもありません。

※ MyLikingの「フォーカスを読む」機能は、OSのスクリーンリーダーとは異なる補助機能です。現在確認している動作環境では、「フォーカスを読む」「キーボード操作」など一部機能はiOS・Androidに対応していません。

本格改修の代わりではなく、対応できる範囲を確認したうえでご活用ください。まずは2週間、無料でお試しいただけます。