Individuelle Methodikunterstützung

Konfiguration der Methodik für manuelles Testen im Axe Auditor

Zweck

Kunden, die den axe Auditor nutzen, müssen manchmal die Methodik für manuelles Testen (die DequeWay) anpassen. Dies kann erforderlich sein aufgrund von:

• Spezifischen internen Richtlinien, die zusätzliche oder weniger Prüfungen erfordern.
• Internen Richtlinien, die den Einsatz spezifischer Werkzeuge bei Tests vorschreiben.
• Richtlinienentscheidungen, die verschiedene Attributänderungen der Issues (Einfluss, Beschreibungen, Empfehlungen) erfordern.

Dieses Dokument beschreibt die Anpassungen, die an der Methodik für manuelles Testen im axe Auditor vorgenommen werden können, und erklärt, wie diese Änderungen an Deque zurückgegeben werden, um für Ihre gehostete Instanz verpackt und bereitgestellt zu werden.

Wie das funktioniert: Rollen und Arbeitsablauf

Die Instanz Ihres Unternehmens von axe Auditor wird von Deque gehostet und verwaltet. Das bedeutet, dass Deque die Installation, die Versionssequenzierung, die Verpackung und die Bereitstellung der Methodik verwaltet. Ihr Team ist nur für die Bearbeitung der Methodik-Konfigurationsdateien verantwortlich. Sie müssen keine Versionsnummern aktualisieren, Pakete erstellen oder Installations- oder Datenbankbefehle ausführen. Deque übernimmt dies alles für Sie.

Der End-to-End-Prozess ist:

Umfangshinweis: Dieses Dokument listet alle verfügbaren Anpassungstypen zur Vollständigkeit auf. Die spezifischen Änderungen, die Ihr Team vornehmen wird, sollten dem vereinbarten Änderungsumfang entsprechen.

Bevor Sie beginnen

1. Original sichern. Bevor Sie etwas bearbeiten, machen Sie eine Kopie des entpackten package-Ordners. Wenn eine Bearbeitung das Paket beschädigt, ist dies Ihr einziger sicherer Weg zur Wiederherstellung.

cp -r package package_backup_original

2. Bearbeiten Sie nur die in jedem Abschnitt aufgeführten Dateien. Die Dateien sind voneinander abhängig. Das Bearbeiten einer Datei, die nicht für eine bestimmte Änderung aufgeführt ist — oder das Auslassen einer Datei, die ist aufgelistet ist — kann dazu führen, dass ein Paket fehlschlägt, erst wenn es an Deque zurückgesendet wird.

3. Validieren Sie jede Datei, die Sie bearbeiten. Jede Datei ist JSON und muss nach der Bearbeitung weiterhin gültiges JSON sein (keine nachgestellten Kommas, ausgeglichene Klammern). Validieren Sie, bevor Sie 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 gehen von Englisch (en) aus. Wenn Ihre Organisation die Methodik in zusätzlichen Sprachen benötigt, informieren Sie Deque — Deque ermöglicht die Sprachunterstützung während der Konfiguration. In diesem Fall muss jede Änderung, die Sie in einer .en.json-Datei vornehmen, auch in der entsprechenden Sprachdatei (z. B. dem .nl.json-Äquivalent) für jede zusätzliche Sprache vorgenommen werden.

Erlaubte Updates

Aktualisierung der Testmethodik für einen bestimmten Checkpunkt

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

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

Schritte:

1. Finden Sie den spezifischen Deque-Checkpunkt in der JSON-Datei (z.B. 1.1.1.a).
2. Suchen Sie nach dem testing-methodology Attribut unter diesem spezifischen Checkpunkt.
3. Nehmen Sie entsprechende Änderungen an jedem Asset-Typ vor, der unter testing-methodology aufgeführt ist.
4. Speichern Sie die Datei an ihrem aktuellen Ort.

Hinweis: Der in axe Auditor sichtbare Checkpunktname kann ebenfalls mit denselben Anweisungen geändert werden. Anstatt den testing-methodology Abschnitt zu aktualisieren, aktualisieren Sie das name Attribut unter dem entsprechenden Checkpunkt in derselben Datei.

Aktualisierung der Auswirkung einer Regel

