Analyse von iframes
Wie die Axe DevTools für Web-APIs Inhalte innerhalb von iframes analysieren und wie die Analyse von Frames eingegrenzt oder eingeschränkt werden kann.
Seiten betten häufig umfangreiche Inhalte in <iframe>-Elemente ein: Zahlungsformulare, Mediaplayer, eingebettete Karten, Chat- und Hilfewidgets sowie Drittanbieterkomponenten. Die Axe DevTools für Web-APIs analysieren den Inhalt dieser Frames als Teil einer normalen Seitenanalyse in jeder unterstützten Sprache, sodass der eingerahmte Inhalt keine Lücke in Ihrer Abdeckung darstellt und kein separater Testsatz erforderlich ist.
Es muss nichts aktiviert werden. axe-core wird in die Frames der Seite geladen, jedes Frame wird zusammen mit dem Dokument auf oberster Ebene analysiert, und die Ergebnisse werden zu einem einzigen Bericht für die Seite zusammengefasst.
Wie Frameresultate angezeigt werden
Resultate aus Frames erscheinen in den gleichen violations-, passes-, incomplete- und inapplicable-Arrays wie der Rest der Seite. Erkennbar sind sie am target-Array bei jedem Resultatknoten: Es enthält einen Selektor pro Ebene der Frame-Verschachtelung, gefolgt von einem Selektor für das Element selbst.
- Ein
targetmit einem Eintrag ist ein Element im Dokument auf oberster Ebene. - Ein
targetmit zwei Einträgen ist ein Element innerhalb eines Frames: Der erste Selektor findet das Frame im übergeordneten Dokument, und der zweite findet das Element innerhalb des Dokuments dieses Frames. - Jeder zusätzliche Eintrag stellt eine weitere Ebene der Rahmenverschachtelung dar.
Für die vollständige Struktur des Resultats, siehe die JavaScript API-Referenz für Browser.
Eingrenzung der Analyse auf oder in einem Frame
Jede API, die include- und exclude-Selektoren akzeptiert, akzeptiert auch einen Pfad durch verschachtelte Frames. Die Regel ist in jeder Sprache dieselbe: Alle Selektoren außer dem letzten stimmen mit aufeinanderfolgenden <iframe>-Elementen überein, und der letzte stimmt mit dem zu analysierenden Element im innersten Frame überein. Die Reihenfolge spielt eine Rolle, da das Frame vor dem darin enthaltenen Element kommen muss.
| Sprache | Wie man ein Element innerhalb eines Frames anvisiert | Referenz |
|---|---|---|
| Node.js und JavaScript | Übergeben Sie ein Array von Selektoren an include oder exclude |
JavaScript API-Referenz für Browser |
| C# | Including/Excluding mit mehreren Selektoren, oder ein FromFrames-Selektor |
C#-API-Referenz |
| Java | including/excluding mit einem List<String> oder einem IFrameSelector mit Hamcrest |
Selenium-Tests, Hamcrest-API-Referenz |
| Python | including()/excluding() mit mehreren Selektoren |
Python-API-Referenz |
| Ruby | Eine within-Klausel mit einem iframe: und selector:-Hash |
RSpec |
Da eine Liste von Selektoren immer als Pfad durch Frames gelesen wird, kann sie nicht verwendet werden, um mehrere unabhängige Elemente auszuwählen. Um mehr als einen Bereich einer Seite zu analysieren, rufen Sie die include- oder exclude-Methode jeweils einmal pro Bereich auf.
Einschränkung der Frameranalyse
Frames machen eine Seite dynamischer, und auf Seiten, auf denen Frames während einer Analyse hinzugefügt oder entfernt werden, kann das Injizieren von axe-core in jeden Frame fehlschlagen. Die Java-API bietet eine Sicherung, die eine Analyse auf das Dokument auf oberster Ebene beschränkt: Rufen Sie disableIframeTesting() vor dem Ausführen auf, und axe-core wird in keinen Frame injiziert. Siehe Selenium-Tests.
Die axe-core iframes-Ausführungsoption deaktiviert die Frameranalyse in diesen APIs nicht. Da jede Bibliothek axe-core über den Browser-Treiber in die Frames injiziert, anstatt axe-core die Frames selbst durchlaufen zu lassen, werden Frameresultate in einer Analyse unabhängig davon gemeldet, ob die Option gesetzt ist oder nicht. Um den Umfang einer Analyse zu begrenzen, schließen Sie den Frame stattdessen aus, indem Sie die exclude-Methode für Ihre Sprache verwenden.
Cross-Origin- und Sandbox-Frames
Ein Frame kann nur analysiert werden, wenn axe-core darin ausgeführt werden kann und seine Ergebnisse zurückmelden kann.
Cross-Origin-Frames werden analysiert. Da diese APIs eine echte Browsersitzung steuern und axe-core über den Treiber in jedes Frame injizieren, wird ein von einem anderen Ursprung bereitgestelltes Frame wie jedes andere Frame analysiert, und seine Resultate erscheinen mit dem Rest der Seite.
Sandbox-Frames hängen von der Bibliothek ab. Ein Frame mit einem sandbox-Attribut, das allow-scripts auslässt, blockiert die Skriptausführung, die axe-core benötigt. Einige Bibliotheken umgehen dies und analysieren das Frame dennoch; andere melden das Frame als ungetestet. Die Python-API stellt without_iframe_sandboxes() bereit, das das sandbox-Attribut entfernt, sodass axe-core in diesen Frames ausgeführt werden kann. Siehe die Python-API-Referenz.
Verwenden Sie die axe-core frame-tested-Regel, um „keine Probleme in diesem Frame“ von „dieses Frame wurde nie analysiert“ zu unterscheiden. Ein Frame, das axe-core nicht erreichen konnte, wird als unvollständig gemeldet, und eines, das es erreicht hat, besteht die Regel. Es handelt sich um eine Best-Practice-Regel, daher erscheint sie nur, wenn Ihre Ruleset Best-Practice-Regeln umfasst; ein ausschließlicher WCAG-Regelsatz lässt sie aus, und ein unanalysiertes Frame erzeugt dann kein Signal.