Aria Level 1 et description des boutons

AmauriC commented 2 months ago

Aria level 1

Le niveau aria level 1 est-il indispensable sur le titre principal de la modal?

<span class="tarteaucitronH1" role="heading" aria-level="1" id="dialogTitle">Gestion des cookies</span>

Cela pose problème à quelques utilisateurs car il y a un doublon avec un autre level 1

Noms des boutons non explicite hors contexte

Les boutons Accepter/Refuser ne sont pas assez explicites. Exemple de code corrigé:

<button type="button" class="tarteaucitronCTAButton tarteaucitronAllow" id="tarteaucitronPersonalize2">       <span class="visually-hidden">Cookies - </span>Tout accepter</button>

Qu'en pensez vous @nicozerr @lucmuller ?

Merci! ☺️

lucmuller commented 2 months ago

Lors d'un précédent audit d'accessibilité réalisé par un expert il nous a été recommandé de mettre un titre de niveau 1 dans la modalbox. Nous soutenant donc qu'il fallait expressement que la modalbox ait un titre, qui plus est de niveau 1.

Si je m'en réfère à : https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-modal https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/dialog/

On constate les attributs aria-labelledby="dialog1_label" et éventuellement : aria-describedby="dialog_desc"
Les deux exemple de HTML contiennent par contre une balise h2.

Pour ce qui est de la discussion sur le fait d'avoir ou non un titre de niveau 1 dans la modalbox en général les critiques viennent des équipes SEO qui prennent pour aquis qu'une page HTML ne doit contenir qu'un et un seul h1.

C'est une croyance très ancrée dans le milieu, elle a néanmoins été démentie depuis longtemps par Google lui-même : https://www.youtube.com/watch?v=zyqJJXWk0gk

Je résume le point de vue SEO :

Google sait très bien déterminer quel est le contenu pertinent
Le rôle "modal" indiquera facilement au SEO que le contenu n'est pas pertinent
IMHO tout contenu "dupliqué" (ce qui est le cas du HTML de TAC) dans plusieurs page du site est ignoré par les moteurs de recherche pour le contenu "pertinent" de la page.

De ce point de vue là je peux dire de manière certaine que :

Avoir 2 titres de niveau 1 dans la page est tout a fait valide et d'un point de vue HTML
Avoir 2 titre de niveau 1 dans la page est tout a fait valide d'un point de vue SEO.

De fait je pense que :

d'un point de vue de l'accessibilité avoir un h1 est tout a fait correct.
Avoir un titre de niveau 1 me semble plus pertinent qu'un titre de niveau 2 (a tout le moins) si le HTML de TAC se trouve en haut de page

@nicozerr pourra certainement approfondir l'aspect accessibilité !

lucmuller commented 2 months ago

Pour ce qui concerne le nommage des boutons, je proposerai :

<span class="visually-hidden">Accepter tous les cookies</span><span class="aria-hidden">Tout accepter"></span>

Dans le cas des boutons génériques.

<span class="visually-hidden">Accepter tous les cookies du service : Nom du service</span><span class="aria-hidden">Tout accepter"></span>

Dans le cas des boutons de services.

L'idéal étant de ne pas avoir de variance dans le texte du bouton et d'utiliser la version accessible pour tout le monde, mais c'est certainement moins esthétique.

idem @nicozerr pourra vraisemblablement approfondir la réponse.

AmauriC commented 2 months ago

Merci beaucoup @lucmuller pour le retour express 🚀

Pour le level 1 ça confirme ce que je pensai, que ce n'est qu'une optimisation pour Google et pas pour l'utilisateur.

nicozerr commented 2 months ago

Bonjour,

Je ne sais pas si je vais faire avancer le schmilblick mais je vais vous donner ma vision.

Plusieurs H1

Le sujet du "1 seul H1 par page" est difficile à appréhender. Il est censé avoir été pris en charge dans la spec HTML 5, mais n'a jamais été implémenté par les navigateurs, et a fini par être abandonné. Je vous invite à lire des articles en recherchant "Document outline multiple h1" dans votre moteur de recherche favori. On trouvera cet article, ou encore celui-ci.

