Free Trial

Konfiguration von Axe DevTools Linter

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

Ein Referenzhandbuch zur Konfiguration von Axe DevTools Linter

Free Trial
Not for use with personal data

Dieser Artikel bietet eine Referenz für die Konfigurationsoptionen des Axe DevTools Linter.

Überblick

Der REST-API-Endpunkt verwendet JSON zur Konfiguration, und der Axe Accessibility Linter-Erweiterung für VS Code, das JetBrains-Plugin und der Axe DevTools Linter Connector verwenden YAML zur Konfiguration. Sowohl JSON- als auch YAML-Beispiele für Axe DevTools Linter-Konfigurationen werden in diesem Leitfaden gezeigt.

Beispielkonfigurationen

Das folgende YAML-Beispiel zeigt eine einfache Konfiguration, die die rules-Option für die Verwendung mit der Axe Accessibility Linter-Erweiterung für VS Code, dem JetBrains-Plugin oder dem Axe DevTools Linter Connector nutzt:

rules:
  html-has-lang: false

Das folgende Beispiel zeigt dieselbe Konfiguration als komplettes Anforderungsobjekt mit der rules-Option für den Axe DevTools Linter REST-Dienst mit seinem hervorgehobenen eingebetteten config-Objekt:

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

In beiden Fällen führen diese Konfigurationen dazu, dass der Axe DevTools Linter Barrierefreiheitsfehler ignoriert, wenn das html-Element ein lang-Attribut fehlt. (Siehe die html-has-lang-Regel für weitere Informationen.)

note

Für alle JSON-Beispiele in diesem Artikel ist das config-Objekt enthalten, um eine Referenzposition für die Konfiguration bereitzustellen.

Die folgenden Abschnitte beschreiben jede Konfigurationsoption und geben Beispiele für deren Verwendung.

Suchreihenfolge der Konfigurationsdatei

Die Axe Accessibility Linter-Erweiterung für VS Code, das JetBrains-Plugin und der Axe DevTools Linter Connector (wenn mit der --config-Option ohne Parameter verwendet) durchsuchen das aktuelle Verzeichnis und übergeordnete Verzeichnisse nach einer axe-linter.yml-Konfigurationsdatei in Ihrer Projektverzeichnisstruktur und verwenden die erste, die sie finden. Eine nützliche Praxis ist es, eine Konfigurationsdatei im Hauptverzeichnis Ihres Projekts zu platzieren, die Ihre Standardkonfiguration enthält, und sie bei Bedarf mit Konfigurationsdateien in verschiedenen Unterverzeichnissen zu ersetzen. Sie können auch eine Konfigurationsdatei in Ihrem Home-Verzeichnis platzieren, die standardmäßig verwendet wird, wenn keine Konfigurationsdateien in Ihrem Projekt vorhanden sind.

important

Konfigurationsdateien werden nicht zusammengeführt. Die erste gefundene wird verwendet.

Die Schritte zum Auffinden der zu verwendenden axe-linter.yml-Konfigurationsdatei sind:

  1. Verwenden Sie die Konfigurationsdatei im aktuellen Verzeichnis (das Verzeichnis, das die Datei enthält, die mit VS Code, einer JetBrains-IDE oder das aktuelle Verzeichnis im Befehlsfenster mit Axe DevTools Linter Connector bearbeitet wird).

  2. Wenn in Schritt 1 keine Konfiguration gefunden wird, durchsuchen Sie die übergeordneten Verzeichnisse, bis eine axe-linter.yml-Konfigurationsdatei gefunden wird. Stoppen Sie in Ihrem Home-Ordner, wenn sich das Projekt in Ihrem Home-Verzeichnisbaum befindet, oder im Root-Verzeichnis, wenn es sich außerhalb Ihres Home-Ordners befindet.

  3. Verwenden Sie eine axe-linter.yml-Konfigurationsdatei in Ihrem Home-Verzeichnis (auch wenn sich Ihr Projekt in einem Verzeichnis außerhalb Ihres Home-Ordners oder auf einem anderen Laufwerk unter Windows befindet). Beispielsweise sind dies die typischen verwendeten Dateien:

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

