Support pour la méthodologie personnalisée

This page is not available in the language you requested. You have been redirected to the English version of the page.

Link to this page copied to clipboard

Not for use with personal data

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 résulter de :

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

Ce document décrit les personnalisations pouvant être apportées à la méthodologie de test manuel dans axe Auditor et explique comment ces modifications sont retransmises à Deque pour l'emballage et le déploiement 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 l'édition 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 packages 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 :

Étape	Propriétaire	Action
1	Deque	Fournit à votre équipe le package actuel de méthodologie (DequeWay).
2	Client	Extrait le package à un emplacement de travail, produisant un dossier nommé `package`.
3	Client	Sauvegarde le dossier `package` original avant d'effectuer des modifications.
4	Client	Effectue les modifications de méthodologie convenues selon les sections ci-dessous.
5	Client	Valide les fichiers JSON modifiés (voir Avant de commencer).
6	Client	Renvoie l'intégralité du dossier `package` à Deque, dans la même structure qu'il a été fourni.
7	Deque	Versionne, emballe, et mappe la méthodologie à la bonne version d'axe-core, et la déploie sur une instance de test pour vérification.
8	Client	Vérifie les modifications sur l'instance de test et confirme la validation.
9	Deque	Promeut la méthodologie vérifiée sur votre instance production.

Note sur l'étendue : Ce document liste tous les types de personnalisation disponibles pour completer les informations. Les modifications spécifiques que votre équipe apportera doivent être conformes à l'étendue des changements convenus.

Avant de commencer

1. Sauvegardez l'original. Avant d'éditer quoi que ce soit, faites une copie du dossier package décompressé. Si une modification casse le package, c'est votre seul moyen propre 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 manquer 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 format JSON et doit rester un JSON valide après modification (pas de virgules finales, des accolades et crochets équilibrés). 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 des langues supplémentaires, informez Deque — Deque active la prise en charge des langues 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 localisation 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 :

Trouvez le point de contrôle Deque spécifique dans le fichier JSON (par exemple, 1.1.1.a).
Recherchez l'attribut testing-methodology sous ce point de contrôle spécifique.
Faites les mises à jour appropriées pour tout type de ressources listé sous testing-methodology.
Enregistrez le fichier à son emplacement actuel.

Note : 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 pertinent 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 dans axe Auditor. Cependant, si vous devez changer l'impact par défaut pour une règle, suivez ces instructions.

Les impacts dans axe Auditor sont stockés au niveau règle, et non 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 exemple, 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 à travers tout Critères de Réussite WCAG associés à la règle.

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

Étapes :

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

Cartographie des valeurs d'impact

Valeur d'impact	Impact dans axe Auditor
5	Bloquant
4	Critique
3	Sérieux
2	Modéré
1	Mineur

Ajouter une nouvelle norme d'accessibilité (par exemple, une norme spécifique à l'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 réellement des fichiers compilés distincts, 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 :

Créez un nouvel objet tableau pour la norme dans standards.json. L'approche la plus simple est de copier l'objet entier pour wcag21aa et de l'ajouter à la fin du fichier.
Changez le id de l'objet nouvellement copié pour quelque chose d'unique qui signifie la norme qu'il représente.
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.
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.
Dans testingMethodologies.json, ajoutez l'identifiant de la nouvelle norme sous le tableau standards pour chaque type d'actif numérique auquel cette norme s'applique.
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.
Dans dist/checkpoints.json, mettez à jour le tableau standards sous chaque description de problème pour les points de contrôle applicables.
Dans issue-descriptions.json, mettez à jour le tableau standards pour tous les objets de règle applicables.
Dans dist/bundle/checkpoints.json, mettez à jour le tableau standards de chaque point de contrôle applicable avec la norme correcte.

Mettez à jour les descriptions de problème courtes et longues pour des règles spécifiques

