カスタムメソッド論法のサポート

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

Not for use with personal data

Axe Auditorにおけるカスタム手動テスト手法の設定

目的

axe Auditorを使用するお客様は、手動テスト手法（DequeWay）を調整する必要があることがあります。この必要性は次のような場合に生じることがあります。

追加または省略されたチェックを必要とする特定の社内ポリシー。
テストを行う際に特定のツールを使用するための社内ガイドライン。
さまざまな問題の属性（影響、説明、推奨事項）を変更するポリシー決定。

この文書では、axe Auditorにおける手動テスト手法に対して行えるカスタマイズを説明し、それらの変更がDequeに戻り、ホストされているインスタンスにパッケージングされてデプロイされる方法を説明します。

どのように動作するか：役割とワークフロー

貴社のaxe AuditorインスタンスはDequeによってホストおよび管理されています。つまり、Dequeが手法のインストール、バージョン順次化、パッケージング、デプロイを管理していることを意味します。貴社のチームは、手法の設定ファイルを編集することのみを担当します。バージョン番号の更新、パッケージのビルド、インストールやデータベースコマンドの実行を行う必要はありません。Dequeがそれらすべてを貴社に代わって処理します。

エンドツーエンドのプロセスは次の通りです：

ステップ	担当者	アクション
1	Deque	現在の手法（DequeWay）バンドルを貴社チームに提供します。
2	顧客	作業場所にバンドルを抽出し、`package`という名前のフォルダーを生成します。
3	顧客	編集を行う前に、元の`package`フォルダーをバックアップします。
4	顧客	以下のセクションに従って、合意された手法の変更を行います。
5	顧客	編集されたJSONファイルを検証します（参照始める前に）。
6	顧客	提供されたのと同じ構造で、`package`フォルダー全体をDequeに送り返します。
7	Deque	手法を正しいaxe-coreバージョンにバージョン管理、パッケージング、マッピングし、検証のためにテストインスタンスにデプロイします。
8	顧客	テストインスタンスでの変更を確認し、承認を確認します。
9	Deque	検証済みの手法を貴社の本番インスタンスに昇格させます。

範囲に関する注意： このドキュメントは完全性のためにすべての利用可能なカスタマイズタイプを一覧化しています。貴社のチームが行う具体的な変更は、合意された変更範囲に沿うべきです。

始める前に

1. 元のバックアップを取ります。 何かを編集する前に、展開されたpackageフォルダーのコピーを作成してください。バンドルが破損した場合、これは元に戻す唯一の方法です。

cp -r package package_backup_original

2. 各セクションに記載されたファイルのみを編集します。 The files are interdependent. Editing a file not listed for a given change — or missing one that は listed — can produce a bundle that fails only after it round-trips back to Deque.

3. 触れたファイルをすべて検証します。 各ファイルはJSONであり、編集後も有効なJSONでなければなりません（トレーリングカンマや括弧の不均衡なし）。送信前に検証を行います：

# Validate a single file
python3 -m json.tool package/dist/bundle/descriptions.json > /dev/null && echo "VALID" || echo "INVALID"

# Or validate every JSON file in the bundle at once
find package/dist -name "*.json" -print0 | while IFS= read -r -d '' f; do
  python3 -m json.tool "$f" > /dev/null 2>&1 && echo "VALID:   $f" || echo "INVALID: $f"
done

4. 言語の前提。 これらの指示は英語を前提としています（en）。追加の言語での方法論が必要な場合は、Dequeにお知らせください。Dequeは構成時に言語サポートを有効にします。その場合、.en.json ファイルで行ったすべての編集は、追加の各言語に対応するローカルファイル（例：.nl.jsonに相当するもの）にも行う必要があります。

許可されている更新

特定のチェックポイントのためのテスト方法論を更新する

axe Auditorで特定のチェックポイントのテスト指示を変更したい場合に便利です。

更新されたファイル： package/dist/bundle/locales/checkpoints.en.json

手順：

JSONファイル内で特定のDequeチェックポイントを見つけます（例：1.1.1.a）。
その特定のチェックポイントの下でtesting-methodology属性を検索します。
testing-methodologyに記載されている任意のアセットタイプに適切な更新を行います。
ファイルを現在の場所に保存します。

注意： axe Auditorで表示されるチェックポイント名も同じ指示を使用して変更できます。testing-methodologyセクションを更新する代わりに、同じファイル内の関連するチェックポイントの下でname属性を更新します。

ルールの影響を更新する

