アクセシビリティテストとは何ですか? （例）

アクセシビリティテストとは何ですか?

アクセシビリティ テストは、テスト対象のアプリケーションが、聴覚、色覚異常、高齢者、その他の恵まれないグループにとっても使用可能であることを確認するために実行されるソフトウェア テストの一種として定義されます。 のサブセットです ユーザビリティテスト.

障害を持つ人々は、ソフトウェア製品の操作を支援する支援技術を使用します。このようなソフトウェアの例は次のとおりです。

• 音声認識ソフトウェア – 話された言葉をテキストに変換し、コンピューターへの入力として機能します。
• スクリーンリーダーソフトウェア – 画面に表示されているテキストを読み上げるために使用されます。
• 画面拡大ソフトウェア– モニターを拡大し、視覚障害のあるユーザーが読みやすくするために使用されます。
• 特殊キーボード モーター制御が困難なユーザー向けにタイピングを容易にするために作られました

アクセシビリティテストを行う理由

理由1: 障​​害者市場に対応します。

人口の約 20% が障害を抱えています。

• 1人に10人が重度の障害を抱えている
• 1歳以上の2人に65人が能力が低下している

障害には、盲目、聴覚障害、障害、または身体のあらゆる障害が含まれます。

ソフトウェア製品が障害者向けに作られていれば、この大きな市場に対応できます。 ソフトウェアのアクセシビリティの問題は、アクセシビリティ テストを通常のソフトウェア テスト ライフ サイクルの一部にすれば解決できます。

理由2: アクセシビリティ法を遵守する

世界中の政府機関が、障害者が IT 製品にアクセスできるようにすることを義務付ける合法化を打ち出しています。

各国政府による法的行為は以下のとおりです。

• 米国: アメリカ障害者法 – 1990 年
• 英国: 障害者差別禁止法 – 1995 年
• オーストラリア: 障害者差別法 – 1992 年
• アイルランド: 2005 年障害法

アクセシビリティ テストは、法的遵守を確保するために重要です。

理由3: 潜在的な訴訟を回避する

過去には、フォーチュン 500 企業が、自社の製品が障害者に配慮していないという理由で訴訟を起こされたことがあります。 ここではいくつかの著名な事例を紹介します。

• 全国盲人連盟（NFB）vs Amazon (2007)
• セクストンとNFB対 Target (2007)
• NFB 対 AOL の和解 (1999 年)

障害者をサポートし、潜在的な訴訟を回避する製品を作成することが最善です。

どの障害をサポートすべきか?

アプリケーションは次のような障害を持つ人々をサポートする必要があります。

障害の種類	身体障害 Descriptexpression CMS
視覚障害	全盲または色覚異常または視力低下 視覚的なストロボやフラッシュ効果の問題などの視覚的な問題
身体障害	片手でマウスやキーボードを使用することはできません。 手の動きや筋肉の遅さなどの運動能力の低下
認知障害	学習障害や記憶力の低下、またはより複雑なシナリオを理解できない
読み書き能力の障害	読解の問題
聴覚障害	難聴や聴覚障害などの聴覚の問題 聞こえない、またははっきりと聞こえない

アクセシビリティテストを行うにはどうすればよいですか?

アクセシビリティ テストは次の 2 つの方法で実行できます。

1. マニュアル
2. 自動化

アクセシビリティ テストは、テスターに​​とって障害について馴染みがないため、難しい場合があります。 障害を理解するには、特別なニーズがある障害者と協力する方がよいでしょう。

アクセシビリティをテストするには、障害に応じてさまざまな方法があります。 それらすべてを一つ一つ学んでいきます。

1) 視覚障害

さて、私には視覚能力がないとしましょう。 私は全盲なので、XYZ ウェブサイトにアクセスしたいと思いました。 その場合、どのような選択肢がありますか👍 XYZ Web サイトにアクセスできませんか? どのような選択肢があるでしょうか? と呼ばれる XNUMX 語のオプションがあります。 スクリーンリーダー。 はい、正解です。 スクリーンリーダー。 さて、このスクリーン リーダーは何でしょうか? Web上のコンテンツをナレーションするために使用されるソフトウェアです。 基本的には、コンテンツ、リンク、ラジオ ボタン、画像、ビデオなど、Web サイトにあるものです。スクリーン リーダーがすべてをナレーションしてくれます。 利用可能なスクリーン リーダーが多数あります。 私はジョーズで働いてきました。

