Unterstützung für benutzerdefinierte Methodik

Konfiguration der benutzerdefinierten manuellen Testmethodik in axe Auditor

Zweck

Kunden, die axe Auditor verwenden, müssen manchmal die manuelle Testmethodik (die DequeWay) anpassen. Dies kann erforderlich sein aufgrund von:

• Spezifische interne Richtlinien, die zusätzliche oder weniger Prüfungen erfordern.
• Interne Richtlinien zur Verwendung spezifischer Werkzeuge bei Tests.
• Richtlinienentscheidungen, die verschiedene Problemattribute ändern (Auswirkungen, Beschreibungen, Empfehlungen).

Dieses Dokument beschreibt die Anpassungen, die an der manuellen Testmethodik in axe Auditor vorgenommen werden können, und erklärt, wie diese Änderungen an Deque zurückfließen, um sie für Ihre gehostete Instanz zu verpacken und bereitzustellen.

Wie das funktioniert: Rollen und Arbeitsablauf

Die axe Auditor-Instanz Ihrer Organisation wird von Deque gehostet und verwaltet. Das bedeutet, dass Deque die Installation, die Versionsabfolge, das Packaging und die Bereitstellung der Methodik verwaltet. Ihr Team ist lediglich für die Bearbeitung der Methodikkonfigurationsdateien verantwortlich. Sie müssen keine Versionsnummern aktualisieren, Pakete erstellen oder Installations- oder Datenbankbefehle ausführen. Deque übernimmt all das für Sie.

Der gesamte Prozess ist folgendermaßen:

Hinweis zum Umfang: Dieses Dokument listet alle verfügbaren Anpassungstypen auf, um Vollständigkeit zu gewährleisten. Die spezifischen Änderungen, die Ihr Team vornehmen wird, sollten mit dem vereinbarten Änderungsumfang übereinstimmen.

Bevor Sie beginnen

1. Sichern Sie das Original. Bevor Sie etwas bearbeiten, machen Sie eine Kopie des entpackten package-Ordners. Wenn eine Bearbeitung das Paket beschädigt, ist dies der einzige saubere Weg, um zurückzukehren.

cp -r package package_backup_original

2. Bearbeiten Sie nur die in jedem Abschnitt aufgeführten Dateien. Die Dateien hängen voneinander ab. Das Bearbeiten einer Datei, die für eine bestimmte Änderung nicht aufgeführt ist — oder das Übersehen einer aufgeführten Datei ist — kann ein Paket erzeugen, das erst nach der Rückführung zu Deque fehlschlägt.

3. Validieren Sie jede Datei, die Sie bearbeiten. Jede Datei ist JSON und muss nach der Bearbeitung ein gültiges JSON bleiben (keine abschließenden Kommata, ausgewogene Klammern/Schlüssel). Validieren Sie vor dem Senden:

# 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. Sprachannahme. Diese Anweisungen setzen Englisch voraus (en). Wenn Ihre Organisation zusätzlich Methodiken in anderen Sprachen benötigt, informieren Sie Deque — Deque ermöglicht Sprachunterstützung während der Konfiguration. In diesem Fall muss jede Änderung, die Sie in einer .en.json-Datei vornehmen, auch in der entsprechenden Lokalisierungsdatei (z. B. das .nl.json-Äquivalent) für jede zusätzliche Sprache vorgenommen werden.

Erlaubte Aktualisierungen

Aktualisieren der Testmethodik für einen bestimmten Checkpoint

Nützlich, wenn Sie die Testanweisungen für einen bestimmten Checkpoint in axe Auditor ändern möchten.

Aktualisierte Dateien: package/dist/bundle/locales/checkpoints.en.json

Schritte:

1. Lokalisieren Sie den spezifischen Deque-Checkpoint in der JSON-Datei (z. B. 1.1.1.a).
2. Suchen Sie nach dem testing-methodology-Attribut unter diesem spezifischen Checkpoint.
3. Nehmen Sie geeignete Updates für jeden unter testing-methodology aufgeführten Asset-Typ vor.
4. Speichern Sie die Datei an ihrem aktuellen Speicherort.

Hinweis: Der Checkpoint-Name, der in axe Auditor sichtbar ist, kann auch mit den gleichen Anweisungen geändert werden. Anstatt den testing-methodology-Abschnitt zu aktualisieren, aktualisieren Sie das name-Attribut unter dem relevanten Checkpoint in derselben Datei.

Auswirkungen einer Regel aktualisieren