Die Suche wird beendet, sobald die erste axe-linter.yml-Datei gefunden wird.

Zusammenfassung der Konfiguration von Axe DevTools Linter

Produkt Art der Konfiguration Beschreibung
Axe Accessibility Linter-Erweiterung für VS Code oder das JetBrains-Plugin Eine YAML-Datei namens axe-linter.yml Siehe Suchreihenfolge der Konfigurationsdatei.
Axe Linter Connector Eine YAML-Datei namens axe-linter.yml Befolgt die Schritte in Suchreihenfolge der Konfigurationsdatei, wenn mit der --config-Option ohne Parameter verwendet.
Axe Linter Connector Eine YAML-Datei namens Dateiname Wenn verwendet mit --config Dateiname.
Axe Linter REST API JSON-Konfigurationsobjekt Siehe Das Konfigurationsobjekt.

Konfigurationsoptionen

element

Die element-Option ermöglicht es Ihnen, das emittierte Element basierend auf dem angegebenen Attributwert Ihrer Komponente zu ändern. Beispielsweise könnten Sie eine benutzerdefinierte Komponente haben, die in bestimmten Fällen ein img-Element und in anderen Fällen ein button-Element erzeugt, was komplexere Anwendungsfälle ermöglicht.

Die folgende Konfiguration legt fest, dass das as-Attribut auf der my-button-Komponente das emittierte Element vom Standardwert button ändern kann:

YAML:

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

JSON:

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

Die folgende Verwendung gibt ein img-Element anstelle des standardmäßigen button-Elements aus, weil das as-Attribut das Ausgabeelement angibt:

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

Das Ausgabe-img-Element wird dann geprüft und es wird festgestellt, dass ihm ein alt-Attribut fehlt.

exclude

Die exclude-Option verhindert, dass übereinstimmende Dateien geprüft werden. Sie können Wildcards und Globs verwenden. Ihre Verwendung ist hauptsächlich für die VS Code-Erweiterung oder das JetBrains-Plugin gedacht und wird vom REST-Endpunkt ignoriert.

exclude: *.tmp

enterpriseId

Das optionale enterpriseId-Feld akzeptiert einen String, der an Nutzungsanalytik-Ereignisse für Unternehmensattribution angehängt wird. Die meisten Benutzer müssen diesen Wert nicht festlegen; möglicherweise wird er von Ihrem Deque-Ansprechpartner angefordert. Dieses Feld wird bei Vor-Ort-Implementierungen ignoriert.

enterpriseId: 'acme-corp'

global-components

Die global-components-Konfigurationsoption gibt dem Axe DevTools Linter an, wie Ihre eigenen benutzerdefinierten Komponenten oder Komponenten von Drittanbieterbibliotheken in native HTML-Elemente abgebildet werden, sodass Sie Ihre Komponenten so prüfen können, als wären sie native HTML-Elemente. Zum Beispiel behandelt die folgende Konfiguration alle benutzerdefinierten DqButton-Komponenten, als wären sie native HTML-button-Elemente. Dies weist automatisch jedes Attribut auf DqButton button zu, wodurch ein zugänglicher Name für alle DqButton-Komponenten erforderlich wird.

YAML:

global-components:
  DqButton: button

JSON:

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

Alternativ können Sie für Komponenten, die nicht alle Attribute auf native HTML-Komponenten abbilden, die für die Barrierefreiheitskonformität erforderlichen Attribute mit der attributes-Option auflisten. Sie können die unterstützten Attribute der Komponente auflisten und auch Attribute umbenennen. Es gibt drei spezielle Werte:

  • Der aria-*-Wert teilt dem Axe DevTools Linter mit, dass alle Attribute, die mit aria- beginnen, unverändert auf das native HTML-Element abgebildet werden. Beachten Sie, dass der Wert mit einem Stern endet.
  • Der <text>-Wert teilt dem Axe DevTools Linter mit, dass eine Eigenschaft verwendet wird, um den Inhalt (den Wert zwischen dem offenen und geschlossenen Tag) des nativen HTML-Elements festzulegen.
  • Der <element>-Wert teilt dem Axe DevTools Linter mit, dass das emittierte Element den Wert dieses Attributs annehmen kann, was es ermöglicht, das emittierte Element abhängig vom Wert des angegebenen Attributs zu ändern.

