アクセシビリティツールの完全ガイド

アクセシブルなウェブサイトを構築することを学ぶことは、アクセシブルなプラクティスを実装し始めたばかりの人にとっては気の遠くなるような作業になる可能性があります。 よりアクセスしやすいWebサイトの構築を開始できるように、シングルユースのブックマークレットから本格的なアプリケーションに至るまで、さまざまなアクセシビリティツールをまとめました。

アリア

WebAIM Millionの調査によると、ARIAのあるホームページはARIAのないホームページよりも平均して41％多くの検出可能なエラーがあります。 ARIAは、複雑なWebアプリケーションを作成するために不可欠なツールですが、仕様は厳密であり、支援技術を定期的に使用しない人はデバッグするのが難しい場合があります。 ツールを使用すると、ARIAを正しく使用し、アプリケーションにエラーが発生しないようにすることができます。

TPGiは、ページをスキャンしてすべての要素とその指定された役割およびARIA属性が有効であることを確認するWAI-ARIAブックマークレットを作成しました。 ブックマークレットをアクティブにすると、ページにエラーがないかスキャンされ、結果が表示された新しいタブが開きます。 結果には、有効な役割の総数、検出されたARIAエラー、およびエラーが見つかった場所のコードスニペットが含まれるため、ページを簡単にデバッグできます。

上記のブックマークレットで明示的にテストされていないことの1つは、重複するARIAロールの存在です。 特定のランドマークの役割には、いくつかの要素に適用されるように聞こえる名前がありますが、 bannerやcontentinfoなど、ページごとに1回だけ使用する必要があります。 Adrian Roselliは、これらのARIAの役割のいずれかが重複していないかどうかを確認するための簡単なCSSベースのブックマークレットを作成しました。 ブックマークレットをアクティブにすると、問題のある要素に赤いアウトラインが追加されます。

NerdeRegionは、aria-liveリージョンのすべての出力をログに記録するChrome拡張機能です。 スクリーンリーダーが予期せず何かをアナウンスしている理由がわかりませんか？ NerdeRegionを使用すると、タイムスタンプ付きのアナウンスとその発信元のソース要素をすべてDevToolsのパネル内で追跡できます。 さまざまなスクリーンリーダーでaria-liveリージョンがアナウンスされる方法にバグや矛盾がある可能性があるため、NerdeRegionは、問題がコードまたはデバイスの組み合わせによって引き起こされている可能性があるかどうかを判断するための優れたツールになります。

自動テストツール

このクラスのツールは、開発者またはテスターがコードの出力に対して自動テストを実行するために使用でき、ソースコードでは明白に表示されない可能性のあるエラーをキャッチします。 ここで説明した以外にも、高品質の有料サービスやその他のツールが多数ありますが、参入障壁を減らすために、包括的な無料サービスを備えたツールに焦点を当てています。 リストされているすべてのツールは、パブリックインターネット上にないページで実行できるため、開発フローに簡単に組み込むことができます。 アクセシビリティテストは複雑であり、サイトの完全なコンテキストを理解するには常に手動テストが必要であることに注意することが重要ですが、これらの自動テストツールを使用すると確実に有利なスタートを切ることができます。

多くのツールは内部でaxe-coreを使用するため、ツールを組み合わせて使用​​するのは冗長な場合があります。 最終的に、どの種類のツールを選択するかは、どの種類のUIを好むか、および結果の包括性のレベルに関係します。 たとえば、Google Chromeに組み込まれているツールであるLighthouseは、axe-coreルールの部分的な選択を使用するため、ax DevToolsでクリーンスキャンを取得できた場合は、Lighthouseスキャンも実行する必要はありません。

Axe DevToolsはChrome拡張機能またはFirefox拡張機能として利用可能であり、開発者ツールのパネルとして表示されます。 ページ全体またはページの一部のみをテストできます。検出されたすべての問題は重大度でソートされ、デバッグを容易にするためのコードスニペットが付属しています。 Axeでは、インテリジェントガイドテスト機能を使用して、他の自動ツールよりも多くのエラーを検出することもできます。 インテリジェントガイドテストは、結果を生成するためにテスターに​​質問する前に、テストする領域を特定し、可能な限り多くの重労働を行います。 Axeを使用すると、結果を保存およびエクスポートすることもできます。これは、より長く、より協調的な開発プロセスの一環としてエラーを修正する場合に役立ちます。