Sie können die Auswirkungsstufe (Blocker, Kritisch, Ernst, Mittel, Geringfügig) für jedes Problem in axe Auditor ändern. Wenn Sie jedoch die Standard-Auswirkung für eine Regel ändern müssen, befolgen Sie diese Anweisungen.

Auswirkungen in axe Auditor werden auf der Regel Ebene gespeichert, nicht auf der Ebene eines WCAG-Erfolgskriteriums oder Checkpunkts. Eine einzelne Regel kann mehrere Deque-Checkpunkte betreffen (z.B. Regel-ID alt-text-dynamic-image-inconsistent). Die Auswirkungsänderung für die Regel verändert die Standardauswirkung für ein Problem, das durch die Verletzung dieser Regel über Alle WCAG-Erfolgskriterien hinweg ausgelöst wird, mit denen die Regel verbunden ist.

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

Schritte:

1. Finden 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 folgende Tabelle).
4. Speichern Sie die Datei an ihrem aktuellen Ort.

Auswirkungswert-Zuordnungen

Hinzufügen eines neuen Barrierefreiheitsstandards (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, nutzen Sie die folgenden Schritte.

⚠️ Intern bei Deque – vor der Veröffentlichung lösen: Die Dateiliste für diesen Abschnitt verweist auf drei checkpoint-bezogene Pfade, die mit dem Rest des Dokuments (das dist/bundle/… verwendet) inkonsistent sind: 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 dies Pfadfehler sind, aktualisieren Sie dann die Liste entsprechend und entfernen Sie diesen Hinweis.

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 besteht darin, das gesamte Objekt für wcag21aa zu kopieren und es am Ende der Datei hinzuzufügen.
2. Ändern Sie das id des neu kopierten Objekts in etwas Einzigartiges, das den Standard, den es repräsentiert, kennzeichnet.
3. Aktualisieren Sie das rubric Array für das neue Objekt, um alle zugrunde liegenden Teststandards darzustellen, die Teil dieses neuen Standards sind.
4. Fügen Sie in descriptions.json für alle Regeln, die mit Ihrem neuen Standard verbunden sind, die ID des neuen Standards (von standards.json) dem standards Array hinzu.
5. Fügen Sie in testingMethodologies.json die ID des neuen Standards unter dem standards Array für jeden digitalen Asset-Typ hinzu, auf den dieser Standard zutrifft.
6. Fügen Sie in standards.en.json ein neues Objekt mit der ID und dem Namen des neuen Standards hinzu. Das name Feld ist das, was Benutzer in der Benutzeroberfläche von axe Auditor sehen.
7. Aktualisieren Sie in dist/checkpoints.json das standards Array unter jeder Problem-Beschreibung für die entsprechenden Checkpunkte.
8. Aktualisieren Sie in issue-descriptions.json das standards Array für alle zutreffenden Regelobjekte.
9. Aktualisieren Sie in dist/bundle/checkpoints.json das standards Array für jeden zutreffenden Checkpunkt mit dem richtigen Standard.

Aktualisieren Sie die kurze und lange Problembeschreibung 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 — das Ändern dieses Textes beeinflusst Alle Erfolgskriterien, mit denen sie verbunden ist.

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

Schritte:

1. Suchen Sie in descriptions.en.json 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) entsprechend.
3. Speichern Sie die Datei an ihrem aktuellen Ort.

Aktualisierung der Behebungsempfehlung

Wenn Sie die Bibliothek für Behebungen 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. Suchen Sie in recommendations.en.json nach der spezifischen Regel (z. B. alt-text-dynamic-image-inconsistent) und der Kontrollpunktkombination, für die Sie die Bibliothek zur Fehlerbehebung ändern möchten.
2. Aktualisieren Sie den Text für recommendationType (Empfehlungstechnik), rule, howtofix und background (Abschnitte der Empfehlung zur Behebung), wo zutreffend.
3. Speichern Sie die Datei an ihrem aktuellen Ort.

Entfernen Sie digitale Asset-Typen

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

Zu aktualisierende Dateien:

• dist/bundle/testingMethodologies.json — Hauptmethodologien der Tests
• dist/bundle/locales/testingMethodologies.en.json — Englische Übersetzungen