Utilisez ces instructions pour mettre à jour le texte de sélection de description de problème (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 — modifier ce texte affecte tous critères de succès auxquels il est lié.

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

Étapes :

Dans descriptions.en.json, recherchez la règle spécifique (par exemple, alt-text-dynamic-image-inconsistent).
Mettez à jour le texte pour shortText (Description Courte du Problème) et issueDescText (Description Longue du Problème) selon le cas.
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 correspondre à votre politique, utilisez les instructions suivantes.

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

Étapes :

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 modifier la bibliothèque de remédiation.
Mettez à jour le texte pour recommendationType (Technique de Recommandation), rule, howtofix, et background (sections de la recommandation à corriger) selon le cas.
Enregistrez le fichier à son emplacement actuel.

Supprimer les types d'actifs numériques

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

Fichiers à mettre à jour :

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

Étape 1 : Retirer 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 : Retirer du fichier de la langue anglaise

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

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

Ajouter un nouveau type d'actif numérique

Utilisez cela 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 ; remplacez par votre propre identifiant de type d'actif, si nécessaire.

Fichiers à mettre à jour :

dist/bundle/testingMethodologies.json — données des principales méthodologies de test
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 à la méthodologie de test
dist/bundle/schemata.json — définitions de schéma avec références à la méthodologie 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 la langue anglaise

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

Fichier : dist/bundle/checkpoints.json

Pour chaque point de contrôle qui devrait supporter 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 local du point de contrôle

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

Pour chaque point de contrôle qui devrait supporter 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 devraient supporter 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 : 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

Ajouter 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 de problèmes avec ces points de contrôle, vous saisissez manuellement les descriptions et recommandations en utilisant la fonctionnalité Créer 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 une méthodologie de test localisée

É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 norme 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 — quels sens sont nécessaires pour tester ce point de contrôle (sight, hearing : true/false).
automatedRules — tableau optionnel d'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 le non-WCAG).
terms — tableau optionnel de références de termes du glossaire avec propriétés id et ordinal.

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

Utilisez le format d'identifiant tiret : convertissez les points en tirets (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 nouvelles lignes et les balises HTML appropriées pour les listes.

Ajouter un point de contrôle WCAG

Fichiers à mettre à jour — 6 fichiers pour une implémentation complète du point de contrôle WCAG :

package/dist/bundle/checkpoints.json — définissez le point de contrôle avec des champs spécifiques à WCAG.
package/dist/bundle/locales/checkpoints.en.json — méthodologie de test localisée, exemples, techniques connexes (utilisez le format d'identifiant avec tiret : 1-4-3-a, pas 1.4.3.a).
package/dist/bundle/descriptions.json — descriptions de problèmes avec niveaux d'impact et références de points de contrôle.
package/dist/bundle/locales/descriptions.en.json — descriptions de problèmes localisées.
package/dist/bundle/recommendations.json — recommandations de remédiation liées aux descriptions de problèmes.
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 des 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 critère de conformité WCAG, choisissez Créer votre propre description au lieu d'un prédéfini, puis saisissez manuellement la description et (si nécessaire) la recommandation adaptée au problème rencontré.

Étape 1 : Définir le critère

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 d'ID de règles automatisées.
grouping — Numéro de ligne directrice 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 tirets (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ème

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ème 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 tirets (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 critère spécifique

Utilisez ces instructions si vous ne souhaitez pas que votre équipe teste et rapporte sur un critère 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 :

Dans checkpoints.json, recherchez le critère spécifique (par exemple, 1.2.1.b). Supprimez l'objet entier associé à ce critère tout en conservant un JSON valide. Enregistrez le fichier.
Dans descriptions.json, recherchez le critère spécifique (par exemple, 1.2.1.b). Supprimez uniquement l'objet qui utilise le critère sous la règle tout en conservant un JSON valide. Une seule règle peut s'appliquer à plusieurs critères — supprimez uniquement l'objet pour le critère que vous retirez ; ne retirez pas la règle complète. Enregistrez le fichier.
Dans recommendations.json, recherchez le critère spécifique (par exemple, 1.2.1.b). Supprimez chaque objet associé à ce critère (il peut y en avoir plus d'un) tout en conservant un JSON valide. Enregistrez le fichier.
Dans checkpoints.en.json, recherchez le critère spécifique en utilisant le format avec tirets (par exemple, 1-2-1-b). Supprimez l'objet entier tout en conservant un JSON valide. Enregistrez le fichier.
Dans recommendations.en.json, recherchez le critère spécifique en utilisant le format avec tirets (par exemple, 1-2-1-b). Supprimez chaque objet associé à ce critère (il peut y en avoir plus d'un) tout en conservant un JSON valide. Enregistrez le fichier.

Envoyer les modifications à Deque

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

Confirmez que chaque fichier modifié passe toujours la validation JSON (voir Avant de commencer).
Confirmez que les modifications correspondent au périmètre convenu.
Renvoyez l'intégralité du dossier package à Deque dans sa structure d'origine (ne renvoyez pas seulement des fichiers individuels).

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

Support

Pour des questions concernant ce processus, le périmètre de modifications convenu, ou pour demander un support linguistique supplémentaire, contactez votre interlocuteur chez Deque.

Support pour la méthodologie personnalisée

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

Objectif

Comment cela fonctionne : rôles et flux de travail

Avant de commencer

Mises à jour autorisées

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

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

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

Mettez à jour les descriptions de problème courtes et longues pour des règles spécifiques

Mettez à jour la recommandation de remédiation

Supprimer les types d'actifs numériques

Ajouter un nouveau type d'actif numérique

Ajouter un nouveau point de contrôle

Ajouter un point de contrôle non-WCAG

Ajouter un point de contrôle WCAG

Supprimer un critère spécifique

Envoyer les modifications à Deque

Support

Is this page helpful?

Help us improve this page

Still need help?