aria-required-children
Les rôles conteneurs doivent posséder au moins un enfant au rôle requis
Vérifie que les rôles conteneurs ayant une entrée documentée « required owned elements » (list, listbox, menu, radiogroup, table, grid, tablist, tree, row, ...) contiennent au moins un descendant, ou un élément référencé par aria-owns, doté d’un rôle possédé acceptable.
Applicabilité. S’applique aux éléments dotés d’un rôle explicite, valide et non abstrait qui fait aussi partie des rôles conteneurs ayant une entrée documentée « required owned elements » (list, listbox, menu, menubar, radiogroup, rowgroup, table, grid, treegrid, tablist, tree, row). Le conteneur doit avoir son rôle explicite, mais un élément possédé peut tenir son rôle des ElementInternals d’un élément personnalisé (this.attachInternals().role), comme un élément natif possédé tient le sien de sa balise.
Attendu. Au moins un descendant, ou un élément référencé par aria-owns, a l’un des rôles possédés acceptables pour ce rôle conteneur. Un conteneur qui n’en a aucun mais possède du texte, directement ou à travers des enveloppes génériques (un <span> ou un <div> sans rôle), échoue (fail) : le texte se trouve là où devraient être ses enfants requis, comme dans une liste dont les éléments n’ont pas de rôle (ACT bc4a75, Failed Example 1). Celui qui ne possède rien fait l’objet d’une question (cantTell) : il ne transmet rien de faux (un role="list" vide est annoncé comme une liste sans éléments, ce qu’il est effectivement), et un script peut le remplir. Savoir si le contenu que possède un conteneur est VALIDE relève d’aria-prohibited-children, et cette règle-là échoue toujours : une structure réellement mal décrite (un role="button" parmi des éléments de liste, un tablist de simples boutons) est donc détectée avec la même force qu’avant. Les équivalents HTML natifs fonctionnent déjà ainsi : aucune règle de cet ensemble ne fait échouer un <ul> vide, et list-children-valid n’évalue que les enfants qui existent.
Ce que rapporte un constat.
role: le rôle du conteneur.requiredOwnedRoles: les rôles dont il lui faut au moins un enfant. Chaque élément est un nom de rôle.
Ces champs de data.details aident à lire et à reproduire un constat. À part reasonCode et les quelques champs que la page Schéma de sortie donne comme stables, ils ne constituent pas un contrat stable : un champ peut être renommé ou supprimé dans une version mineure, ne vous appuyez donc pas dessus.
Exemples
<ul role="list"><li>Item</li></ul>
Le rôle list possède au moins un enfant de rôle listitem.
<div role="list"></div>
Un role="list" vide ne possède aucun enfant au rôle requis ; il est annoncé comme une liste sans éléments, ce qu’il est effectivement, mais cela mérite un coup d’œil.
Comment vérifier
Quand cette règle ne peut pas trancher, elle renvoie cantTell et laisse la question à une personne. Chaque question qu’elle peut poser figure ici sous son code de raison, avec les étapes pour y répondre. Un constat porte les mêmes étapes dans howToCheck, dans la langue de l’analyse. Voir Schéma de sortie.
ARIA_REQUIRED_CHILD_MISSING
- Inspectez le conteneur indiqué par le rapport et notez son rôle et les rôles enfants qu’il exige (comme listitem pour list, option pour listbox).
- Regardez ce qu’il affiche à l’écran : vérifiez s’il est vide ou s’il contient des images, des icônes ou des contrôles.
- Interagissez avec la page (ouvrez les menus, chargez les résultats) et vérifiez si des enfants ayant le rôle requis sont ajoutés ensuite.
- Ouvrez le panneau Accessibilité des outils de développement du navigateur et vérifiez les rôles de tout ce qu’il contient.
Réussite. Le conteneur est vide et ne transmet rien, ou les éléments qu’il affiche portent le rôle requis.
Échec. Il affiche des éléments (images, icônes, contrôles) dépourvus du rôle enfant requis : la structure n’est donc pas transmise, ce qui ne respecte pas le critère WCAG 1.3.1 (ACT bc4a75).