Analyse des iframes
Comment les Axe DevTools pour les API Web analysent le contenu à l'intérieur des iframes, et comment cibler ou restreindre l'analyse des cadres.
Les pages placent souvent un contenu substantiel à l'intérieur des éléments <iframe> : formulaires de paiement, lecteurs multimédias, cartes intégrées, widgets de chat et d'aide, et composants tiers. Les Axe DevTools pour les API Web analysent le contenu de ces cadres dans le cadre d'une analyse ordinaire de la page, dans toutes les langues prises en charge, de sorte que le contenu encadré ne soit pas un vide dans votre couverture et n'ait pas besoin d'un ensemble de tests distinct.
Il n'y a rien à activer. axe-core est chargé dans les cadres de la page, chaque cadre est analysé avec le document de niveau supérieur, et les résultats sont combinés en un seul rapport pour la page.
Comment les résultats des cadres sont rapportés
Les résultats des cadres arrivent dans les mêmes tableaux violations, passes, incomplete et inapplicable que le reste de la page. Ce qui les identifie est le tableau target sur chaque nœud de résultat : il contient un sélecteur par niveau de nesting du cadre, suivi d'un sélecteur pour l'élément lui-même.
- Un
targetavec une entrée est un élément du document de niveau supérieur. - Un
targetavec deux entrées est un élément à l'intérieur d'un cadre : le premier sélecteur trouve le cadre dans le document parent, et le second trouve l'élément à l'intérieur du document de ce cadre. - Chaque entrée supplémentaire représente un autre niveau de nesting du cadre.
Pour la structure complète du résultat, voir la Référence de l'API JavaScript du navigateur.
Cibler l'analyse sur un cadre ou à l'intérieur d'un cadre
Chaque API qui accepte les sélecteurs include et exclude accepte également un chemin à travers les cadres imbriqués. La règle est la même dans toutes les langues : tous les sélecteurs sauf le dernier correspondent à des éléments <iframe> successifs, et le dernier correspond à l'élément à analyser à l'intérieur du cadre le plus profond. L'ordre est important, car le cadre doit précéder l'élément qui est à l'intérieur.
| Langue | Comment cibler un élément à l'intérieur d'un cadre | Référence |
|---|---|---|
| Node.js et JavaScript | Passez un tableau de sélecteurs à include ou exclude |
Référence de l'API JavaScript du navigateur |
| C# | Including/Excluding avec plusieurs sélecteurs, ou un sélecteur FromFrames |
Référence de l'API C# |
| Java | including/excluding avec un List<String>, ou un IFrameSelector avec Hamcrest |
Test avec Selenium, Référence de l'API Hamcrest |
| Python | including()/excluding() avec plusieurs sélecteurs |
Référence de l'API Python |
| Ruby | Une clause within avec un iframe: et un hachage selector: |
RSpec |
Parce qu'une liste de sélecteurs est toujours lue comme un chemin à travers les cadres, elle ne peut pas être utilisée pour sélectionner plusieurs éléments sans lien. Pour analyser plus d'une région de la page, appelez la méthode include ou exclude une fois par région.
Restreindre l'analyse des cadres
Les cadres rendent une page plus dynamique, et sur les pages où des cadres sont ajoutés ou supprimés pendant qu'une analyse est en cours, l'injection d'axe-core dans chaque cadre peut échouer. L'API Java fournit une solution de sécurité qui limite une analyse au document de niveau supérieur : appelez disableIframeTesting() avant l'exécution, et axe-core n'est pas injecté dans aucun cadre. Voir Test avec Selenium.
L'option de fonctionnement iframes de axe-core ne désactive pas l'analyse des cadres dans ces API. Parce que chaque librairie injecte axe-core dans les cadres par l'intermédiaire du pilote de navigateur plutôt que de laisser axe-core parcourir les cadres lui-même, une analyse rapporte les résultats des cadres que l'option soit définie ou non. Pour limiter la portée d'une analyse, excluez le cadre à la place, en utilisant la méthode exclude pour votre langue.
Cadres cross-origin et sandboxed
Un cadre ne peut être analysé que lorsque axe-core peut s'y exécuter et rapporter ses résultats.
Les cadres cross-origin sont analysés. Parce que ces API conduisent une session de navigateur réelle et injectent axe-core dans chaque cadre par l'intermédiaire du pilote, un cadre servi à partir d'une autre origine est analysé comme n'importe quel autre cadre, et ses résultats apparaissent avec le reste de la page.
Les cadres sandboxed dépendent de la bibliothèque. Un cadre avec un attribut sandbox qui omet allow-scripts bloque l'exécution du script dont axe-core a besoin. Certaines bibliothèques contournent cela et analysent le cadre de toute façon; d'autres rapportent le cadre comme non testé. L'API Python expose without_iframe_sandboxes(), qui supprime l'attribut sandbox pour que axe-core puisse s'exécuter dans ces cadres. Voir la Référence de l'API Python.
Utilisez la règle frame-tested de axe-core pour distinguer "pas de problèmes dans ce cadre" de "ce cadre n'a jamais été analysé." Un cadre que axe-core n'a pas pu atteindre est signalé comme incomplet, et un cadre qu'il a atteint passe la règle. C'est une règle de bonne pratique, donc elle n'apparaît que lorsque votre règleset inclut des règles de bonnes pratiques; un ensemble de règles limité aux règles WCAG l'omettant, et un cadre non analysé ne produit alors aucun signal.