ウェブ・アクセシビリティというと、視覚障害者がスクリーン・リーダーを使ってオンライン作業を行うことが真っ先に思い浮かびます。しかし、そこには知識のギャップがあります。スクリーンリーダーは実際にどのように機能するのか？スクリーン・リーダーはどれも同じなのでしょうか？また、なぜあなたのウェブサイトでスクリーンリーダーのテストを行う必要があるのでしょうか？この記事を読むことで、ウェブコンテンツのスクリーンリーダーテストを効果的に実施し、サイトを訪れるすべての人に、よりアクセシブルなウェブサイト体験を提供する方法を学ぶことができます。

スクリーンリーダーとは？

スクリーンリーダーとは、視力の弱い方でも、コンピューターやモバイル機器を使ってウェブサイトのコンテンツにアクセスできる音声合成ソフトのことです。スクリーンリーダーは、Windows、iOS、Androidなどの一般的なOS上で動作するように設計されています。スクリーンリーダーが解読できるコンテンツには、電子メール、ウェブページ、その他の文書が含まれます。

これは通常、スクリーン・リーダーが、ユーザーのデバイスのサウンド・カードを介して、サイトのコンテンツ（見出し、テキスト、リンク、画像など）を人工音声（音声合成装置としても知られている）で「アナウンス」することで実現される。スクリーン・リーダーの中には、リフレッシュ可能な点字ディスプレイを使ってウェブ・コンテンツにアクセスできるものもあり、これは特に盲ろう者にとって便利です。スクリーン・リーダーは、家庭、職場、教育現場などでウェブ・コンテンツにアクセスするために使用することができます。

スクリーン・リーダーの中には、音声出力だけでなく、ウェブ・コンテンツを拡大したり、コントラストを上げたり色を反転させたりして、ウェブページの外観を変更できるものもあります。これらの機能は、視力の弱い方や色覚異常のある方に役立ちます。

視力を失ったユーザーの多くは、マウスを使ってウェブコンテンツを正確に操作することができないため、一般的にはキーボードコマンドを使ったり、トラックパッドやタッチスクリーン上でジェスチャーをしたりしてスクリーンリーダーを操作します。これにより、目の見えるユーザーと同じ作業をコンピューターで行うことができます。利用可能な機能や仕組みは、使用するスクリーン・リーダーによって異なり、すべてのスクリーン・リーダーが同じではありません。ほとんどのテクノロジーと同様に、異なる機能を備えた多くのブランドやスタイルが存在します。スクリーンリーダーには、有料のものと無料のものがあります。また、AndroidやiOSで動作するソフトウェアのように、ユーザーのデバイスに組み込まれているものもあります。

人気のスクリーンリーダーソフトウェア

無料：
・NVDA ・Windowsナレーター ・VoiceOver（macOS / iOS） ・Orca（Linux） 有料： ・JAWS ・PC-Talker ・Dolphin ・COBRA ・Serotek Corporation ・Window-Eyes System Access
例えば、WindowsとMacの両方のデバイスを使用している場合、視覚障害者は複数のスクリーンリーダーを使用することもあります。ほとんどのスクリーン・リーダーは、ユーザーのニーズに合わせてカスタマイズすることができます。例えば、スクリーン・リーダーの音声のスピードを変えたり、句読点の数を変えたりすることができます。また、複数の言語に対応しています。

スクリーンリーダーを使用している人は？

スクリーン・リーダーは、視力を失った人が最もよく利用します。目が不自由で画面に表示されているものを見ることができない人や、部分的に目が不自由で画面に表示されているあらゆる種類のコンテンツを確実に識別できない人などです。また、認知障害や学習障害をお持ちの方でも、スクリーンリーダーを使用することで、Webページのコンテンツを見聞きすることができるようになります。

すべてのスクリーン・リーダーに共通しているのは、ユーザーが自立してコンピューターやモバイル・デバイスを使用し、画面出力を必要とせずに日常的なオンライン作業を行えるようにすることです。これには、ウェブの閲覧、電子メールの作成、オンラインでの購入、マルチメディアコンテンツへのアクセスなどが含まれます。

アクセシブルなWebサイトを構築することで恩恵を受けるのは、スクリーン・リーダーのユーザーである可能性が高いため、Webアクセシビリティの監査やモニタリングにスクリーン・リーダーのテストを組み込むことで、スクリーン・リーダーを使用する際にユーザーが直面する課題を直接理解することは非常に良いアイデアです。