Sie können das Auswirkungsniveau (Blocker, Kritisch, Schwerwiegend, Mäßig, Gering) für jedes Problem innerhalb von axe Auditor ändern. Wenn Sie jedoch die Standard-Auswirkung für eine Regel ändern müssen, folgen Sie diesen Anweisungen.

Auswirkungen in axe Auditor werden auf der Ebene Regel gespeichert, nicht auf WCAG-Erfolgskriterien- oder Checkpoint-Ebene. Eine einzelne Regel kann mehrere Deque-Checkpoints betreffen (z. B. Regel-ID alt-text-dynamic-image-inconsistent). Das Ändern der Auswirkung für die Regel ändert die Standardauswirkung für ein Problem, das durch die Verletzung dieser Regel ausgelöst wird, über alle WCAG-Erfolgskriterien hinweg, die mit der Regel verbunden sind.

Aktualisierte Dateien: package/dist/bundle/descriptions.json

Schritte:

1. Lokalisieren Sie die spezifische Deque-Regel in der JSON-Datei (z. B. alt-text-dynamic-image-inconsistent).
2. Suchen Sie nach dem impact-Attribut unter dieser spezifischen Regel.
3. Aktualisieren Sie die Auswirkung mit einem numerischen Wert (siehe Tabelle unten).
4. Speichern Sie die Datei an ihrem aktuellen Speicherort.

Zuordnungen von Auswirkungswerten

Hinzufügen eines neuen Zugänglichkeitsstandards (z. B. eines organisationsspezifischen Standards)

Wenn Sie organisationsspezifische Teststandards haben, die Sie Ihren Teams zusätzlich zu den bestehenden Standards (wie WCAG 2.1 AA oder ACAA) bereitstellen möchten, verwenden Sie die folgenden Schritte.

⚠️ Deque intern — vor der Veröffentlichung lösen: Die Dateiliste für diesen Abschnitt verweist auf drei Checkpoint-bezogene Pfade, die mit dem Rest des Dokuments nicht konsistent sind (das verwendet dist/bundle/…): package/dist/checkpoints.json, package/dist/issue-descriptions.json und package/dist/bundle/checkpoints.json. Bestätigen Sie, ob dist/checkpoints.json und dist/issue-descriptions.json tatsächlich unterschiedliche kompilierte Dateien sind, oder ob es sich um Pfadfehler handelt, und aktualisieren Sie die Liste entsprechend und entfernen Sie diese Notiz.

Aktualisierte Dateien:

• 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

Schritte:

1. Erstellen Sie ein neues Array-Objekt für den Standard in standards.json. Der einfachste Ansatz ist, das gesamte Objekt für wcag21aa zu kopieren und es am Ende der Datei hinzuzufügen.
2. Ändern Sie die id des neu kopierten Objekts zu etwas Einzigartigem, das den Standard kennzeichnet, den es repräsentiert.
3. Aktualisieren Sie das rubric-Array für das neue Objekt, um alle zugrunde liegenden Teststandards darzustellen, die Teil dieses neuen Standards sind.
4. In descriptions.json fügen Sie für alle Regeln, die mit Ihrem neuen Standard verknüpft sind, die ID des neuen Standards (aus standards.json) dem standards-Array hinzu.
5. In testingMethodologies.json fügen Sie die ID des neuen Standards unter dem standards-Array für jeden digitalen Assettyp hinzu, auf den dieser Standard anwendbar ist.
6. In standards.en.json fügen Sie ein neues Objekt mit der ID und dem Namen des neuen Standards hinzu. Das Feld name ist das, was Benutzer in der Axe Auditor-Benutzeroberfläche sehen.
7. In dist/checkpoints.json aktualisieren Sie das standards-Array unter jeder Problem-Beschreibung für die zutreffenden Prüfpunkte.
8. In issue-descriptions.json aktualisieren Sie das standards-Array für alle anwendbaren Regelobjekte.
9. In dist/bundle/checkpoints.json aktualisieren Sie das standards-Array jedes anwendbaren Prüfpunkts mit dem korrekten Standard.

Aktualisieren Sie die kurzen und langen Problembeschreibungen für spezifische Regeln

Verwenden Sie diese Anweisungen, um den Auswahltext der Problembeschreibung (kurz) und die lange Beschreibung des Problemtyps für jede Regel zu aktualisieren. Eine einzelne Regel kann mehrere WCAG-Erfolgskriterien betreffen — die Änderung dieses Textes wirkt sich auf alle Erfolgsrichtlinien aus, mit denen sie verbunden ist.

