<summary> et aria-expanded

Bonjour à tous,

Je travaille actuellement sur l’accessibilité et j’essaie de m’assurer que tous les éléments interactifs sont correctement annoncés aux utilisateurs de lecteurs d’écran. J’ai remarqué que certains exemples utilisent l’attribut aria-expanded sur l’élément <summary>pour indiquer si le contenu associé est déplié ou non :

<details>
<summary class="ma-classe" aria-expanded="false">Question&#x202F;?</summary>

Cela m’amène dès lors à me demander : les éléments <details>et <summary>ne gèrent-ils pas déjà l’état déplié/replié de manière native ? Si c’est le cas, l’ajout d’aria-expanded est-il redondant ou même incorrect dans ce contexte ? Pourrait-il créer une surcharge d’informations ou de la confusion pour les technologies d’assistance ?

Merci beaucoup pour vos explications et pour vos conseils sur les meilleures pratiques dans ce domaine.

Bonjour,

Tu as vu juste : l'attribut open de details (MDN) est censé faire cela. Et il est correctement interprété dans tous les cas SAUF UN.
Voiceover iOS (et iPadOS j'imagine) ignore ces éléments, c'est qu'une div pour lui... OK sur macOS , OK partout ailleurs (avec iOS 16.x en tout cas, je n'ai pas retesté avec iOS 17.x). Si tu as déjà un composant Disclosure de dispo, continue à l'utiliser... Sinon c'est pas bien long à coder... Plus long à mettre en place que 2 éléments et 1 attribut c'est sûr, attend-toi à avoir des regards en allant voir les dévs (et on peut pas les blâmer... Merci Apple).

Je n'ai pas testé ce cas de rôle natif + attribut ARIA mais a priori c'est à éviter très fort :
1. c'est inutile
2. à moins que cela résolve 1 problème dans 1 environnement sans conséquence dans les autres. Mais pour cela il faut tester dans approx. 5 environnements (desktop Win Chr/Fx + Mac, mobile Android + iOS)
3. on revient à la 1ère règle d'ARIA qui est de ne pas utiliser ARIA (sous-entendu tant qu'on est pas certain d'en avoir besoin, qui est la raison de ton sujet)

J'avais testé plein de palliatifs possibles en 2022 (avec iOS 16.x donc) pour faire restituer à VO iOS un "bouton" et son état via details / summary sans pourrir la situation partout ailleurs et j'avais échoué. Et j'ai pourtant mmh beaucoup d'imagination, pas juste role=button mais nope pas moyen.
J'ignore quel est l'avis de mes consœurs et confrères : j'ai demandé mais tout le monde avait piscine (et moi aussi ).

Note : un accordéon, c'est un peu plus que "plusieurs disclosures", mauvais élément pour ça.

Ressources :
ARIA Patterns du W3C/WAI
Details / Summary Are Not {insert control here} par A. Roselli
Composants permettant d'afficher/masquer des contenus par Access&Use, une exceeellente utilisation de mon pognon par l'UE (pas lié à ta question, plutôt pour aller plus loin et discuter avec d'autres corps de métier mais cette ressource peu connue est d'une telle qualité que ce serait dommage de passer à côté).
Modifié par Felipe (25 Mar 2024 - 11:23)