FAQ

„Meine Ergebnisse haben sich nach dem Update auf core 1.14 geändert“

1.14 meldet mehr cantTell und behauptet weniger, mit Absicht. Die Änderungen, die sich am ehesten in einer Pipeline zeigen:

• Keine zusammengesetzte WCAG-Regel ergibt pass. Ein Kriterium gilt nur als erfüllt, wenn seine Regeln alles prüfen, was es verlangt, und noch keines ist als vollständig geprüft aufgeführt. Ein Kriterium, dessen Regeln alle pass ergeben, ist daher cantTell (composite.rollup.cantTell.partialCheck). Eines, dessen Regeln nichts gefunden haben, ist nur bei 2.4.3, 2.4.4, 2.4.7, 2.4.9, 2.5.3 und 4.1.1 notApplicable, sonst cantTell (composite.rollup.cantTell.partialCoverage). Eine Regel mit fail lässt ihr Kriterium weiterhin fehlschlagen. Ein Dashboard oder Gate, das erfüllte Kriterien zählt, sieht keines; siehe den Eintrag weiter unten und WCAG-Konformitätszuordnung.
• Zwei Regeln fragen mehr. page-title-patterns fragt nach jedem Seitentitel, nicht nur nach generischen oder aus Vorlagen stammenden, denn ob ein Titel seine Seite beschreibt, entscheidet eine Person (G88). duplicate-id fragt auch unter WCAG 2.0 und 2.1 nach 4.1.1, da die Errata von 2023 es als erfüllt werten, außer ein Profil gibt keepsParsing: true an, wie en301549-v3.2.1.
• Elf neue Regeln, darunter die ersten für 3.3.1 (invalid-field-error-message), 4.1.3 (live-region-announcements) und 1.4.5 (image-of-text). Die meisten fragen; click-handler-keyboard-operable, focus-not-removed-by-script und aria-owns-valid können fail ergeben, ebenso aria-valid-attr-value, das jetzt die Bedingungen zwischen Attributen prüft (etwa aria-valuemin über aria-valuemax). Siehe den Regelkatalog.
• Manche Fehlschläge werden zu Fragen, und neue Fehlschläge kommen hinzu. td-has-header fragt einmal nach einer großen Tabelle ohne Kopfzelle, statt jede Zelle fehlschlagen zu lassen, und form-control-single-label fragt nach einem Feld mit zwei Labels. Kontrast wird an mehr von dem gemessen, was die Seite zeichnet (Text auf der Leinwand der Seite in jedem Farbschema, ::first-line, font-size-adjust, ein Platzhalter, dessen Farben die Seite gewählt hat), es können also neue Kontrast-Fehlschläge erscheinen.
• Manche Befunde haben einen neuen Reason-Code. Siebzehn Regeln, die keinen gaben, geben jetzt einen, und einige Codes sind nach Ursache geteilt. Eine von 1.13 geschriebene Baseline passt bis 1.15 weiter auf sie; schreiben Sie sie mit migrateBaselineEntries um (siehe den Eintrag weiter unten). Eine Code-Scanning-Warnung zu einem solchen Befund wird geschlossen und erscheint neu.
• Jedes cantTell sagt, wie es zu beantworten ist. Der Befund einer Core-Regel trägt Schritte in howToCheck, und manche tragen ein lean: wohin die Hinweise der Seite deuten. Das Ergebnis bleibt cantTell, und nichts scheitert an einem lean, außer Sie verlangen es (leanFailAs). Der HTML-Bericht gruppiert diese Befunde in wahrscheinlich nicht erfüllt, wahrscheinlich erfüllt und solche, die eine Person prüfen muss. Siehe Ausgabeschema.
• 1.14.1 meldet beim Textabstand weniger Fehlschläge. text-spacing-content-loss lässt keinen Text mehr fehlschlagen, den die Seite nicht verliert. Zu einer Seite, deren Scrollen mit body { position: fixed } gesperrt ist, wie bei vielen hinter einem Consent-Banner, und zu einer fixierten Box, die höher als der Viewport ist, wird als VIEWPORT_SCROLL_LOCKED nachgefragt; zu Text, den eine Box abschneidet, die das Skript der Seite an ihn anpasst, etwa das schwebende Label eines Angular-Material-Felds, als TEXT_CLIPPED_SCRIPT_SIZED. Ein Baseline-Eintrag oder eine Code-Scanning-Warnung dazu wird geschlossen wie bei einem behobenen Fehler. Die Schritte von 36 Fragen fragen außerdem, ob ein anderer Weg auf der Seite dasselbe leistet, bevor sie zu einem Fehlschlag führen.

