アクセシビリティ テストのステップバイステップ ガイド

この投稿の目的は、アクセシビリティの重要性と、さまざまなシステムでアクセシビリティ テストを実施する重要性について説明することです。さらに、この目標を達成するために実装できるさまざまなツールやテクニックに焦点を当てて説明します。

アクセシビリティについて話すとき、それは障害を持つ個人の使いやすさとして定義することもできます。つまり、誰でも状況に関係なく使えるシステムを目指しているのです。

障害のある個人とは、身体的、視覚的、聴覚的、言語的、または認知的欠陥などを持ち、さまざまな文脈上の障壁と対話する際に制限に直面し、そのため社会に完全かつ積極的に参加できない人々を指します。

一時的か永続的か、部分的か絶対的かにかかわらず、どんな人でも障害を抱える状況に陥る可能性があることを理解する必要があります。

上記の一例としては、家庭内の事故の後、しばらく移動するために松葉杖を使用する必要がある人、またはシステムを適切に解釈するためにスクリーン リーダーが必要な視覚障害のある人が挙げられます。

国立統計研究所が行った調査によると、ウルグアイには障害のある人々が50万人以上おり、これはウルグアイ人口のほぼ17％に相当します。

世界保健機関(WHO) によると、世界では人口の 15% 以上 (100 万人以上) が障害のある状況に直面しています。

ご覧のとおり、これは幅広い人々がこの影響を受けることを意味しており、アクセシビリティを考慮して設計されていないため、システムに適切にアクセスできない可能性があります。

コンテンツの概要

• アクセシビリティテストとは何ですか?
• アクセシビリティ標準とは何ですか?
• WCAG タイムライン
• 規格の構成と適合レベル
• アクセシビリティテストツールとは何ですか?
• アクセシビリティテストはどのように実施されますか?
• アクセシビリティテストツール
• ユーザー アクセシビリティ テスト (手動テスト)
• ウェブアクセシビリティの例
• 結論

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

一言で言えば、ソフトウェア製品にプロセスと検証技術を適用して、それが期待されるアクセシビリティ要件と標準を満たしているかどうかを検証することです。

システムは、状況に関係なく、すべての人がシステムを認識、理解、操作、操作できるように設計されている場合にアクセシブルであると見なされます。

仕事と日常業務の両方でますます多くのシステムが使用されるようになったため、この種のテストの関連性は最近ますます高まっています。

アクセシビリティ標準とは何ですか?

アクセシビリティ標準とは、システムが持つアクセシビリティの程度を理解できるようにする業界内のガイドライン、ルール、管理、規範です。世界で最も使用されている標準は、国際標準の主要な非営利団体である W3C (World Wide Web Consortium) の WCAG (Web Content Accessibility guideline)です。

WCAG に加えて、世界のさまざまな地域で使用されている次のような標準とアクセシビリティ ガイドラインがいくつかあります。

リハビリテーション法、第504条および第 508 条。セクション 504 は障害のある個人にワークスペース、教育、その他の組織へのアクセスを提供するのに役立ち、セクション 508 はテクノロジーへのアクセスを提供するのに役立ちます。

アメリカ障害者法 (ADA) : この法律は、学校や組織などのすべての公共団体が、誰もがテクノロジーにアクセスできるようにしなければならないと規定しています。これには、アクセシビリティ対応システムとアクセシビリティ テスト ツールの両方が含まれます。

WCAG タイムライン

WCAG は、現在 Web システムとモバイル アプリケーションに適用され、常に進化している非常に大きな標準です。

それをよりよく理解し、どのように進化したかを知るために、アクセシブルなデザインの一般規則を記述する目的で、この標準の最初のバージョン (WCAG 1.0) が 1999 年 5 月に登場しました。その後、2008 年 12 月に、Web コンテンツをよりアクセスしやすくするための幅広い推奨事項を網羅した WCAG 2.0 に置き換えられました。 2018 年 6 月に、バージョン WCAG 2.1 が公開されました。これは現在最も安定したバージョンです。