視覚障害者はどのようにウェブサイトを体験するのでしょうか？

スクリーン・リーダーのユーザーは、支援技術に依存しないユーザーとは異なる方法でコンテンツを体験します。ここでは、目の見えるユーザーとスクリーン・リーダーを使用しているユーザーがコンテンツを認識する際の主な違いをご紹介します。

キーボードによるナビゲーション：視力を失ったユーザーは、ウェブコンテンツにアクセスする際、通常の視覚的な手がかりとマウスの組み合わせではなく、キーボードによるナビゲーションに頼ることが多いものです。ウェブサイトにキーボードアクセスを提供していないと、視覚障害者にとって大きな障害となります。

スキャンとスキップ：スクリーン・リーダーのユーザーは、ページ全体の読み上げを聞くのではなく、キーボード・コマンドを使ってウェブページの異なるセクション間をスキップするのが一般的です。つまり、セクション間をすばやく移動して、自分に最も適した情報を見つけられるようにするのです。そのためには、適切なHTMLフォーマットを使用するなど、スクリーン・リーダーの使用を考慮してウェブサイトをデザインしなければなりません。

画像：視力を失ったユーザーは、画像を正確に認識することが難しいため、正確で説明的な代替テキストを使って意味を理解します。代替テキストがなかったり、不適切だったりすると、理解の妨げになります。

デザイン：目の見えるユーザーは、視覚的なデザインを手がかりにしてコンテンツを理解し、ナビゲートする傾向がありますが、スクリーン・リーダーのユーザーは、直線的なテキストベースの方法でコンテンツを認識します。色や配置などのデザイン要素、例えばカルーセルやポップアップなどは、スクリーンリーダーを使用しているユーザーにとってはあまり意味がなく、かえって邪魔になることもあります。

リンク：スクリーン・リーダーのユーザーの多くは、ページ内のコンテンツを素早く見つけるために、リンクからリンクへと「タブ」で移動します。このとき、「ここをクリック」や「詳しくはこちら」といった曖昧なリンクアンカーテキストではなく、説明的なリンクであれば、より簡単に探すことができます。

なぜスクリーンリーダーテストが重要なのか？

画像に代替テキストを追加しない、見出しを省略するなどのアクセシビリティの見落としは、スクリーンリーダーを使用しているビジターがコンテンツに効果的にアクセスするか、サイトが使い物にならないと判断するかの分かれ目となります。

自動テストでは、ウェブサイト上の多くのアクセシビリティ・エラーを検出することができますが、完全に包括的な監査を行い、アクセシビリティの修正を行った後にすべてが期待通りに機能していることを確認するためには、スクリーン・リーダーを使った手動のアクセシビリティ・テストも行う必要があります。これはスキップすべきステップではありません。

スクリーン・リーダーのテストでは、スクリーン・リーダーのユーザーがWebサイトで遭遇する最も一般的な障害を実際に体験することができます。文字通り、スクリーン・リーダーのユーザーの立場に立って、ウェブサイトを操作することができます。これらの洞察をもとに、ユーザーのニーズをより正確に満たすコンテンツをデザインすることで、潜在的な市場シェアを拡大し、包括的な組織としての評判を確立することができます。

英国では約200万人が何らかの形で視力を失っていると言われていますが、自社のウェブサイトがスクリーンリーダーに対応していないと、この層の人々に十分なサービスを提供できなかったり、よりアクセシブルな競合他社にビジネスを奪われたりする危険性があります。英国では人口の高齢化に伴い、視力を失う人の数も将来的に増加すると予想されています。2030年までに270万人が何らかの視覚障害を抱えて生活すると推定されています。2030年には270万人が何らかの視覚障害を持つようになると言われています。

さらに、EUウェブアクセシビリティ指令、The Public Sector Bodies (Website and Mobile Applications) Accessibility Regulations、The Equality Act 2010などの法律で定められているアクセシビリティ要件を満たしていないウェブサイトは、法律に違反している可能性があります。これらの法律はWeb Content Accessibility Guidelines (WCAG)を参照しており、WCAGには代替テキストの基準設定など、スクリーンリーダーの使用に適用されるいくつかの要件が含まれています。

