Axe Developer Hub 用語集
Axe Developer Hubを理解するのに役立つ用語
a11y
「アクセシビリティ」の数字を使った略語（またはヌーモニム）であり、11（イレブン）は、最初の「a」から最後の「y」までの文字数を表しています。 アクセシビリティの発音は「 アライ」です。
APIキー
認証のためには、 APIキー を Axeアカウント設定で生成します。同じAPIキーを複数のプロジェクトで使用することができますが、Axe Developer Hub APIキーはWebプロジェクト専用、Axe DevTools Mobile APIキーはモバイルプロジェクト専用です。
Axe Developer Hub
Axe Developer Hub では、新しいテストプロジェクトを作成し、アクセシビリティテスト実行の結果を表示します。必要なだけプロジェクトを作成して、ウェブサイトやモバイルアプリのアクセシビリティを表示および管理できます。
ベストプラクティス
Dequeが示す ベストプラクティス は、特定の公式な方法が存在しない、または不十分な場合に、望ましいアクセシビリティの結果をもたらすために時間をかけて検証された技術です。それらは、確立されたアクセシビリティのルールセットには公式には含まれていませんが、Dequeのベストプラクティスに従うことで、テスト対象のウェブページのアクセシビリティと全体的な品質を向上させることができます。Dequeのベストプラクティスのガイドラインに従わないことが自動的に失敗を示すわけではありません。また、アプリケーション、サイト、またはページの目標に応じた適切性を考慮するためには専門的な判断が必要です。時には、特定の問題を解決するためのベストプラクティスのアクセシビリティ技術が適用できない、または実用的でないことがあります。「 ベストプラクティス 」で、ベストプラクティスのルールセットを構成するルールをご覧ください。
ビルドID
ユーザーが提供しない場合は ビルドID は、自動的にUUIDとして生成され、スキャンを1つのテストセッションとしてリンクするために使用されます。複数のマシンや環境でテストスイートを実行する際には、ビルドIDを提供すると、すべての実行がリンクされ、Developer Hubで1つのセッションとして表示されます。
重複
「 重複 」は、複数の ページ状態で同じドキュメントオブジェクトモデル（DOM）ノードに見られる同じアクセシビリティの問題です。重複の問題を修正すると、すべての重複が消えるため、すべてが同じ問題です。
e2eテスト
エンドツーエンド、または e2eテストは、ウェブアプリケーション全体の機能を実際の実装によりテストすることを指します。Axe Developer Hubを使用すると、アクセシビリティの問題に対するe2eシナリオをテストすることができます。
実験的ルール
実験的ルール は、まだ開発中であり、新しい技術やアクセシビリティの問題の理解や認識の向上に対応するためにテストされています。これらのルールは、まだ開発中であり、誤検出を招く可能性があるため、製品環境では頼るべきではありません。最終的にはこのルールセットのルールがアクセシビリティ基準の一部になる可能性があります。実験的ルールはデフォルトで無効になっています。最新バージョンのaxe-coreにおけるこのルールセットを構成するルールについては、 実験的ルール をご覧ください。
Git
多くのDeveloper Hubプロジェクトには、 Git リポジトリを使用するテストスイートがあります。Gitを使用することで、特定のブランチやコミットにおけるコードに、アクセシビリティの欠陥を関連付けることができ、その解決に役立ちます。
Gitless
Gitless は、Gitリポジトリを使用しないテストスイートを持つDeveloper Hubプロジェクトを指します。Gitリポジトリは必須ではありませんが、特定のコードの変更にアクセシビリティの欠陥を関連付けることができ、その解決に役立ちます。
影響
各アクセシビリティ違反には 影響度 のレベルが割り当てられ、最も影響力の小さいものから大きいものまで4つのレベルに分類されます： 軽微、 中程度、 重大、そして 致命的。この指標は修正の優先順位を決めるのに役立ち、Dequeのアクセシビリティ専門家がデフォルトで各違反タイプに影響度を割り当てます。
影響度が 重大 または 致命的 な欠陥は、障害者にとって重大な、または克服不可能な障壁を呈し、法的責任が最も高くなります。 軽微 および 中程度 の問題はそれほど深刻ではありませんが、依然としてコンプライアンスと障害者のニーズに対処するために重要です。
アクセシビリティ問題の影響を分類するために使用される4つのレベルは次のとおりです：
-
軽微：中程度の問題よりも障害者に与える影響は小さいですが、完全に対応するためには依然として解決が必要です。
-
中程度：障害者にとっての障壁が存在しますが、それは基本的なコンテンツやフローのアクセスを妨げるものではありません。これらの問題は法的措置を招く可能性があり、完全に対応する前に修正する必要があります。
-
重大：障害者がサイトと対話する際に重大な障壁に直面し、関連コンテンツへのアクセスが困難でフラストレーションを引き起こします。法的措置を避けるためには、高優先度で修正するべきです。
-
致命的：障害者がウェブページ上の機能にアクセスまたは対話することが完全にできない状態で、コンテンツがアクセス不可能であり、御社が訴訟の高いリスクにさらされます。致命的な問題の修正は最優先事項とすべきです。
変更されたテストスイート
「 変更されたテストスイート 」とは、Axe Developer Hubでプロジェクトを新たに作成する際に提供される指示に従って変更したテストスイートのことです。テストスイートの変更によって、既存のテストスイートに最小限の変更でアクセシビリティテストを追加できるようになります。
組織管理者
「 組織管理者 （org admin）」とは、Axeアカウントで企業全体に対する管理権限を持つユーザーのことです。オーグ管理者は、特定のプロジェクトのメンバーであるかどうかに関わらず、任意のプロジェクトのメンバーや設定を管理できます。オーグ管理者は、新しいプロジェクトを作成するかAxe Developer Hubに結果を送信するにはアクティブなAxe Developer HubまたはAxe DevTools for Mobileのライセンスが必要ですが、ライセンスがなくても既存のプロジェクトを管理できます。
ページ状態
「 ページ状態 」は、特定の時点でのウェブページのドキュメントオブジェクトモデル（DOM）の状態を指します。ログイン画面や動的UIを持つ複雑なウェブサイト、例えばシングルページアプリケーション（SPA）などにおいて、異なるページ状態を確認することは役立ちます。DOM状態の例には以下があります：
- 要素の可視性
- 要素の内容
- ラジオボタンとチェックボックスの選択状態
Watcherを使用する場合、パッケージはDOMに変化が検出されるたびにウェブページを再スキャンし、各時点で新しいページの状態を保存します。
プロジェクト
プロジェクト は、Axe Developer Hubでアクセシビリティの結果、テスト実行の情報、Gitのデータ（ブランチとコミット）を保持します。Developer Hubで新しいプロジェクトを作成し名前を付けると、テストでプロジェクトを識別し、結果データをプロジェクトに関連付けるためのプロジェクトIDが作成されます。
プロジェクト管理者
プロジェクト管理者 は、昇格された権限を持つプロジェクトメンバーです。プロジェクト管理者はプロジェクトメンバーが行えるすべてのことに加え、プロジェクト設定の管理、メンバーの追加や削除、メンバーの役割の変更が可能です。Axe Watcherを使用する際は、パイプラインでテストを実行するためにプロジェクト管理者のAPIキーが必要です。
プロジェクトID
プロジェクトID は、新しいプロジェクトを追加すると自動的に生成され、そのプロジェクトに結果データを関連付けます。Developer Hubにアクセシビリティの結果を送信するには、プロジェクトIDとAPIキーの両方が必要です。プロジェクトIDを1つのテストスイート/リポジトリにマッピングすることが、プロジェクトのアクセシビリティステータスをより正確に追跡するための最良の方法です。
プロジェクトメンバー
プロジェクトメンバー は、Axe Developer Hubのプロジェクトに追加されたユーザーです。プロジェクトメンバーは、プロジェクト内でテストを実行したり、結果を閲覧したりすることができます。プロジェクトにアクセスするには、メンバーは有効なライセンスを持っている必要があります。
SHA
Gitでコミットを作成すると、そのコミットを一意に識別するためのIDが生成されます。この一意のIDは SHA （暗号ハッシュ関数のグループであるSecure Hash Algorithmsにちなんで名付けられています）と呼ばれます。
タグ
タグ は、WCAGのような特定のアクセシビリティガイドラインに属するルールをグループ化します。ルールとそれらが属するタグについての詳細は axe-coreルールの説明
WCAG
WCAG、つまり ウェブコンテンツアクセシビリティガイドラインは、障害を持つ人々にウェブコンテンツをより利用しやすくするために、ワールドワイドウェブコンソーシアム（W3C）によって開発された一連のガイドラインです。これらのガイドラインは、障害を持つさまざまな人々が利用できるアクセシブルなウェブサイトやデジタルコンテンツを作成するための枠組みを提供します。
WCAGの3つの適合レベルは、ウェブコンテンツの特定の要素がその適合レベルを達成するために満たされなければならない成功基準によって定義されています。適合レベルAは最低の適合レベルであり、適合レベルAAAは最も厳格です。適合レベルAAは、レベルAとレベルAAの成功基準の両方を満たす必要があります。すべての成功基準（A、AA、AAA）を満たすことは、レベルAAAへの適合に必要です。
WCAG 1.0はこれらのガイドラインの最初のバージョンで、1999年に公開されました。WCAG 2.0は2008年に公開され、より幅広い障害者にウェブコンテンツをアクセシブルにするための、より包括的なガイドラインを提供しました。
WCAG 2.1は2018年に公開され、以前のバージョンを基に構築され、WCAG 2.0のリリース以降に出現したアクセシビリティ問題に対応するための新しい成功基準を含んでいます。WCAG 2.1はまた、モバイルアクセシビリティ、低視力アクセシビリティ、および認知や学習障害についての追加ガイダンスも提供しています。
WCAG 2.2は、これらのガイドラインの最新の繰り返しで、2023年に公開され、WCAG 2.1に対して9つの新しい成功基準を提供します。それは、認知や学習障害のあるユーザー、低視力のユーザー、およびモバイルデバイスでの障害を持つユーザーのニーズに対する改善されたガイダンスを提供します。それはWCAG 2.1と後方互換性があります。