a écrit :
Je ne connais rien aux technos d'accessibilité, mais une petite exploration du DOM permet de trouver tous les liens d'une page, je ne comprends pas pourquoi il faut ajouter des tabindex. C'est tout simplement le signe que les gens qui font des navigateurs se fichent pas mal de la navigation au clavier.
Oui, mais...
1 - Les liens en display:none ne sont pas listés. Un lecteur d'écran étant, comme son nom l'indique, un dispositif qui vocalise ce qui se trouve à l'écran, ce qui est masqué visuellement doit l'être aussi vocalement; question de logique.
2 - Ton symbole n'est pas un vrai lien, c'est un div ou un span bidouillé. C'est donc à toi que revient la charge de renseigner le rôle correct et de gérer son fonctionnement pour qu'il se comporte comme un lien ordinaire.
Gérer le fonctionnement d'un élément personnalisé pour qu'il se comporte exactement comme si, ce n'est pas quelque chose d'évident et ça nécéssite d'être scrupuleusement testé dans plein de configurations variées; en fait, dans 99.99% des cas sur 99.99% des sites web du monde ce n'est pas fait correctement jusqu'au bout.
D'où l'article posté par Raphaël, conseillant au maximum d'utiliser les éléments préconçus pour leur usage avec leurs rôles implicites, avant de prendre la voie du composant personnalisé; simplement parce que faire un composant personnalisé qui est aussi accessible que son homologue natif est très difficile.
a écrit :
et il faudrait sans doute une réflexion sur quels liens doivent ou non avoir un tabindex, dans quel ordre, etc.
Tous les liens sont focusables par défaut et il n'y a pas de raison de changer ce comportement. Quant à l'ordre, la valeur 0 permet justement de ne pas avoir à y réfléchir. Tabindex=0 indique que l'élément doit être focusable et qu'il doit s'insérer dans l'ordre naturel du DOM.
a écrit :
Si je rends la "racine" cliquable, cela veut dire qu'il faut stopper la propagation, pour éviter qu'un clic sur un "enfant" remonte jusqu'à la racine ce qui pose des problèmes sur les vieux navigateurs qui ne supportent pas stopPropagation(); vous me direz que les vieux navigateurs ne tournent pas sur tablette, mais dans la mesure du possible je ne tiens pas à avoir du code divergeant entre les différents media.
Je ne vois pas le rapport. Tu mets "Page 12/12" en lien ou en un autre span est c'est réglé en 5 secondes, et tu ne te casses pas la tête avec des problèmes depropagation des évènements aux potentiels enfants.
a écrit :
Et par ailleurs je n'ai toujours pas trouvé comment être sûr qu'un media est un "touch" bidule
Si tu construisais des pages accessibles, tu n'aurais même pas à te poser cette question.
a écrit :
A mon sens, ce qui est surtout une catastrophe pour l'accessibilité, c'est que les navigateurs du marché s'en contrefichent. Il est contradictoire de prétendre faire des "balises sémantiques" et devoir ajouter des "roles" et autres choses du même genre dans lesdites balises. Il ne devrait pas y avoir quoi que ce soit à faire pour qu'une page soit "accessible". C'est le navigateur qui devrait se débrouiller, quitte à donner quelques recommandations pour faciliter le travail.
Les éléments standards avec leurs rôles implicites sont là. Si tu les utilises correctement, tu es à peu près certain de faire une page accessible sans rien avoir à faire d'autre.
Après, dès le moment où tu utilises des composants personalisés à base de conteneurs génériques type div/span ou si tu détournes certains éléments de leur utilisation prévue, les navigateurs tout comme les aides techniques ne sont pas magiques, ils ne peuvent pas deviner tes intentions; tu dois les expliciter clairement.
LE souci principal étant que, malgré la richesse de HTML, la majorité des gens n'arrivent pas à se contenter de ce qui existe de base.
Et si, après toutes les années que HTML existe, personne n'a jamais sérieusement pensé à standardiser les menus déroulants à la souris, c'est sûrement parce qu'au fond, c'est probablement une mauvaise idée. Je ne dis pas que HTML n'a pas de lacunes, mais elles se font de plus en plus rares.