もし、スクリーン・リーダーを使用しているウェブサイトの訪問者が視聴者の一部ではないと思っているなら、それはおそらく、ウェブサイトのトラフィックにスクリーン・リーダーが含まれているのを見たことがないからだと思いますが、考え直してください。Google AnalyticsやSiteimprove Analyticsのような分析ソフトウェアは、スクリーンリーダーのような支援技術を追跡しません。

次は、スクリーン・リーダーのアクセシビリティ・テストを行う方法を学びましょう。

スクリーンリーダーテストの実施方法

スクリーン・リーダーのテストに入る前に、スクリーン・リーダーを使ったテストだけでは、サイトが完全にアクセシブルであることを保証するものではないことに留意することが重要です。自動テストと手動テストを組み合わせて、スクリーン・リーダーを使用する場合と使用しない場合のテストを行う必要があります。

スクリーン・リーダーを使用してコンテンツのアクセシビリティをテストすることは簡単に聞こえますが、支援技術に関する基本的な知識がないままスクリーン・リーダーのテストに飛びつくことは、実際には逆効果になります。これらのチェックをスクリーン・リーダーに詳しい人に任せるか、少なくとも基本的な知識を身につけてから始めるようにしてください。また、最も一般的なキーボードショートカットコマンドのいくつかを知っておくことも有益です。

基本的な知識を身につけたら、テストを始めましょう。では、どこから始めればよいのでしょうか？スクリーン・リーダーのアクセシビリティ・エラーが最も頻繁に発生する傾向にあるため、優先的に取り組むべき特定のエリアがあります。これらの問題領域は次のとおりです。

・HTMLマークアップ：あなたのウェブサイトでは、見出し、段落、リスト、テーブル、フォームなどの要素にセマンティックなHTMLマークアップを使用していますか？ ・代替テキスト：あなたのウェブサイトでは、画像、アイコン、テキスト以外のコンテンツに説明的な代替テキストを使用していますか？ ・キーボードの互換性：キーボードだけで操作できるサイトになっていますか？ ・視覚に訴えるコンテンツ：あなたのウェブコンテンツは、視覚的な手がかりがなくても理解できるものですか？例えば、リンクテキストは説明的ですか？ダウンロードするには赤いボックスをクリックしてください」など、指示には視覚的な手がかりが必要ですか？ ・ダイナミックコンテンツ：コンテンツはますます複雑でダイナミックになってきており、画面上で要素が動いたり変化したりすることは、理解の妨げになることがあります。マルチメディアコンテンツの自動カルーセルや自動再生を無効にすることで、ユーザーが自分のサイトをコントロールできるようになります。 ・アクセシビリティオーバーレイ：アクセシビリティ・オーバーレイを使用したウェブサイトは、スクリーン・リーダーのユーザーがコンテンツを読むことを困難にします。アクセシビリティオーバーレイは、スクリーンリーダーによるページの正しい解釈を妨げ、効果的なナビゲーションの障害となることがあります。ウェブサイトにアクセシビリティ・オーバーレイを設置している場合、スクリーン・リーダーのテストで正しく動作するかどうかを確認することが非常に重要です。

スクリーンリーダーのテストにJAWSとNVDAを使用する方法：17ステップのチェックリスト

さまざまなスクリーンリーダーの技術には違いがありますので、JAWSやNVDAなど、さまざまなスクリーンリーダーでコンテンツをテストすることをお勧めします。また、OSごとに1つのスクリーンリーダーのテストを行うことがベストプラクティスであるため、Mac OS/iOSで動作するように設計されたVoiceOverでのテストも検討するとよいでしょう。

JAWSは、最も一般的に使用されているスクリーンリーダーであり、スクリーンリーダーのテストを始めるのに適しています。しかし、JAWSはユーザーにとって最も高価なスクリーンリーダーの1つでもあるため、NVDAのような、より広く利用されている技術と一緒にテストすることは理にかなっています。

NVDAは、Windowsに対応した無料のスクリーンリーダーです。ユーザーはウェブコンテンツを音声や点字で表示することができます。

コンテンツをテストするスクリーンリーダーを選択したら、次のチェックリストを使って、サイトとの互換性をテストしてください。