このバージョンには、Web コンテンツのアクセシビリティだけでなく、モバイル アプリケーションのアクセシビリティも含まれています

現在、2 つの新しい文書の作成が進められています。一方では、Web コンテンツ 2.1 のアクセシビリティ ガイドラインを含むバージョン WCAG 2.2。

一方、シルバー (Ag)プロジェクトは現在進行中であり、バージョン WCAG 3.0 になります。この文書には、追加のガイドラインとさまざまなスコアリングメカニズムが含まれます。このプロジェクトはバージョン WCAG 2.2 の後継となることが期待されていますが、それを置き換えるものではなく、WCAG 2.X との互換性もありません。これは一連の代替ガイドラインになります。

規格の構成と適合レベル

標準とその仕組みを理解するために、Web コンテンツの現在のアクセシビリティ ガイドラインには4 つの設計原則(知覚可能、操作可能、理解可能、堅牢*)* が含まれており、78 の基準を適用してさまざまな障害状況を評価する 13 のガイドラインに分散されています。これらは、それほど厳格ではない (A)、中程度に厳しい (AA)、および最も厳格な (AAA) の 3 つのコンプライアンス レベルにグループ化されています。

アクセシブルであるとみなされるコンテンツに関して言及されている 4 つの設計原則は次のとおりです。

• 知覚可能: Web サイトのコンテンツは、すべてのユーザーの観点から意味をなすものでなければなりません。

• 操作可能: ユーザーがすべてのページを簡単に移動できる場合、Web サイトは操作可能です。

• 理解可能:システムのすべての要素は誰でも理解できる必要があるため、言語は簡単でなければなりません。

• 堅牢性: Web サイトのコンテンツは、あらゆる種類のテクノロジーおよびユーザーと互換性がある必要があります。

  
  

WCAG の範囲をよりよく理解するために、これらのガイドラインは、すべての Web 画像 (HTML コード内のタグ) には画像を説明するための代替属性 (alt) が必要であるなど、非常に技術的で低レベルの状況から、より高度な状況まで多岐にわたります。レベルのガイドライン – たとえば、すべてのマルチメディア コンテンツには字幕とそれに対応する翻訳が必要です。

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

身体障害を持ち、コンピューターやモバイル デバイスなどのデバイスを使用できない人は、システムとの対話を支援するサポート ツールが必要になります。サポート ツールの一部は次のとおりです。

• 特別なキーボード: 運動障害のあるユーザー向けに特別に設計されています。

• 画面ズーム ソフトウェア:視覚障害のある人を支援するために開発され、画面を拡大して読みやすくします。

• スクリーン リーダー:このタイプのツールは、画面に表示されるテキストを読み取るために使用されます。

• 音声認識ソフトウェア: 音声を認識すると、話された単語がテキストに置き換えられるため、システムへのエントリ ポイントとして機能します。

  
  

アクセシビリティテストはどのように実施されますか?

テストは、システムが定義された基準を満たしているかどうかを検証する手順とアクティビティを使用して実行されます。

この目的のために、この種のテストを実行する方法のガイドラインとして機能するいくつかの手順が定義されています。これらは、検証タスクを容易にするアクティビティとアクセシビリティ テスト ツールを定義します。

アクセシビリティ テスト ツール - アクセシビリティ テストの実行方法

アクセシブルであるとみなされるためにシステムが何を備えていなければならないかがわかったので、次を使用してさまざまなテストを実行する方法を見ていきます。

• アクセシビリティテストツール
• ユーザー アクセシビリティ テストまたは手動テスト

アクセシビリティテストツール

WCAG 標準は、検証ツールまたは自動ツールを使用して検証されます。検証を実行するために、Web またはモバイル アプリケーションのHTMLコードを読み取り、WCAG に準拠しているガイドラインと準拠していないガイドラインを示すレポートをすぐに取得します。