Die vollständige Liste steht im CHANGELOG.md von core.

„runOnly hat einen Fehler geworfen: no rule or tag named …, oder either rule ids or tags“

Seit 1.10.0 wird ein runOnly, das als nacktes Array oder als String übergeben wird, als Regel-IDs oder als Tags gelesen (siehe ENGINE_OPTIONS.md). In zwei Fällen wirft es einen Fehler:

• Ein Wert, der weder eine Regel noch einen Tag benennt, meist ein Tippfehler: runOnly: ['img-alt-presnt']. Prüfen Sie die ID gegen getChecksCatalog(). An der Groß- und Kleinschreibung liegt es nicht: Regel-IDs und Tags werden unabhängig davon erkannt, IMG-ALT-PRESENT wählt also img-alt-present aus.
• Regel-IDs und Tags in einem Array: runOnly: ['img-alt-present', 'wcag2a']. Verwenden Sie die Objektform, um sie zu kombinieren:

runOnly: {
  includeRuleIds: ['img-alt-present'],
  tags: ['wcag2a'],
  includeMode: 'or',
}

Vor 1.10.0 wurde ein nacktes Array ignoriert, und alle Regeln liefen.

Die Objektform, { includeRuleIds }, { tags } oder { type: 'tag', values }, sowie engineOptions.rules.include / .tags.include werfen ebenfalls einen Fehler, mit code: 'INVALID_RUN_ONLY', wenn kein Wert in der Liste eine Regel oder einen Tag benennt (runOnly.tags: no tag named "wcag2.2aa".). Früher liefen dann gar keine Regeln, was sich wie ein Scan ohne Befunde liest. Ein einzelner unbekannter Wert neben bekannten, oder in einer Ausschlussliste, erzeugt nur ein console.warn.

„Ich habe Tags und Regel-IDs ausgewählt, und der Scan hat keine Regel ausgeführt, sieht aber ohne Befunde aus“

Unter dem Standard includeMode: 'and' führt eine Auswahl aus Tags und Regel-IDs nur die Regeln aus, die zu beidem passen. .withTags('wcag2a').withRules('region') führt nichts aus, da region eine Best Practice ohne den Tag wcag2a ist, und ein Scan ohne Regeln hat keine Verstöße. Die Engine warnt in der Konsole der Seite, die ein Testlauf nicht zeigt, und wirft INVALID_RUN_ONLY nur unter strictOptions. Um beides auszuführen, fordern Sie es an: .includeMode('or') in den Bindings, includeMode: 'or' in runOnly (oben) oder --include-mode or in der CLI. Ab Version 1.3.0 beendet sich die CLI mit 2 und diesem Hinweis, wenn die beiden keine gemeinsame Regel haben.

Um eine Auswahl, die nichts trifft, vor dem Lauf zu erkennen, prüfen Sie plannedChecks() des Builders, die Regeln, die der Scan ausführen wird, ermittelt ohne Seite (in Cypress ein Chainable):

const builder = new A11yCoreBuilder({ page })
  .withTags('wcag2a')
  .withRules('region')
  .includeMode('or'); // the wcag2a rules, plus region
 
if (builder.plannedChecks().length === 0) {
  throw new Error('This selection runs no rule.');
}

Wie sich die Teile einer Auswahl kombinieren, steht in Engine-Optionen.

„runOnly.tags: no rules for WCAG 2.2 Level A ("wcag22a")“

