Support de méthodologie personnalisée

Configuration de méthodologie de test manuel personnalisé dans Axe Auditor

Objectif

Les clients utilisant axe Auditor ont parfois besoin d'ajuster la méthodologie de test manuel (leDequeWay). Ce besoin peut découler de :

• Politiques internes spécifiques nécessitant des vérifications supplémentaires ou moindres.
• Directives internes pour utiliser des outils spécifiques lors des tests.
• Décisions politiques modifiant divers attributs des problèmes (impact, descriptions, recommandations).

Ce document décrit les personnalisations qui peuvent être apportées à la méthodologie de test manuel dans axe Auditor, et explique comment ces modifications sont transmises à Deque pour leur emballage et déploiement sur votre instance hébergée.

Comment cela fonctionne : rôles et workflow

L'instance axe Auditor de votre organisation est hébergée et gérée par Deque. Cela signifie que Deque gère l'installation, le séquençage des versions, l'emballage et le déploiement de la méthodologie. Votre équipe est uniquement responsable de la modification des fichiers de configuration de la méthodologie. Vous n'avez pas besoin de mettre à jour les numéros de version, de créer des paquets ou d'exécuter des commandes d'installation ou de base de données. Deque s'occupe de tout cela pour vous.

Le processus de bout en bout est :

Note sur la portée : Ce document liste tous les types de personnalisation disponibles à titre d'exhaustivité. Les modifications spécifiques que votre équipe apportera doivent correspondre à la portée des changements convenus.

Avant de commencer

1. Sauvegardez l'original. Avant de modifier quoi que ce soit, faites une copie du dossier décompressé package. Si une modification casse le bundle, c'est le seul moyen sûr de revenir en arrière.

cp -r package package_backup_original

2. Modifiez uniquement les fichiers listés dans chaque section. Les fichiers sont interdépendants. Modifier un fichier non listé pour un changement donné — ou en oublier un qui est est listé — peut produire un ensemble qui échoue seulement après son retour chez Deque.

3. Validez chaque fichier que vous modifiez. Chaque fichier est en JSON et doit rester un JSON valide après modification (pas de virgules finales, parenthèses/accolades équilibrées). Validez avant envoi :

# 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. Hypothèse linguistique. Ces instructions supposent l'anglais (en). Si votre organisation requiert une méthodologie dans d'autres langues, informez Deque — Deque permet la prise en charge linguistique lors de la configuration. Dans ce cas, chaque modification que vous effectuez dans un fichier .en.json doit également être faite dans le fichier de langue correspondant (par exemple, l'équivalent .nl.json) pour chaque langue supplémentaire.

Mises à jour autorisées

Mettre à jour la méthodologie de test pour un point de contrôle spécifique

Utile lorsque vous souhaitez modifier les instructions de test pour un point de contrôle spécifique dans axe Auditor.

Fichiers mis à jour : package/dist/bundle/locales/checkpoints.en.json

Étapes :

1. Localisez le point de contrôle Deque spécifique dans le fichier JSON (par ex. 1.1.1.a).
2. Recherchez l'attribut testing-methodology sous ce point de contrôle spécifique.
3. Effectuez les mises à jour appropriées à tout type de ressource listé sous testing-methodology.
4. Enregistrez le fichier à son emplacement actuel.

Remarque : Le nom du point de contrôle visible dans axe Auditor peut également être modifié en utilisant les mêmes instructions. Au lieu de mettre à jour la section testing-methodology, mettez à jour l'attribut name sous le point de contrôle concerné dans le même fichier.

Mettre à jour l'impact d'une règle

Vous pouvez modifier le niveau d'impact (bloquant, critique, grave, modéré, mineur) pour chaque problème dans axe Auditor. Cependant, si vous devez changer l'impact par défaut d'une règle, suivez ces instructions.

Les impacts dans axe Auditor sont stockés au niveau règle, pas au niveau des Critères de Réussite WCAG ou des points de contrôle. Une seule règle peut affecter plusieurs points de contrôle Deque (par ex. id de règle alt-text-dynamic-image-inconsistent). Modifier l'impact pour la règle change l'impact par défaut d'un problème déclenché par la violation de cette règle à travers tout Critères de Réussite WCAG connectés à la règle.

Fichiers mis à jour : package/dist/bundle/descriptions.json

Étapes :

1. Localisez la règle Deque spécifique dans le fichier JSON (par ex. alt-text-dynamic-image-inconsistent).
2. Recherchez l'attribut impact sous cette règle spécifique.
3. Mettez à jour l'impact avec une valeur numérique (voir le tableau ci-dessous).
4. Enregistrez le fichier à son emplacement actuel.