Schritt 1: Aus der Datei für 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 dasselbe Methodologie-Objekt aus dieser Datei.

Fügen Sie einen neuen digitalen Asset-Typ hinzu

Verwenden Sie dies, um einen neuen digitalen Asset-Typ hinzuzufügen – zum Beispiel eine web-app oder macos Methodologie. Das untenstehende Beispiel verwendet web-app; ersetzen Sie es durch Ihre eigene Asset-Typ-ID.

Zu aktualisierende Dateien:

• dist/bundle/testingMethodologies.json — Hauptmethodologien der Tests
• dist/bundle/locales/testingMethodologies.en.json — Englische Übersetzungen
• dist/bundle/locales/checkpoints.en.json — Englischer Kontrollpunktinhalt mit Methodologie-Abschnitten
• dist/bundle/checkpoints.json — Hauptkontrollpunktdaten
• dist/bundle/descriptions.json — Problembeschreibungen mit Methodologiereferenzen
• dist/bundle/schemata.json — Schemadefinitionen mit Methodologiereferenzen

Schritt 1: Zur Datei für Testmethodologien hinzufügen

Datei: dist/bundle/testingMethodologies.json

Fügen Sie das neue Methodologie-Objekt dem 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 dasselbe Methodologie-Objekt zu dieser Datei hinzu.

Schritt 3: Referenzen zur Kontrollpunktdatei hinzufügen

Datei: dist/bundle/checkpoints.json

Fügen Sie für jeden Kontrollpunkt, der die neue Methodologie unterstützen soll, diese dem Array testingMethodologies des Kontrollpunkts 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: Methodologie-Inhalt zur Kontrollpunkt-Lokalisierungsdatei hinzufügen

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

Fügen Sie für jeden Kontrollpunkt, der die neue Methodologie unterstützen soll, den Methodologie-Inhalt 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: Referenzen zur Beschreibungsdatei hinzufügen

Datei: dist/bundle/descriptions.json

Fügen Sie für Problembeschreibungen, die die neue Methodologie unterstützen sollen, diese ihrem Array testingMethodologies hinzu.

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

Schritt 6: Referenzen zur Schemadatei 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
  }
}

Fügen Sie einen neuen Kontrollpunkt hinzu

Hinzufügen eines Nicht-WCAG-Kontrollpunkts

Wichtig: Nicht-WCAG-Kontrollpunkte bieten nicht Unterstützung für vordefinierte Beschreibungen oder Empfehlungen durch descriptions.json und recommendations.json. Beim Melden von Problemen mit diesen Kontrollpunkten geben Sie Beschreibungen und Empfehlungen manuell mit der Erstellen Sie Ihre eigene Beschreibung-Funktion im Tool ein.

Zu aktualisierende Dateien — nur 2:

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