1.お使いのスクリーンリーダーをインストールします。NVDAはウェブサイトから無料でダウンロードできます。JAWSをお使いになるにはライセンスが必要です。ライセンスはウェブサイトで購入できます。 2.テストしたいブラウザを選択してください。 3.キーボードショートカットを使用して、ウェブサイトのコンテンツを読み、スクリーンリーダーのユーザーエクスペリエンスを最初から最後まで再現します。以下のような動作でナビゲートする必要があります。 4.ページに見出しがないか、不適切でないかをチェックする 5.HTMLドキュメントに言語属性があるかどうかを確認する（これにより、目的の地域の正しいアクセントと正しい発音でコンテンツを読み上げることができます）。 6.入力フォームの記入 - ラベルやプロンプトが期待通りに機能しているか？ 7.コールトゥアクションボタンを操作する 8.データテーブルとのインタラクション - 表形式のデータがある場合にのみ使用してください。 9.画像のaltテキストに記述性があるか確認する 10.リンクテキストに記述性があるか確認する 11.ボタンのテキストに記述性があるか確認する 12.CAPTCHA、アクセシビリティのオーバーレイ、予期せぬ画面変更、Flashコンテンツなど、一般的に問題となる要素をチェックする。 13.検索機能が存在し、機能しているかを確認する 14.メインコンテンツへのスキップ」や「ナビゲーションのスキップ」のリンクが存在するかどうかを確認する 15.自動カルーセルや自動再生が無効になっていないか 16.別の種類のスクリーン・リーダーでプロセスを繰り返す 17.必要なアクセシビリティの修正を行った後、スクリーン・リーダーのテストを繰り返し、アクションが成功したことを確認します。

これらのチェック項目の多くは、スクリーンリーダーを使ってコンテンツを操作するユーザーだけでなく、すべてのユーザーにとって有益なウェブデザインのベスト・プラクティスです。

どのくらいの頻度で、スクリーンリーダーを使ってウェブサイトをテストすべきですか？

自動化されたツールは、ウェブ・アクセシビリティに取り組むための素晴らしい出発点ですが、スクリーン・リーダーを使用する訪問者にとってサイトが本当にアクセシブルであるかどうかを知るには、アクセシビリティ監査にスクリーン・リーダー・テストを含めなければなりません。しかし、どのくらいの頻度でスクリーン・リーダー・テストを実施すべきでしょうか？

原則として、スクリーンリーダーテストは、Webサイトの移行や再設計など、Webサイトに大規模な変更や追加を行ったときや、アクセシビリティ監査の一環として実施する必要があります。しかし、本番稼動後ではなく、本番稼動前に実施するのがベストです。初期のスクリーンリーダーテストで得られた洞察は、後から対応したり追加したりするのではなく、サイト開発の形を整えるのに役立ちます。

ウェブアクセシビリティは、単発のプロジェクトではなく、プロセスとして考えてください。サイトに新しいコンテンツを追加するたびに、スクリーン・リーダーのユーザーに新たなアクセシビリティの障害をもたらす危険性があります。毎週スクリーン・リーダー・テストを行うのはやり過ぎですが、ページに重大なエラーが潜んでいた場合に備えて、定期的なスクリーン・リーダー・テストをウェブサイトの保守点検に組み込むこともお勧めします。

スクリーンリーダーのテストは、WCAG準拠の要件ですか？

スクリーンリーダーのテストは、WCAG準拠のために明示的に義務付けられているわけではありませんが、ウェブサイトのメンテナンスプロセスにスクリーンリーダーの手動チェックを組み込むことは、アクセシビリティのベストプラクティスです。WCAGには、スクリーンリーダーの使用に適用されるいくつかの成功基準が含まれています。 ・テキスト以外のコンテンツには、「テキストによる代替手段」を用意する必要があります。 ・各ウェブページの人間の言語は、ソフトウェアアプリケーションによって「プログラム的に決定」することができます。 ・ウェブページ上の各通路やフレーズの人間の言語は、プログラムで決定することができる。

ウェブアクセシビリティを確保する最も効果的な方法は、明確でシンプルなコンテンツを設計し、自動テストやスクリーンリーダーを使ってウェブページを定期的にテストし、ウェブサイト全体でWCAGの原則に従うという、複合的なアプローチであることを忘れないでください。これらのステップに従えば、あなたのウェブサイトは誰にとってもより包括的な空間となるでしょう。