Die neun WCAG-Tags für Version und Stufe, wcag2a bis wcag22aaa, sind immer bekannt, aber drei davon tragen keine Regel: wcag21aaa, wcag22a und wcag22aaa, deren Kriterien keine automatische Prüfung haben. Wird eines davon neben anderen Tags genannt, protokolliert console.info diese Zeile: Der Rest der Liste läuft, und diese Kriterien brauchen eine manuelle Prüfung. Übergeben Sie engineOptions.logUntestedWcag: false, um die Zeile wegzulassen, oder wählen Sie stattdessen nach Ziel aus, was kein Tag nennt: runOnly: { wcag: { version: '2.2', level: 'AA' } } (siehe Auswahl nach WCAG-Ziel). Eine Liste nur aus solchen Tags würde nichts ausführen, daher wirft sie INVALID_RUN_ONLY mit derselben Erklärung.

„runOnly.wcag.version must be …“ oder „runOnly.bestPractices must be true or false …“

runOnly.wcag nimmt { version, level } an, mit version als '2.0', '2.1' oder '2.2' (ein String: 2.2 als Zahl wird abgelehnt) und level als 'A', 'AA' oder 'AAA'; runOnly.bestPractices nimmt true oder false an. Alles andere wirft INVALID_RUN_ONLY mit dem Feld und dem Wert, statt eine Auswahl auszuführen, die Sie nicht gemeint haben.

„engineOptions: unknown option "lcoale" (did you mean "locale"?)“, oder ein Scan hat INVALID_ENGINE_OPTIONS geworfen

Zu einem Optionsschlüssel, der ein oder zwei Buchstaben von einem bekannten entfernt ist, unabhängig von Groß- und Kleinschreibung, gibt es eine Warnung, und er wird ignoriert: Der Scan läuft, als wäre er nicht da, korrigieren Sie also die Schreibweise. Andere unbekannte Schlüssel bleiben stumm, da eine eigene Regel eigene Einstellungen aus ctx.engineOptions lesen kann. Mit engineOptions.strictOptions: true wirft der Scan stattdessen einen Fehler mit code: 'INVALID_ENGINE_OPTIONS', bei jedem Schlüssel, den die Engine nicht liest (verschachtelte eingeschlossen), und bei einem Wert vom falschen Typ oder außerhalb seiner Menge, und nennt jeweils den nächsten bekannten Schlüssel; problems des Fehlers listet sie auf. Siehe Fehler in den Optionen abfangen.

„Meine eigene Regel schlägt fehl, die WCAG-Zusammenfassung aber nicht“

Eine eigene Regel zählt für die WCAG-Zusammenfassung (rulesResults) jedes Kriteriums, dem sie zugeordnet ist: Geben Sie ihr meta.wcagSc: ['1.1.1'] oder einen WCAG-Eintrag in meta.normativeMappings. Ohne beides steht sie in keiner Zusammenfassung. Eine eigene Regel, die nicht gelaufen ist (aufgeführt in skippedCustomRules), zählt ebenfalls nicht. Eine Überschreibung einer eingebauten Regel zählt nur dort, wo ihre eigene Zuordnung es sagt; eine, die keine angibt, verlässt also die Zusammenfassungen, für die ihre eingebaute Regel gezählt hat, und eine Warnung (customRules: "…" overrides a built-in rule but maps to none of the criteria of …) nennt sie; geben Sie ihr die Kriterien der eingebauten Regel, damit sie dort bleibt.

„Mein eingegrenzter Scan meldet alles als notApplicable“ oder „contextSelector hat einen Fehler geworfen: … is not a valid CSS selector“

Seit 1.10.0 scannt ein contextSelector, der auf kein Element passt, nichts, und einer, den der Browser nicht parsen kann, wirft einen Fehler (siehe ENGINE_OPTIONS.md).