アクセシビリティを評価するためのツールが市場でいくつか見つかります。

今回はそのうちの2つを紹介します。

Ax (Axe Accessibility) を使用すると、 Web ページの構造が WCAG ガイドラインを満たしていることを確認できます。 CCA (カラー コントラスト アナライザー) は、 WCAG ガイドラインを考慮して色のコントラストを検証します。これらがどのように機能するかを理解するために、それらがどのように使用されるかの簡単な例をいくつか紹介します。

1.Axe (Axe 開発ツール)

このツールは、Web サイトの構造を検査し、Web サイトがすべての WCAG ガイドラインおよび上記のその他の標準の一部を満たしているかどうかを確認するのに役立ちます。

たとえば、Web サイト上でAxを実行し、見出しの構造と順序に関するアクセシビリティ ガイドラインを満たしていないことが判明した場合、このツールを使用すると、これらの側面を迅速に特定できます。

Google Chrome で使用するには、Chrome ウェブストアから拡張機能をインストールするだけです。実行するには、開発者コンソールを開き、「Axe Dev Tools」タブを選択します。このツールはさまざまな検証オプションを提供しており、Web サイト全体または特定の要素をスキャンして検証することができます。たとえば、Web サイト全体を検証するオプションを選択した場合、影響レベルごとに分類された Web サイトのすべてのアクセシビリティ検出結果を含む完全なレポートがすぐに生成されます。

もう 1 つ指摘すべき点は、 Ax が問題の説明と各エラーの解決方法に関する提案を提供するため、エラーを理解しやすくなり、修正プロセスが迅速化されることです。

2. カラーコントラストアナライザー (CCA)

CCAを使用して実行されるテストは、色のコントラスト感度が低い人の状況をシミュレートするために重要です。この状態は、さまざまな色覚異常などの視覚障害のある人に発生する可能性があります。同様に、この種の状況は高齢者にさらに一般的であり、年が経つにつれて悪化する可能性があります。

コントラストがほとんどまたはまったくない色がある場合の主な問題は、システムの移動、読み取り、または操作がいかに困難になるかということです。そのため、このツールは、前景色 (テキストまたは画像) と前景色 (テキストまたは画像) の間に十分なコントラストがあることを確認するのに役立ちます。背景色。

たとえば、Web サイト上のボタンのコントラストを確認する場合、 CCAを使用して前景色 (テキストの色) と背景色を取得できます。 CCA は、両方の色のコントラスト比を自動的に分析します。

CCAツールをダウンロードすると、色を選択するためのさまざまな方法が表示されることがわかります。この場合、スポイトで前景色を選択し、同様にスポイトで背景色を選択します。このツールは、 WCAGガイドラインを考慮した色のコントラストの結果をすぐに表示します。

このツールを使用するもう 1 つの利点は、テキストのサイズに応じて必要な色のコントラスト比に関する推奨事項が提供されることです。

このツールによって提供される推奨事項は、 WCAGガイドラインを使用して実装されました。これらは、このタイプの状況に対する 2 つの準拠レベル、つまり最小コントラスト (AA レベル)と改善されたコントラスト (AAA レベル)を決定します。これらのコンプライアンス レベルの基準には、次のことが記載されています。

• レベル AA の場合、通常のテキストのコントラスト比は少なくとも 4.5、大きなテキストのコントラスト比は少なくとも 3.1 である必要があります。この場合、 WCAG は「大きい」テキストを指し、18 ピクセルまたは 14 ピクセルを太字で示します。

• レベル AAA の要件は、通常のテキストの場合は 7.1、大きなテキストの場合は 4.5 のコントラスト比です。

  
  

  
  

  
  

ユーザー アクセシビリティ テスト (または手動テスト)

アクセシビリティ テスト検証ツールでテストを補完するために、テスト担当者が Web サイトの構造ではなくコンテンツに集中できるようにするユーザー テストまたは手動テストが実行されます。