Accessibility Insightsもaxe-coreで実行されますが、axDevToolsとは異なるいくつかの機能があります。 Android、Windows、またはブラウザ拡張機能など、さまざまなプラットフォームで実行できます。 Accessibility Insightsのすべてのバージョンは、個々の要素情報を検索するためのインスペクターのようなツールと、自動チェックを実行する方法を備えています。 Web拡張機能には、完全なレポートを生成できるようにするための自動テスト、ガイド付きテスト、および手動テストの組み合わせを備えた評価機能も含まれています。

WAVE by WebAIMは、私のツールキットの不可欠な部分です。 拡張形式で利用できるほか、一括テストサービスとAPIも利用できます。このツールは、そのシンプルさとスピードにより、開発中の作業をチェックするのに最適です。 すべてがページの側面にパネルとして読み込まれ、ページをスクロールすることでエラーの全体像を把握できます。 サイドパネルにエラーが表示されていても、それがDOMのどこにあるかわからない場合は、スタイルをオフにして、マークアップ内でエラーを見つけることができます。 WAVEの見出しとランドマーク機能は、作成時にドキュメントのセマンティクスが正しいことを保証するため、私のお気に入りの1つです。

SiteImproveには、有料サービスに加えて無料のChrome拡張機能があります。 WAVEと同様に、拡張機能をページで実行すると、適合レベル、重大度、責任などのフィルターを含む、ページの横にあるパネルにエラーが一覧表示されます。 自動テストは常に誤検知を生成する傾向があるため、重大度フィルターは特に便利です。

GitHub Actionsを使用してソースコードのアクセシビリティテストを自動化することを検討したことがありますか？ まだGitHubActionsに頭を悩ませていなくても、適切なワークフローを設定するために少しだけ助けが必要な場合でも、AdrianBolonioのチュートリアルはあなたにぴったりです。 これは、axe、pa11y、Lighthouse、ユニットテストなどのライブラリを使用してGitHubリポジトリで直接アクセシビリティテストを自動化する方法を段階的に示しています。

メインブランチへのプルリクエストを作成または更新するとすぐにGitHubアクションが実行されるようにリポジトリを構成する方法を学習します。 いずれかのGitHubアクションでアクセシビリティの脆弱性が検出されると、プルリクエストがクラッシュし、検出されたエラーを解決するまでマージが無効になります。 大きな違いを生む小さなディテール。

色

昨年、ホームページのなんと86.4％で低コントラストのテキストエラーが見つかりました。 開発者はカラーパレットの制御が制限されていることが多いため、プロセスのできるだけ早い段階でアクセス可能なカラーパレットを確立するようにすることが重要です。

カラーパレットのデザインを開始するときは、ブラウザ内のカラーピッキングツールが役立つ場合があります。 私の色はアクセシブルですかは、アクセシブルなカラーパレットを理解するのに役立つツールです。 基本モードでは、任意の2色間のコントラスト比が計算されます。 テキストのフォントサイズとフォントの太さは、適合性のレベルに基づいて必要なコントラスト比に影響を与える可能性があります。このツールは、満たすさまざまな標準をすべて適切にレイアウトします。 また、HSL範囲スライダーを備えているため、任意の色を微調整でき、調整を行うと結果が自動的に更新されます。 パレットモードでは、パレット内のすべての色を相互に比較し、満たされているコントラスト比と基準を表示できます。これは、さまざまな色を組み合わせる方法を決定するのに役立ちます。 色を調整すると、パーマリンクも更新されるため、チームと色の組み合わせを簡単に共有できます。 色を選択するために別のインターフェイスが必要な場合、Atul Varmaは、HSL範囲スライダーの代わりにカラーピッカーを使用する同様のツールを構築しました。

Geenesは、追加するカラーグループごとに完全な色合い/色合いの範囲を構築することですべてを実行しようとします。これにより、限られたパレットではなく、フルカラーシステムを設計できます。 Geenesでは、コントラスト比を提供するだけでなく、パレットをさまざまなモックアップに適用したり、さまざまな形の色覚異常をエミュレートしたりすることもできます。 ほとんどの機能を無料で試用でき、寄付で複数のパレットのロックを解除できます。

特定のツールは、特定の色関連のアクセシビリティの問題を解決するのに役立ちます。 特にボタンは、テキストの色と背景色を気にする必要があるだけでなく、ボタンの背景とページの背景、およびフォーカスのアウトラインの色と両方の背景を考慮する必要があるため、注意が必要な場合があります。 Stephanie EcklesのプロジェクトButtonBuddyは、これらの要件を簡単な言葉で説明し、これらの個々のパーツの色を選択するのに役立ちます。