Schritt 1: Fügen Sie den Kontrollpunkt 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-Kontrollpunkte (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 Kontrollpunkt gilt: desktop, mobile, kiosk, native-mobile-ios, native-mobile-android, pdf, windows-desktop, ms-excel, ms-powerpoint, ms-word.
• requiredSenses — Welche Sinne benötigt werden, um diesen Kontrollpunkt zu testen (sight, hearing: true/false).
• automatedRules — optionale Liste von automatisierten Regel-IDs (typischerweise leer [] für benutzerdefinierte Kontrollpunkte).
• grouping — Logische Gruppierung zur Organisation (z. B. "custom.1", "1", "s.1").
• categories — Relevante Kategorien der Barrierefreiheit (kann leer [] für Nicht-WCAG sein).
• terms — optionale Liste von Glossarbegriffsreferenzen mit id und ordinal Eigenschaften.

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

Verwenden Sie das mit Bindestrich-ID-Format: Ersetzen Sie Punkte durch Bindestriche (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.

Einen WCAG-Checkpoint hinzufügen

Zu aktualisierende Dateien — 6 Dateien für die vollständige Implementierung eines WCAG-Checkpoints:

1. package/dist/bundle/checkpoints.json — definieren Sie den Checkpoint mit WCAG-spezifischen Feldern.
2. package/dist/bundle/locales/checkpoints.en.json — lokalisierte Testmethodik, Beispiele, verwandte Techniken (verwenden Sie das ID-Format mit Bindestrich: 1-4-3-a, nicht 1.4.3.a).
3. package/dist/bundle/descriptions.json — Problembeschreibungen mit Auswirkungsstufen und Checkpoint-Referenzen.
4. package/dist/bundle/locales/descriptions.en.json — lokalisierte Problembeschreibungen.
5. package/dist/bundle/recommendations.json — Behandlungsempfehlungen, die mit den Problembeschreibungen verknüpft sind.
6. package/dist/bundle/locales/recommendations.en.json — lokalisierter Empfehlungsinhalt (Titel, Beschreibung, Schritte, Ressourcen).

Optional — manuelle Eingabe: Wenn Sie lieber darauf verzichten möchten, vordefinierte Beschreibungen und Empfehlungen zu den JSON-Dateien hinzuzufügen, können Sie diese beim Protokollieren von Problemen im Tool bearbeiten: Wählen Sie Ihren WCAG-Checkpoint aus, entscheiden Sie sich für Erstellen Sie Ihre eigene Beschreibung anstelle eines vordefinierten, und geben Sie dann manuell die auf das gefundene Problem zugeschnittene Beschreibung und gegebenenfalls Empfehlung ein.

Schritt 1: Den Checkpoint definieren

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-Nummeriermuster (z. B. "1.4.3.a", "2.1.1.b").
• successCriteria — WCAG-Erfolgskriterium-Nummer (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: Methodik der Tests hinzufügen

Datei: package/dist/bundle/locales/checkpoints.en.json — verwenden Sie das Format mit Bindestrich (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: Problembeschreibungen hinzufügen

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

Ein Objekt für die neue Beschreibung hinzufügen:

"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 Format mit Bindestrich (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: Empfehlungsinhalte 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 Checkpoint entfernen

Verwenden Sie diese Anweisungen, wenn es einen bestimmten Checkpoint gibt, den Ihr Team nicht testen und gegen den nicht berichten 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. Suchen Sie in checkpoints.json den spezifischen Checkpoint (z. B. 1.2.1.b). Löschen Sie das gesamte Objekt, das diesem Checkpoint zugeordnet ist, während Sie gültiges JSON beibehalten. Speichern Sie die Datei.
2. Suchen Sie in descriptions.json den spezifischen Checkpoint (z. B. 1.2.1.b). Löschen Sie nur das Objekt, das den Checkpoint unter der Regel verwendet, während Sie gültiges JSON beibehalten. Eine einzelne Regel kann auf mehrere Checkpoints angewendet werden — entfernen Sie nur das Objekt für den Checkpoint, den Sie entfernen; entfernen Sie nicht die gesamte Regel. Speichern Sie die Datei.
3. Suchen Sie in recommendations.json den spezifischen Checkpoint (z. B. 1.2.1.b). Löschen Sie jedes Objekt, das mit diesem Checkpoint verbunden ist (es kann mehr als eins sein), während Sie gültiges JSON beibehalten. Speichern Sie die Datei.
4. Suchen Sie in checkpoints.en.json den spezifischen Checkpoint, indem Sie das Format mit Bindestrich (z. B. 1-2-1-b) verwenden. Löschen Sie das gesamte Objekt, während Sie gültiges JSON beibehalten. Speichern Sie die Datei.
5. Suchen Sie in recommendations.en.json den spezifischen Checkpoint, indem Sie das Format mit Bindestrich (z. B. 1-2-1-b) verwenden. Löschen Sie jedes Objekt, das mit diesem Checkpoint verbunden ist (es kann mehr als eins sein), während Sie gültiges JSON beibehalten. Speichern Sie die Datei.

Änderungen zurück an Deque senden

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 zurück an Deque in seiner ursprünglichen Struktur (senden Sie nicht nur einzelne Dateien).

Deque wird die Version zuweisen, das Paket schnüren, es der richtigen axe-core-Version zuordnen und es an einen Testinstanz zur Verifizierung bereitstellen. Nachdem Ihr Team die Änderungen auf der Testinstanz überprüft und freigegeben hat, fördert Deque die Methodik zu Ihrer Produktion-Instanz.

Unterstützung

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