axe Auditor内の各問題に対して影響度（ブロッカー、クリティカル、重大、中程度、小）が変更できます。ただし、ルールのデフォルト影響を変更する必要がある場合、次の指示に従ってください。

axe Auditor内の影響はルールレベルで保存され、WCAGの成功基準やチェックポイントレベルでは保存されません。単一のルールは複数のDequeチェックポイントに影響を与える可能性があります（例：ルールID alt-text-dynamic-image-inconsistent）。ルールの影響を変更すると、このルール違反によってトリガーされる問題のデフォルト影響が、ルールに接続されたすべて WCAG成功基準に対して変わります。

更新されたファイル： package/dist/bundle/descriptions.json

手順：

JSONファイル内で特定のDequeルールを見つけます（例：alt-text-dynamic-image-inconsistent）。
その特定のルールの下でimpact属性を検索します。
数値値で影響を更新します（以下の表を参照してください）。
ファイルを現在の場所に保存します。

影響値のマッピング

影響値	axe Auditorでの影響
5	ブロッカー
4	クリティカル
3	重大
2	中程度
1	小

新しいアクセシビリティ基準を追加する（例：組織固有の基準）

既存の基準（例えば、WCAG 2.1 AA または ACAA）に加えて、組織固有のテスト基準をチームに提供したい場合、次の手順を使用してください。

⚠️ Deque内部 — 公開前に解決： このセクションのファイルリストは、ドキュメントの残りと一貫性のない3つのチェックポイント関連のパスを参照しています（dist/bundle/…を使用）：package/dist/checkpoints.json、package/dist/issue-descriptions.json、package/dist/bundle/checkpoints.json。dist/checkpoints.jsonとdist/issue-descriptions.jsonが本当に異なるコンパイルファイルであるのか、それともこれらがパスエラーなのかを確認し、リストを適宜更新し、このメモを削除します。

更新されたファイル：

package/dist/bundle/standards.json
package/dist/bundle/descriptions.json
package/dist/bundle/testingMethodologies.json
package/dist/bundle/locales/standards.en.json
package/dist/checkpoints.json
package/dist/issue-descriptions.json
package/dist/bundle/checkpoints.json

手順：

標準のために新しい配列オブジェクトをstandards.jsonに作成します。最も簡単な方法は、wcag21aaのオブジェクト全体をコピーしてファイルの末尾に追加することです。
コピーした新しいオブジェクトのidを、その標準を表すユニークなものに変更します。
この新しい標準の一部であるすべてのテスト基準を表すように、新しいオブジェクトのrubric配列を更新します。
descriptions.jsonで、新しい標準に関連するすべてのルールに対して、新しい標準のid（standards.jsonから）をstandards配列に追加します。
testingMethodologies.jsonで、この標準が適用される各デジタル資産タイプのstandards配列の下に新しい標準のidを追加します。
standards.en.jsonで、新しい標準のidと名前を持つ新しいオブジェクトを追加します。nameフィールドは、axe Auditorユーザーインターフェースでユーザーが見るものです。
dist/checkpoints.jsonで、適用されるチェックポイントのために各問題記述のstandards配列を更新します。
issue-descriptions.jsonで、すべての適用可能なルールオブジェクトのstandards配列を更新します。
dist/bundle/checkpoints.jsonで、各適用可能なチェックポイントのstandards配列を正しい基準で更新します。

特定のルールの短くて長い問題記述を更新する

これらの指示を使用して、ルールごとの問題記述選択テキスト（短い）と問題タイプの長い記述を更新します。単一のルールが複数のWCAG成功基準に影響を与える可能性があります — このテキストを変更することは、それに関連する全て基準に影響を与えます。

更新されたファイル： package/dist/bundle/locales/descriptions.en.json

手順：

descriptions.en.jsonで、特定のルール（例：alt-text-dynamic-image-inconsistent）を検索します。
shortText（短い問題記述）とissueDescText（長い問題記述）のテキストを適切に更新します。
ファイルを現在の場所に保存します。

修正推奨を更新する

修正ライブラリと関連する説明をポリシーに合わせて変更したい場合は、次の指示を使用します。

更新されたファイル： package/dist/bundle/locales/recommendations.en.json

手順：

recommendations.en.jsonで、修正ライブラリを変更したい特定のルールとチェックポイントの組み合わせ（例：alt-text-dynamic-image-inconsistent）を検索します。
recommendationType（推奨技術）、rule、howtofix、およびbackground（修正のための推奨セクション）のテキストを適切に更新します。
ファイルを現在の場所に保存します。

