Configuration d'axe DevTools Linter
Un guide de référence pour la configuration d'axe DevTools Linter
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.)
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
-
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).
-
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
-
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
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
- Pour une référence aux API REST fournies par axe DevTools Linter, voir Référence de l'API REST axe DevTools Linter.
- Pour des procédures pas à pas pour la création de mappages de composants personnalisés, voir Linting Custom Components.
- Pour télécharger l'extension pour VS Code, voir axe Accessibility Linter.
- Pour plus d'informations sur le plugin JetBrains, consultez Utilisation du plugin avec les IDE JetBrains.