Retour du BreizhCamp — A11y pour les nuls

Introduction

Une fois de plus, toute l’équipe Slickteam a eu la chance de pouvoir assister au Breizhcamp et ses nombreuses conférences. Parmi celles-ci, plusieurs ont retenu mon attention dont celle sur A11y présentée par Hélène Esnault. Ayant un intérêt particulier pour les sujets d’accessibilité (j’avais d’ailleurs déjà écrit un article sur ce sujet en 2018) mais n’en ayant pas eu dans mes projets récents, il me semblait important de me mettre à jour à ce propos. Ce que j’espérais de cette conférence de 55 minutes : l’évolution des normes, et des outils pour simplifier le travail afin de rendre une interface accessible. Dans cet article, je suivrai l’ordre de présentation de la conférence.

Origine du nom “A11y”

État des lieux général

La première partie de la conférence a été centrée sur la présentation de A11y, son intérêt et son utilisation, mais aussi sur le handicap de manière générale. Je pense que c’était un excellent point de départ puisque, comme dit durant la conférence, trop de gens pensent que le handicap ne concerne qu’une infime partie de la population, et qu‘avoir une interface accessible n’apporte pas de grande valeur ajoutée (Spoiler : c’est faux !). 24% de la population française active (de 15 à 64 ans) est touchée par un handicap que ce soit lié à une déficience moteur, auditive, visuelle, ou autre. Ça représente beaucoup de personnes, et une partie potentiellement importante de votre audience. De plus, lorsque l’on parle de handicap, nous avons tendance à nous focaliser sur les handicaps de naissance ou suite à un accident, mais la vieillesse par exemple apporte des handicaps auxquels nous aurons (presque) tous droit. Peu importe le type de handicap, des solutions existent afin de faciliter l’accès aux sites : diffusion de contenu de plusieurs manières, une structure de page compréhensible, changement de contrastes, etc… Et tout ça passe par beaucoup d’acronymes :

• WAI (Web Accessibility Initiative) : Autorité américaine en charge de rédiger les normes et bonnes pratiques liées à l’accessibilité sur le web ;
• WCAG (Web Content Accessibility Guidelines) : Recommandations à suivre pour rendre son site accessible. Elle comporte 14 directives avec 3 niveaux de conformité (A, AA & AAA) ;
• RGAA (Référentiel Général d’Amélioration de l’Accessibilité) : Version française des WCAG, adaptée pour les besoins en Europe et en France. Certains organismes ont l’obligation légale de respecter ces normes.

Mise en place

La seconde partie était axée sur la mise en place de toutes ces règles afin de rendre une interface accessible.

Le design

Le point de départ de tout cela : le design. L’utilisation de typographies lisibles, d’une bonne hiérarchisation des éléments avec des éléménts importants plus visibles, des contrastes de couleur assez importants, l’absence d’animations à tout va et le tout dans un parcours UX clair permet d’avoir une très bonne base pour avoir un site accessible. Petit point d’attention sur les animations, certaines personnes sont atteintes de “motion sickness”, évitez donc de faire comme sur cette page de Vercel ou donnez la possibilité de pouvoir désactiver les animations (scrollez, vous verrez 😵 ).

La sémantique HTML

Ensuite, la sémantique HTML a une (très) grande importance également. Pour aborder ce sujet, la notion de POSH (Plain Old Semantic HTML) a été abordée. Dans beaucoup de projets, très peu de balises HTML sont utilisées. En effet, lorsqu’un bloc est nécessaire par exemple, on fait souvent une div par réflexe sans se poser de questions. Mais c’est un mauvais réflexe, puisque selon MDN, il existe 142 balises HTML différentes, et certaines ont de réelles valeurs sémantiques. Il faut donc vraiment les utiliser ! Ce n’est pas un simple détail comme on pourrait le penser, puisque ces balises HTML ont un réel intérêt et ne sont pas perçues de la même manière par les lecteurs d’écran notamment, ce qui évite d’avoir certains développements à faire. Les fonctionnalités souris et claviers sont déjà intégrées à ces éléments.

Exemple pour un bloc avec titre et description :

<!-- DON'T -->
<div>
    <div>Beast of Bodmin</div>
    <p>A large feline inhabiting Bodmin Moor.</p>