デジタル資産タイプを削除する

特定の資産タイプが組織に適用されない場合に使用します（例：PDFまたはAndroidテストが対象外である場合）。

更新するファイル：

dist/bundle/testingMethodologies.json — 主なテスト方法データ
dist/bundle/locales/testingMethodologies.en.json — 英語翻訳

ステップ 1: テストメソッドファイルから削除

ファイル: dist/bundle/testingMethodologies.json

削除したい手法のオブジェクト全体を見つけて削除します。

// BEFORE — remove this entire object (example: "native-mobile-android"):
{
  "id": "native-mobile-android",
  "techniques": ["general"],
  "standards": [
    "wcag2a", "wcag21a", "wcag22a",
    "wcag2aa", "wcag21aa", "wcag22aa",
    "acaa", "en301549-wad",
    "508-2017-wcag2", "508-2017-wcag21"
  ]
}
// AFTER — object completely removed

ステップ 2: 英語ロケールファイルから削除

ファイル: dist/bundle/locales/testingMethodologies.en.json

このファイルから同じ方法オブジェクトを削除します。

新しいデジタル資産タイプを追加する

新しいデジタル資産タイプを追加するために使用します — 例えば、web-appやmacosメソッド。以下の例ではweb-appを使用しています。必要に応じて自分の資産タイプIDを代入してください。

更新するファイル：

dist/bundle/testingMethodologies.json — 主なテスト方法データ
dist/bundle/locales/testingMethodologies.en.json — 英語翻訳
dist/bundle/locales/checkpoints.en.json — テスト手法のセクションを含む英語のチェックポイントコンテンツ
dist/bundle/checkpoints.json — 主なチェックポイントデータ
dist/bundle/descriptions.json — テスト手法に関する問題記述
dist/bundle/schemata.json — テスト手法参照付きのスキーマ定義

ステップ 1: テストメソッドファイルに追加

ファイル: dist/bundle/testingMethodologies.json

新しい方法オブジェクトを配列に追加します。

{
  "id": "web-app",
  "techniques": ["general", "html", "aria", "css"],
  "standards": [
    "wcag2a", "wcag21a", "wcag22a",
    "wcag2aa", "wcag21aa", "wcag22aa",
    "acaa", "en301549-wad",
    "508-2017-wcag2", "508-2017-wcag21"
  ]
}

ステップ 2: 英語ロケールファイルに追加

ファイル: dist/bundle/locales/testingMethodologies.en.json

同じメソドロジーオブジェクトをこのファイルに追加します。

ステップ 3: チェックポイントファイルへの参照を追加

ファイル: dist/bundle/checkpoints.json

新しいメソドロジーをサポートするべき各チェックポイントについて、そのチェックポイントのtestingMethodologies 配列に追加します。

{
  "id": "1.4.3.a",
  "testingMethodologies": [
    "desktop", "mobile", "kiosk",
    "native-mobile-ios", "native-mobile-android",
    "pdf",
    "web-app",          // ← Add this line
    "ms-excel", "ms-powerpoint", "ms-word", "windows-desktop"
  ]
}

ステップ 4: チェックポイント言語ファイルにテスト方法論の内容を追加

ファイル: dist/bundle/locales/checkpoints.en.json

新しいメソドロジーをサポートするべき各チェックポイントについて、テスト方法論の内容を追加します。

{
  "1.4.3.a": {
    "name": "Color Contrast (Minimum)",
    "testing-methodology": {
      "desktop": "<ol>...</ol>",
      "mobile": "<ol>...</ol>",
      "native-mobile-android": "<ol>...</ol>",
      "web-app": "<ol>\n<li>Open the web application in a modern browser</li>\n<li>Use browser developer tools to inspect text elements</li>\n<li>Check color contrast ratios using accessibility tools</li>\n<li>Verify contrast meets WCAG requirements</li>\n</ol>",  // ← Add this new entry
      "pdf": "<ol>...</ol>"
    }
  }
}

ステップ 5: 説明ファイルへの参照を追加

ファイル: dist/bundle/descriptions.json

新しいメソドロジーをサポートするべき問題の説明について、それをtestingMethodologies 配列に追加します。

{
  "id": "some-issue-id",
  "data": [
    {
      "type": "issue",
      "testingMethodologies": [
        "desktop", "mobile",
        "native-mobile-android", "pdf",
        "web-app"        // ← Add this line
      ]
    }
  ]
}