D'un point de vu SEO, certains disent que c'est une hérésie et que ça "masque" l'importance du titre de la page dans un H1 ; d'autres disent que Google est tout a fait capable de faire la différence entre un H1 dans <main>, et un H1 dans une <section> ou un <article>. Et d'un point de vue accessibilité, j'avoue que ça peut être source d'embrouille car, selon la position de TAC dans le code, on peut avoir des imbrications de titres moyennement logiques. Exemple avec la capture suivante, montrant un bloc "Flash Infos" avec H2 avant le titre de la page H1, et TAC au tout début de la page, avec son H1, semblant indiquer qu'il est le parent du Flash Infos.

Personnellement, je ne suis pas fan des H1 multiples, et je les indique comme non-conformes lorsqu'ils sont visibles (visuellement ou avec une technologie d'assistance) et qu'ils cassent la hiérarchie des titres sur la page. J'ai demandé à un utilisateur aveugle d'une grande association d'utilisateurs malvoyants et non voyants, et il m'a indiqué que "ça ne gênait pas les utilisateurs expérimentés, mais ça pouvait quand même gêner certaines personnes".

Si ça ne tenait qu'à moi, je passerai le titre du bandeau de TAC (le div#tac_title.tac_visually-hidden) en H2. Quant à celui de la modale (le span #dialogTitle.tarteaucitronH1), je le ferai aussi. Mais ici, selon moi, H1 ou H2 n'a pas vraiment d'importance car on se trouve dans le contexte spécifique de la modale, le reste du site n'est pas atteignable au clavier, et lorsqu'on sort de la modale elle disparaît et son titre avec.

Et pour finir, le titre dans la modale est quand même largement préférable, surtout si ce titre ressemble visuellement à un titre (texte gros et gras).

Titre des boutons

Pour le bouton "Tout accepter", la proposition suivante de Luc n'est pas conforme :

<span class="visually-hidden">Accepter tous les cookies</span><span class="aria-hidden">Tout accepter</span>

La règle à respecter est : le nom accessible doit au moins contenir le texte visible. Ici, le nom accessible est "Accepter tous les cookies" mais le texte affiché est "Tout accepter". Une personne utilisant un logiciel de contrôle vocal (genre Dragon Naturally Speaking) ne pourra jamais activer ce bouton sans se rabattre sur son clavier (virtuel) ou sa grille de navigation.

La proposition d'Amauri est meilleure : <button type="button" class="tarteaucitronCTAButton tarteaucitronAllow" id="tarteaucitronPersonalize2"><span class="visually-hidden">Cookies - </span>Tout accepter</button>

Ici, le nom accessible est "Cookies - Tout accepter". L'utilisateur de contrôle vocal verra et dira "Tout accepter", et le logiciel pourra lui proposer d'activer le bouton "Cookies - Tout accepter". C'est bon. On pourrait même remplacer le tiret "-" par deux-points ":". Pareil pour "Tout refuser" : <button type="button" class="tarteaucitronCTAButton tarteaucitronDeny" id="tarteaucitronPersonalize2"><span class="visually-hidden">Cookies : </span>Tout refuser</button>

Et pour les services, le bouton est actuellement :

<button type="button" aria-label="Autoriser YouTube" id="stratis-youtubeAllowed" class="tarteaucitronAllow" aria-pressed="false"><span class="tarteaucitronCheck" aria-hidden="true"></span>Autoriser</button>

Le nom accessible est "Autoriser Youtube" et l'intitulé visible est "Autoriser". C'est carrément conforme.

lucmuller commented 2 months ago

Pour le bouton "Tout accepter", la proposition suivante de Luc n'est pas conforme :

<span class="visually-hidden">Accepter tous les cookies</span><span class="aria-hidden">Tout accepter</span>

La règle à respecter est : le nom accessible doit au moins contenir le texte visible.

Aparté : Merci pour la correction :) Je tente de me souvenir de ça pour mes prochaines implémentations !

AmauriC commented 2 months ago

Merci pour votre implication 🥰

La grille de navigation c'est visuel et ça donne vraiment envie d'améliorer l'accessibilité. Je ne savais même pas que c'était un outil 😶

H1

Donc consensus Accessibilité/SEO pour passer de h1 à h2 ?

Boutons

Pas possible de garder le principe des aria-label et faire simplement comme les autres boutons:

<button aria-label="Cookies : Tout accepter" type="button" class="tarteaucitronCTAButton tarteaucitronAllow" id="tarteaucitronPersonalize2">Tout accepter</button>

nicozerr commented 2 months ago

H1

