Accordéons

Sommaire

Principe

Les accordéons sont des composants dynamiques qui permettent d’optimiser l’affichage d’un contenu dans un espace réduit grâce à un système de « plier/déplier » appliqué sur un groupe de panneaux.

Ils sont contrôlables via une action sur le bouton qui surplombe le contenu de chaque panneau.

Cette fiche s’appuie sur le motif de conception « Accordion » détaillé dans les ARIA Authoring Practices Guide (APG) du W3C.

Socle HTML

<h2>
<button aria-expanded="false" aria-controls="accordion-panel-1">Entête du panneau 1</button>
</h2>
<div id="accordion-panel-1">
[Contenu du panneau 1 (replié)]
</div>

<h2>
<button aria-expanded="true" aria-controls="accordion-panel-2">Entête du panneau 2</button>
</h2>
<div id="accordion-panel-2">
[Contenu du panneau 2 (déplié)]
</div>

<h2>
<button aria-expanded="false" aria-controls="accordion-panel-3">Entête du panneau 3</button>
</h2>
<div id="accordion-panel-3">
[Contenu du panneau 3 (replié)]
</div>

Rôles, états et propriétés ARIA

  • Chaque entête de panneau doit être balisé avec un <button>.
  • Chaque bouton d’entête de panneau doit être entouré d’une balise de titre (<h1> à <h6>) dont le niveau dépend du contexte dans lequel l’accordéon est intégré.
  • L’attribut aria-expanded doit être appliqué sur chaque bouton d’entête de panneau. Sa valeur doit être renseignée dynamiquement en fonction de l’état du panneau associé :
    • aria-expanded="true" lorsque le panneau associé est déplié.
    • aria-expanded="false" lorsque le panneau associé est replié.
  • Chaque bouton d’entête de panneau doit être rattaché à son panneau associé via l’attribut aria-controls :
    • Chaque panneau doit posséder un attribut id renseigné avec une valeur unique.
    • Chaque bouton d’entête de panneau doit posséder un attribut aria-controls renseigné avec la valeur de l’attribut id du panneau associé.

Interactions au clavier

Entrée ou Espace

  • Si le focus clavier est positionné sur le bouton d’entête d’un panneau replié, déplie le panneau associé. Si l’accordéon n’autorise le déploiement que d’un seul panneau à la fois, et si un autre panneau est déjà déplié, replie ce panneau.
  • Si le focus clavier est positionné sur le bouton d’entête d’un panneau déplié, replie le panneau associé si l’accordéon autorise le repliement de ce panneau. Certains accordéons exigent qu’un seul et unique panneau soit déplié à tout instant ; dans ce cas de figure, le panneau déplié ne peut pas être replié via une action sur son bouton d’entête associé.

Remarque

Dans le socle HTML proposé sur cette fiche, des titres de niveau 2 (<h2>) sont utilisés pour baliser les entêtes des panneaux d’accordéon. Le niveau de ces titres est éventuellement à adapter en fonction du contexte d’intégration de ce composant : il est important de veiller à maintenir une hiérarchie des titres logique dans la page.

Ainsi, si un <h2> surplombe le système d’accordéon, chaque entête de panneau devient enfant de ce titre de niveau 2 et devra donc être balisé avec <h3>.

Composants

Ces composants « Accordéons » sont proposés ici car leur niveau d’accessibilité est jugé bon ou très bon.

Toutefois, avant de les utiliser dans votre projet, il est important de vérifier le respect des spécifications présentées ci-avant. Certains pouvant nécessiter quelques ajustements.

4 commentaires

  • Par Gaëtan, le 10 novembre 2016 à 11h31.

    Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.

    Bonjour,

    Super notice, comme toutes les autres d’ailleurs :)

    Je me demandais, est-il préférable d’ajouter les différents rôles (tablist, tab, tabpanel) directement dans le markup HTML ou via JavaScript ?

    Merci d’avance pour ta réponse !

    Répondre

    • Par Johan Ramon, le 14 novembre 2016 à 9h59.

      Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.

      Bonjour Gaëtan,

      Merci pour ton message.

      Concernant ta question, il est préférable d’ajouter les différents rôles via JavaScript.

      Ainsi, dans le cas où le composant est parcouru sans le support de JavaScript, l’utilisateur de lecteur d’écran (synthèse vocale et/ou plage braille) ne se voit plus restituer des infos du type « Onglet ». Ce qui est souhaité car sans JS le composant n’est plus un accordéon mais un contenu classique, sans interaction possible.

      Johan

      Répondre

  • Par Claire Bizingre, le 2 juillet 2017 à 21h09.

    Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.

    Bonjour,

    Si je relis la page de référence du W3C (https://www.w3.org/TR/wai-aria-practices/#accordion), je ne vois pas cette notion de gestion de tablist et de tab et je vois une structure de bouton et de heading.

    Est-ce qu’il y a une autre ressource à considérer alors ?

    Merci pour votre éclairage !

    Répondre

  • Par Laurent Bracquart, le 10 juillet 2017 à 10h13.

    Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.

    Bonjour Claire,

    C’est bien vu !

    Effectivement, comme tu le constates, les motifs de conception décrits dans nos fiches AcceDe Web diffèrent parfois de ceux proposés dans le document que tu cites : les WAI-ARIA Authoring Practices 1.1.

    La raison ? Une mise à jour de la spécification ARIA est en cours (passage de ARIA 1.0 à ARIA 1.1), et nos fiches s’appuient pour le moment sur les motifs de conception de la recommandation officielle, qui reste aujourd’hui la version ARIA 1.0.

    Suite à ton commentaire, nous allons rajouter un encart informatif en haut de chacune des fiches relatives à un motif de conception ARIA, et mettrons à jour progressivement ces dernières, à mesure que la spécification ARIA 1.1 se stabilisera.

    Belle journée à toi,

    Répondre

Ajouter un commentaire

Tous les champs sont obligatoires.

Haut de page