用語集

This page is not available in the language you requested. You have been redirected to the English version of the page.
Link to this page copied to clipboard

Axe DevTools for Webで使用される用語

Not for use with personal data

a11y

アクセシビリティの略。文字aに続いて11文字、そして文字yとして解釈されます。

アゴラ

AgoraはDequeの内部アーティファクトリポジトリです。これはArtifactoryインスタンスに基づいています。Agoraを通じて、ユーザーはAxe DevToolsコンポーネントをダウンロードしたり、カスタムルールセットを管理・配布したりできます。

ARIA

アクセシブル リッチ インターネット アプリケーション (ARIA) は、ワールド ワイド ウェブ コンソーシアム (W3C) によって公開されている技術仕様で、特に動的コンテンツやAjax、HTML、JavaScript、および関連する技術で開発されたユーザーインターフェイスコンポーネントのアクセシビリティを向上させる方法を定義しています。

支援技術

障がいを持つ人々の中には、ソフトウェアやウェブサイトと単独ではインタラクションできない人もいます。これらの人々は、インターネットを公平に利用するために支援技術を必要とします。非常に一般的な支援技術の一つはスクリーンリーダーです。これらのデバイスは、視覚障がいや盲目の人々のために画面上のテキストを音声で読み上げます。使用するプラットフォームに応じて、様々なスクリーンリーダーがあります。例としては、PCではNVDAやJAWS、MacではVoiceOver、AndroidではTalkBackがあります。

ベストプラクティス

Dequeのベストプラクティスは、特定の形式的手法が不足している場合や不十分な場合に、望ましいアクセシビリティ結果をもたらす、試行錯誤された手法です。公式には確立されたアクセシビリティルールセットには含まれていませんが、Dequeのベストプラクティスに従うことで、テストされたウェブページのアクセシビリティと全体的な品質が向上します。Dequeのベストプラクティスガイドラインに準拠していないからといって、自動的に失敗を意味するわけではないことに注意すべきです。さらに、アプリケーション、サイト、またはページの目標において、適切であるかを考慮するための専門的判断が必要です。時には、ベストプラクティスのアクセシビリティ手法が、特定の問題を解決するためには適用できなかったり、実用的でなかったりすることがあります。ベストプラクティスルールセットを構成するルールについては、ベストプラクティスを参照してください。

ブラウザ自動化プラットフォーム

Axe Watcherにおいて、ブラウザ自動化プラットフォームはウェブサイトのテストを自動化するために使用するフレームワークです。プラットフォームにはCypress、Playwright、Puppeteer、WebdriverIO、およびWebDriverJSが含まれます。詳細については、

チェックポイント

a11yの専門家であるDequeのチームによって作成された、アクセシビリティ要件テストのための確立された方法で、テスト結果の一貫性と正確性を高めます。WCAG成功基準に基づいて、これらのガイドラインのより明確な分類と解釈を提供し、失敗は通常コンテンツタイプ別に分かれています。Dequeのチェックポイントは、アクセシビリティ評価中にレビュアーが一貫した正確なテスト結果を出すのを助けます。チェックポイントは、Dequeのデジタル平等への道の重要な部分であるDequeチェックポイント(およびその要件)のマスターリストの中で、最も関連性のあり、適用可能なセクションを指します。

コンポーネントテスト

CypressやPlaywrightとAxe Watcherを使うことで、個別のコンポーネント(例えばReactコンポーネント)を分離してテストすることができます。これとは対照的に、e2eテストは実際の環境でウェブアプリケーション全体をテストします。Axe Developer Hubは、エンドツーエンドのシナリオでアクセシビリティの問題を検出でき、Cypressを使ってコンポーネントを分離してテストすることも可能です。e2eテストをご覧ください。

設定の上書き

設定の上書きを使用すると、特定のテスト実行の設定をカスタマイズできます。(JavaScript/TypeScript) configurationOverrides プロパティまたは (Java) ConfigurationOverridesクラスでのテスト設定を通じて行います。これらの上書き設定は、組織のグローバル設定に準拠する必要があり、アクセシビリティ基準、ベストプラクティス、実験的ルール、axe-coreのバージョンの変更を含むことができます。

カスタムルールセット