一部の色の組み合わせは、色覚異常のない人が見たときに技術的にコントラスト要件を満たす場合がありますが、特定の種類の色覚異常や低視力に問題を引き起こす可能性があります。 使用できるユーザーは、視覚フィルターを適用してさまざまなタイプの色覚異常をエミュレートし、おおよその色のコントラスト比を計算します。

既存のサイトのコンテキストで色の組み合わせをテストしたい場合、StarkはChromeのカラーピッカー拡張機能であり、特定の種類の色覚異常をシミュレートできます。 さらに、Anna Monusは、Chromeにすでに組み込まれている色覚異常ツールの役立つ記事を作成しました。 この種のエミュレーションは、テストを実際のユーザーに完全に置き換えることはできませんが、より適切な初期選択を行うのに役立ちます。

開発者として、私たちはプロジェクトに取り組み始めることがあります。そこでは、完全な事前に確立されたブランドパレットなしで、設計を進めてコードを書き始める必要があります。 開発が開始されると、カラーパレットを外部ツールに前後にインポートし続けるのは面倒な場合があります。 コード環境内で色のコントラストをチェックするための多くのオプションがあります。 Alex Clappertonは、2色で渡すCLIツールを開発しました。このツールは、コントラスト比と合格基準をターミナルに出力します。 BBCは、2色を使用して希望の基準を満たしているかどうかを判断するJavaScriptカラーコントラストチェッカーを公開しています。 このようなツールは、テストとともにコードベースに配置することも、Storybook、PatternLabなどの設計システムライブラリに実装することもできます。

A11yカラートークンはさらに一歩進んで、CSSまたはSASSで補色トークンを自動的に生成できるようにします。 色と希望の比率を渡して、要件を満たすその色の色合いまたは色合いを生成します。 何かのコントラスト比をすばやく確認する必要がある場合、ChromeとFirefoxは、それぞれの開発ツールのカラーセレクター内にもカラーコントラスト情報を表示するようになりました。 これらのツールのどれもあなたの好みに合わない場合、ステファニーウォルターは色のアクセシビリティに関する彼女のブログ投稿で他の多くの色関連のツールオプションをカバーしています。

互換性

支援技術を構築することで、デバッグに関して別のレベルの複雑さが追加されることがよくあります。 支援技術は本質的にブラウザーの上部にあるインターフェースの別のレイヤーであるため、ブラウザーと支援技術の組み合わせに注意を払う必要があります。 バグは、ブラウザまたは支援技術のいずれかに存在する場合もあれば、特定の組み合わせでのみ存在する場合もあります。 特定の問題を修正しようとするときは、このバグトラッカーのリストを手元に置いておくことをお勧めします。 これらのいくつかは、他の人があなたが抱えているバグを経験しているかどうかを確認できるように公開されていますが、他の人は非公開でバグを報告する手段を提供するだけです。

すべてのブラウザとスクリーンリーダーの組み合わせがうまく連携するわけではなく、すべてのユーザー補助機能がブラウザ間で等しくサポートされているわけではありません。 これらのツールは、デバイスの特定の組み合わせでバグが発生しているかどうかを確認するのに役立ちます。 HTML5アクセシビリティは、新しいHTML機能のリストであり、デフォルトのブラウザ実装がアクセス可能にサポートされているかどうかを示します。 同様に、アクセシビリティサポートは、最も一般的なブラウザとスクリーンリーダーの組み合わせでのARIAの役割とそのサポートのリストを提供します。

アクセシビリティの文書化

アクセシビリティは、多くのUXデザインチームではまだ後から考えられています。 アクセシビリティの考え方を採用するのに役立つ簡単ですが非常に効率的な戦略は、QualtricsのEliseLivingstonと彼女のチームからのものです。 彼らは、エンジニアリングに引き渡す前に、すべての設計ドキュメントにアクセシビリティドキュメントを追加し始めました。 製品のアクセシビリティを改善するだけでなく、設計プロセスのかなり早い段階で潜在的なアクセシビリティの問題を確認することもできます。

エリーゼは、アクセシビリティのドキュメントに2つのステップで取り組むことを提案しています。最初にキーボードの動作を定義し、次に支援技術で理解できるセマンティックラベルを指定します。 試してみたい場合は、エリーゼがアプローチについて知っておく必要のあるすべてのことを記事にまとめました。 現在のプロセスを再考する絶好の機会です。

フォーカス管理

フォーカスの管理は、複雑なアプリケーションにアクセスできるようにするために必要ですが、多くの場合難しい部分です。 フォーカスの順序は論理的であり、フォーカスはカスタムコンポーネント上で正しく移動し、相互作用可能な各要素には明確なフォーカススタイルがあることを考慮する必要があります。

