Ergebnisse und Berichte

Jeder Scan liefert ein einziges, einfaches JSON-Objekt. Die vier Berichtsformate unten werden aus genau diesem Objekt erzeugt, und jedes ist für ein anderes Publikum gemacht: einen Menschen, der einen Browser-Tab durchsieht, ein Codeanalyse-Dashboard, das nur SARIF versteht, eine CI-Testansicht, die JUnit liest, oder das eigene Format des W3C für Implementierungsberichte. Wählen Sie die Form, die zu denen passt, die das Ergebnis tatsächlich ansehen werden.

Ausgabeschema

Der genaue Vertrag, den jeder Runner zurückgibt und aus dem jedes andere Berichtsformat abgeleitet wird: eine Ergebnishülle auf oberster Ebene, ein Eintrag pro Regel (einschließlich jedes pass und notApplicable — nie eine Liste nur mit Verstößen), Details pro Vorkommen bis hinunter zum gemeldeten Element, explizite Unsicherheitscodes für alles, was eine Regel nicht entscheiden konnte, und zusammengesetzte Zusammenfassungen pro WCAG-Erfolgskriterium. Jeder offene Befund einer core-Regel sagt, wie eine Person ihn beantwortet, und manche sagen, in welche Richtung die Anhaltspunkte der Seite weisen (eine Tendenz), sodass eine Prüfung mit den wahrscheinlichen Fehlern beginnt statt mit einer flachen Liste. Es lohnt sich, das einmal zu lesen, wenn Sie irgendetwas auf einem rohen Ergebnis aufbauen. Die vollständige Form finden Sie unter Ausgabeschema.

HTML-Bericht

Eine HTML-Datei, die sich in jedem Browser öffnet, ohne Server oder Build-Schritt. Oben eine Zusammenfassung in einfacher Sprache, dann die Fehlschläge, danach die Befunde, die eine Prüfung brauchen, sortiert in wahrscheinlich nicht erfüllt, wahrscheinlich erfüllt und solche, die nur eine Person beurteilen kann, bei core-Regeln jeweils mit den Schritten zur Prüfung, darunter eine WCAG-Zusammenfassung nach Konformitätsstufe, die aus den zusammengesetzten Ergebnissen der Engine selbst stammt, und ganz unten eine vollständige, durchsuchbare Tabelle für alle, die tiefer einsteigen wollen. Das ist der Bericht für Prüfende, die keine rohe Ausgabe lesen möchten. Siehe HTML-Bericht.

SARIF-Bericht

Speisen Sie einen Scan direkt in GitHub Code Scanning oder jedes andere Dashboard ein, das SARIF verarbeitet, ohne selbst einen Konverter zu schreiben. Verstöße werden auf SARIF-Ergebnisse mit einem stabilen, inhaltsbasierten Fingerprint abgebildet. So filtert eine Baseline / Allowlist weiterhin zuverlässig, und ein Dashboard kann einen Befund über Commits hinweg verfolgen, statt ihn jedes Mal zu verlieren, wenn sich eine Zeilennummer verschiebt. Ein Log ohne Ergebnisse bedeutet, dass unter den gelaufenen Prüfungen nichts fail ergab oder eine Prüfung braucht; es ist keine Konformitätsaussage. Eine Option hebt die Befunde, die wahrscheinlich nicht erfüllt sind, zu Fehlern an, für einen Build, der an ihnen scheitern soll, ohne an jeder offenen Frage zu scheitern. Siehe SARIF-Bericht.

JUnit-Bericht

Bringen Sie Barrierefreiheitsergebnisse in die Testansicht, die Ihre CI ohnehin hat — das Merge-Request-Widget von GitLab, den Tests-Tab von Azure DevOps, Jenkins, CircleCI —, neben Ihre Unit-Tests. Jedes WCAG-Kriterium ist eine Suite und jede Regel ein Test, sodass ein auf einer Seite wiederholter Fehler ein einziger fehlgeschlagener Test ist und die Zahlen zwischen Läufen stabil bleiben. cantTell erscheint als übersprungener Test, sichtbar, ohne den Build rot zu färben, es sei denn, Sie lassen den Build bei denen scheitern, die wahrscheinlich nicht erfüllt sind. Die Namen der Suites sind in jeder Locale gleich, daher beginnt die Testhistorie nicht von vorn, wenn sich die Sprache des Scans ändert. Eine grüne Suite bedeutet, dass die für ein Kriterium gelaufenen Regeln nichts gefunden haben, nicht, dass das Kriterium erfüllt ist. Siehe JUnit-Bericht.

EARL-Bericht

Ein W3C-Implementierungsbericht in EARL/JSON-LD, der das Ergebnis jeder Regel festhält, nicht nur die Verstöße — das Format, das die ACT Rules Community Group für Implementierungsberichte akzeptiert. Auf den ACT-Testfällen ausgeführt, hält er das Ergebnis für jeden einzelnen fest, sodass sich prüfen lässt, wie die Engine jede Regel umsetzt, statt es ungeprüft zu glauben. Er ist weder eine Zertifizierung noch ein Nachweis der WCAG-Konformität: Als ACT-Implementierung gelistet zu sein, ist keine Billigung durch das W3C. Siehe EARL-Bericht.