• Alles ist notApplicable: Sehen Sie sich result.contextMatch an. elementCount: 0 bedeutet, dass der Selektor auf nichts gepasst hat, also nichts gescannt wurde: Das ist kein Ergebnis ohne Befunde. unmatchedSelectors nennt den Selektor. Prüfen Sie ihn auf Tippfehler, oder ob das Element beim Scan schon auf der Seite ist (etwa Inhalt, den ein Skript erst nach dem Laden rendert).
• Der Scan hat mit code: 'INVALID_CONTEXT_SELECTOR' einen Fehler geworfen: Der Selektor in der Meldung und in der Eigenschaft selector des Fehlers ist kein gültiges CSS, zum Beispiel '#main[' oder ein >>>-Kombinator. Oder der Bereich ist gar kein Selektor, etwa ein Element oder ein Objekt { include, exclude }, und die Meldung sagt, was übergeben wurde: Übergeben Sie einen Selektor, der auf das Element passt, und Ausschlüsse in engineOptions.excludeSelectors.

In jedem dieser Fälle wurde früher stattdessen die ganze Seite gescannt: bei einem Selektor, der auf nichts passte oder sich nicht parsen ließ, bis 1.10.0, und bei einem Bereich, der kein Selektor ist, auch noch in 1.10.0.

„Ein Scan hat PAGE_BUILTINS_BROKEN geworfen“

Die eigenen Skripte der Seite haben ein JavaScript-Built-in verändert, auf das sich die Engine verlässt (Array.prototype.filter, Map, JSON.stringify und weitere), daher könnte ein Scan der Seite ein Ergebnis liefern, das sich gut liest und falsch ist. Die Meldung des Fehlers und seine Liste broken nennen jedes davon. Scannen Sie die Seite, bevor ihre Skripte sie verändern (fügen Sie das Bundle früher ein, oder scannen Sie einen Build ohne das Skript, das es tut). Siehe Bekannte Einschränkungen.

„Mein Scan kehrt nie zurück“

Etwas in der Seite blockiert den Scan: ein Getter oder ein Skript, das nie zurückkehrt, oder eine Schleife in einer Regel eines Packs oder einer eigenen Regel. Nichts innerhalb der Seite kann einen Scan anhalten, sobald er begonnen hat; setzen Sie das Zeitlimit also dort, wo Sie ihn starten, und geben Sie den Tab auf, wenn es überschritten ist. Standalone zeigt, wie das mit Playwright und Puppeteer geht; in jsdom führen Sie den Scan in einem Worker-Thread oder einem Kindprozess aus.

„Ein Scan dauert nach einem Update länger“

Den Großteil eines Scans machen Style- und Layout-Berechnungen im Browser aus; seine Dauer hängt deshalb ebenso von der Seite, dem Rechner und dem Browser ab wie von der Engine. Ein Release kann sie trotzdem ändern: Eine Regel, die jetzt mehr von der Seite prüft, kostet mehr, und das CHANGELOG.md von core sagt, wann ein Release ändert, was eine Regel kostet. PERFORMANCE.md auf GitHub hält fest, wie lange ein Scan von Release zu Release dauert, als Verhältnis zu einem früheren Release auf denselben Seiten, und wie das gemessen wird. Eine Regel, die langsamer ist und mehr findet, zahlt womöglich für das, was sie jetzt findet; eine, die bei gleichen Ergebnissen langsamer ist, ist eine Regression, die es wert ist, gemeldet zu werden.

„Ein Pack ist nicht gelaufen“, oder skippedPacks ist nicht leer

Ein Pack, dessen core-Bereich das installierte core ausschließt, das nicht gültig ist oder das nicht zu core passt (eine Regel-ID außerhalb seines Namensraums, ein Wörterbuchschlüssel, den core hat), wird übersprungen: Der Scan läuft ohne es, warnt und listet es mit dem Grund in result.skippedPacks; unter strictOptions wirft er einen Fehler. In einer Seite wird ein in engineOptions.packs genanntes Pack, das kein Aufruf von packScript registriert hat oder das mit einer anderen core-Version registriert wurde, genauso aufgeführt. Die Bindings melden es als Lücke 'pack-skipped', die Test-Matcher lassen die Assertion scheitern, und die CLI endet mit Exit-Code 2. Installieren Sie das Pack neben @surea11y/core und dem Paket, das es ausführt, damit alle drei dieselbe Kopie von core nutzen. Siehe Packs.