たとえば、検証ツールを使用して、すべての画像に代替属性 (alt) があることを確認できますが、この種のテストでは、代替テキストが表示されている画像と一致しているかどうかを確認することになります。

これらの検査がどのように実施されるかは、障害の状況によって決まります。この場合、5 つのカテゴリが定義されています。

1. 色の使用テスト

2. 2. フィールドに焦点を当てたテスト

3. ナビゲーションテスト

4. 「ズーム」テスト

5. スクリーンリーダーのテスト

   
   

1. 色の使用テスト

これらのテストの目的は、システムで何が起こっているかを理解するためにシステムが色の使用だけに依存していないことを検証することです。

たとえば、以下では、視覚障害者 (または色覚異常者) の認識と、視覚障害のない人の認識を比較する状況を示します。視覚障害者にとって、情報が正しく入力されているかどうかを識別できないことがわかります。

この状況を解決する 1 つの方法は、以下のような説明的なメッセージとアイコンを組み込むことです。

2. フィールドに焦点を当てたテスト

この種のテストの目的は、運動障害のある人でもシステムを使用できることを確認することです。

このテストでは、ブラウザーによって提供されるフォーカス インジケーターがシステムで有効になっていること、および Web サイト上のすべての要素がシステムに含まれていることを検証します。こうすることで、ユーザーは自分がどこに位置しているのか、何を選択しているのかを知ることができます。

3. ナビゲーションテスト

この種のテストは通常、マウスを使用してシステムと対話するのではなく、キーボードを使用して実行されます。テストを実行するには、キーボード ナビゲーションが可能になるようにフォーカスが正しく設定されている必要があるため、これらはフィールドに焦点を当てたテストに関連しています。

それらを実行するために、一連の質問が提示されます。

• 「tab」キーで上に移動し、「shift + tab」で下に移動して Web サイト内を移動するとき、これらは順番に実行されますか?

• Web サイト全体を左から右、上から下に移動して、Web サイトのすべてのセクションにアクセスできますか?

• サイト上にキーボードだけではアクセスできない要素やコンテンツはありますか?

  
  

このようなタイプの状況は、ナビゲーション テスト中に検証されます。

4.「ズーム」テスト

これらは弱視の人にとって非常に重要です。この状況はあらゆる年齢層の人々にとってますます一般的になってきており、その重要性はますます高まっています。

ズーム機能は、WCAG の推奨事項とアクセシビリティ ガイドラインに含まれているだけでなく、人々の日常生活を楽にするアクセシビリティ テスト ツールにも含まれています。

このような種類のテストを実行するときは、アプリケーションでズーム機能が有効になっているかどうかという非常に単純な質問から始めます。

技術的または設計上の問題により、ズーム機能が無効になる場合があります。これは、ズーム機能を必要とするユーザーがズーム機能を使用するオプションがないことを意味します。

尋ねる必要がある 2 番目の質問は、ズームが適用されたときにアプリケーションが正しく動作するかどうかです。

ズーム機能が有効になっている場合、画面サイズをたとえば 200% に拡大しても、問題なく情報を視覚化し、システム内で操作できることを確認することが重要です。

この種のテストで問題が特定されるのは一般的です。情報が切り取られている、Web サイト上の要素が正しく調整されていない、したがってインタラクションが良好でないなどの問題が発生するためです。ユーザー。

5. スクリーンリーダーのテスト

最後に、画面読み取りを伴うテストについて説明します。このツールは、HTML コンテンツを簡略化されたオーディオに変換します。つまり、画面に表示されている内容を読み取って説明します。

これらのツールの主な目的は、視覚障害のある人々が状況に関係なく、あらゆるシステムをナビゲートできるようにすることです。

彼らは、前述のスクリーン リーダーを使用してシステム内を移動する人々がシステムにアクセスできることを確認しようとしています。

