Configuration d'axe DevTools Linter

Link to Configuration d'axe DevTools Linter copied to clipboard

Un guide de référence pour la configuration d'axe DevTools Linter

Free Trial
Not for use with personal data

Cet article fournit une référence pour les options de configuration d'axe DevTools Linter.

Aperçu

Le point de terminaison de l'API REST utilise JSON pour la configuration, et l'extension axe Accessibility Linter pour VS Code, le plugin JetBrains et le connecteur axe DevTools Linter utilisent YAML pour la configuration. Des exemples JSON et YAML de configurations d'axe DevTools Linter sont présentés dans ce guide.

Exemples de configurations

L'exemple YAML suivant illustre une configuration simple qui utilise l'option pour l'extension axe Accessibility Linter pour VS Code, le plugin JetBrains ou axe DevTools Linter Connector : rules

rules:
  html-has-lang: false

L'exemple suivant illustre la même configuration qu'un objet de requête complet avec l'option pour le service REST axe DevTools Linter avec son objet intégré mis en surbrillance : rules config

{
  "source": "<html></html>",
  "filename": "file.html",
  "config": {    "rules": {      "html-has-lang": false    },    "exclude": [],
    "tags": []
  }
}

Dans les deux cas, ces configurations font qu'axe DevTools Linter ignore les erreurs d'accessibilité lorsque l'élément manque un attribut. html lang (Voir la règle html-has-lang pour plus d'informations.)

note

Pour tous les exemples JSON de cet article, l'objet est inclus pour fournir un emplacement de référence pour la configuration. config

Les sections suivantes décrivent chaque option de configuration et donnent des exemples de leur utilisation.

Plusieurs fichiers de configuration

L'extension axe Accessibility Linter pour VS Code, le plugin JetBrains et le axe DevTools Linter Connector (lorsqu'il est utilisé avec l'option --config sans paramètre) rechercheront dans le répertoire actuel et les répertoires parents les axe-linter.yml fichiers de configuration dans l'arborescence de votre projet et utiliseront le premier qu'ils trouvent. Une pratique utile consiste à placer un fichier de configuration à la racine de votre projet contenant votre configuration par défaut et à le remplacer (si nécessaire) par des fichiers de configuration dans différents sous-répertoires. Vous pouvez également placer un fichier de configuration dans votre répertoire personnel qui sera utilisé par défaut s'il n'y a pas de fichiers de configuration dans votre projet.

Les étapes utilisées pour localiser les fichiers de configuration sont : axe-linter.yml

  1. Utilisez le fichier de configuration dans le répertoire actuel (le répertoire contenant le fichier en cours d'édition avec VS Code, un IDE JetBrains ou le répertoire actuel de l'invite de commande avec axe DevTools Linter Connector).

  2. Si aucune configuration n'est trouvée à l'étape 1, recherchez les répertoires parents jusqu'à ce qu'un fichier de configuration soit trouvé, en vous arrêtant dans votre dossier personnel si le projet se trouve dans l'arborescence de votre répertoire personnel ou dans le répertoire racine s'il se trouve en dehors de votre dossier personnel. axe-linter.yml

  3. Utilisez un fichier de configuration situé dans votre répertoire personnel (même si votre projet est situé dans un répertoire en dehors de votre dossier personnel ou sur un autre lecteur sous Windows). axe-linter.yml Par exemple, voici les fichiers typiquement utilisés :

    • /home/username/axe-linter.yml (Linux)
    • /Utilisateurs/username/axe-linter.yml (macOS)
    • C:\Users\username\axe-linter.yml (Windows)

La recherche s'arrête lorsque le premier axe-linter.yml fichier est trouvé.

Résumé de la configuration d'axe DevTools Linter

Produit Type de configuration Description
Extension axe Accessibility Linter pour VS Code ou le plugin JetBrains Un ou plusieurs fichiers YAML nommés axe-linter.yml Voir Configurations multiples.
axe Linter Connector Un ou plusieurs fichiers YAML nommés axe-linter.yml Suivez les étapes de Configurations multiples lorsqu'il est utilisé avec l'option sans paramètre --config .
axe Linter Connector Un fichier YAML nommé nom de fichier Lorsqu'il est utilisé avec --config nom de fichier.
API REST axe Linter Objet de configuration JSON Voir l'objet config.

Options de Configuration

element

L'option element vous permet de modifier l'élément émis en fonction de la valeur d'attribut spécifiée de votre composant. Par exemple, vous pouvez faire en sorte qu'un composant personnalisé émette un img élément dans certains cas et un button élément dans d'autres cas, permettant ainsi des cas d'utilisation plus complexes.

L'exemple de configuration ci-dessous spécifie que l'attribut sur le composant peut modifier l'élément émis par défaut de as my-button button:

YAML :

global-components:
  my-button:
    element: button
    attributes:
      - as: <element>

JSON :

{
  "config": {
    "global-components": {
      "my-button": {
        "element": "button",
        "attributes": [
          {
            "as": "<element>"
          }
        ]
      }
    }
  }
}

L'exemple d'utilisation ci-dessous émet un élément img au lieu de l'élément par défaut button car l'attribut spécifie l'élément de sortie as :

<my-button as="img"></my-button>

L'élément de sortie img sera ensuite analysé et il sera constaté qu'il manque un attribut alt .

exclude

L'option exclude empêche l'analyse des fichiers correspondants. Vous pouvez utiliser des caractères génériques et des globs. Son utilisation est principalement destinée à l'extension VS Code ou au plugin JetBrains et est ignorée par le point de terminaison REST.

exclude: *.tmp

global-components