Aktualisierte Dateien: package/dist/bundle/locales/descriptions.en.json

Schritte:

1. In descriptions.en.json suchen Sie nach der spezifischen Regel (z.B., alt-text-dynamic-image-inconsistent).
2. Aktualisieren Sie den Text für shortText (Kurze Problembeschreibung) und issueDescText (Lange Problembeschreibung) nach Bedarf.
3. Speichern Sie die Datei an ihrem aktuellen Speicherort.

Aktualisieren Sie die Empfehlung zur Behebung

Wenn Sie die Bibliothek für Korrekturmaßnahmen und die zugehörigen Beschreibungen ändern möchten, um sie mit Ihrer Richtlinie in Einklang zu bringen, verwenden Sie die folgenden Anweisungen.

Aktualisierte Dateien: package/dist/bundle/locales/recommendations.en.json

Schritte:

1. In recommendations.en.json suchen Sie nach der spezifischen Regel (z.B., alt-text-dynamic-image-inconsistent) und der Prüfpunktekombination, für die Sie die Bibliothek ändern möchten.
2. Aktualisieren Sie den Text für recommendationType (Empfehlungstechnik), rule, howtofix und background (Abschnitte der Empfehlung zur Behebung) entsprechend.
3. Speichern Sie die Datei an ihrem aktuellen Speicherort.

Entfernen Sie digitale Assettypen

Verwenden Sie dies, wenn ein bestimmter Assettyp für Ihre Organisation nicht anwendbar ist (zum Beispiel, wenn PDF- oder Android-Tests außerhalb des Umfangs liegen).

Zu aktualisierende Dateien:

• dist/bundle/testingMethodologies.json — Hauptdaten der Testmethodologien
• dist/bundle/locales/testingMethodologies.en.json — Englische Übersetzungen

Schritt 1: Aus der Datei „Testmethodologien“ entfernen

Datei: dist/bundle/testingMethodologies.json

Suchen und entfernen Sie das gesamte Objekt für die Methode, die Sie löschen möchten.

// 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

Schritt 2: Aus der englischen Lokalisierungsdatei entfernen

Datei: dist/bundle/locales/testingMethodologies.en.json

Entfernen Sie das gleiche Methodologieobjekt aus dieser Datei.

Einen neuen digitalen Assettyp hinzufügen

Verwenden Sie dies, um einen neuen digitalen Assettyp hinzuzufügen — zum Beispiel eine web-app- oder macos-Methodologie. Das untenstehende Beispiel verwendet web-app; ersetzen Sie die entsprechende Asset-Type-ID nach Bedarf.

Zu aktualisierende Dateien:

• dist/bundle/testingMethodologies.json — Hauptdaten der Testmethodologien
• dist/bundle/locales/testingMethodologies.en.json — Englische Übersetzungen
• dist/bundle/locales/checkpoints.en.json — Englischer Prüfinhalt mit Testmethodologieabschnitten
• dist/bundle/checkpoints.json — Hauptdaten der Prüfpunkte
• dist/bundle/descriptions.json — Problembeschreibungen mit Testmethodologiebezügen
• dist/bundle/schemata.json — Schemadefinitionen mit Testmethodologiebezügen

Schritt 1: Zur Datei „Testmethodologien“ hinzufügen

Datei: dist/bundle/testingMethodologies.json

Fügen Sie das neue Methodologieobjekt zum Array hinzu.

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

Schritt 2: Zur englischen Lokalisierungsdatei hinzufügen

Datei: dist/bundle/locales/testingMethodologies.en.json

Fügen Sie dieses Datei dasselbe Methodologieobjekt hinzu.

Schritt 3: Verweise zur Checkpoint-Datei hinzufügen

Datei: dist/bundle/checkpoints.json

Für jeden Checkpoint, der die neue Methodologie unterstützen soll, fügen Sie ihn diesem Checkpoint-testingMethodologies-Array hinzu.

{
  "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"
  ]
}

Schritt 4: Inhalte zur Testmethodologie zur Checkpoint-Lokaldatei hinzufügen

Datei: dist/bundle/locales/checkpoints.en.json

Für jeden Checkpoint, der die neue Methodologie unterstützen soll, fügen Sie die Inhalte zur Testmethodologie hinzu.

{
  "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>"
    }
  }
}

Schritt 5: Verweise zu der Beschreibungsdatei hinzufügen

Datei: dist/bundle/descriptions.json