レベルアクセスによるこのブックマークレットは、ページ上のすべてのフォーカス可能な要素にラベルを付けて、フォーカスの順序が読み取りの順序と一致することを確認できるようにします。 Firefoxユーザー向けに、Firefoxのアクセシビリティインスペクタはバージョン84以降にこの機能を追加しました。

さまざまなコンポーネントやサードパーティのコードが予期せずフォーカスを移動する可能性がある複雑なコードベースでは、Scott Vinkleによるこの小さなスニペットは、現在フォーカスされている要素を確認するのに役立ちます。 アプリケーションの他の部分によってフォーカスが移動するのに苦労している場合は、 console.logをconsole.traceに置き換えて、フォーカスを移動している関数を正確に特定したい場合もあります。

Webページですべてのフォーカススタイルをテストするために、ScottO'Haraのスクリプトを開始点として使用できます。 すべての要素をタブで移動すると、しばらくすると面倒になる可能性があるため、各要素を回転するスクリプトを使用すると、フォーカススタイルが一貫して表示され、ページのコンテキスト内で機能することを確認できます。

フォーカスの順序を修正するために正のタブインデックスを設定することは、一般的なアクセシビリティの落とし穴です。 正のtabindexを持つ要素は、ブラウザが最初にそれらにタブで移動するように強制します。 これは技術的にはエラーではないかもしれませんが、多くの場合予期しないものであり、解決するよりも多くの問題を引き起こす可能性があります。 Paul J. Adamのtabindexブックマークレットを使用すると、tabindex属性が適用されているすべての要素を強調表示できます。

レイアウトの使いやすさ

レイアウトがCSSグリッドまたはFlexboxの順序プロパティに大きく依存している場合、ドキュメントの読み取り順序が視聴者の期待と同期しないことがあります。 Adrian Roselliは、サイトが意味のあるシーケンスガイドラインに合格していることを確認できるように、読み取り順序を追跡するためのブックマークレットをコーディングしました。

WCAGには、特定のテキスト設定が適用されたときにすべてのコンテンツが引き続き機能するテキスト間隔基準が含まれています。 これをテストするために、Steve Faulknerは、必要なテキスト間隔設定をページ上のすべてのテキストに自動的に適用するブックマークレットを作成しました。 高さの固定などを避け、オーバーフローを許可すると、サイトにアクセスしやすくなるだけでなく、サイトに配置したコンテンツがレイアウトを壊さないようになります。コンテンツ編集者はこれに感謝します。

Jared Smithは、カーソルを44×44ピクセルのボックスに変換するブックマークレットを作成しました。これにより、コントロールにカーソルを合わせると、推奨されるターゲットサイズの基準を満たしていることを確認できます。

リンター

Lintersは、アプリケーションを実行またはビルドする前にソースコードをスキャンすることでエラーを検出するツールのクラスです。 リンターを使用することで、コードを実行またはビルドする前に小さなバグを修正できるため、後で貴重なQA時間を節約できます。

多くの開発者はすでにESLintを知っており、ある程度の能力で使用しています。 新しいツールを学ぶ代わりに、既存のワークフローに新しいプラグインを含めることで、アクセシビリティテストをすぐに開始することができます。 Eslint-plugin-jsx-a11yは、JSX要素用のESLintプラグインであり、コードを記述したときにエラーが表示されます。 スコット・ヴィンクルは、それを設定するのに役立つガイドを書きました。

Dequeには、GithubアプリまたはVSCodeExtensionとして利用可能なaxLinterが付属しています。 Axe Linterは、React、Vue、HTML、およびMarkdownファイルを構成なしでコアルールと照合するため、簡単に起動して実行できますが、独自のオプションを渡すこともできます。 便利な機能の1つは、WCAG2とWCAG2.1を区別することです。これは、特定の基準を満たそうとしている場合に役立ちます。

マークアップ

ウェブは弾力性があるように作られています。 マークアップが壊れている場合、ブラウザは間違いを修正するために最善を尽くします。 ただし、これは、スタイリングの観点とアクセシビリティの観点の両方から、意図しない副作用を引き起こす可能性があります。 W3C HTMLバリデーターを介して出力を実行すると、壊れたタグ、それらを持たないはずの要素に適用されている属性、その他のHTMLエラーなどを検出するのに役立ちます。 Dequeは、同じエンジンに基づいてW3C HTML Validatorブックマークレットを作成しました。これにより、通常のバリデーターが到達できないローカルホストまたはパスワードで保護されたページのマークアップを確認できます。

