a écrit :
Cependant, les checkbox et boutons radios sont cachés pour créer d'autres cases à cocher avec des div. (Ex. Materialize, etc...) Est-ce que cette pratique
rend toujours le formulaire accessible pour les personnes non-voyantes ? En effet, les liseuses n'affichent pas le contenu caché par le CSS.
Je suis un développeur non-voyant.
Pour que ce soit accessible aux lecteurs d'écran, il faut que ton composant de substitution :
1 - Utilise correctement ARIA
2 - Gère les entrées (clavier, souris, tactile, autres) exactement comme si le composant était natif, et ce, complètement, sans rien omettre, de sorte que l'utilisateur puisse utiliser le composant exactement de la même manière que s'il était natif, sans surprise désagréable
Les plus gros travers que j'observe au point 1 sont
A - L'utilisation de rôles inappropriés au contexte, parce que le concepteur n'a pas bien compris à quoi servent réellement certains rôles ou comment ils s'utilisent
B - L'oubli total ou partiel de mettre à jour les propriétés ARIA lorsque l'état du composant change
Le second point implique que le composant soit focusable et manipulable uniquement au clavier, ce qui est de loin le plus gros écueil.
Le plus souvent, la gestion du clavier est au mieux très incomplète, au pire totalement absente; probablement plus souvent par totale ignorance, négligeance ou facilité de réutilisation de composant eux-mêmes inaccessibles plutôt que de réelle incompétence.
Par exemple pour les cases à cocher et boutons radio, c'est la touche espace qui est communément utilisée pour basculer l'état. Le fait que les boutons poussoir peuvent aussi être actionnés avec espace est assez méconnu. Pour les listes déroulantes, très peu connaissent Alt+Bas/Haut pour ouvrir/fermer la liste et même le fait qu'on peut naviguer dans les entrées avec les flèches, Home/End ou PageUp/Down, que la liste soit déroulée ou non. ET pour les composants plus complexes, la méconnaissance générale est encore d'autant plus importante.
En pratique et en tant qu'utilisateur, je me retrouve réglulièrement en situation d'inconfort à cause de listes déroulantes traficotées qui ne marchent pas toujours comme je m'y attends, ou encore d'éléments inopérants ou inatteignables au clavier.
Le gros problème avec les composants personnalisés utilisant ARIA, c'est que tous les comportements normalement acquis nativement n'existent pas et sont à reprogrammer entièrement soi-même. Ce n'est pas forcément compliqué, mais peu sont au courant de ce fait, et de tout ce que les composants natifs supportent comme possibilités d'interactions. Ne serait-ce à commencer par la simple focusabilité clavier, obtenue avec tabindex=0.
En fait, on va rarement chercher chez ceux qui ont défini toutes ces interactions standard, pour apprendre qu'elles existent, pourquoi et comment; c'est du côté des concepteurs de GUI des OS qu'on trouve l'essentiel, en particulier chez Microsoft et Apple.
D'où ma recommandation: essaie d'utiliser au maximum les composants natifs, et ne fais appel à des composants personnalisés que quand tu n'as vraiment pas d'alternative native. ARIA ne devrait être utilisé que dans des cas relativement exceptionnels, non couverts par les composants natifs, et en pleine connaissance de cause.
IL y a plusieurs raisons à cela :
1 - En utilisant des composants natifs, tu hérites immédiatement de tous les comportements standard, implicitement accessibles, que tu n'as donc pas à reprogrammer toi-même. Si les composants natifs ne sont pas eux-mêmes accessibles, ça signifie que le navigateur lui-même, voire l'OS tout entier ne l'est pas, et à ce stade c'est la responsabiilité des éditeurs de navigateurs et/ou d'OS.
2 - Puisque tu n'as rien à reprogrammer toi-même, tu n'as pas 99.9% de chances de ne pas faire les choses correctement jusqu'au bout
En bref, tu gagnes du temps, des neurones, et le résultat a de bonnes chances d'être beaucoup plus accessible au final. Mais personne ne semble avoir compris ça et persiste dans des solutions personnalisées qui ne fonctionne pas ou mal.
C'est vrai qu'en HTML4, le choix de composants natifs utilisables sur le web était très restreint. HTML5 a apporté énormément de choses indispensables, même si certains navigateurs tardent à tout implémenter. Pour moi le HTML5 n'est pas encore allé assez loin; il aurait dû y avoir quelque chose de standard pour les menus, les arbres, les listes multicolonnes, les onglets, les zones d'édition WYSIWYG, et beaucoup d'autres; il faut que 90% des JQuery UI, des tinyMCE et compagnie deviennent inutiles. Ce jour-là l'accessibilité aura fait un pas de géant.
Modifié par QuentinC (11 Apr 2017 - 10:23)