ステップ 6: スキーマファイルへの参照を追加

ファイル: dist/bundle/schemata.json

新しいテストメソドロジーをスキーマ定義に追加します。

{
  "testingMethodologies": {
    "desktop": null,
    "kiosk": null,
    "mobile": null,
    "native-mobile-ios": null,
    "native-mobile-android": null,
    "pdf": null,
    "web-app": null,   // ← Add this line
    "ms-excel": null,
    "ms-powerpoint": null,
    "ms-word": null,
    "windows-desktop": null
  }
}

新しいチェックポイントを追加

WCAG 以外のチェックポイントを追加

重要: WCAG 外のチェックポイントは、descriptions.json と recommendations.json を通じた事前定義の説明や推奨をしないでくださいされません。これらのチェックポイントで問題を記録する際は、ツールの独自の説明を作成する機能を使って説明と推奨を手動で入力します。

更新するファイル — 2つのみ:

package/dist/bundle/checkpoints.json — チェックポイントを定義する
package/dist/bundle/locales/checkpoints.en.json — ローカライズされたテストメソドロジーを提供

ステップ 1: チェックポイントをcheckpoints.jsonに追加

{
  "id": "custom.1.1",
  "requiredSenses": {
    "sight": true,
    "hearing": false
  },
  "successCriteria": "",
  "automatedRules": [],
  "testingMethodologies": ["desktop", "mobile"],
  "grouping": "custom.1",
  "categories": [],
  "standards": ["custom"]
}

キー項目:

id — カスタム形式を使用したユニークな識別子 (例: custom.1.1、brand.2.3、TT.01.A、s.1.1)。
successCriteria — 非 WCAG チェックポイントのための空の文字列 "" (またはカスタム形式のような"tt-01.A")。
standards — カスタム標準識別子、例: ["custom"]、["TT508"]、["smoke"]、["brand"] (しないでください ["wcag2a"])。
testingMethodologies — このチェックポイントが適用されるプラットフォーム: desktop、mobile、kiosk、native-mobile-ios、native-mobile-android、pdf、windows-desktop、ms-excel、ms-powerpoint、ms-word。
requiredSenses — このチェックポイントをテストするために必要な感覚 (sight、hearing: true/false)。
automatedRules — 自動化されたルール ID のオプション配列 (通常、カスタムチェックポイントのために空の[])。
grouping — 組織のための論理的なグループ化 (例: "custom.1"、"1"、"s.1")。
categories — 関連するアクセシビリティカテゴリー (非 WCAG の場合は空にできる[])。
terms — id と ordinal プロパティを持つ用語集項目のオプション参照配列。

ステップ 2: ローカライズされたコンテンツをcheckpoints.en.jsonに追加

ハイフンで区切るID形式を使用してください: ドットをハイフンに変換します (例: custom-1-1、custom.1.1 ではなく)。

"custom-1-1": {
  "examples": "<ul>\n  <li>Example 1: Describe a scenario where this applies</li>\n  <li>Example 2: Describe another scenario</li>\n</ul>",
  "related-techniques": {
    "general": "<ul>\n  <li>Technique reference 1</li>\n  <li>Technique reference 2</li>\n</ul>",
    "html": "<ul>\n  <li>HTML-specific technique</li>\n</ul>"
  },
  "testing-methodology": {
    "desktop": "<ol>\n  <li>Step 1 for desktop testing</li>\n  <li>Step 2 for desktop testing</li>\n</ol>",
    "mobile": "<ol>\n  <li>Step 1 for mobile testing</li>\n  <li>Step 2 for mobile testing</li>\n</ol>"
  },
  "name": "Your Custom Checkpoint Name",
  "overview": {
    "general": "General description of what this checkpoint tests and why it matters for accessibility.",
    "html": "HTML-specific description if applicable; otherwise can match general."
  }
}

新しい行には\nを使用し、リストには適切なHTMLタグを使用してください。

WCAG チェックポイントを追加

更新するファイル — 6つのファイル 完全な WCAG チェックポイントの実装について:

package/dist/bundle/checkpoints.json — WCAG 固有のフィールドを使用してチェックポイントを定義する。
package/dist/bundle/locales/checkpoints.en.json — ローカライズされたテスト方法論、例、関連する技術 (ID形式を使って: 1-4-3-a、1.4.3.a ではなく)。
package/dist/bundle/descriptions.json — インパクトレベルとチェックポイント参照を含む問題の説明。
package/dist/bundle/locales/descriptions.en.json — ローカライズされた問題の説明。
package/dist/bundle/recommendations.json — 問題の説明にリンクした修正推奨。
package/dist/bundle/locales/recommendations.en.json — ローカライズされた推奨内容 (タイトル、説明、手順、リソース)。