スクリーン リーダーにはさまざまな種類があり、デスクトップ アプリケーションであるものもあれば、Chrome 拡張機能であるものもあります。例としては、NVDA、JAWS、Windows ナレーター、スクリーン リーダーなどが挙げられます。

これらのテストを実行するには、まずツールをアクティブにしてから、リーダーが解釈した内容が画面に表示されている内容と一致しているかどうかを観察しながら、システム内を手動で移動します。

最後に、テスト中に見つかったすべてのアクセシビリティ エラーの詳細を記載したレポートが作成されます。

この種のテストで検出できる問題はいくつかあります。たとえば、フォーム上の入力フィールドを通過していて、読者がフィールドを読み取れなかった場合、視覚障害者にとっては問題になります。視覚障害者は何を理解できないためです。入力する必要がある情報。

ウェブアクセシビリティの例

Web アプリケーションがアクセス可能であることが何を意味するかは理解できたので、システムがアクセシビリティ要件を満たしている場合と満たしていない場合を示す例をいくつか示します。

1. 適切な色のコントラスト

視覚障害のある人は、単純な背景であろうとテキストのある画像であろうと、背景色とコントラストがない場合、テキストを読むのが難しくなる可能性があります。

たとえば、ビデオの字幕や画像に印刷されたテキストなどです。

2. フォーム内のフィールドに説明的なタグを提供する

フォームの各フィールドにタグが埋め込まれてフォームが実装されるのが一般的です。スクリーン リーダーがこれらの説明を見落とす可能性があるため、この方法は行わないことをお勧めします。さらに、認知障害のあるユーザーは、フィールドの意図や参照を理解できない可能性があります。

これは、ベスト プラクティスに従っていない例です。

これを次の方法で実装することをお勧めします。

3. タイトルと簡単なスペース

シンプルな階層を備えた優れたデザインは、ユーザーがタイトルと、対応するテキスト、スペース、要素の位置との関係を理解するのに役立ちます。さらに、乱雑さが軽減され、コンテンツがよりアクセスしやすくなります。

4. メディア消費の代替手段

コンテキストをさまざまな形式で利用できるようにして、障害のある人がコンテンツにアクセスできるさまざまな方法を提供することが推奨されます。

以下では、ビデオがどのように表示されるかを確認できます。さらに、音声が文字に起こされて読めるようになります。

結論

ソフトウェア製品のアクセシビリティは、多くのユーザーに影響を与える可能性があるため、無視できない属性です。各人が直面している障害の状況に応じて、標準や優良事例によって定められた規制の採用の度合いに応じて、ソフトウェアの操作が容易になるか困難になるかが決まります。

システムのアクセシビリティを競争上の利点として考えることが重要です。システムのアクセシビリティは、ユーザー エンゲージメントを高めるだけでなく、メンテナンスと有効性を向上させ、世界のさまざまな国の既存および将来の法的要件にも適合するためです。あなたは国際的に行きます。

WACGなどのアクセシビリティ標準は、情報システムをアクセシブルにするための優れた参照フレームワークと優れた実践方法を提供し、アクセシビリティ テストへの道を歩み始めるための優れたガイドを提供します。同様に、規格の 3 つのコンプライアンス レベルのおかげで、システムの現在の状態を測定し、将来段階的に新しいレベルに到達するために実行するアクションを計画することができます。

アクセシビリティ テストを実行するには、 AxやCCAなど、さまざまなアクセシビリティ テスト ツールがあります。これらは、アクセシビリティの観点からシステムの一般的な状態を迅速に判断し、途中で検出されたエラーを修正するための推奨事項を提供する非常に優れた分析能力を提供します。

これらのツールを補完するには、ツールで達成された結果を見るだけでは得られないアクセシビリティの他の側面を理解できるようにする検証活動と手動検証を考慮することも重要です。

アクセシビリティ テスト ツールと手動テストを組み合わせた戦略を適用すると、システムによって提供されるアクセシビリティのレベルを認識し、さらなる成熟度に向けた改善の機会を検出できるようになります。