</div>
<!-- DO -->
<dl>
    <dt>Beast of Bodmin</dt>
    <dd>A large feline inhabiting Bodmin Moor.</dd>
</dl>

La grande majorité du temps, lorsque l’on veut faire ce type de contenu, une div globale, puis soit une div soit un élément de titre, et un p pour la description. Or, les balises HTML dl, dt, et dd sont faites pour, comme expliqué dans cette documentation du MDN. En plus d’avoir une meilleure sémantique, ça permet d’avoir un style pré-construit, et c’est plus optimisé pour le SEO.

Le Javascript & ARIA

La sémantique peut malheureusement faire défaut pour certains aspects, auquel cas il faut faire appel à Javascript. Par exemple, la balise video n’a pas toutes ses commandes accessibles au clavier sur tous les navigateurs, le Javascript peut remédier à ce problème. Le langage peut également être utile dans des cas plus spécifiques lors de l’utilisation d’évènements souris par exemple.
Les ARIA (Accessible Rich Internet Applications) permettent de rendre un contenu ou une application web accessible. Elles ont pour but de rajouter des informations d’accessibilité sur des éléments HTML qui n’en ont pas nativement. Elles sont divisées en 3 :

• roles : Le role permet à un élément HTML d’avoir un rôle sémantique qu’il n’a pas dans son utilisation “classique”. Des balises HTML spécifiques pour tous les usages sont disponibles, et dans la très grande majorité du temps, elles sont et doivent être utilisées puisqu’elles contiennent déjà ces rôles là sans avoir à les préciser. Cependant, dans certains cas précis, si vous ne pouvez pas, alors il faudra ajouter l’ARIA role sur les éléments en questions afin que les lecteurs d’écran s’y retrouvent. Dans les rôles disponibles il y a notamment scrollbar, list, listitem, switch, banner, etc… La liste complète est disponible sur cette page ;
• properties : Les properties servent à représenter et décrire les caractéristiques d’un élément. Elles permettent au lecteur d’écran de retranscrire davantage d’informations sur l’élément afin de donner plus d’indications à l’utilisateur, afin qu’il puisse interagir au mieux avec. Il existe par exemple les propriétés aria-hidden, aria-haspopup, aria-valuemax, etc… La liste complète est disponible sur cette page ;
• states : Les states ont pour but de donner l’état courant d’un élément. Par exemple si celui-ci est checked ou disabled. Parmi celles-ci on peut retrouver entre autres : aria-checked, aria-disabled,aria-expanded, etc… La liste complète est disponible avec la liste des properties ci-dessus.

Quelques outils

Une partie que j’attendais beaucoup pour cette conférence était une liste d’outils utiles et pratiques pour faciliter la mise en place de l’accessibilité sur un projet. Je ne vais pas faire la liste exhaustive des outils ici puisque ce n’est pas le but, mais dans un premier lieu, une liste de librairies UI accessibles a été présentée et j’ai trouvé ça très intéressant car plusieurs listes ont été proposées pour différents frameworks (React, Vue.js, Angular, et même pour les Web Components). Ensuite, une liste d’outils “globaux” a été donnée afin de tester son code directement dans le navigateur, notamment via des extensions navigateurs comme Wave ou encore Axe DevTools (qui propose même un plugin de lint VS Code).

Conclusion

Ayant déjà travaillé sur des projets publics nécessitant le respect des normes RGAA, les premières parties étaient, pour moi, plus un rappel que de nouveaux acquis. En revanche, je pense que ce genre de petit rafraîchissement reste toujours utile, surtout après avoir été plusieurs mois sans travailler sur le sujet. La partie que j’ai trouvé la plus intéressante a été sur le listing de nouveaux outils que je ne connaissais pas et qui me pourront me servir dans de futurs projets où un sujet d’accessibilité sera présent. Autrement dit, cette conférence était plus axée pour les novices en accessibilité, mais toujours intéressante pour les personnes ayant déjà des compétences dans le domaine. En d’autres mots, je la recommande ! Si vous voulez la retrouver, voici le lien vers la vidéo.

Si vous avez apprécié cet article ou avez trouvé ça utile (ou si vous voulez également partager votre retour), n’hésitez pas à 👏 et partager !