Sevablog

De manière globale, l’accessibilité est le fait de rendre accessible un bien ou un service à l’ensemble de la population, notamment aux personnes en situation de handicap, qu’il soit physique ou mental. Dans notre cas, l’accessibilité va surtout porter sur le fait que notre site sera utilisable par n’importe qui, peu importe le contexte :

L’objectif principal de réaliser un site accessible est l’enjeu humain avant tout. Les bénéfices SEO et performance ne sont que secondaires.

Dans la plupart des recherches qu’on effectue en anglais, on tombe souvent sur l’acronyme a11y. C’est tout simplement parce qu’il y a 11 lettres entre le a et le y de “accessibility”. Ça vaut aussi pour le i18n de “internationalization”.

Pas de magie là dedans, ni de case à cocher en back-office. La démarche est avant tout humaine, et ce, dès la genèse du site, avant même de sortir la moindre petite ligne de code, avant même le premier croquis, dès sa conception. Tous les postes sont donc concernés (clients compris).

Pour la suite des tests, nous allons nous pencher sur le cas d’un site que l’agence a conçu et développé : Covireivac. Pourquoi lui ? Parce qu’il s’agit d’un site grand public à forte fréquentation, mais aussi parce qu’on l’a déjà audité et qu’il a une super note ! 😁 On en parle aussi ici.

Sur un site existant, il existe de nombreux outils gratuits mis à disposition pour lancer un audit, nous allons principalement nous intéresser aux outils mis à disposition par le navigateur Chrome.

On peut également trouver l’extension Axe qui est une référence en la matière : https://www.deque.com/axe/

Cet outil est disponible directement dans les DevTools (touche F12 pour l’ouvrir)

Ensuite, on a plusieurs options avant de lancer un audit, il est souhaitable de les sélectionner en fonction de son besoin.

Il est important de lancer l’audit (surtout en cas de test des performances) au moins deux fois d’affilée : Sur le 2e, le cache sera pris en compte et pourra grandement impacter la note finale en cas de test de performances.

De plus, il est nécessaire de tester les pages les plus fréquentées du site et pas uniquement la home qui est généralement bien plus complexe et lourde à charger. Ce n’est pas non plus la seule page visitée de votre site ! (je vous laisse consulter les statistiques de visites).

Également dans le DevTools, dans l’onglet “Elements” on retrouve dans la sidebar, un autre onglet “Accessibility” qui va nous permettre d’avoir l’arborescence du site tel qu’il serait vu par un lecteur d’écran.

Au delà des outils, il est également nécessaire d’avoir une très bonne connaissance du code html mis en place afin de se poser les bonnes questions (heureusement, on est là pour ça) :

Cette liste est non exhaustive mais permet déjà de soulever la plupart des problèmes qu’on pourrait rencontrer.

Pour l’anecdote, Julien notre responsable technique, avait une interface pour contrôler l’état des serveurs, hors celui-ci n’était visible que par une puce verte ou rouge… Pas de chance il est daltonien, donc pour lui tout était… vaguement vert… Pas pratique quand on est chargé de veiller à leur bon fonctionnement…

On parlait un peu plus haut des aria-attributes, ces attributs qui vont permettre aux lecteurs d’écrans d’ajouter des descriptions, des informations ou de se masquer. En voici quelques-uns :

Chaque élément de formulaire dispose maintenant de son propre type, bien penser à les utiliser, surtout lorsqu’on navigue sur téléphone où le clavier va s’adapter, mais encore et toujours aussi pour nos lecteurs d’écrans qui vont bien mieux interpréter chaque champs :

Bien penser à ajouter un id sur chaque champs avec un attribut for sur le label pour faire la liaison entre les 2 éléments.

Pour chaque image à but non décoratif, il est important de la décrire via son attribut html alt . Cet attribut va permettre d’une part d’afficher la description de l’image lorsque celle-ci n’est pas chargée pour une raison ou une autre (très important pour des campagnes d’emailings par exemple où Outlook ne charge pas immédiatement les images).

Et d’une autre part, va permettre aux lecteurs d’écrans de décrire l’image affichée. Il est donc primordial de contextualiser la description (une image peut vouloir dire plusieurs choses différentes selon le contexte de l’article).

Il existe une media query pour cibler si l’utilisateur a choisi d’afficher les animations ou non dans les options de son navigateur, il est donc important de le prendre en compte :

@media (prefers-reduced-motion: reduce) {
 * {
   animation-duration: 0.01ms !important;
   animation-iteration-count: 1 !important;
   transition-duration: 0.01ms !important;
   scroll-behavior: auto !important;
 }
}

On peut aussi rendre l’état focus disponible uniquement lorsqu’on navigue au clavier :

*:focus {
 &:not(:focus-visible) {
   outline: none;
 }
}

Pour conclure, on parle beaucoup d’accessibilité en ce moment, mais il ne faut pas voir ça comme une tendance, mais bien un élément primordial et impératif à la bonne conception d’un site web.

Ces optimisations vont cependant demander une vigilance particulière pour les développeurs et l’ensemble de la chaîne de production, ce qui va forcément impacter les temps passés et donc les coûts.

Merci à l’équipe de AccessibilityCon pour cette super journée de workshop avec Emmanuel Demey et les conférences des nombreux intervenants, c’était très enrichissant !