Mappings des valeurs d'impact

Ajouter une nouvelle norme d'accessibilité (par ex., une norme spécifique à une organisation)

Si vous disposez de normes de test spécifiques à votre organisation que vous souhaitez fournir à vos équipes en plus des normes existantes (telles que WCAG 2.1 AA ou ACAA), utilisez les étapes suivantes.

⚠️ Interne Deque — à résoudre avant publication : La liste des fichiers pour cette section fait référence à trois chemins liés aux points de contrôle qui sont incohérents avec le reste du document (qui utilise dist/bundle/…) : package/dist/checkpoints.json, package/dist/issue-descriptions.json, et package/dist/bundle/checkpoints.json. Confirmez si dist/checkpoints.json et dist/issue-descriptions.json sont vraiment des fichiers compilés distincts, ou si ce sont des erreurs de chemin, puis mettez à jour la liste en conséquence et supprimez cette note.

Fichiers mis à jour :

• 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

Étapes :

1. Créez un nouvel objet de tableau pour le standard dans standards.json. La manière la plus simple est de copier l'intégralité de l'objet pour wcag21aa et de l'ajouter en bas du fichier.
2. Changez le id de l'objet nouvellement copié en quelque chose d'unique qui signifie le standard qu'il représente.
3. Mettez à jour le tableau rubric pour le nouvel objet afin de représenter toutes les normes de test sous-jacentes qui font partie de ce nouveau standard.
4. Dans descriptions.json, pour toutes les règles associées à votre nouveau standard, ajoutez l'identifiant du nouveau standard (de standards.json) au tableau standards.
5. Dans testingMethodologies.json, ajoutez l'identifiant du nouveau standard sous le tableau standards pour chaque type d'actif numérique auquel ce standard s'applique.
6. Dans standards.en.json, ajoutez un nouvel objet avec l'identifiant et le nom du nouveau standard. Le champ name est ce que les utilisateurs voient dans l'interface utilisateur de l'auditeur axe.
7. Dans dist/checkpoints.json, mettez à jour le tableau standards sous chaque description de problème pour les points de contrôle applicables.
8. Dans issue-descriptions.json, mettez à jour le tableau standards pour tous les objets de règle applicables.
9. Dans dist/bundle/checkpoints.json, mettez à jour le tableau standards de chaque point de contrôle applicable avec le standard correct.

Mettre à jour les descriptions courtes et longues des problèmes pour des règles spécifiques

Utilisez ces instructions pour mettre à jour le texte de sélection de la description des problèmes (court) et la description longue du type de problème pour chaque règle. Une seule règle peut affecter plusieurs Critères de Réussite WCAG — modifier ce texte affecte tous Critères de Réussite auxquels elle est connectée.

Fichiers mis à jour : package/dist/bundle/locales/descriptions.en.json

Étapes :

1. Dans descriptions.en.json, recherchez la règle spécifique (par exemple, alt-text-dynamic-image-inconsistent).
2. Mettez à jour le texte pour shortText (Description courte du problème) et issueDescText (Description longue du problème) selon le besoin.
3. Enregistrez le fichier à son emplacement actuel.

Mettez à jour la recommandation de remédiation

Si vous souhaitez modifier la bibliothèque de remédiation et les descriptions associées pour vous aligner sur votre politique, utilisez les instructions suivantes.

Fichiers mis à jour : package/dist/bundle/locales/recommendations.en.json

Étapes :

1. Dans recommendations.en.json, recherchez la règle spécifique (par exemple, alt-text-dynamic-image-inconsistent) et la combinaison de points de contrôle pour laquelle vous voulez changer la bibliothèque de remédiation.
2. Mettez à jour le texte pour recommendationType (Technique de recommandation), rule, howtofix, et background (sections de la recommandation à corriger) selon le besoin.
3. Enregistrez le fichier à son emplacement actuel.

Supprimer les types d'actifs numériques

Utilisez ceci lorsqu'un type d'actif donné ne s'applique pas à votre organisation (par exemple, si les tests PDF ou Android sont hors champ).

Fichiers à mettre à jour :

• dist/bundle/testingMethodologies.json — données principales des méthodologies de test
• dist/bundle/locales/testingMethodologies.en.json — traductions anglaises

Étape 1 : Supprimer du fichier des méthodologies de test

Fichier : dist/bundle/testingMethodologies.json

Trouvez et supprimez l'intégralité de l'objet pour la méthodologie que vous souhaitez supprimer.

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

Étape 2 : Supprimer du fichier de paramètres locaux en anglais

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

Supprimez le même objet méthodologique de ce fichier.

Ajouter un nouveau type d'actif numérique