„Meine eigene Regel liefert immer cantTell ohne erkennbaren Grund“

Prüfen Sie zuerst das Feld error des Ergebnisses — steht dort "<something> is not defined", verweist Ihr runInPage auf eine Variable außerhalb des Funktionskörpers (eine const auf Modulebene, einen importierten Helfer, alles, was nicht über ctx.* erreicht wird). Das ist eine echte, häufige Falle: runInPage wird zu Quelltext serialisiert und später im Seitenkontext erneut ausgewertet, daher fängt der Build das nie ab — erst das Ausführen der Regel zeigt es, und der Fehler sieht aus wie ein normales (wenn auch wenig aussagekräftiges) Ergebnis, nicht wie ein Absturz. Siehe RULE_AUTHORING.md §1.1 für die vollständige Erklärung und die Lösung (den Wert in runInPage verschieben oder über ctx.rule/ctx.helpers durchreichen).

„Eine geometrieabhängige Regel (z. B. target-size-minimum) meldet immer notApplicable“

Reines jsdom (ohne echten Browser) implementiert kein CSS-Layout — getBoundingClientRect() liefert immer eine Geometrie von null. Regeln, die echtes Layout brauchen, melden unter jsdom notApplicable, statt zu raten. Führen Sie den Scan stattdessen in einem echten Browser aus (Puppeteer/Playwright — siehe INTEGRATION.md Pattern 2), um von diesen Regeln echte Befunde zu erhalten. Siehe LIMITATIONS.md.

„Eine Web Component ergibt cantTell (name_internals)“