Das folgende YAML-Beispiel zeigt alle Werte, die mit global-components verwendet werden können:

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.)

Eine gleichwertige JSON-Version (innerhalb des config-Objekts) sieht wie folgt aus:

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

Nur Attribute, die für die Barrierefreiheit relevant sind, müssen in der attributes-Liste stehen. Elementnamen unterscheiden zwischen Groß- und Kleinschreibung. CamelCase, wie oben gezeigt, wird häufig mit .jsx-Dateien verwendet, aber Kebab-Case (das in Vue, Angular und HTML-benutzerdefinierten Elementen verwendet wird) kann ebenfalls verwendet werden.

Für Anleitungen zur Verwendung der benutzerdefinierten Komponentenabbildung siehe Linting benutzerdefinierter Komponenten.

global-libraries

Axe DevTools Linter bietet integrierte Unterstützung für mehrere beliebte Komponentenbibliotheken und Frameworks.

Die folgenden Bibliotheken werden derzeit unterstützt:

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

Um die Linting-Bibliothek für Komponenten zu aktivieren, fügen Sie den NPM-Paketnamen der Bibliothek dem global-libraries-Array für YAML-Konfigurationsdateien hinzu:

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

Sie müssen @mui/material und @deque/cauldron-react in YAML in Anführungszeichen setzen, da @ als reserviertes Zeichen interpretiert wird.

Oder die äquivalente JSON-Konfiguration wird unten gezeigt:

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

Jede Komponente mit dem gleichen Namen wie eine Komponente aus der globalen Bibliothek wird als diese Bibliothekskomponente behandelt, was das erneute Exportieren und Umdeklarieren von Komponenten ohne Verlust ihrer Zuordnung ermöglicht.

Für weitere Informationen siehe Vorkonfigurierte Komponentenbibliotheken.

overrides

Sie können ändern, wie der Axe DevTools Linter dateiweise konfiguriert wird, indem Sie die overrides-Konfigurationsoption verwenden. Mehrere Überschreibungen auf derselben Datei werden in der Reihenfolge aufgelöst. Das heißt, die letzte aufgelistete Überschreibung hat die höchste Priorität.

Derzeit wird nur die linter-Überschreibung unterstützt und wird verwendet, um den Linter zu ändern, der auf die übereinstimmenden Dateien angewendet wird.

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

Sie können Regeln einzeln mit der rules-Option in Ihrer Konfiguration zulassen oder ablehnen. Jede Regel kann auf true (aktiviert, als Fehler gemeldet — Standard), false (deaktiviert) oder warn (aktiviert, als Warnung gemeldet) gesetzt werden:

rules:
  some-rule: false   # turn off rule
  other-rule: true   # turn on rule (default)
  color-contrast: warn  # report violations as warnings instead of errors

Oder im config-Objekt in Ihrer JSON-REST-Anfrage:

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

Für Informationen zur Verwendung von rules mit der REST-API siehe Die rules-Eigenschaft. Wenn Sie rules mit dem Axe DevTools Linter Connector verwenden möchten, siehe Konfigurationsdatei. Um die Regeln zu sehen, die der Axe DevTools Linter befolgt, siehe Barrierefreiheitsregeln. Weitere Informationen zur Verwendung der tags-Option, um Sammlungen von Regeln von der Verarbeitung auszuschließen, siehe unten Tags.

Zum Unterdrücken von Regeln für bestimmte Zeilen in einer Quelldatei ohne Änderung dieser Konfigurationsdatei siehe Unterdrücken von Linting-Regeln mit Inline-Direktiven.

tags

Sie können Regeln als Gruppe basierend auf dem WCAG-Standard, mit dem sie verknüpft sind, mithilfe der tags-Option ablehnen:

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

Siehe auch

Is this page helpful?

Help us improve this page

Still need help?