Referenz für das Nutzungssicherungsereignis
Informationen über die Eigenschaften der Version 2 des Nutzungssicherungsereignisses
Dieser Artikel enthält Referenzinformationen über:
- Die Ereignisdaten, die an den Nutzungssicherungsdienst gesendet werden (Version 2 des Ereignisobjekts,
EventV2) - Sein enthaltenes
applicationProperties-Objekt - Das
testResults-Objekt (enthalten imapplicationProperties-Objekt), wennAXE_INCLUDE_TEST_RESULTSauftruegesetzt ist
Ereignis Version 2
Das folgende TypeScript-Interface definiert ein Ereignis der Version 2:
interface EventV2 {
version: 'v2'
productName: string
productComponent: string
productComponentVersion: string
event: string
dateTime: Date
keycloakId?: string
distinctId: string
userId?: string
organization?: string
department?: string
application?: string
devInstance?: boolean
sessionId?: string
userStatus?: string
loggedIn?: boolean
applicationProperties?: Record<string, any>
userJobRole?: string
actor?: 'human' | 'automation'
teams?: { id: string; name: string }[]
}| Name | Beschreibung |
|---|---|
| Akteur | Ob eine Person (human) oder ein automatisierter Ablauf (automation) den Test durchgeführt hat. Festgelegt durch die CLI, die Node.js-APIs und die Ruby-API. Siehe Akteur. |
| application | Die Anwendung, die dieses Ereignis erstellt hat |
| applicationProperties | applicationProperties unten definiert |
| dateTime | Datum und Uhrzeit (bis zur Millisekunde) im ISO-8601-Format, UTC-Zeitzone |
| department | Die Abteilung des Benutzers innerhalb der Organisation |
| devInstance | Ob diese Nutzung als Entwicklerinstanz betrachtet wird und wahrscheinlich herausgefiltert werden sollte |
| distinctId | Die eindeutige UUID des Benutzers |
| event | Ereignistyp als Zeichenkette, üblicherweise "analyze" oder "uri: analyze"-Werte |
| keycloakId | Die Keycloak-ID des Benutzers |
| loggedIn | Ob der Benutzer eingeloggt ist |
| organization | Die Organisation des Benutzers |
| productComponent | Von den APIs festgelegt, um verschiedene Integrationen wie Playwright anzuzeigen |
| productComponentVersion | Eine Zeichenkette, die die Version der Produktkomponente angibt |
| productName | Von den APIs festgelegt, um die verwendete Integration anzuzeigen |
| sessionId | Eine UUID zur Identifizierung der Sitzung (um Ereignisse zu gruppieren) |
| Teams | Die Teams, die den Test durchführen, als ein Array von { id, name }-Objekten. Festgelegt durch die CLI, die Node.js-APIs und die Ruby-API. Siehe Teams. |
| userId | Die ID des Benutzers |
| userJobRole | Die Jobrolle des Benutzers |
| userStatus | Der Status des Benutzers |
| version | Eine Zeichenkette, die die Version des Ereignisses angibt, immer „v2“ |
distinctId
Der Wert von distinctId ist eine UUID, die für jeden Benutzer gesetzt wird, sobald die Metriken aufgezeichnet werden. Sie sollte über die Zeit stabil bleiben, da sie beim ersten Start des CLI oder Codes, der die APIs nutzt, festgelegt wird. Sie wird in der Datei .deque/distinct_id im Home-Verzeichnis jedes Benutzers gespeichert.
Akteur
Die CLI, die Node.js-APIs und die Ruby-API setzen actor auf automation, wenn eine dieser Umgebungsvariablen auf einen anderen Wert als false oder 0 gesetzt ist: CI, BUILD_NUMBER, BUILDKITE, CIRCLECI, CODEBUILD_BUILD_ID, GITHUB_ACTIONS, GITLAB_CI, JENKINS_URL, TEAMCITY_VERSION, TF_BUILD oder BITBUCKET_BUILD_NUMBER. Andernfalls ist actor human. Setzen Sie die Umgebungsvariable AXE_ACTOR auf human oder automation, um die Erkennung zu überschreiben. Das @axe-devtools/browser-Paket kann keine Umgebungsvariablen lesen, wenn es in einem Browser läuft, daher meldet es dort human.
Teams
Das teams-Array zeichnet die Teams auf, deren Mitglieder den Test durchgeführt haben. Die CLI, die Node.js-APIs und die Ruby-API senden es immer, als leeres Array ([]), wenn keine Teams festgelegt sind. Sie stellen die Teams selbst bereit, mit der Umgebungsvariable AXE_TEAMS, der --set-teams-Option der CLI, der setTeams-Methode Ihrer Node.js-API oder der for_teams-Klausel oder teams Konfigurationseigenschaft der Ruby-API. Jedes Team ist ein Objekt mit den String-Eigenschaften id und name:
[{ "id": "1", "name": "Web" }]Einträge ohne eine Zeichenfolge id und name werden verworfen. Ein Wert, der nicht gelesen werden kann oder kein JSON-Array ist, wird ignoriert und das Ereignis wird dennoch gesendet.
applicationProperties
Das applicationProperties-Objekt enthält Informationen über die Anzahl des Testlaufs, wie das Beispiel unten zeigt:
applicationProperties: {
advancedRules: { enabled: false, value: 'disabled', source: 'unavailable' },
target: 'https://broken-workshop.dequelabs.com/',
targetMedium: 'text/html',
urlCount: 1,
engineVersion: '4.14.0',
failedRuleCount: 2,
failedRuleNames: 'color-contrast,label',
failedItemCount: 5,
criticalIssueCount: 3,
seriousIssueCount: 2,
moderateIssueCount: 0,
minorIssueCount: 0,
needsReviewItemCount: 4,
inapplicableRuleCount: 39,
incompleteRuleCount: 2,
passedRuleCount: 21,
testResults: {}
},| Eigenschaft | Beschreibung |
|---|---|
| fortgeschritteneRegeln | Ob erweiterte Regeln durchgeführt wurden. Die CLI, die Node.js-APIs und die Ruby-API führen niemals erweiterte Regeln aus, daher ist dies immer { enabled: false, value: 'disabled', source: 'unavailable' }. |
| Befehl | Der CLI-Befehl, der den Scan durchgeführt hat, wie z. B. spec oder bulk-spec. Wird nur vom CLI gesendet. |
| kritischeAnzahl | Anzahl der fehlgeschlagenen Elemente mit kritischem Einfluss |
| engineVersion | Die Version von axe-core, die für das Testen verwendet wird |
| failedItemCount | Gesamtzahl der Barrierefreiheitsfehler, die auf der Webseite gefunden wurden |
| failedRuleCount | Anzahl der Regeln, die auf der Seite fehlgeschlagen sind |
| failedRuleNames | Kommagetrennte Zeichenkette mit Namen der Regeln, die fehlgeschlagen sind |
| inapplicableRuleCount | Anzahl der Regeln, die nicht angewendet wurden |
| geringeAnzahl | Anzahl der fehlgeschlagenen Elemente mit geringem Einfluss |
| mäßigeAnzahl | Anzahl der fehlgeschlagenen Elemente mit mäßigem Einfluss |
| zuÜberprüfendeElementeAnzahl | Anzahl der Elemente, die überprüft werden müssen |
| incompleteRuleCount | Anzahl der Regeln, die unvollständig waren |
| passedRuleCount | Anzahl der Regeln, die bestanden wurden |
| schwereAnzahl | Anzahl der fehlgeschlagenen Elemente mit schwerwiegendem Einfluss |
| Ziel | Getestete URL |
| zielMedium | Mime-Typ des Ziels. Vor Version 4.14.0 „target_medium“ genannt. |
| testResults | Das testResults-Objekt, siehe den nächsten Abschnitt für weitere Informationen |
| urlAnzahl | Anzahl der untersuchten, verschiedenen URLs. Eine CLI-Spezifikationsseite, deren Aktionen navigieren und erneut analysieren, meldet mehr als 1. |
testResults
Das testResults-Objekt wird als ein axeResults-Objekt definiert (definiert durch axe-core). Es wird nur gesetzt, wenn Sie die AXE_INCLUDE_TEST_RESULTS-Umgebungsvariable auf true gesetzt haben, was nur durch die CLI und die Node.js-APIs unterstützt wird.
interface AxeResults extends EnvironmentData {
toolOptions: RunOptions;
passes: Result[];
violations: Result[];
incomplete: Result[];
inapplicable: Result[];
}Das folgende zeigt ein Beispiel für ein testResults-Objekt:
{
testEngine: {
name: "axe-core",
version: "4.4.1"
},
testRunner: {
name: "axe"
},
testEnvironment: {
userAgent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML,like Gecko) Version/16.0 Safari/605.1.15",
windowWidth: 1280,
windowHeight: 720
},
timestamp: "2023-02-02T20:09:04.785Z",
url: "https://broken-workshop.dequelabs.com/",
toolOptions: {
reporter: "v1"
},
inapplicable: [],
passes: [],
incomplete: [],
violations: []
}Aus Gründen der Kürze wurden die inapplicable-, passes-, incomplete- und violations-Arrays, die normalerweise Result-Objekte enthalten, nicht aufgenommen.
Sie können die TypeScript-Definitionen für diese Objekte im axe-core GitHub-Repo sehen.
Siehe auch
Für Anleitungen, die zeigen, wie der Nutzungsdienst verwendet wird, siehe Erste Schritte mit dem Usage Service und den APIs und Erste Schritte mit dem Usage Service und dem CLI.
Für allgemeine Informationen zum Nutzungsdienst siehe Der Axe DevTools für Web-Nutzungsdienst.