オプション — 手動入力: 事前に定義された説明や推奨事項をJSONファイルに追加するのを省略したい場合は、ツールで問題を報告する際にそれらを処理できます。WCAGのチェックポイントを選択し、事前に定義されたものの代わりに独自の説明を作成するを選び、見つけた問題に合わせた説明と（必要であれば）推奨事項を手動で入力してください。

ステップ1：チェックポイントを定義する

ファイル: package/dist/bundle/checkpoints.json

{
  "id": "1.4.3.a",
  "requiredSenses": {
    "sight": true,
    "hearing": false
  },
  "successCriteria": "1.4.3",
  "automatedRules": ["color-contrast"],
  "testingMethodologies": [
    "desktop", "mobile", "kiosk",
    "native-mobile-ios", "native-mobile-android",
    "pdf", "ms-excel", "ms-powerpoint", "ms-word", "windows-desktop"
  ],
  "grouping": "1.4",
  "categories": ["cat.distinguishable"],
  "standards": ["wcag2aa"]
}

キー項目:

id — WCAGの番号付けパターン（例："1.4.3.a"、"2.1.1.b"）。
successCriteria — WCAG成功基準の番号（例："1.4.3"）。
standards — "wcag2a" (レベルA)、"wcag2aa" (レベルAA)、または"wcag2aaa" (レベルAAA)。
automatedRules — 自動化ルールIDの配列。
grouping — WCAGガイドラインの番号（例："1.4"、"2.1"）。

ステップ2：テスト方法論を追加する

ファイル: package/dist/bundle/locales/checkpoints.en.json — ハイフン付きフォーマットを使用する（1-4-3-a）。

"1-4-3-a": {
  "name": "Color Contrast (Minimum)",
  "overview": {
    "general": "Text and images of text have a contrast ratio of at least 4.5:1, except for large text which has a contrast ratio of at least 3:1.",
    "html": "Text and images of text have a contrast ratio of at least 4.5:1, except for large text which has a contrast ratio of at least 3:1."
  },
  "examples": "<ul>\n  <li>Gray text on white background with insufficient contrast</li>\n  <li>Blue text on blue background that doesn't meet requirements</li>\n</ul>",
  "testing-methodology": {
    "desktop": "<ol>\n  <li>Identify all text content on the page</li>\n  <li>Use a color contrast analyzer tool</li>\n  <li>Ensure normal text has at least 4.5:1 contrast ratio</li>\n  <li>Ensure large text has at least 3:1 contrast ratio</li>\n</ol>",
    "mobile": "<ol>\n  <li>Test on a mobile device under various lighting conditions</li>\n  <li>Use mobile accessibility testing tools</li>\n  <li>Verify contrast ratios meet WCAG requirements</li>\n</ol>",
    "assistive-technology": "<p><strong>Screen reader testing is optional for this checkpoint.</strong></p>\n<p><strong>Using NVDA:</strong></p>\n<ol>\n  <li>Navigate through text content</li>\n  <li>Verify text readability</li>\n</ol>"
  },
  "related-techniques": {
    "general": "<ul>\n  <li><a href=\"https://www.w3.org/WAI/WCAG22/Techniques/general/G18\">G18: Ensuring contrast ratio of at least 4.5:1</a></li>\n</ul>",
    "html": "<ul>\n  <li><a href=\"https://www.w3.org/WAI/WCAG22/Techniques/css/C21\">C21: Specifying line spacing in CSS</a></li>\n</ul>"
  }
}

ステップ3：問題説明を追加する

ファイル: package/dist/bundle/descriptions.json

{
  "id": "insufficient-color-contrast",
  "data": [
    {
      "type": "issue",
      "impact": 4,
      "checkpoint": "1.4.3.a",
      "standards": ["wcag2aa"],
      "references": [
        {
          "standards": ["wcag2aa"],
          "checkpoint": "1.4.3.a"
        }
      ],
      "testingMethodologies": ["desktop", "mobile"]
    }
  ]
}

ステップ4：ローカライズされた問題説明を追加する

ファイル: package/dist/bundle/locales/descriptions.en.json

新しい説明のオブジェクトを追加する:

"insufficient-color-contrast": {
  "shortText": "Insufficient color contrast",
  "issueDescText": "Text does not have sufficient contrast against its background to meet WCAG 2.1 AA requirements."
}