カスタムルールセットは、ルールデータ(ルールとチェック)を含むJSONファイルから作成され、Axe DevToolsコンポーネントに新しいルールを追加したり、ルールの重要度/影響度を変更したり、テストからルールを削除するために使用されます。

重複

重複は、同じ文書オブジェクトモデル (DOM) ノードにおける同じアクセシビリティ問題が複数のページ状態で見られるものです。重複を含む問題を修正すると、すべての重複が消えます。それらはすべて同じ問題だからです。

e2eテスト

エンドツーエンド、またはe2eテストは、実際の実装を通じてウェブアプリケーション全体の機能をテストすることを指します。Axe Developer Hubを使用すると、アクセシビリティ問題に対するエンドツーエンドシナリオをテストでき、Cypressを使って個別のコンポーネントを分離してテストすることも可能です。また、コンポーネントテストをご覧ください。

イベント

APIまたはCLIの使用状況を追跡するために、メトリクスライブラリはイベントを作成し、それを使用状況サービスに送信します。イベントには、ウェブページスキャン中に違反したアクセシビリティルールの数や、アクセシビリティスキャンが完了した日時などの使用情報が含まれます。

実験的ルール

実験的ルールは、新しい技術やアクセシビリティの問題の理解と認識を深めるために、まだ開発されテストされています。これらのルールはまだ開発中で、誤検出の可能性があるため、運用環境での使用には頼るべきではありません。最終的には、このルールセットのルールがアクセシビリティ標準の一部になる可能性があります。実験的ルールはデフォルトでは無効です。最新バージョンのaxe-coreでこのルールセットを構成するルールについては実験的ルールを参照してください。

フラッシュ

フラッシュ関数はAxe Watcherのテスト結果をDequeサーバーに書き込み、その結果がAxe Developer Hubに記録されることを保証するために必要です。テストスイートでflush関数を呼び出す必要があります。

Gitless

Gitlessとは、Gitリポジトリを使用しないテストスイートでWatcherパッケージを使用することを指します。Gitリポジトリを使用する必要はありませんが、Gitリポジトリを使用することで、アクセシビリティの欠陥を特定のコード変更に関連付け、その解決を助けることができます。

グローバル設定

グローバル設定Axe設定の一部として、様々なオプションを一箇所で設定し、異なるDeque製品間で共有できるようにします。管理者は、特定の設定をユーザーが変更できるようにすることができます。

アイデンティティトークン

アイデンティティトークンは、DequeのAgoraアーティファクトリポジトリにアクセスするためにJFrogによって発行されるセキュリティトークンです。アイデンティティトークンは、作成時にコピーする必要があります。これがアクセスできる唯一の機会です。トークンは指定された時間間隔後に期限切れになります。通常は1年です。

影響

すべてのアクセシビリティ違反には影響レベルが割り当てられています。影響は、修正努力を優先順位付けする際に役立つ指標です。デフォルトでは、各違反タイプに対してDequeのアクセシビリティ専門家によって影響レベルが割り当てられます。これらの値はほとんどの状況に一般化されているので、ユーザーはルールセットのカスタマイズの一環としてそれらを変更する判断を使うことができます。重大またはクリティカルな影響レベルは、障害を持つユーザーが重大または克服不可能な使用バリアに直面することを意味します。これらは最も大きな法的責任を伴います。軽度および中程度の問題はそれほど深刻ではありませんが、障害を持つユーザーにとって重要な問題を表しており、ページが完全に準拠するためには対処が必要です。検出されたアクセシビリティ問題の影響を分類するために、次の4つのレベルが使用されます:

  • クリティカル: この影響レベルは、障害のあるユーザーがウェブページ上の機能にアクセスしたり対話したりすることが完全にブロックされることを意味します。解決策が実施されるまで、コンテンツは完全にアクセス不可能です。これは、組織が訴訟の脅威にさらされることを意味します。クリティカルな問題の修正は最優先事項であるべきです。

  • 深刻: この影響レベルは、障害のあるユーザーがサイトと対話する際に重大な障害に直面することを意味します。これらのユーザーは、関連するコンテンツにアクセスしようとするときに大きなフラストレーションを経験します。解決策が実施されるまで、一部のコンテンツへのアクセスが難しい、または不可能になり、組織が法的行動の脅威にさらされることになります。修正は高い優先順位であるべきです。

  • 中程度: この影響レベルは、障害のあるユーザーにいくつかの障害が存在することを意味しますが、それらが基本的なフローやコンテンツへのアクセスを妨げることはありません。このレベルの影響を持つ問題は、法的行動の脅威にさらされることがあります。ページが完全に準拠する前に修正を必要とし、解決すべきです。

  • 軽度: 障害のあるユーザーにとって、中程度の問題よりも影響が少ない問題です。この問題は、中程度、深刻、クリティカルな問題よりも優先度が低いかもしれませんが、ページが完全に準拠するために解決が必要です。