Für Problembeschreibungen, die die neue Methodologie unterstützen sollen, fügen Sie sie deren testingMethodologies-Array hinzu.

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

Schritt 6: Verweise zur Schema-Datei hinzufügen

Datei: dist/bundle/schemata.json

Fügen Sie die neue Testmethodologie zu den Schemadefinitionen hinzu.

{
  "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
  }
}

Einen neuen Checkpoint hinzufügen

Hinzufügen eines Nicht-WCAG-Checkpoints

Wichtig: Nicht-WCAG-Checkpoints unterstützen nicht keine vorgefertigten Beschreibungen oder Empfehlungen über descriptions.json und recommendations.json. Bei der Protokollierung von Problemen mit diesen Checkpoints geben Sie Beschreibungen und Empfehlungen manuell über die Erstellen Sie Ihre eigene Beschreibung-Funktion im Tool ein.

Zu aktualisierende Dateien — nur 2:

• package/dist/bundle/checkpoints.json — den Checkpoint definieren
• package/dist/bundle/locales/checkpoints.en.json — lokalisierte Testmethodologie bereitstellen

Schritt 1: Fügen Sie den Checkpoint zu checkpoints.json hinzu

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

Schlüsselfelder:

• id — eindeutiger Bezeichner mit Ihrem benutzerdefinierten Format (z.B., custom.1.1, brand.2.3, TT.01.A, s.1.1).
• successCriteria — leerer String "" für Nicht-WCAG-Checkpoints (oder ein benutzerdefiniertes Format wie "tt-01.A").
• standards — Ihr benutzerdefinierter Standardbezeichner, z.B., ["custom"], ["TT508"], ["smoke"], ["brand"] (nicht ["wcag2a"]).
• testingMethodologies — Plattformen, auf denen dieser Checkpoint gilt: desktop, mobile, kiosk, native-mobile-ios, native-mobile-android, pdf, windows-desktop, ms-excel, ms-powerpoint, ms-word.
• requiredSenses — welche Sinne erforderlich sind, um diesen Checkpoint zu testen (sight, hearing: true/false).
• automatedRules — optionale Liste von automatisierten Regel-IDs (normalerweise leer [] für benutzerdefinierte Checkpoints).
• grouping — logische Gruppierung zur Organisation (z.B., "custom.1", "1", "s.1").
• categories — relevante Kategorien der Barrierefreiheit (kann leer sein [] für Nicht-WCAG).
• terms — optionale Liste von Glossartermreferenzen mit id- und ordinal-Eigenschaften.

Schritt 2: Lokalisierte Inhalte zu checkpoints.en.json hinzufügen

Verwenden Sie das mit Bindestrich-ID-Format: Punkte in Bindestriche umwandeln (z.B., custom-1-1, nicht 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."
  }
}

Verwenden Sie \n für Zeilenumbrüche und geeignete HTML-Tags für Listen.

Hinzufügen eines WCAG-Checkpoints

Zu aktualisierende Dateien — 6 Dateien für eine vollständige WCAG-Checkpoint-Implementierung:

1. package/dist/bundle/checkpoints.json — den Checkpoint mit WCAG-spezifischen Feldern definieren.
2. package/dist/bundle/locales/checkpoints.en.json — lokalisierte Testmethodologie, Beispiele, verwandte Techniken (Verwenden Sie das mit Bindestrichen versehene ID-Format: 1-4-3-a, nicht 1.4.3.a).
3. package/dist/bundle/descriptions.json — Problembeschreibungen mit Auswirkungen und Checkpoint-Verweisen.
4. package/dist/bundle/locales/descriptions.en.json — lokalisierte Problembeschreibungen.
5. package/dist/bundle/recommendations.json — Empfehlungen zur Behebung, die mit Problembeschreibungen verknüpft sind.
6. package/dist/bundle/locales/recommendations.en.json — lokalisierte Empfehlungstexte (Titel, Beschreibung, Schritte, Ressourcen).

Optional — manuelle Eingabe: Wenn Sie es bevorzugen, vordefinierte Beschreibungen und Empfehlungen aus den JSON-Dateien zu überspringen, können Sie diese beim Protokollieren von Problemen im Tool bearbeiten: Wählen Sie Ihren WCAG-Prüfpunkt aus, wählen Sie Erstellen Sie Ihre eigene Beschreibung anstelle eines vordefinierten aus und geben Sie dann manuell die Beschreibung und (falls erforderlich) die Empfehlung ein, die auf das gefundene Problem zugeschnitten ist.

