カスタム手法サポート

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内部 — 公開前に解決してください: このセクションのファイルリストは、文書の残りで使用されているdist/bundle/…とは一致しない3つのチェックポイント関連パスを参照しています：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配列に追加します（standards.jsonから）。
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チェックポイントの追加

完全なWCAGチェックポイント実装のための更新が必要なファイル — 6つのファイル:

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?