Beaucoup de bavardages autour du vieux <details> ainsi que <summary> éléments ces derniers temps! J'ai vu Léa Verou a récemment tweeté une observation sur l'élément display comportement et cela s'est en quelque sorte scindé en plus d'observations et de notes d'utilisation de la part des gens, y compris un discussion ravivée si <summary> devrait être autorisé à contenir des éléments interactifs ou non.
Il y a beaucoup de points à relier et je ferai de mon mieux ici pour faire exactement cela.
Peut-on modifier l'affichage des éléments imbriqués dans le <details> élément?
Hyper bizarre ! Si nous ouvrons DevTools, la feuille de style de l'agent utilisateur nous dit <details> est un élément affiché en tant que bloc.
Remarquez le nécessaire <summary> élément et les deux supplémentaires <div>s là-dedans. Nous pouvons passer outre le display, droite?
Ce à quoi on pourrait s'attendre, c'est que <details> a maintenant une hauteur explicite de 40vh et trois rangées où la troisième rangée occupe l'espace restant des deux premières. Comme ça:
Ugh, mais la troisième rangée ne… fait… pas ça.
Apparemment, nous avons affaire à un conteneur de grille incapable d'appliquer un comportement de grille à ses éléments de grille. Mais la spécification HTML nous dit :
La
detailsl'élément est devrait rendre comme un boîte de bloc. On s'attend également à ce que l'élément ait un arbre d'ombre avec deux fentes.(Souligner le mien)
Et un peu plus tard :
La
detailsseconde de l'élément fente devrait avoir sonstyleattribut défini sur "display: block; content-visibility: hidden;" quand ledetailsl'élément n'a pas deopenattribuer. Quand il a leopenattribut, lestylel'attribut devrait être supprimé de la seconde fente.(C'est moi qui souligne, encore une fois)
Ainsi, la spécification indique le deuxième emplacement - les deux supplémentaires <div>s de l'exemple - ne sont contraints d'être des éléments de bloc que lorsque <details> est fermé. Quand c'est ouvert — <details open> - ils doivent se conformer à l'affichage de la grille qui remplace le style de l'agent utilisateur… n'est-ce pas ?
C'est le débat. je comprends slots sont mis à display: contents par défaut, mais bloquer des éléments imbriqués dans des emplacements et supprimer la possibilité de les styliser semble inopportun. Est-ce un problème de spécification que le contenu est des emplacements, ou un problème de navigateur que nous ne pouvons pas remplacer leur display même s'ils sont dans le buis ? Des personnes plus intelligentes peuvent m'éclairer, mais cela semble être une implémentation incorrecte.
Is <details> un conteneur ou un élément interactif ?
Beaucoup de gens sont en utilisant <details> pour basculer les menus ouvert et fermé. C'est une pratique popularisé par GitHub.
Semble raisonnable. La spécification le permet bien sûr :
La
detailsélément représente un widget de divulgation à partir duquel l'utilisateur peut obtenir des informations supplémentaires ou contrôles.(Souligner le mien)
D'accord, donc on pourrait s'attendre à ce que <details> est le conteneur (il a un implicitement role=group) et <summary> est un élément interactif qui définit le conteneur open Etat. Logique depuis <summary> a un implicite button rôle de l' dans certains contextes (mais pas de rôle WAI-ARIA correspondant).
Mais Melanie Sumner a fait quelques recherches cela semble non seulement contredire cela, mais conduit à la conclusion que l'utilisation <details> comme menu n'est probablement pas la meilleure chose. Voyez ce qui se passe quand <details> est rendu sans le <summary> élément:
Il fait exactement ce que la spécification suggère lorsqu'il manque un <summary> — il fait le sien :
La première
summaryélément enfant de l'élément, le cas échéant, représente le résumé ou la légende des détails. S'il n'y a pas d'enfantsummaryélément, l'agent utilisateur doit fournir sa propre légende (par exemple "Détails").(Souligner le mien)
Melanie l'a fait passer par un validateur HTML et — surprise ! - c'est invalide :
Alors, <details> nécessite le <summary>. Et quand <summary> est manquant, <details> crée son propre, bien qu'il soit relayé en tant que balisage non valide. C'est tout beau et valable quand <summary> y a-t-il:
Tout cela amène à une nouvelle question : pourquoi est-ce <summary> donné un implicite button rôle quand <details> est ce qui semble être l'élément interactif ? Peut-être s'agit-il d'un autre cas où l'implémentation du navigateur est incorrecte ? Là encore, la spécification classe les deux comme éléments interactifs. Vous pouvez voir à quel point tout cela devient complètement déroutant.
Quoi qu'il en soit, la conclusion ultime de Melanie selon laquelle nous devrions éviter d'utiliser <details> pour les menus est basé sur la façon dont la technologie d'assistance lit et annonce <details> contenant des éléments interactifs. L'élément est annoncé, mais il n'y a aucune mention de contrôles interactifs au-delà jusqu'à ce que vous, euh, interagir comprenant <details>. Ce n'est qu'alors que quelque chose comme une liste de liens sera annoncé.
En outre, le contenu à l'intérieur d'un effondré <details> est exclu de la recherche dans la page (sauf dans les navigateurs Chromium, qui peuvent accéder au contenu réduit au moment de la rédaction), ce qui rend les choses encore plus difficiles à trouver.
Si <summary> autoriser les éléments interactifs ?
C'est la question posée dans ce fil ouvert. L'idée est que quelque chose comme ceci serait invalide:
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>Scott O'Hara résume bien pourquoi c'est un problème:
Le lien n'est pas du tout détectable par JAWS lors de la navigation avec son curseur virtuel. Si vous naviguez vers l'élément récapitulatif via la touche Tab, JAWS annonce « exemple de texte, bouton » comme nom et rôle de l'élément. Si vous appuyez à nouveau sur la touche Tab, JAWS annonce à nouveau "exemple de texte, bouton" même si le focus du clavier est sur le lien.
[...]
Je pourrais en dire plus sur les divers problèmes que les différents AT ont avec le modèle de contenu pour le résumé… mais cela ne ferait qu'étendre ce commentaire au-delà de ce qui est nécessaire. tldr ; le modèle de contenu récapitulatif produit des expériences très incohérentes et parfois tout simplement brisées pour les personnes utilisant AT.
Scott a ouvert des tickets pour corriger ce comportement dans Chrome ainsi que WebKit. Merci Scott !
Pourtant, c'est du HTML valide :
Scott va plus loin dans un article de blog séparé. Par exemple, il explique comment gifler role=button on <summary> peut sembler une solution raisonnable pour s'assurer qu'elle est systématiquement annoncée par la technologie d'assistance. Cela réglerait également le débat sur la question de savoir si <summary> devrait autoriser les éléments interactifs car les boutons ne peuvent pas contenir d'éléments interactifs. Le seul problème est que Safari traite ensuite <summary> comme un bouton standard, qui perd son expanded ainsi que collapsed États. Ainsi, le rôle correct est annoncé, mais maintenant son état ne l'est pas. 🙃
Où allons-nous maintenant?
Avez-vous peur d'utiliser <details>/<summary> avec tous ces problèmes et incohérences ? Je le suis bien sûr, mais seulement dans la mesure où je m'assure que ce qu'il contient offre le bon type d'expérience et d'attentes pour les utilisateurs.
Je suis juste content que ces conversations aient lieu et qu'elles se déroulent en plein air. Pour cette raison, vous pouvez commenter les trois solutions proposées par Scott sur la façon dont le modèle de contenu pour <summary> est défini, votez pour ses tickets et signalez vos propres problèmes et cas d'utilisation pendant que vous y êtes. Espérons que mieux nous comprenons comment les éléments sont utilisés et ce que nous attendons d'eux, mieux ils sont mis en œuvre.