未完了

未完了 結果は、axe-coreがそれが違反であるか否かを完全には確定できなかったことを意味します。そのため、人間によるチェックが必要です。axe-coreは誤検出ゼロを目指しているため、確信を持って違反と判断できる問題のみを報告し、不確実なものは別に記録します。未完了要確認 は同じ結果タイプの別名であり、使用しているAxe DevToolsコンポーネントによって、どちらが表示されるかが決まります。未完了の結果は、アクセシビリティの問題になる場合もあればそうでない場合もあります。

インテリジェントガイド付きテスト (IGT)

インテリジェントガイド付きテスト(IGT)は、Axe DevToolsウェブブラウザ拡張機能のインタラクティブなアクセシビリティテストコンポーネントであり、自動テストでは検出できないアクセシビリティエラーを見つけるように設計されています。IGTは、テスト中のウェブページに関してユーザーに簡単な質問をし、このフィードバックを利用して、自動テストだけでは検出できないアクセシビリティエラーをさらに特定します。インテリジェントガイド付きテストについて詳しく知りたい場合は、インテリジェントガイド付きテストのドキュメントを訪れてください。

問題

ウェブページやウェブアプリケーションのコードで識別されたアクセシビリティガイドライン(WCAG 1.0、WCAG 2.0、Section 508、およびWAI-ARIAなどの標準によって定義された)の違反。

JSONアクセシビリティ結果

Axe DevTools APIまたはCLIを使用してウェブサイトをアクセシビリティ問題のためにテストすると、その結果はドキュメントでJSONアクセシビリティ結果ファイルと呼ばれるJSONファイルとして保存されます。このファイルをAxe Reportsにアップロードすることができ(Axe Reportsウェブサイトを通じてウェブサイトのアクセシビリティを時間をかけて監視できます)、またJSONアクセシビリティ結果ファイルをCLIを使ってローカルで.csv、.xml、または.htmlにフィルター/変換することも可能です。詳細についてはCLIでのレポートをご覧ください。あるいは、APIを使用してJSONアクセシビリティ結果ファイルをテスト実行中にレポートに変換することも可能です(詳細については以下のレポートを参照してください)。

手動モード

デフォルトでは、Axe Developer Hubは各ウェブページを自動的に分析し、新しいページ状態を検出するとページを再度分析します。この自動動作を無効にすることもできますが、

また、自動解析の動作を無効にすることができます

どちらの場合も、これによりWatcherが手動モードになります。手動モードでは、analyze()メソッドを呼び出したときにのみページが分析されます。

メトリクスライブラリ

DequeのAPIおよびCLIが使用情報を使用サービスに報告するために使用する内部ライブラリ。

修正されたテストスイート

変更されたテストスイートは、Axe Developer Hubにより新しいプロジェクトを作成した際の指示に従って変更されたテストスイートです。テストスイートを変更することで、アクセシビリティテストを既存のテストスイートに最小限の変更で追加できます。

要確認

その問題がアクセシビリティ基準の実際の違反であるかを判断するためには、人間による検査が必要です。要確認未完了 と同じ意味であり、axe-coreがその問題が違反かどうかを完全に確定することができなかったことを意味します。アクセシビリティテストが初めての場合や、既知の問題が多数あるサイトを扱っている場合は、まず違反を処理してください。「要確認」の結果に取り組むときは、それを修正すべきか無視すべきかを決定する前に、デジタルアクセシビリティの専門家に相談してください。

ページ状態