Utilisez ceci pour ajouter un nouveau type d'actif numérique — par exemple une méthodologie web-app ou macos. L'exemple ci-dessous utilise web-app ; substituez votre propre identifiant de type d'actif si nécessaire.

Fichiers à mettre à jour :

• dist/bundle/testingMethodologies.json — données principales des méthodologies de test
• dist/bundle/locales/testingMethodologies.en.json — traductions anglaises
• dist/bundle/locales/checkpoints.en.json — contenu des points de contrôle en anglais avec sections des méthodologies de test
• dist/bundle/checkpoints.json — données des points de contrôle principaux
• dist/bundle/descriptions.json — descriptions de problèmes avec références aux méthodologies de test
• dist/bundle/schemata.json — définitions de schémas avec références aux méthodologies de test

Étape 1 : Ajouter au fichier des méthodologies de test

Fichier : dist/bundle/testingMethodologies.json

Ajoutez le nouvel objet de méthodologie au tableau.

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

Étape 2 : Ajouter au fichier de paramètres locaux en anglais

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

Ajoutez le même objet méthodologique à ce fichier.

Étape 3 : Ajoutez des références au fichier checkpoint

Fichier : dist/bundle/checkpoints.json

Pour chaque checkpoint qui doit prendre en charge la nouvelle méthodologie, ajoutez-le au tableau testingMethodologies de ce checkpoint.

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

Étape 4 : Ajoutez du contenu méthodologique de test au fichier de localisation du checkpoint

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

Pour chaque checkpoint qui doit prendre en charge la nouvelle méthodologie, ajoutez le contenu méthodologique de test.

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

Étape 5 : Ajoutez des références au fichier de descriptions

Fichier : dist/bundle/descriptions.json

Pour les descriptions de problèmes qui doivent prendre en charge la nouvelle méthodologie, ajoutez-les à leur tableau testingMethodologies.

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

Étape 6 : Ajoutez des références au fichier schema

Fichier : dist/bundle/schemata.json

Ajoutez la nouvelle méthodologie de test aux définitions du schema.

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

Ajouter un nouveau checkpoint

Ajout d'un checkpoint non-WCAG

Important : Les checkpoints non-WCAG ne ne pas prennent pas en charge les descriptions ou recommandations prédéfinies via descriptions.json et recommendations.json. Lors de la consignation de problèmes avec ces checkpoints, vous entrez manuellement les descriptions et recommandations en utilisant la fonctionnalité Créez votre propre description dans l'outil.

Fichiers à mettre à jour — seulement 2 :

• package/dist/bundle/checkpoints.json — définir le checkpoint
• package/dist/bundle/locales/checkpoints.en.json — fournir une méthodologie de test localisée

Étape 1 : Ajoutez le checkpoint à checkpoints.json

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

Champs clés :

• id — identifiant unique utilisant votre format personnalisé (par ex., custom.1.1, brand.2.3, TT.01.A, s.1.1).
• successCriteria — chaîne vide "" pour les checkpoints non-WCAG (ou un format personnalisé comme "tt-01.A").
• standards — votre identifiant de norme personnalisé, par ex., ["custom"], ["TT508"], ["smoke"], ["brand"] (ne pas ["wcag2a"]).
• testingMethodologies — plateformes où ce checkpoint s'applique : desktop, mobile, kiosk, native-mobile-ios, native-mobile-android, pdf, windows-desktop, ms-excel, ms-powerpoint, ms-word.
• requiredSenses — quels sens sont nécessaires pour tester ce checkpoint (sight, hearing : true/false).
• automatedRules — tableau optionnel d'identifiants de règles automatisées (généralement vide [] pour les checkpoints personnalisés).
• grouping — regroupement logique pour l'organisation (par ex., "custom.1", "1", "s.1").
• categories — catégories d'accessibilité pertinentes (peut être vide [] pour non-WCAG).
• terms — tableau optionnel de références de termes du glossaire avec les propriétés id et ordinal.

Étape 2 : Ajoutez du contenu localisé à checkpoints.en.json

Utilisez le format d'identifiant trait d'union : convertissez les points en traits d'union (par ex., custom-1-1, pas 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."
  }
}

Utilisez \n pour les nouvelles lignes et les balises HTML appropriées pour les listes.

Ajouter un checkpoint WCAG

Fichiers à mettre à jour — 6 fichiers pour une implémentation complète de checkpoint WCAG :

