L’accessibilité est un sujet de tous les temps, qui prend de plus en plus d’ampleur dans un monde où on parle d’inclusivité, d’égalité, d’équité. Pourtant, le web est bien loin d’incarner tout cela. 😅

Avez-vous déjà songé à la façon dont peuvent naviguer sur internet des personnes aveugles ? Des personnes à la mobilité physique réduite, qui ne peuvent pas utiliser de souris ?

Nous n’y pensons pas forcément, et même en tant que développeur.euse.s, on peut avoir tendance à oublier ces typologies d’utilisateurs. Alors pour rendre le web plus inclusif, plus accessible à tous, que pouvons-nous faire au quotidien pour améliorer les conditions de navigation de nos users ? 

Posh ça vous dit quelque chose ?

C’est l’acronyme pour Plain Old Semantic HTML. Eh oui, il n’y a pas de surprise, le meilleur moyen de rendre un site accessible est d’utiliser ce que le navigateur nous fournit. Et non, nous ne sommes pas réduits à quelques balises comme nous pourrions le croire en lisant une grande partie du code existant dans le monde. Tout ne se résume pas à une <div> 😉. 

Selon les sources, nous aurions entre 111 et 142 balises HTML à notre disposition. De quoi répondre à la majorité de nos besoins.

L’avantage de ces balises : elles intègrent déjà les comportements de navigation au clavier et à la souris. 

Certes, elles sont parfois un peu moche, osons le dire, et ne sont pas forcément toutes customisables selon nos envies ou celles des designers. Ce qui nous pousse parfois à ré-implémenter des éléments à la main. Autant dire que c’est rarement une partie de plaisir, quoiqu’un excellent challenge technique car il faut penser à tous les cas à la marge.

Et qui dit sémantique, dit quelques règles basique à suivre telles que : 

• l’ordre logique des titres est à respecter. Un <h1> sera toujours suivi d’un <h2> ou <h3> mais un <h4> ne devrait pas être positionné avant un <h1>
• un input est accompagné d’un label
• remplir le alt d’une image (quand cela a du sens)
• un lien VS un bouton => un bouton appel à une action, un lien à une navigation
• etc.

Le CSS a aussi son rôle à jouer dans l’histoire

Chaque élément utilisé sur le web a une apparence et un comportement particulier et des fonctionnalités qui lui sont propres. Les utilisateurs, après plusieurs décennies à voguer sur le web, sont habitués à ses conventions communes. Il est donc important que les designers et les développeurs les respectent.

Un des rôles non négligeables du CSS est de mettre l’accent sur les contrastes de couleurs, afin que tout le monde puisse lire les contenus à leur disposition. 
Des nuances trop proches les unes des autres posent un souci de lecture pour les personnes aux déficiences visuelles (daltonien, protanopie,etc.).

Pour plus d’infos sur ce sujet, je vous invite à lire l’article de Maxime sur les contrastes.

Et Javascript dans tout cela ?

Idéalement, un site devrait pouvoir fonctionner correctement avec le moins de JS possible. Car si celui est à la base de tout votre site, si pour une quelconque raison, le navigateur ne compile pas, votre site ne sera accessible à personne !

L’utilité de javascript va surtout être dans les cas de ré-implémentation d’éléments auxquels il faut ajouter/ remettre l’accessibilité au clavier et à la souris ou ajouter de l’interaction sur des éléments qui n’en ont pas de base. Dans ce cas précis, nous faisons appel aux Aria Roles pour compléter notre code et lui donner plus de sens. 

ARIA ? Késaco ?

Les Accessible Rich Internet Application, de leur petit nom, sont des attributs qui définissent comment rendre tel ou tel élément web accessible. Ils permettent de compléter la sémantique HTML pour que les éléments interactifs puissent être lus par des outils d’assistances tels que les lecteurs d’écrans.

Car un des points importants d’une bonne sémantique HTML et des ARIA, c’est de rendre le contenu accessible et lisible aux lecteurs d’écrans (ça coule de source maintenant mais ce n’est pas toujours évident de prime abord). 

Ils se distinguent en 3 types : les rôles (utilisés pour les widgets qui n’existent pas de façon native comme les menus, sliders, etc.), les propriétés (ce sont les caractéristiques des widgets susmentionnées) et les états (permettant de savoir dans quel état se trouve l’élément : ouvert, fermé, actif, etc.).

Si on applique toutes ses pratiques, nous sommes normalement parés pour réaliser un site accessible à la majorité, et contrairement à ce que beaucoup pensent, rendre accessible un site web ne prend pas plus de temps (si l’on part de la page blanche) !

Pour aller plus loin:

• MDN : https://developer.mozilla.org/fr/docs/Web/Accessibility
• W3C : https://www.w3.org/TR/wai-aria/
• Access guide : https://accessguide.io/
• La documentation sur les WCAG français (RGAA) https://www.numerique.gouv.fr/publications/rgaa-accessibilite/
• Video de présentation sur l’importance de l’accessibilité sur le net https://www.youtube.com/watch?v=3f31oufqFSM
• Suivez le parcours d’une personne à l’accessibilité réduite à travers un petit jeu et comment lui rendre la vie plus simple https://www.youtube.com/watch?v=HE2R86EZPMA