あなたが視覚的な人であれば、Gael Poupardのプロジェクトa11y.cssは、マークアップ内で起こりうるリスクをチェックするスタイルシートです。 拡張形式またはブックマークレット形式の両方で利用可能で、表示されるアドバイスのレベルだけでなく言語もカスタマイズできます。 同様に、sa11yは、ブックマークレットとしてインストールしたり、コードベースに統合したりできるツールです。 Sa11yは、CMSコンテンツの出力を確認するために特別に設計されています。 コンテンツ編集者が理解して必要な修正を行うことができるように、非技術的な言語で警告が表示されます。

読解レベル

アクセシブルなサイトは、アクセシブルなコンテンツから始まります。 認知的アクセシビリティは、進行中のWCAG 3ドラフトの主要な焦点であり、現在、成功基準3.1.5で言及されています。これは、作成者がコンテンツをより低い2年生（7〜9年生）の読解レベルで理解できるようにすることを目指していることを示唆しています。

Hemingway Editorは、コンテンツを作成するときにコンテンツの読み取りレベルを計算するため、コンテンツを簡単に理解できるように編集できます。 側面のパネルは、コンテンツをより読みやすくするためにどのように改善できるかについての提案を提供します。 サイトがすでに公開されている場合、Juicy Studioは、提供されたフォームにURLを渡す可読性ツールを作成し、3つの異なる読解レベルアルゴリズムを使用してサイトのコンテンツを分析および評価します。 これらのスコアのそれぞれが何を伴うかについての有益な説明もあります。 ただし、この特定のツールの1つの制限は、ナビゲーションやフッターテキストなど、結果を歪める可能性のある、ページにレンダリングされるすべてのテキストを考慮に入れることです。

テストスイートと継続的インテグレーション

ほとんどの自動テストツールの欠点は、ブラウザで実行する必要があることです。 単一の大規模なコードベースで作業している場合は、アクセシビリティテストを既存のテストプロセスに組み込むか、継続的インテグレーションフローの一部として組み込むことができます。 カスタムテストを作成すると、自動テストツールにはないアプリケーションの認識が得られ、カスタマイズされた包括的なテストをよりスケーラブルな方法で実行できます。

繰り返しになりますが、axe-coreは、これらのツールのほとんどを頻繁にサポートするオープンソースライブラリとしてポップアップ表示されるため、ツールが機能するかどうかは、テスト結果の違いではなく、コードとの統合の程度に基づく可能性があります。 。 Marcy Suttonは、アクセシビリティの自動テストの作成を開始するためのフレームワークにとらわれないガイドを公開しました。 彼女は、単体テストと統合テストの違いと、さまざまなシナリオでどちらかを選択する理由について説明します。

楽しんでいるテストフレームワークがすでにある場合は、 axe-coreを組み込んだライブラリがすでに存在する可能性が高くなります。 たとえば、Josh McClureはヒノキの斧を使用するガイドを作成し、NickColleyはjest-axeでJestフレーバーのバージョンを作成しました。

Pa11yは、CIバージョンでも利用可能なテストに関する構成可能なインターフェイスを提供するツールです。 その多くの構成オプションにより、テストで発生する可能性のある複雑な問題を解決できます。 たとえば、アクション機能を使用すると、テストを実行する前に一連のアクションを渡すことができ、ページにアクセスする前に認証が必要な画面をテストする場合に役立ちます。

ユーザー設定

ユーザーのオペレーティングシステムとブラウザの設定を検出するのに役立つ多くの新しいメディアクエリがあります。 最近、開発者はモーション設定やダークモードなどのデフォルトを設定するためにこれらの設定を検出することがよくありますが、同じ設定がないと再現が難しいバグが発生する可能性もあります。

Magica11yは、ユーザーの好みを判断できる一連の関数です。 ドキュメントページを技術者以外のテスターに​​送信するか、これらをアプリに組み込んで、ユーザーの環境をより正確に再現できるようにします。

まとめ

自動化されたアクセシビリティテストは、すべてのアクセシビリティエラーの30％しかキャッチできないと推定されています。 ツールは改善を続けていますが、設計および開発プロセスに障害者を含めることに取って代わることは決してありません。 持続可能で全体的なアクセシビリティプロセスでは、テスターや障害のあるユーザーが後でこれらの問題を見つけて報告できるようにするのではなく、チーム全体でツールを使用してプロセスの早い段階でこれらのエラーをできるだけ多くキャッチする必要があります。

さらに多くのツールが必要ですか？ A11yプロジェクトとStarkは、開発者とユーザーの両方のための追加のアクセシビリティツールのリストを厳選しました！ または、下のコメントに提案を残してください。ワークフローにどのツールを組み込んでいるかをお聞かせください。