1. package/dist/bundle/checkpoints.json — définir le checkpoint avec des champs spécifiques à la WCAG.
2. package/dist/bundle/locales/checkpoints.en.json — méthodologie de test localisée, exemples, techniques associées (utilisez le format d'identifiant avec trait d'union : 1-4-3-a, pas 1.4.3.a).
3. package/dist/bundle/descriptions.json — descriptions des issues avec niveaux d'impact et références de checkpoint.
4. package/dist/bundle/locales/descriptions.en.json — descriptions des issues localisées.
5. package/dist/bundle/recommendations.json — recommandations de remédiation liées aux descriptions des issues.
6. package/dist/bundle/locales/recommendations.en.json — contenu de recommandation localisé (titre, description, étapes, ressources).

Optionnel — saisie manuelle : Si vous préférez éviter d'ajouter des descriptions et recommandations prédéfinies aux fichiers JSON, vous pouvez les gérer lors de l'enregistrement des problèmes dans l'outil : sélectionnez votre point de contrôle WCAG, choisissez Créez votre propre description au lieu d'un prédéfini, puis entrez manuellement la description et, si nécessaire, la recommandation adaptée au problème rencontré.

Étape 1 : Définir le point de contrôle

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

Champs clés :

• id — Modèle de numérotation WCAG (par exemple, "1.4.3.a", "2.1.1.b").
• successCriteria — Numéro de critère de réussite WCAG (par exemple, "1.4.3").
• standards — "wcag2a" (Niveau A), "wcag2aa" (Niveau AA), ou "wcag2aaa" (Niveau AAA).
• automatedRules — tableau d'identifiants de règles automatisées.
• grouping — Numéro de directive WCAG (par exemple, "1.4", "2.1").

Étape 2 : Ajouter la méthodologie de test

Fichier : package/dist/bundle/locales/checkpoints.en.json — utilisez le format avec trait d'union (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>"
  }
}

Étape 3 : Ajouter des descriptions de problèmes

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

Étape 4 : Ajouter des descriptions de problèmes localisées

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

Ajoutez un objet pour la nouvelle description :

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

Étape 5 : Ajouter des recommandations

Fichier : package/dist/bundle/recommendations.json

Utilisez le format avec trait d'union (1-4-3-a) et ajoutez-le à l'identifiant de la recommandation.

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

Étape 6 : Ajouter le contenu des recommandations

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

Supprimer un point de contrôle spécifique

Utilisez ces instructions si vous ne souhaitez pas que votre équipe teste et signale un certain point de contrôle.

Fichiers mis à jour :

• 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

Étapes :

1. Dans checkpoints.json, recherchez le point de contrôle spécifique (par exemple, 1.2.1.b). Supprimez l'ensemble de l'objet associé à ce point de contrôle tout en maintenant un JSON valide. Enregistrez le fichier.
2. Dans descriptions.json, recherchez le point de contrôle spécifique (par exemple, 1.2.1.b). Supprimez uniquement l'objet qui utilise le point de contrôle sous la règle tout en maintenant un JSON valide. Une seule règle peut s'appliquer à plusieurs points de contrôle — supprimez uniquement l'objet pour le point de contrôle que vous retirez ; ne supprimez pas la règle complète. Enregistrez le fichier.
3. Dans recommendations.json, recherchez le point de contrôle spécifique (par exemple, 1.2.1.b). Supprimez chaque objet associé à ce point de contrôle (il peut y en avoir plus d'un) tout en maintenant un JSON valide. Enregistrez le fichier.
4. Dans checkpoints.en.json, recherchez le point de contrôle spécifique en utilisant le format avec trait d'union (par exemple, 1-2-1-b). Supprimez l'ensemble de l'objet tout en maintenant un JSON valide. Enregistrez le fichier.
5. Dans recommendations.en.json, recherchez le point de contrôle spécifique en utilisant le format avec trait d'union (par exemple, 1-2-1-b). Supprimez chaque objet associé à ce point de contrôle (il peut y en avoir plus d'un) tout en maintenant un JSON valide. Enregistrez le fichier.

Envoyer les modifications à Deque

Lorsque les modifications sont complètes et validées :

1. Confirmez que chaque fichier modifié passe toujours la validation JSON (voir Avant de commencer).
2. Confirmez que les modifications correspondent à la portée convenue.
3. Envoyez l'intégralité du dossier package à Deque dans sa structure d'origine (n'envoyez pas seulement des fichiers individuels).

Deque assignera la version, emballera le paquet, le mappant à la bonne version axe-core, et le déploiera dans une instance de test pour vérification. Après que votre équipe ait vérifié les modifications sur l'instance de test et donné son approbation, Deque promeut la méthodologie sur votre instance production.

Support

Pour des questions concernant ce processus, la portée du changement convenu, ou pour demander un soutien linguistique supplémentaire, contactez votre point de contact Deque.