アクセシビリティテストの基本を学ぶ

学習の目的

この単元を完了すると、次のことができるようになります。

アクセシビリティテストの重要性を理解する。
アクセシビリティテストを自動化することの長所と短所を要約する。
アクセシビリティテストを自動化するために使用できるツールを特定する。
自動アクセシビリティテストを作成するための戦略を説明する。

アクセシビリティテストを実施する理由

アクセシビリティテストは、障害のある人を含むすべてのユーザーが Web サイトやアプリケーションなどのデジタル製品を使用できるようにするためのものです。つまり、ユーザーがアクセシビリティの障壁に直面する前に、それを見つけて取り除くということです。理想を言えば、最初からアクセシビリティに関する不具合が存在しないのが望ましいのですが、現実には開発中に不具合が発生することがあります。開発にあたっては、こうした不具合がユーザーに届かないようにすることが目標となります。

アクセシビリティテストは、設計段階から始まり、開発中も、リリース後でさえも、開発ライフサイクル全体を通して実施されるのが理想です。こうしたプロアクティブなアプローチによって、各段階でアクセシビリティを考慮して統合することができます。

アクセシビリティテストを実施することで、次のことが可能になります。

すべてのユーザーが平等にアクセスできる、インクルーシブなデジタルエクスペリエンスを提供する
法規制や法律の要件を満たす
より幅広いユーザー層にリーチする
全体的なユーザーエクスペリエンスを向上させる

このモジュールでは、自動テストと手動テストの両方を扱います。どちらも、包括的なアクセシビリティテストを提供するためには非常に重要です。では、自動アクセシビリティテストから見ていきましょう。

アクセシビリティテストを自動化することの長所と短所

ご存じのように、自動アクセシビリティテストを使用すれば、デジタル製品がアクセシビリティの基準を満たしているかどうかを迅速に評価できます。たとえば、自動テスト用のソフトウェアは Web サイトをスキャンして、代替テキストの欠如、色のコントラスト不足、見出しの欠落など、さまざまなアクセシビリティの障壁を特定できます。テストプロセスを自動化することで、効率が高まり、一貫性が向上し、拡張性も保証されます。

自動アクセシビリティテストを実行している開発者。

自動テストには多くの利点がありますが、重大なアクセシビリティの問題や、人間の理解やコンテキストの判断が必要な微妙な障壁を見逃してしまう可能性があることも忘れないでください。たとえば、テキストの画像が見出しとして使用されている場合、自動テストでは検出できるとは限りません。また、アクセシビリティの障壁がユーザーに与える現実的な影響を評価することもできません。アクセシビリティを最も包括的に評価するには、常に自動テストと手動テストの両方を実施することが重要です。

自分で作成したアクセシビリティテストを自動化する場合は、ユーザーインターフェースで再発したアクセシビリティの不具合を検出できるように、既存のテストユーティリティとカスタムテストケースを組み合わせて使用しましょう。iOS や Android 向けのモバイルテストフレームワークには、基本的なアクセシビリティチェックが含まれています。ネイティブコードで機能を開発する場合は、テストフレームワークでサポートされている基本的なチェックを実行するテストを追加してください。モバイルテストに関する詳細は、この単元の最後にある「リソース」を参照してください。

アクセシビリティテストツールを使用する

アクセシビリティテストを実施する際には、いろいろな自動および半自動のツールを使用できます。ほとんどのツールは、Web コンテンツアクセシビリティガイドライン (WCAG) に従ってコンテンツを比較し、アクセシビリティの障壁を特定します。役立つツールをいくつか紹介します。

ツール	概要	機能
Axe	Web サイトやその他の HTML ベースのユーザーインターフェース向けに、包括的なアクセシビリティテストを提供するオープンソースのテストツールです。	コーディング中にアクセシビリティのエラーを検出でき、既存のテスト環境に統合してアクセシビリティテストを自動化できます。
WAVE	視覚障害のあるユーザーに影響を与えるコントラスト不足や代替テキストの欠落など、一般的なアクセシビリティの障壁を特定するための無料の評価ツール一式です。	アイコンやインジケーターを使用して多くのアクセシビリティの問題を特定し、人間による Web コンテンツの評価を支援します。
Google Lighthouse	WCAG 違反を含むアクセシビリティの問題を監査するオープンソースの自動ツールです。	アクセシビリティ監査を実施して、ページのアクセシビリティレベルを反映した 100 点満点のスコアを付けます。
Linters	開発ライフサイクルの初期から統合することで、アクセシビリティの問題や違反を未然に防げる自動ツールで、GitHub: infofarmer / eslint-plugin-jsx-a11y や GitHub: reactjs / react-a11y などがあります。	HTML、CSS、JavaScript などのソースコードを解析し、キーボードナビゲーションの問題や見出しまたはランドマークの不適切な使用といったアクセシビリティの障壁を検出します。
sa11y	Salesforce が作成した、アクセシビリティテストを自動化するためのオープンソースの JavaScript ライブラリ群です。	機械的に検出可能な静的 DOM のアクセシビリティの問題を特定できます。

これらのツールによって実施されるテストは、すべてを網羅しているわけではありません。すべてのテストに合格したとしても、その製品が完全なアクセシビリティを備えているとは限りません。ただし、これらのテストを実施することで、主なアクセシビリティの問題を明らかにすることができ、不具合の再発によってコードのアクセシビリティが損なわれる事態を防ぐのに役立ちます。包括的にアクセシビリティを評価するためには、自動テストに加えて、常に手動テストも実施することをお勧めします。手動テストについては後ほど説明します。

独自のアクセシビリティテストを作成する

コンポーネントのアクセシビリティ対応に多くの労力を費やしたのなら、それが維持できているかどうかを確認したくなるはずです。HTML 要素で想定されるキーボード動作や ARIA 属性の正しさなど、さまざまなアクセシビリティの要素について自動テストを作成することができます。

例: Lightning ボタンのテスト

以下は、Lightning Web コンポーネント (LWC) の Jest テスト用の擬似コードです。Lightning ボタンを作成し、そのコンポーネントの構造がアクセシブルであることを検証しています。

registerSa11yMatcher();
const element = createButton({
    label: 'Submit',
    variant: 'brand-outline',
    title: 'This is a submit button',
});
const button = shadowQuerySelector(element, 'button');


return Promise.resolve().then(async () => {
    await expect(button).toBeAccessible();
});

このコード例では、まず sa11y を登録して、コンポーネントのアクセシビリティチェックができるようにします。次に、表示ラベル、特定のバリエーション、タイトルを設定したボタンを作成します。そして、このボタンを取得して変数に代入します。最後に、アクセシビリティチェックを導入するために、非同期関数を使用してこのボタンをチェックします。

Jest で要素のアクセシビリティをチェックする際には、チェック対象の HTML 構造を抽出して、WCAG 標準に従って検証します。たとえば、描画される要素に対してすべての ARIA 属性が正しく設定されていることを確認します。

以上が、アクセシビリティテストの基本です。これらの原則を実際に試してみる準備はいいですか? 次は、キーボードやスクリーンリーダーのテストを実施する方法について学びましょう。

予想時間

トピック

ヘルプをお探しですか?

Salesforce Platform のリソース