Il y a 2 H1:

Celui du bandeau div#tac_title.tac_visually-hidden
Celui de la fenêtre modale de configuration span #dialogTitle.tarteaucitronH1

Les deux peuvent passer en titre de niveau 2. Tu peux utiliser des balises <h2> mais tu devras peut-être modifier le CSS, ou bien conserver tes balises actuelles en ajoutant role="heading" aria-level="2" et tu n'auras rien d'autre à modifier.

Attention : si tu changes le niveau du titre de la fenêtre modale de configuration, le niveau des autres titres de cette fenêtre devront aussi être modifiés.

Voici la hiérarchie des titres actuellement (capture de l'extension HeadingsMap) :

Tu devras avoir ceci :

nicozerr commented 2 months ago

Boutons

<button aria-label="Cookies : Tout accepter" type="button" class="tarteaucitronCTAButton tarteaucitronAllow" id="tarteaucitronPersonalize2">Tout accepter</button>

Moi ça me va tout à fait.

lucmuller commented 2 months ago

ou bien conserver tes balises actuelles en ajoutant role="heading" aria-level="2" et tu n'auras rien d'autre à modifier.

Ceci me semble assurer une meilleure rétrocompatibilité. Si l'on modifie la structure du HTML cela peut potentiellement avoir un impact sur la mise en forme des sites. Le risque que les styles utilisent les sélecteurs [role="heading"] et/ou [aria-level] me semble moins probables. J'ajusterai avec une modification de aria-level="2" plutôt qu'un h2.

Pour ma culture : @nicozerr : Est-ce que l'utilisation de titre dans la modalbox est effectivement obligatoire ? Est-ce que la modalbox ne pourrait pas se contenter de mention aria-labelledby et éventuellement aria-describedby ?

nicozerr commented 2 months ago

Lorsqu'on ouvre un journal, un magazine, ou un site Internet, nous lisons les titres (et les images) pour trouver l'info qui nous intéresse. Et plus un titre est gros, plus son niveau hiérarchique est élevé. Pour les personnes malvoyantes et non-voyantes naviguant avec une technologies d'assistance type lecteur d'écran + clavier, ça doit pouvoir être aussi pratique : Ces technologies d'assistance proposent des raccourcis ou peuvent afficher tous les titres de la page, avec leur arbre hiérarchique, et de naviguer par titre. Comme je le montre sur la capture suivante du site Grenoble Alpes Métropole.

Les titres structurent la page, ou une zone "hors-contexte" comme une fenêtre modale. Ces personnes peuvent donc naviguer de titre en titre, qui est en fait la navigation la plus utilisée au monde en accessibilité. En accessibilité, on utilise même des titres invisibles pour mieux structurer une page, comme le titre invisible du bandeau de TAC.

De plus, ce qui ressemble visuellement à un titre doit être un titre dans le code. Un titre simulé avec un paragraphe (<p>) gros et gras n'est pas un titre sémantiquement parlant, et constitue une erreur d'accessibilité (et SEO pas top). Dans le cas du titre de la modale de TAC, ceux des groupes de services, et ceux des services eux-mêmes, je préconise très fortement de les conserver. C'est hyper pratique et ça identifie la structure de la modale comme cela est fait visuellement.

De manière générale, les titres ne sont pas obligatoires si visuellement il n'y a pas d'élément le supposant. Ça ne sera pas pratique pour tout le monde, et donc ça ne sera plus de l'accessibilité.

Pour finir :

aria-label et aria-labelledby servent à donner un nom à la modale. C'est obligatoire en accessibilité pour tout composant complexe comme une modale, un carrousel, une liste d'onglets. J'invite à consulter le système de modèle de design proposé par la branche accessibilité du W3C. aria-label doit avoir un texte comme valeur (ex. : "Panneau de gestion des cookies"), et aria-labelledby doit être l'ID d'un élément visible, comme implémenté dans la modale de TAC.

aria-description (mauvais support navigateur) et aria-describedby ne définissent pas le nom d'un élément, mais sa description. Ce n'est pas obligatoire mais c'est pratique.

Ces deux éléments permettent à un utilisateur d'avoir assez d'information avant d'entrer dans un composant complexe, pour savoir dans quoi il s'embarque, s'il navigue dedans ou s'il le saute. Comme l'attribut title d'une balise <iframe>.

AmauriC / tarteaucitron.js