Schritt 1: Definieren Sie den Prüfpunkt

Datei: 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"]
}

Schlüsselfelder:

• id — WCAG Nummerierungsmuster (z. B. "1.4.3.a", "2.1.1.b").
• successCriteria — WCAG-Erfolgskriteriennummer (z. B. "1.4.3").
• standards — "wcag2a" (Stufe A), "wcag2aa" (Stufe AA) oder "wcag2aaa" (Stufe AAA).
• automatedRules — Array von automatisierten Regel-IDs.
• grouping — WCAG-Leitliniennummer (z. B. "1.4", "2.1").

Schritt 2: Fügen Sie die Testmethodik hinzu

Datei: package/dist/bundle/locales/checkpoints.en.json — verwenden Sie das formatierte Format (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>"
  }
}

Schritt 3: Fügen Sie Problembeschreibungen hinzu

Datei: 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"]
    }
  ]
}

Schritt 4: Lokalisierte Problembeschreibungen hinzufügen

Datei: package/dist/bundle/locales/descriptions.en.json

Fügen Sie ein Objekt für die neue Beschreibung hinzu:

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

Schritt 5: Empfehlungen hinzufügen

Datei: package/dist/bundle/recommendations.json

Verwenden Sie das formatierte Format (1-4-3-a) und fügen Sie es der Empfehlungs-ID hinzu.

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

Schritt 6: Empfehlungstext hinzufügen

Datei: 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"
  ]
}

Einen bestimmten Prüfpunkt entfernen

Verwenden Sie diese Anweisungen, wenn es einen bestimmten Prüfpunkt gibt, den Ihr Team nicht testen und melden soll.

Aktualisierte Dateien:

• 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

Schritte:

1. In checkpoints.json, suchen Sie nach dem spezifischen Prüfpunkt (z. B. 1.2.1.b). Löschen Sie das gesamte mit diesem Prüfpunkt verbundene Objekt, während Sie gültiges JSON erhalten. Speichern Sie die Datei.
2. In descriptions.json, suchen Sie nach dem spezifischen Prüfpunkt (z. B. 1.2.1.b). Löschen Sie nur das Objekt, das den Prüfpunkt unter der Regel verwendet, während Sie gültiges JSON erhalten. Eine einzelne Regel kann für mehrere Prüfpunkte gelten — Entfernen Sie nur das Objekt für den Prüfpunkt, den Sie entfernen; entfernen Sie nicht die gesamte Regel. Speichern Sie die Datei.
3. In recommendations.json, suchen Sie nach dem spezifischen Prüfpunkt (z. B. 1.2.1.b). Löschen Sie jedes mit diesem Prüfpunkt verbundene Objekt (es kann mehr als eines geben), während Sie gültiges JSON erhalten. Speichern Sie die Datei.
4. In checkpoints.en.json, suchen Sie nach dem spezifischen Prüfpunkt mit dem formatieren Format (z. B. 1-2-1-b). Löschen Sie das gesamte Objekt, während Sie gültiges JSON erhalten. Speichern Sie die Datei.
5. In recommendations.en.json, suchen Sie nach dem spezifischen Prüfpunkt mit dem formatieren Format (z. B. 1-2-1-b). Löschen Sie jedes mit diesem Prüfpunkt verbundene Objekt (es kann mehr als eines geben), während Sie gültiges JSON erhalten. Speichern Sie die Datei.

Änderungen an Deque zurücksenden

Wenn die Bearbeitungen abgeschlossen und validiert sind:

1. Bestätigen Sie, dass jede bearbeitete Datei weiterhin die JSON-Validierung besteht (siehe Bevor Sie beginnen).
2. Bestätigen Sie, dass die Änderungen dem vereinbarten Umfang entsprechen.
3. Senden Sie den gesamten package-Ordner in seiner Originalstruktur zurück an Deque (senden Sie nicht nur einzelne Dateien).

Deque weist die Version zu, verpackt das Bündel, ordnet es der richtigen axe-core-Version zu und stellt es in einer Testinstanz zur Überprüfung bereit. Nachdem Ihr Team die Änderungen auf der Testinstanz überprüft und freigegeben hat, befördert Deque die Methodik zu Ihrer Produktion-Instanz.

Unterstützung

Bei Fragen zu diesem Prozess, dem vereinbarten Änderungsumfang oder um zusätzliche Sprachunterstützung anzufordern, wenden Sie sich an Ihren Deque-Ansprechpartner.