基本的に、ジョーズまたはその他のスクリーン リーダーを起動して Web サイトにアクセスすると、完全なコンテンツがナレーションで表示されます。 例: 私はジョーズを起動し、ブラウザを起動しました。JAWS は Mozilla を発表します。 Firefox ページが始まります。アドレスバーに移動すると、JAWS がそれをアナウンスします。 アドレスバー 次に入力します。 www.google.com アドレスバー上で、ジョーズは次のように説明します:-

Address Bar,w,w,w,period,g,o,o,g,l,e,period,c,o,m. Also, when the page loads completely jaws will again announce Google.Com Home page.

Now if I go to Google Search, then JAWS will announce that Google search. So it would be easy for a blind person to recognize things in an easy manner.

ここで説明したいのは、スクリーンリーダーはテキストボックスに何かを入力すると単語ごとに読み上げてくれるということです。. 同様に、リンクがある場合はリンクとして発音され、ボタンの場合はボタンとして発音されます。 視覚障害者が物事を簡単に識別できるようにします。

Web サイトの設計と開発が不十分な場合、ジョーが正しいコンテンツをナレーションできず、その結果視覚障害者がアクセスできなくなる可能性があります (通常、ジョーがリンクをナレーションしているとします)。コンテンツの場合、盲目のユーザーはそれがリンクであることを決して知ることができず、それがその Web サイトにとって重要なものである場合 👍)。その場合、Web サイト ビジネスにとっては大きな損失となるでしょう。

2) 視覚障害

視覚障害に関して言及したいカテゴリーは XNUMX つあります。

一つ目は色覚異常です。 色覚異常とは、完全に盲目ではないが、特定の色を正しく見ることができないことを意味します。 赤と青は、色覚異常があると正しく見ることができない一般的な色です。 つまり、基本的に、私が赤色の色覚異常を持っていて、80% が赤色である Web サイトを使用したい場合、その Web サイトで快適に使用できるでしょうか? 答えはいいえだ。

したがって、ウェブサイトは、色覚異常を持つ人でも問題なくアクセスできるように設計される必要があります。 赤色のボタンの簡単な例を考えてみましょう。 黒で縁取られている場合にアクセスできるようにするため。 それならアクセスも簡単ですよ。 通常、黒と白は普遍的なものと考えられています。

3) 弱視障害

XNUMX つ目は、視力が悪い (視力がはっきりしていない) か、さまざまな視力の問題 (網膜に関連する目の問題が多いなど) を抱えている人で、サイトにアクセスできない場合です。

1) このような場合、最善の策は、小さなテキストを避けることです。 それは視力の悪い人にとって大きな利点となるからです。

2) また、視覚障害のある人は、ウェブサイトのテキストを拡大して快適に利用したいと考えています。そのため、ウェブサイトは、拡大してもテキストを拡大してもレイアウトが崩れないように設計する必要があります。そうしないと、視覚障害のある人にとって良い印象を与えません。

4) その他の障害

障害のあるユーザー向けのアクセシビリティ テストで考慮すべき重要なポイントの 1 つは、マウスを使用せずに Web サイトにアクセスすることです。ユーザーは Web サイトのリンク、ボタン、ラジオ ボタン、チェックボックス、ポップアップ、ドロップダウンに完全にアクセスでき、すべてのコントロールがキーボードから完全にアクセス可能で、操作可能である必要があります。

次に例を示します。: 右利きで麻痺していて、マウスを使うのが苦手だったり、マウスを使いたくないと言ったらどうしますか? その場合、サイト上のリンクやチェックボックスにキーボードでアクセスできないとしたら、👍 つまり、Web サイトはキーボードで完全にアクセス可能である必要があります。

Alternative Text should be there for Images, Audio, Video so that screen reader reads them and will narrate them so that a blind person can easily recognize what the  image, audio, the video is all about. In addition, to it, keyboard shortcuts should be there to easily access website and navigation should be available with the keyboard.