ページ状態とは、特定の時点におけるウェブページのドキュメントオブジェクトモデル(DOM)の状態を指します。ページ状態は、ログイン画面やシングルページアプリケーション(SPA)などの動的UIを持つ複雑なウェブサイトに役立ちます。DOM状態の例としては以下が含まれます。

  • 要素の可視性
  • 要素の内容
  • ラジオボタンやチェックボックスのチェック状態

Watcherパッケージは、DOMに変更が検出されるとウェブページを再スキャンし、毎回新しいページ状態を保存します。

プロジェクト

Axe Developer Hubのプロジェクトには、アクセシビリティ結果、テスト実行情報、およびGitデータ(ブランチとコミット)が含まれています。この情報とプロジェクトの関連付けは、プロジェクトのプロジェクトIDを通じて行われます。Axe Developer Hubで新しいプロジェクトを作成し名前を付けると、そのプロジェクトIDが生成され、テストと連携してプロジェクトを識別するために使用できます。

レポート

レポート作成とは、JSONアクセシビリティ結果ファイルをAxe Reportsにアップロードしたり、別のアプリケーションで使用するためにローカルで.csv、.xml、または.htmlファイルに変換したりすることを指します。

RGAA

RGAA、またはRéférentiel Général d'Amélioration de l'Accessibilitéは、フランス政府のウェブアクセシビリティ基準です。これは主にWCAG 2.1に基づいており、ウェブコンテンツのアクセシビリティを評価するための具体的な技術基準を提供します。現在サポートされているバージョンはルールセットIDrgaav4として識別されるRGAA 4です。

ルール

ルールはアクセシビリティガイドラインの成功基準に対応しています。それらはJSONオブジェクトファイルによって定義されており、ID、説明、ヘルプメタデータに加え、1つ以上のチェックとオプションのパラメータを含みます。

セクション508

1973年のアメリカリハビリテーション法の修正条項であり、連邦機関が障害者がアクセスできるようにその電子情報技術を提供することを求めています。これは、World Wide Web Consortium(W3C)が開発したウェブコンテンツアクセシビリティガイドライン(WCAG)に基づく16の条項で構成されていますが、WCAG 1.0または2.0標準とは同一ではありません。

SHA

Gitコミットを作成すると、それを一意に識別するIDが生成されます。この一意のIDはSHAと呼ばれます(セキュアハッシュアルゴリズムの略称であり、暗号ハッシュ関数の一群です)。

使用サービス

Axe DevTools for Web(APIおよびCLI)使用状況の指標を記録するRESTウェブサービスです。Dequeが提供するパブリックサービスまたは自身で設定するサービスのいずれかです。詳細については、Axe DevTools for Web利用サービスをご覧ください。

違反

Axe DevToolsによって特定された、1つ以上のアクセシビリティ基準に違反した問題です。

ウォッチャー

テストスイートに統合するコードコンポーネントはウォッチャーと呼ばれます。Dequeは、サポートされている言語およびテストフレームワーク向けにいくつかの版のパッケージを提供しています。Webサイトのテストスイートにウォッチャーパッケージを統合し、ウェブページを分析して結果をAxe Developer Hubに報告し、そこで結果を確認できます。ウォッチャーパッケージは、現在のGitコミットとブランチをスキャンし、テスト実行を関連付けます。

WCAG

WCAG、またはWebコンテンツアクセシビリティガイドラインは、World Wide Web Consortium(W3C)によって開発され、障害者がウェブコンテンツにアクセスしやすくする方法を説明しています。WCAG 1.0は1999年5月に発行され、WCAG 2.0は2008年12月に発行されました。WCAG 2.0は、より高度な技術に広く適用され、自動テストと人的評価によってより正確にテスト可能です。WCAG 2.1は2018年6月に発行されました。これらのガイドラインには、特定の要素に対するテスト可能な基準を定義する成功基準が含まれています。最新のガイドラインであるWCAG 2.2は2023年に発行され、WCAG 2.1に対して9つの新しい成功基準を提供します。

ラッピング

ラッピングは、ブラウザ自動化プラットフォーム(例:Cypress)を修正して、ブラウザ自動化プラットフォームの機能が呼ばれるたびにアクセシビリティテストコード(ウォッチャーパッケージ内)を呼び出すことを指します。ラッピングを使用すると、コードに最小限の変更を加えて、既存のテストスイートにアクセシビリティテストを統合することができます。