Prise en charge de la méthodologie personnalisée

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

Objectif

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

• Politiques internes spécifiques nécessitant des vérifications supplémentaires ou moins nombreuses.
• 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 renvoyées à Deque pour être emballées et déployées sur votre instance hébergée.

Comment cela fonctionne : Rôles et flux de travail

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, la séquence 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 construire 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 le périmètre : Ce document répertorie tous les types de personnalisations disponibles pour l'exhaustivité. Les changements spécifiques que votre équipe effectuera doivent s'aligner sur le périmètre de changement convenu.

Avant de commencer

1. Sauvegardez l'original. Avant de modifier quoi que ce soit, faites une copie du dossier package extrait. Si une modification casse le paquet, c'est votre seul moyen propre pour 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 une modification donnée — ou en manquer un qui est listé — peut produire un paquet qui échoue seulement après son retour à 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, accolades/crochets équilibrés). Validez avant d'envoyer :

# 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 de langue. Ces instructions partent du principe que l'anglais (en). Si votre organisation nécessite une méthodologie dans des langues supplémentaires, informez Deque — Deque permet la prise en charge des langues lors de la configuration. Dans ce cas, chaque modification que vous apportez dans un fichier .en.json doit également être faite dans le fichier local 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. Apportez les mises à jour appropriées à tout type de ressource répertorié 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 changer le niveau d'impact (bloquant, critique, sérieux, modéré, mineur) pour chaque problème au sein d'axe Auditor. Cependant, si vous devez changer l'impact défaut pour une règle, suivez ces instructions.

Les impacts dans axe Auditor sont stockés au niveau règle, pas au niveau d'un critère de succès WCAG ou d'un point 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 pour un problème déclenché par la violation de cette règle sur tout critères de succès WCAG lié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.

Correspondance des valeurs d'impact

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

Si vous avez des 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 véritablement distincts fichiers compilés, ou s'il s'agit d'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 la norme dans standards.json. L'approche la plus simple est de copier l'objet entier pour wcag21aa et de l'ajouter au bas du fichier.
2. Changez le id du nouvel objet copié pour quelque chose d'unique qui signifie la norme 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 cette nouvelle norme.
4. Dans descriptions.json, pour toutes les règles associées à votre nouvelle norme, ajoutez l'identifiant de la nouvelle norme (de standards.json) au tableau standards.
5. Dans testingMethodologies.json, ajoutez l'identifiant de la nouvelle norme sous le tableau standards pour chaque type de ressource numérique auquel cette norme s'applique.
6. Dans standards.en.json, ajoutez un nouvel objet avec l'identifiant et le nom de la nouvelle norme. Le champ name est ce que les utilisateurs voient dans l'interface utilisateur d'axe Auditor.
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 la norme correcte.

Mettre à jour les descriptions des problèmes courte et longue 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 succès WCAG — le changement de ce texte affecte tout critères de succès auxquels elle est liée.

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

Étapes :

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

Mettre à jour la recommandation de remédiation

Si vous souhaitez changer la bibliothèque de remédiation et les descriptions associées pour les aligner avec 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 souhaitez 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 de ressources numériques

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

Fichiers à mettre à jour :

• dist/bundle/testingMethodologies.json — données des méthodologies de test principales
• 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'objet entier 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 localisation en anglais

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

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

Ajouter un nouveau type de ressource numérique

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

Fichiers à mettre à jour :

• dist/bundle/testingMethodologies.json — données des méthodologies de test principales
• dist/bundle/locales/testingMethodologies.en.json — traductions anglaises
• dist/bundle/locales/checkpoints.en.json — contenu des points de contrôle anglais avec sections de méthodologie de test
• dist/bundle/checkpoints.json — données principales des points de contrôle
• dist/bundle/descriptions.json — descriptions des problèmes avec références aux méthodologies de test
• dist/bundle/schemata.json — définitions de schéma 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 localisation en anglais

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

Ajoutez le même objet de méthodologie à ce fichier.

Étape 3 : Ajouter des références au fichier de points de contrôle

Fichier : dist/bundle/checkpoints.json

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

{
  "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 : Ajouter le contenu de la méthodologie de test au fichier de localisation du point de contrôle

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

Pour chaque point de contrôle qui doit prendre en charge la nouvelle méthodologie, ajoutez le contenu de la méthodologie 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 : Ajouter 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-la à leur tableau testingMethodologies.

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

Étape 6 : Ajouter des références au fichier de schéma

Fichier : dist/bundle/schemata.json

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

{
  "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 point de contrôle

Ajout d'un point de contrôle non-WCAG

Important : Les points de contrôle non-WCAG ne pas supportent pas les descriptions ou recommandations prédéfinies via descriptions.json et recommendations.json. Lors de l'enregistrement des problèmes avec ces points de contrôle, vous saisissez 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 point de contrôle
• package/dist/bundle/locales/checkpoints.en.json — fournir des méthodologies de test localisées

Étape 1 : Ajouter le point de contrôle à 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 exemple, custom.1.1, brand.2.3, TT.01.A, s.1.1).
• successCriteria — chaîne vide "" pour les points de contrôle non-WCAG (ou un format personnalisé comme "tt-01.A").
• standards — votre identifiant de standard personnalisé, par exemple, ["custom"], ["TT508"], ["smoke"], ["brand"] (pas ["wcag2a"]).
• testingMethodologies — plateformes où ce point de contrôle s'applique : desktop, mobile, kiosk, native-mobile-ios, native-mobile-android, pdf, windows-desktop, ms-excel, ms-powerpoint, ms-word.
• requiredSenses — quel sens est nécessaire pour tester ce point de contrôle (sight, hearing : true/false).
• automatedRules — tableau optionnel des identifiants de règles automatisées (typiquement vide [] pour les points de contrôle personnalisés).
• grouping — regroupement logique pour l'organisation (par exemple, "custom.1", "1", "s.1").
• categories — catégories d'accessibilité pertinentes (peut être vide [] pour les non-WCAG).
• terms — tableau optionnel des références de termes de glossaire avec propriétés id et ordinal.

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

Utilisez le format d'id trait d'union : convertissez les points en traits d'union (par exemple, 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 sauts de ligne et les balises HTML appropriées pour les listes.

Ajouter un point de contrôle WCAG

Fichiers à mettre à jour — 6 fichiers pour une mise en œuvre complète d'un point de contrôle WCAG :

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

Optionnel — saisie manuelle : Si vous préférez ne pas ajouter de descriptions et recommandations prédéfinies aux fichiers JSON, vous pouvez les traiter lors de la journalisation 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 trouvé.

É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 succès WCAG (par exemple, "1.4.3").
• standards — "wcag2a" (Niveau A), "wcag2aa" (Niveau AA), ou "wcag2aaa" (Niveau AAA).
• automatedRules — tableau des ids de règles automatisées.
• grouping — numéro de la 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és

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'id 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 voulez pas que votre équipe teste et établisse un rapport sur un point de contrôle spécifique.

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'intégralité 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 dans la règle tout en maintenant un JSON valide. Une règle unique 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 tous les objets associés à 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'intégralité 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 tous les objets associés à 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 terminées et validées :

1. Confirmez que chaque fichier modifié passe encore 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 uniquement des fichiers individuels).

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

Support

Pour toute question concernant ce processus, la portée des changements convenus ou pour demander un support linguistique supplémentaire, contactez votre point de contact chez Deque.