また、焦点が完全に見える必要があります。 Tab キーを押しているとき、ユーザーはコントロールがどこに移動しているかを確認できるはずです。 可視フォーカスを使用すると、視力の弱いユーザーや色覚異常のあるユーザーでも、サイトの流れを識別することが非常に簡単になり、アクセスも容易になります。

聴覚障害のあるユーザー（耳が聞こえない、または聞き取りにくい）: 最後は聴覚に障害のある人です。 聴覚障害者であっても、ウェブサイトのコンテンツを見ることができるので、ウェブサイトにアクセスできます。 しかし、オーディオとビデオとなると困難に直面します。 その場合、ビデオとオーディオには代替テキストが必要です。 代替テキストとは、代替テキストを意味します。 航空券の予約方法に関するビデオがあるとします。 その場合、聴覚障害者がそれを読んでビデオの内容を理解できるように、テキストが存在する必要があります。

サンプル テスト ケース アクセシビリティ テスト

すべてのユーザーがアプリケーションを使用するためにチェックする必要があるポイントは次のとおりです。このチェックリストは、アクセシビリティ テストの承認に使用されます。

1. アプリケーションはすべてのマウス操作とウィンドウに対してキーボード同等の機能を提供しているでしょうか?
2. 手順はユーザー ドキュメントまたはマニュアルの一部として提供されていますか? ドキュメントを使用してアプリケーションを理解し、操作するのは簡単ですか?
3. スムーズなナビゲーションを確保するためにタブが論理的に順序付けされているかどうか?
4. メニューにショートカットキーはありますか?
5. アプリケーションはすべてのオペレーティング システムをサポートしていますか?
6. 各画面またはページの応答時間は、エンド ユーザーがどれくらい待つかをわかるように明確に記載されていますか?
7. アプリケーションにすべてのラベルが正しく書き込まれていますか?
8. アプリケーションの色はすべてのユーザーに対して柔軟かどうか?
9. エンドユーザーが理解しやすいように、画像やアイコンが適切に使用されているか?
10. アプリケーションに音声アラートがあるかどうか?
11. ユーザーがオーディオまたはビデオのコントロールを調整できるかどうか?
12. ユーザーが印刷およびテキスト表示用のデフォルトのフォントを上書きできるかどうか?
13. ユーザーがディスプレイの点滅、回転、または移動を調整または無効にできるかどうか?
14. 情報を伝達したりアクションを示したりする唯一の手段として色分けが使用されていないことを確認してください。
15. ハイライトは色を反転して表示できるかどうか? コントラスト比を変更してアプリケーションの色のテストを行う
16. オーディオおよびビデオ関連のコンテンツは障害者に適切に聞こえるか? Web サイト上でスピーカーのないすべてのマルチメディア ページをテストします。
17. 障害のあるユーザーがソフトウェアやアプリケーションに慣れるためのトレーニングが提供されているかどうか?

アクセシビリティ テストの神話

アクセシビリティ テストに関する誤解は次のとおりです。

神話： アクセシブルなウェブサイトの作成には費用がかかります

事実： 高価ではありません。 基本的なテストとともに、設計段階自体でのアクセシビリティの問題について時間をかけて検討します。これにより、コストが節約されるだけでなく、やり直しも可能になります。

神話： アクセスできない Web サイトをアクセス可能な Web サイトに変更するには、時間も費用もかかります

すべての変更を一度に組み込む必要はありません。 障害のあるユーザーにとって最も必要な基本的なニーズに取り組みます。

神話： アクセシビリティは単純で退屈です

ウェブページを魅力的にすることはできますが、すべてのユーザーがアクセスできるように設計する必要があります。また、W3C ウェブ コンテンツ アクセシビリティ ガイドラインでは、テキストのみのページの使用は強く推奨されていません。

神話： 視覚障害者向けのアクセシビリティ

事実 アクセシビリティ ガイドラインに従うことで、ソフトウェアの全体的な使いやすさが向上し、一般ユーザーにも役立ちます。

まとめ

ソフトウェアエンジニアリングでは、アクセシビリティテストは、アプリケーションを障害者に優しいものにするのに役立ちます。Webアプリケーションの複雑さのためにアクセシビリティガイドラインに従うことが不可能な場合は、通常のユーザー用に1つのバージョンのWebサイトを構築し、障害者用に別のバージョンを構築します。