Axe Developer Hub 用語集

a11y

数字に基づく略語（またはナムレニム）は、単語「アクセシビリティ」のものであり、「11」（11）は、アクセシビリティで始まりの「a」と終わりの「y」の間にある文字数を表します。アライとして発音されます。

APIキー

認証のために、Axeアカウント設定でAPIキーを生成します。同じAPIキーを複数のプロジェクトで使用できますが、Axe Developer Hub APIキーはWebプロジェクト専用、Axe DevTools Mobile APIキーはモバイルプロジェクト専用でなければなりません。

Axe Developer Hub

Axe Developer Hubは新しいテストプロジェクトを作成し、アクセシビリティテストの実行結果を表示することを可能にします。ウェブサイトやモバイルアプリでアクセシビリティを管理するために必要なだけ多くのプロジェクトを作成できます。

ベストプラクティス

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

ビルドID

ビルドIDはユーザーによって提供されない場合、自動的にUUIDとして生成され、スキャンを単一のテストセッションとしてリンクするために使用されます。複数のマシンまたは環境でテストスイートを実行する際に、ビルドIDを提供すると、これらすべての実行を1つのセッションとしてリンクし、Developer Hubに表示されます。

重複

重複は複数のページ状態で同じドキュメントオブジェクトモデル（DOM）ノードに見られる同じアクセシビリティ問題です。重複のある問題を修正すると、それらの重複はすべて同じ問題なので消えます。

e2eテスト

エンドツーエンド、またはe2eテストは、実際の実装をテストすることでウェブアプリケーション全体の機能をテストすることを指します。Axe Developer Hubを使用すると、アクセシビリティの問題についてe2eシナリオをテストできます。

実験的ルール

実験的ルールは新しい技術やアクセシビリティ問題に対する理解や認識を改善するために、まだ開発とテストが行われています。これらのルールはまだ開発中であり、誤検知の可能性があるため、本番環境では依存すべきではありません。最終的には、このルールセットのルールがアクセシビリティ標準の一部になる可能性があります。実験的なルールはデフォルトで無効になっています。このルールセットを構成するルールについては、最新バージョンのaxe-coreExperimental Rulesをご覧ください。

Git

多くのDeveloper Hubプロジェクトには、Gitリポジトリを使用するテストスイートがあります。Gitを使用すると、異なるブランチや特定のコミットでのコードにアクセシビリティの欠陥を関連付けることができ、それらの解決を支援します。

Gitless

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

影響

すべてのアクセシビリティ違反には影響度レベルが割り当てられ、最も影響が少ないものから最も影響のあるものへと、軽微、中程度、重大、致命的の4つのレベルに分類されます。この指標は修正の優先順位付けに役立ち、Dequeのアクセシビリティの専門家はデフォルトで各違反タイプにインパクトレベルを割り当てます。

重大または致命的のインパクトレベルを持つ欠陥は、障害のあるユーザーに重大なまたは乗り越えられない障壁をもたらし、最も高い法的責任があります。軽微と中程度の問題はそれほど深刻ではありませんが、コンプライアンスと障害者のニーズに対応するためには依然として重要です。

アクセシビリティ問題の影響を分類するために使用される4つのレベルは次のとおりです：

1. 軽微: 障害のあるユーザーに対して中くらいの問題よりも少ない影響を与える問題ですが、完全なコンプライアンスを達成するためには解決が必要です。

2. 中程度: 障害のあるユーザーに対していくつかの障壁が存在しますが、基本的なコンテンツやフローにアクセスすることを妨げるものではありません。これらの問題は、法的措置のリスクを生じさせる可能性があるため、完全なコンプライアンスを達成する前に是正する必要があります。

3. 重大: 障害のあるユーザーは、サイトとの対話において重大な障壁に直面し、関連するコンテンツにアクセスする際にフラストレーションを感じ、困難を伴います。法的措置を回避するために修正が最優先事項となります。

4. 致命的: 障害のあるユーザーがウェブページ上の機能にアクセスまたは対話することが完全に阻止され、コンテンツはアクセス不可能となり、あなたの組織は訴訟に非常に脆弱になります。重要な問題の修正は最優先で行うべきです。

変更されたテストスイート

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

組織管理者

組織管理者（組織の管理者）は、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キーの両方が必要です。プロジェクトのアクセシビリティステータスをより正確に追跡するために、1つのプロジェクトIDと1つのテストスイート/リポジトリをマッピングするのがベストプラクティスです。

プロジェクトメンバー

プロジェクトメンバーは、Axe Developer Hubプロジェクトに追加されたユーザーです。プロジェクトメンバーは、プロジェクト内でテストを実行し、結果を表示することができます。メンバーはプロジェクトにアクセスするためにアクティブなライセンスを持っている必要があります。

SHA

Gitでコミットを作成すると、それに固有のIDが作成されます。この固有のIDはSHAと呼ばれ、Secure Hash Algorithm（暗号化ハッシュ関数のグループ）の名前に由来します。

タグ

タグは、WCAGのような特定のアクセシビリティガイドラインに属するルールをグループ化します。ルールとそれらのルールが属するタグについての詳細はaxe-coreルールの説明をご覧ください。

WCAG

WCAG、またはウェブコンテンツアクセシビリティガイドラインは、World Wide Web Consortium (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と後方互換性があります。