Ensembles de règles personnalisés

Un ensemble de règles personnalisé est un fichier JSON généré qui est transmis à axe.configure afin de contrôler la manière dont axe teste votre page. Il peut modifier la manière dont les règles existantes fonctionnent, par exemple en les désactivant ou en modifiant leur impact, ou peut être utilisé pour créer des règles entièrement nouvelles.

Voici quelques-unes des choses que vous pouvez faire avec des ensembles de règles personnalisés :

• Modifier la règle ou changer l'impact.
• Désactiver les règles.
• Créer de nouvelles règles pour tester la politique d'accessibilité de votre organisation.
• Limiter les solutions autorisées pour les éléments. Par exemple, ne pas autoriser l'attribut title à donner à un élément <img> un nom accessible.
• Modifier le contraste minimal dans la règle de contraste des couleurs.
• Mettre à jour les rôles et propriétés ARIA pris en charge.

La commande « ruleset » a le format suivant :

axe ruleset [options]

Options

-c, --custom <path>

Générer un ensemble de règles personnalisé à partir d'un changes.json fichier dans le répertoire actuel ou à partir du chemin spécifié.

-d, --destination <path>

Répertoire de sortie pour le fichier JSON du jeu de règles

-t, --tags <list>

Liste de [tags] séparés par des virgules(https://github.com/dequelabs/axe-core/blob/develop/doc/API.md#axe-core-tags) qui seront utilisés pour filtrer les ensembles de règles standard

-f, --format [format]

Format de sortie (js ou json) pour le fichier JSON du jeu de règles

-l, --log

Générer une liste de toutes les règles incluses dans les ensembles de règles générés.

-x, --désactiver-autres-règles {#-x---désactiver-autres-règles}

Désactive toutes les règles non incluses dans la propriété « rules » du fichier « changes.json » ou du répertoire « rules ».

-a, --axe-source <path>

Chemin vers un fichier source de axe personnalisé

--508 [nom de fichier]

Générer une configuration standard pour les règles de la section 508.

--en301549 [nom de fichier]

Générer une configuration standard pour les règles EN 301 549.

--ttv5 [nom de fichier]

Générer une configuration standard pour les règles Trusted Tester v5.

--wcag2 [nom de fichier]

Générer une configuration standard pour les directives WCAG 2.0.

--wcag21 [nom de fichier]

Générer une configuration standard pour les directives WCAG 2.1.

--wcag22 [nom de fichier]

Générer une configuration standard pour les directives WCAG 2.2.

--wcag2aaa [nom de fichier]

Générer une configuration standard pour les directives WCAG 2.0 Niveau AAA.

--wcag21aaa [nom de fichier]

Générer une configuration standard pour les directives WCAG 2.1 Niveau AAA.

--wcag22aaa [nom de fichier]

Générer une configuration standard pour les directives WCAG 2.2 Niveau AAA.

--all [nom de fichier]

Générer une configuration standard pour toutes les directives (508, WCAG 2 et WCAG 2.1).

--seulement-changements

Générez uniquement les modifications et les ajouts à l'ensemble de règles et non la configuration complète.

Génération d'un ensemble de règles personnalisé

Pour générer un ensemble de règles personnalisé, vous aurez besoin d'un fichier « changes.json », soit dans le répertoire actuel, soit dans le chemin spécifié par l'option « --custom ».

Le fichier changes.json a le même format que l'objet passé à axe.configure. Dans le fichier, vous pouvez spécifier les modifications apportées aux règles et contrôles de axe actuel, ainsi que toutes les nouvelles règles ou contrôles.

Par exemple, si vous souhaitez modifier l'impact de la règle pour qu'il soit valid-lang au lieu de minor , le fichier seriousressemblera à ce qui suit : changes.json

{
    "rules": [{
        "id": "valid-lang",
        "impact": "minor"
    }]
}

Utilisation des répertoires de règles et de contrôles

Si vous le souhaitez, vous pouvez également séparer les nouvelles règles et vérifications dans leurs propres répertoires (nommés rules et checks respectivement). Chaque règle ou contrôle doit être son propre fichier JSON dans son répertoire respectif. Cela ne modifie pas la sortie du fichier JSON généré, mais constitue simplement un moyen pratique d'organiser plusieurs règles et vérifications personnalisées au lieu de les répertorier toutes dans le changes.json fichier.

Par exemple, pour créer une nouvelle règle personnalisée appelée h1-no-duplicate qui vérifie s'il y a plus d'un <h1> élément sur la page, vous pouvez avoir la structure de répertoire suivante :

directory
 ├ changes.json
 ├ rules
 │  └ h1-no-duplicate.json
 └ checks
    └ page-no-duplicate-h1.json

Le h1-no-duplicate.json fichier de métadonnées de règle définirait la règle personnalisée et les vérifications à utiliser :

{
    "id": "h1-no-duplicate",
    "selector": "h1:not([role]), [role=heading][aria-level=1]",
    "tags": ["cat.semantics", "best-practice"],
    "metadata": {
        "description": "Ensures the document has at most one h1 element",
        "help": "Document must not have more than one h1 element"
    },
    "all": [],
    "any": ["page-no-duplicate-h1"],
    "none": []
}

Le page-no-duplicate-h1.json fichier de métadonnées de vérification définirait la vérification personnalisée et la méthode d' evaluate axe à utiliser :

{
    "id": "page-no-duplicate-h1",
    "evaluate": "page-no-duplicate-evaluate",
    "after": "page-no-duplicate-after",
    "options": {
        "selector": "h1:not([role]), [role=heading][aria-level=1]"
    },
    "metadata": {
        "impact": "moderate",
        "messages": {
            "pass": "Document does not have more than one h1 element",
            "fail": "Document has more than one h1 element"
        }
    }
}

Enfin, comme il n'y a pas de changements aux règles ou aux contrôles actuels, le changes.json fichier serait un objet vide :

{}

Après avoir exécuté la commande axe ruleset --custom , le fichier JSON généré ressemblerait à ceci :

{
    "rules": [{
        "id": "h1-no-duplicate",
        "selector": "h1:not([role]), [role=heading][aria-level=1]",
        "tags": ["cat.semantics", "best-practice"],
        "metadata": {
            "description": "Ensures the document has at most one h1 element",
            "help": "Document must not have more than one h1 element"
        },
        "all": [],
        "any": ["page-no-duplicate-h1"],
        "none": []
    }],
    "checks": [{
        "id": "page-no-duplicate-h1",
        "evaluate": "page-no-duplicate-evaluate",
        "after": "page-no-duplicate-after",
        "options": {
            "selector": "h1:not([role]), [role=heading][aria-level=1]"
        },
        "metadata": {
            "impact": "moderate",
            "messages": {
                "pass": "Document does not have more than one h1 element",
                "fail": "Document has more than one h1 element"
            }
        }
    }]
}

Utilisation d'un ensemble de règles personnalisées

Il existe trois manières de configurer des règles personnalisées dans axe DevTools.

• explicitement : cela diffère selon les packages, pour la CLI, utilisez le drapeau --custom .

• variable d'environnement : s'il existe une AXE_RULESET_PATH variable d'environnement définie, axe DevTools la chargera comme ensemble de règles par défaut.

• fichier local : s'il existe un axe-ruleset.json fichier dans le répertoire où axe s'exécute, il sera utilisé comme ensemble de règles par défaut.

Si aucun de ces éléments n'est spécifié, ou si axe DevTools n'est pas en mesure de charger le fichier défini, le jeu de règles par défaut wcag2 sera utilisé à la place.

Support

La création d'ensembles de règles personnalisés nécessite une connaissance approfondie d'axe-core. Pour plus de détails, consultez la documentation de l'API axe-core. Si vous souhaitez obtenir de l'aide pour créer et maintenir votre ensemble de règles personnalisé, contactez votre représentant Deque.