ステップ5：推奨事項を追加する

ファイル: package/dist/bundle/recommendations.json

ハイフン付きフォーマット（1-4-3-a）を使用して、推奨事項IDに追加します。

{
  "id": "insufficient-color-contrast-fix-1-4-3-a",
  "data": [
    {
      "type": "recommendation",
      "description": "insufficient-color-contrast"
    }
  ]
}

ステップ6：推奨事項の内容を追加する

ファイル: package/dist/bundle/locales/recommendations.en.json

"insufficient-color-contrast-fix-1-4-3-a": {
  "title": "Improve Color Contrast",
  "description": "Increase the contrast ratio between text and background colors to meet WCAG 2.1 AA requirements.",
  "steps": [
    "Use a color contrast analyzer to identify insufficient contrast",
    "Adjust text color, background color, or both to achieve a minimum 4.5:1 ratio",
    "For large text (18pt+ or 14pt+ bold), ensure a minimum 3:1 ratio",
    "Test the changes across different devices and lighting conditions"
  ],
  "resources": [
    "WebAIM Color Contrast Checker",
    "W3C Color Contrast Analyzer",
    "Chrome DevTools Accessibility Panel"
  ]
}

特定のチェックポイントを削除する

チームに対してテストや報告を行ってほしくない特定のチェックポイントがある場合は、これらの指示を使用してください。

更新されたファイル:

package/dist/bundle/checkpoints.json
package/dist/bundle/descriptions.json
package/dist/bundle/recommendations.json
package/dist/bundle/locales/checkpoints.en.json
package/dist/bundle/locales/recommendations.en.json

ステップ:

checkpoints.jsonで特定のチェックポイント（例：1.2.1.b）を検索します。このチェックポイントに関連するすべてのオブジェクトを削除し、有効なJSONを維持しながらファイルを保存します。
descriptions.jsonで特定のチェックポイント（例：1.2.1.b）を検索します。ルールのもとでチェックポイントを使用しているオブジェクトだけを削除し、有効なJSONを維持します。単一のルールが複数のチェックポイントに適用されることがあります — 削除するチェックポイントのオブジェクトだけを削除し、完全なルールは削除しないでください。 ファイルを保存します。
recommendations.jsonで特定のチェックポイント（例：1.2.1.b）を検索します。このチェックポイントに関連するすべてのオブジェクト（複数の場合もあります）を削除し、有効なJSONを維持しながらファイルを保存します。
checkpoints.en.jsonでハイフン付きフォーマットを使用して特定のチェックポイント（例：1-2-1-b）を検索します。オブジェクト全体を削除し、有効なJSONを維持しながらファイルを保存します。
recommendations.en.jsonでハイフン付きフォーマットを使用して特定のチェックポイント（例：1-2-1-b）を検索します。このチェックポイントに関連するすべてのオブジェクト（複数の場合もあります）を削除し、有効なJSONを維持しながらファイルを保存します。

変更をDequeに送り返す

編集が完了し、検証されたら:

編集されたすべてのファイルがまだJSON検証に合格することを確認してください（始める前にを参照）。
変更が合意された範囲に合致していることを確認してください。
元の構造のままpackageフォルダ全体をDequeに送り返してください（個々のファイルだけを送らないでください）。

Dequeはバージョンを割り当て、バンドルをパッケージし、適切なaxe-coreバージョンにマッピングし、テストインスタンスで検証するためにデプロイします。チームがテストインスタンスで変更を確認し承認した後、Dequeはメソドロジーをあなたの本番インスタンスに昇格させます。

サポート

このプロセス、合意された変更範囲、または追加の言語サポートを求めるための質問については、Dequeの担当者に連絡してください。

カスタムメソッド論法のサポート

Axe Auditorにおけるカスタム手動テスト手法の設定

目的

どのように動作するか：役割とワークフロー

始める前に

許可されている更新

特定のチェックポイントのためのテスト方法論を更新する

ルールの影響を更新する

新しいアクセシビリティ基準を追加する（例：組織固有の基準）

特定のルールの短くて長い問題記述を更新する

修正推奨を更新する

デジタル資産タイプを削除する

新しいデジタル資産タイプを追加する

新しいチェックポイントを追加

WCAG 以外のチェックポイントを追加

WCAG チェックポイントを追加

特定のチェックポイントを削除する

変更をDequeに送り返す

サポート

Is this page helpful?

Help us improve this page

Still need help?