Ein Custom Element, das sich über ein in einem privaten Feld (#internals) gehaltenes ElementInternals benennt, seine Zustände setzt oder sich eine Rolle gibt, wird vom Browser bereitgestellt, aber kein Skript der Seite kann das zurücklesen. Seit 1.12 liest die Engine Internals, die in einer Eigenschaft liegen (_internals, internals, …), und fragt bei jedem anderen definierten Custom Element ohne lesbaren Namen oder erforderlichen Zustand nach (name_internals, state_internals), statt es scheitern zu lassen.

Damit der Scan solche Elemente beurteilen kann, installieren Sie den Internals-Hook, bevor die Skripte der Seite laufen: installInternalsHook() in jedem Binding (an der Seite oder dem Kontext in Playwright, an der Seite in Puppeteer, am Driver in Selenium, am Browser in WebdriverIO, in der Support-Datei oder in onBeforeLoad in Cypress) und in der Setup-Datei von test-matchers, oder internalsHookScript() aus core für eine eigene Seite. engine.environment.internalsHook im Ergebnis sagt, ob er gelaufen ist ('early' oder 'late'). Der Hook lässt jedes Skript der Seite die Internals jeder Komponente lesen und ist daher für Test- und Audit-Läufe gedacht. Siehe Bekannte Einschränkungen.

„Ich sehe nur fail-/cantTell-Vorkommen — wo ist die Liste der Elemente, die bestanden haben?“

Diese Engine listet absichtlich nie die Elemente auf, die eine Regel bestanden haben — nur die gemeldeten. Ein Gesamtergebnis outcome: 'pass' einer Regel bedeutet „anwendbare Ziele waren vorhanden, und keines wurde gemeldet“, und occurrences ist []. Die Ausnahme sind die Kontrastregeln: Ihr pass trägt ein Vorkommen mit leerem selector, das den Scan beschreibt (wie viel Text in Frage kam und berechenbar war), kein Element. Wenn Sie wissen müssen, welche Elemente konkret geprüft und für in Ordnung befunden wurden: Das wird derzeit nicht bereitgestellt — siehe OUTPUT_SCHEMA.md.

„Eine Regel, die eigentlich anschlagen sollte, liefert notApplicable bzw. findet nichts auf einer Seite, von der ich weiß, dass sie das Problem hat“

Zwei häufige Ursachen, nach Wahrscheinlichkeit geordnet:

1. Das Element ist aus dem Accessibility Tree ausgeschlossen — aria-hidden="true", display: none, visibility: hidden, hidden oder ein inert-Vorfahre. Die meisten Regeln überspringen Inhalte, die für assistive Technologien ohnehin unsichtbar sind, denn ein verborgenes Element zu prüfen wäre sinnlos und könnte ein irreführendes fail für Inhalte erzeugen, auf die niemand trifft. Einige Regeln setzen diese Einschränkung ausdrücklich aus, wo sie keinen Sinn ergäbe (z. B. no-autoplay-audio — verborgenes Audio spielt trotzdem Ton ab) — prüfen Sie den Kopfkommentar der jeweiligen Regeldatei (@applicability) in src/checks/.
2. excludeSelectors — wenn Sie das konfiguriert haben (direkt oder geerbt aus einer gemeinsamen Konfiguration), stellen Sie sicher, dass das betreffende Element nicht davon erfasst wird. Denken Sie daran, dass sich das auch über engineOptions.rules[ruleId].excludeSelectors auf eine einzelne Regel beschränken lässt (siehe ENGINE_OPTIONS.md) — wenn eine Regel, die anschlagen sollte, nur für ein Element immer wieder notApplicable/pass liefert, prüfen Sie, ob gerade für diese Regel eine eigene Ausschlussliste konfiguriert ist, nicht nur die globale.

„Alle Prüfungen ergeben pass, warum ist dann jedes WCAG-Kriterium cantTell?“

Seit 1.14 ergibt eine zusammengesetzte WCAG-Regel in rulesResults nur dann pass, wenn die Regeln des Kriteriums alles prüfen, was es verlangt, und noch ist kein Kriterium so aufgeführt (COMPLETE_CHECK in src/coverage/complete-applicability.js). Ergeben alle Regeln eines Kriteriums pass, ist seine zusammengesetzte Regel cantTell mit dem reasonCode composite.rollup.cantTell.partialCheck: Die Teile, die die Regeln prüfen, sind erfüllt, den Rest prüft eine Person. html-lang-attr-present stellt fest, dass <html lang="fr"> eine Sprache nennt, nicht, dass die Seite auf Französisch ist. Ebenso ist ein Kriterium, dessen Regeln alle nichts gefunden haben, nur dann notApplicable, wenn sie jeden Fall finden, für den es gilt, sonst cantTell mit composite.rollup.cantTell.partialCoverage. Eine Regel mit fail lässt ihr Kriterium weiterhin fehlschlagen. Zeigen Sie diese als „Prüfungen bestanden, Prüfung durch eine Person nötig“ und „nichts zu prüfen gefunden“, nie als erfüllt; siehe WCAG-Konformitätszuordnung.

„Bedeutet ein Scan ohne Fehlschläge, dass die Seite WCAG-konform ist?“

Nein — siehe WCAG_CONFORMANCE.md. Das pass einer Regel bedeutet, dass die gelaufenen Prüfungen in dem Teil der Seite, den sie gescannt haben, ohne Befund blieben. Ein Scan, der auf einen Teil der Seite begrenzt ist, auf einige Regeln beschränkt ist oder unter jsdom läuft, prüft weniger, als er könnte. Ein nennenswerter Teil der WCAG erfordert menschliches Urteil (zutreffende Alternativtexte, verständliche Fehlermeldungen) oder dynamische Tests, die die Architektur dieser Engine überhaupt nicht leisten kann (Tastaturfallen, Reflow beim Zoomen) — siehe LIMITATIONS.md für die explizite, bewusst nicht erschöpfende Liste.

„Sollte ich cantTell als Fehler behandeln?“

Behandeln Sie es als „ein Mensch muss draufschauen“ — es ist bewusst weder bestanden noch nicht bestanden. Häufig werden cantTell-Befunde protokolliert, ohne die CI daran scheitern zu lassen, denn wenn ein Build an etwas scheitert, das die Engine ausdrücklich nicht bestimmen konnte, gewöhnen sich die Beteiligten schnell daran, das Gate zu ignorieren. Ein Team, das jeden Befund vor einem Merge geprüft haben will, kann stattdessen daran scheitern lassen; so oder so sollten Sie sie von Verstößen getrennt halten. Dazwischen kann ein Build nur an den Befunden scheitern, die zu fail tendieren, wo die Hinweise der Seite auf einen Fehlschlag deuten: leanFailAs im JUnit- und im SARIF-Bericht oder leaningFailures(result) (siehe Ausgabeschema). Jeder cantTell-Befund einer Core-Regel sagt in howToCheck, wie er zu beantworten ist. Siehe POLICY.md, wenn Sie dieses Verhalten anpassen möchten (z. B. über einen eigenen Policy-Vertrag), und INTEGRATION.md für ein konkretes Beispiel für CI-Gating.

„Was passiert, wenn eine Locale nur teilweise übersetzt ist?“

Fehlende Schlüssel fallen einzeln auf den englischen Text zurück (nie ein leeres oder kaputtes Ergebnis): Wo in einer unvollständigen Locale eine Übersetzung fehlt, erscheint die englische Meldung, statt dass die Ausgabe ganz fehlschlägt. Siehe I18N.md für den Mechanismus und die aktuelle Abdeckung. Die Gleichheit der Schlüssel wird im eigenen Build von core erzwungen, nicht erhofft: Jeder neue oder umbenannte englische Schlüssel wird in alle anderen Locale-Dateien übertragen und enthält den englischen Text, bis ihn jemand übersetzt — eine Locale kann also bei den Formulierungen hinterherhinken, aber nie bei den Schlüsseln.

„runDomRulesInPage oder runa11yCoreInPage — welche brauche ich?“

runDomRulesInPage, wenn Sie die Funktion direkt im selben Node-Prozess aufrufen (jsdom). runa11yCoreInPage, wenn Sie die Funktion selbst an einen anderen JS-Realm übergeben — fast immer page.evaluate in Puppeteer/Playwright, das die Funktion zu Quelltext serialisiert und im Browser-Tab erneut ausführt (der keinen Zugriff auf den Modul-Scope Ihres Node-Prozesses hat). Siehe INTEGRATION.md für beide Muster vollständig ausgearbeitet.

„Nach dem Update meldet meine Baseline bekannte Befunde als neu und ihre Einträge als veraltet“

Die Identität eines Befunds enthält seinen Reason-Code, und 1.14 hat siebzehn Regeln, die keinen hatten, Codes gegeben und einige Codes nach Ursache geteilt. Eine von 1.13 geschriebene Baseline passt unter 1.14.x über src/baseline-moves.json weiter auf diese Befunde; ein Befund, dessen Ergebnis sich mit dem Update geändert hat, ist trotzdem neu oder fällt weg, und das Changelog sagt, warum. Schreiben Sie die Codes der Datei vor 1.15 mit migrateBaselineEntries aus @surea11y/core/baseline um, oder erzeugen Sie sie neu und prüfen Sie den Diff. Siehe Baseline / Allowlist.

„css-orientation-lock fragt mit STYLESHEETS_NOT_READABLE“

Das Skript einer Seite kann ein Stylesheet nicht lesen, das ein anderer Ursprung ausliefert (ein CDN, ein Schriftendienst), also können die Regeln, die CSS lesen, nicht wissen, was es enthält. Geben Sie dem Scan seinen Text in engineOptions.styleSheetTexts: preloadStyleSheets() oder runa11yCoreInPageAsync im Browser-Bundle lädt die, die der Server freigibt, und ein Werkzeug, das den Browser steuert, kann die übrigen von außerhalb der Seite laden. Siehe „Style sheets from another origin“ in INTEGRATION.md, der Integrationsanleitung auf GitHub.