L'option de configuration indique à axe DevTools Linter comment mapper vos propres composants personnalisés ou des composants de bibliothèques tierces vers des éléments HTML natifs, vous permettant ainsi de linter vos composants comme s'il s'agissait d'éléments HTML natifs. global-components Par exemple, la configuration suivante traitera tous les composants personnalisés comme s'ils étaient des éléments HTML natifs. DqButton button Cela mappe automatiquement chaque attribut de DqButton à button, nécessitant ainsi un nom accessible pour tous les composants DqButton .

YAML :

global-components:
  DqButton: button

JSON :

{
  "config": {
    "global-components" {
      "DqButton": "button"
    }
  }
}

Alternativement, pour les composants qui ne mappent pas tous les attributs aux composants HTML natifs, vous pouvez répertorier les attributs requis pour la conformité d'accessibilité à l'aide de l'option attributes . Vous pouvez répertorier les attributs pris en charge par le composant ainsi que renommer les attributs. Il existe trois valeurs spéciales :

  • La valeur aria-* indique à axe DevTools Linter que tous les attributs commençant par aria- sont mappés à l'élément HTML natif tel quel. Notez que la valeur se termine par un astérisque.
  • La valeur <text> indique à axe DevTools Linter qu'une propriété est utilisée pour définir le contenu (la valeur entre les balises d'ouverture et de fermeture) de l'élément HTML natif.
  • La valeur <element> indique à axe DevTools Linter que l'élément émis peut prendre la valeur de cet attribut, ce qui vous permet de modifier l'élément émis en fonction de la valeur de l'attribut spécifié.

L'exemple YAML suivant montre toutes les valeurs qui peuvent être utilisées avec global-components :

global-components:
  DqButton:
    element: button
    # Ignore all attributes on <DqButton> except the following:
    attributes:
      - role # Map the role attribute from <DqButton /> to <button />
      - aria-* # Map all attributes starting with aria-
      - action: type # <DqButton action="submit" /> maps to <button type="submit" />
      - label: <text> #  <DqButton label="ABC" /> emits <button>ABC</button>
      - as: <element> # <DqButton as="img" /> emits <img> instead of <button>. (You don't have to use *as* for the attribute name.)

Une version JSON équivalente (à l'intérieur de l'objet) est la suivante : config

{
  "config": {
    "global-components": {
      "DqButton": {
        "element": "button",
        "attributes": [
          "role",
          "aria-*",
          {
            "action": "type"
          },
          {
            "label": "<text>"
          },
          {
            "as": "<element>"
          }
        ]
      }
    }
  }
}    

Seuls les attributs pertinents pour l'accessibilité doivent figurer dans la attributes liste. Les noms des éléments sont sensibles à la casse. La casse camel, comme indiqué ci-dessus, est couramment utilisée avec les fichiers .jsx, mais la casse kebab (qui est utilisée dans Vue, Angular et les éléments personnalisés HTML) peut être utilisée.

Pour des procédures pas à pas montrant comment utiliser le mappage de composants personnalisés, voir Linting Custom Components.

global-libraries

Axe DevTools Linter dispose d'un support intégré pour plusieurs bibliothèques de composants et frameworks populaires.

Les bibliothèques suivantes sont actuellement prises en charge :

  • react-native
  • @mui/material
  • @deque/cauldron-react

Pour activer le linting des composants de la bibliothèque, ajoutez le nom du package NPM de la bibliothèque au tableau des fichiers de configuration YAML : global-libraries

global-libraries:
  - '@mui/material'
  - '@deque/cauldron-react'
  - react-native
note

Vous devez mettre entre guillemets @mui/material et @deque/cauldron-react dans YAML car @ est interprété comme un caractère réservé.

Ou la configuration JSON équivalente est affichée ci-dessous :

{
  "config": {
    "global-libraries": [
      "@mui/material"
    ]
  }
}

Tout composant portant le même nom qu'un composant de la bibliothèque globale sera traité comme ce composant de la bibliothèque, ce qui permet de réexporter et de redéclarer les composants sans perdre leur mappage.

Pour plus d'informations, voir Bibliothèques de composants préconfigurés.

overrides

Vous pouvez modifier la façon dont axe DevTools Linter est configuré par fichier en utilisant l'option de configuration. overrides Les overrides multiples sur le même fichier sont résolus dans l'ordre. Autrement dit, le dernier override répertorié a la priorité la plus élevée.

Actuellement, seul le remplacement est pris en charge et est utilisé pour modifier le linter utilisé sur les fichiers correspondants. linter

overrides:
  - files: # An array or single string of filename(s) or glob pattern(s) that match this override setting
      - vue/**/*.html
    linter: vue # Specify that all files that match the pattern should be linted as Vue
  - files: php/**/*.html
    linter: null # Disable axe-linter for these files

rules

Vous pouvez autoriser ou interdire des règles individuellement avec l'option rules dans votre configuration :

rules:
  some-rule: false # turn off rule
  other-rule: true # turn on rule

Ou dans l'objet config dans votre requête JSON REST :

{
  "config": {
    "rules": {
      "some-rule": false,
      "other-rule": true
    }
  }
}

Pour plus d'informations sur l'utilisation rules avec l'API REST, consultez La propriété règles. Si vous souhaitez l'utiliser rules avec le connecteur axe DevTools Linter, consultez Fichier de configuration. Pour voir les règles suivies par axe DevTools Linter, consultez Règles d'accessibilité. Voir tags ci-dessous pour plus d'informations sur l'utilisation de l'option tags pour exclure des collections de règles du traitement.

tags

Vous pouvez interdire les règles en tant que groupe en fonction de la norme WCAG à laquelle elles sont associées à l'aide de l'option : tags

tags: # Disallow all rules other than WCAG 2.1 A, WCAG 2.1 AA, and best practices.
  - wcag21a
  - wcag21aa
  - best-practices

Voir aussi