L’accessibilité des applications web en 2021 est un sujet essentiel à prendre en compte lors de la conception d’applications ou de sites web.
Rendre accessible un site, c’est permettre aux personnes handicapées et à tous les utilisateurs, d’accéder aux contenus web, et ce, quelque soit le périphérique utilisé (ordinateur, mobile, tablette, ...) et leur environnement (niveau sonore, éclairage, etc.)
Dans cet article, nous allons voir comment mettre en place concrètement cette accessibilité dans le cadre du développement d’un site internet et comment la tester. C’est parti !
Rendre son site web accessible est quelque chose d’assez complexe, car cela nécessite de pouvoir se mettre à la place des utilisateurs finaux, et donc de prévoir le maximum de cas d’utilisation pour couvrir tous les handicaps.
Voici donc une liste non exhaustive des choses auxquelles il faut penser lors de la mise en place de l’accessibilité web :
On commence par ce qui prend généralement le plus de temps à mettre en place dans un projet, l’implémentation du retour vocal. Il s’agit de faire en sorte que chaque élément sur l’écran soit lu correctement et donne des indications pertinentes pour les personnes aveugles ou malvoyantes. Pour cela, il existe tout un tas d’outils que l’on va pouvoir utiliser et que nous détaillerons plus bas.
Les contrastes sont des choses à prendre en compte dès la conception de la maquette de votre application. L’idée est de ne pas utiliser des couleurs trop proches pour votre texte et le fond sur lequel il se trouve, afin que des personnes qui distinguent mal les couleurs (daltonisme) puissent quand même lire ces textes sans difficulté.
Exemple de contrastes acceptables
Mauvais exemple de contrastes
La navigation est également un élément essentiel dans l’accessibilité. Également à prévoir dès la conception des premières maquettes, elle doit être intuitive et simple d’utilisation, en prenant en compte le fait que tous les utilisateurs ne puissent pas forcément se déplacer avec une souris. Il faut donc que les éléments de l’écran soient également accessibles facilement avec un clavier.
Indiquer l’élément sur lequel on se trouve est très important lorsqu’on se déplace avec le clavier. Sans cela, l’utilisateur pourrait ne plus savoir où il se trouve.
C’est d’autant plus important pour certains handicaps tels que l’hyperactivité ou les troubles de l’attention qui ont besoin d’une indication visuelle pour savoir exactement où est positionnée leur tabulation lors d’un déplacement au clavier. Pour cela, il faut faire en sorte que les éléments changent d’apparence lorsqu’il sont focalisés. Cela peut être simplement le fait de changer la couleur du contour d’un champ de texte ou d’un bouton par exemple.
Bouton sans focus
Bouton avec focus
Input sans focus
Input avec focus
NVDA (Non Visual Desktop Access) est le lecteur d’écran le plus utilisé aujourd’hui. Il est gratuit et disponible sur Windows et peut être téléchargé sur le site https://www.nvda-fr.org/. NVDA va lire les éléments au survol de la souris ou via le déplacement au clavier. Il tient compte des rôles sur les balises HTML, attention donc à bien les préciser ! C’est d’autant plus important notamment pour les aria-live, où il est nécessaire d’indiquer un rôle alert (nous détaillerons plus bas ce que sont les aria :) ).
Côté MacOS, il existe la solution native Voice Over. Pas besoin de la télécharger, elle est directement intégrée avec le système d’exploitation. Contrairement à NVDA, Voice Over ne lit pas les éléments au survol ! Il est nécessaire de se déplacer avec son clavier ou en cliquant sur les éléments directement. De plus, Voice Over ne tient pas compte de certains attributs html pour sa lecture, c’est le cas des rôles et de l’élément aria-atomic.
Nous avons pu tester NVDA et Voice Over qui représentent à eux deux, la plus grosse part de marché dans le domaine des lecteurs d’écran ! Mais, il en existe plein d’autres ! Si vous êtes sous Linux par exemple et que n’avez donc pas accès à ces 2 là, vous pouvez utiliser des alternatives telles que ORCA.
Il existe également des plugins que l’on peut intégrer dans notre navigateur pour évaluer l’accessibilité d’une page web, comme Equal Access Accessibility Checker.
Développé par IBM, ce plugin disponible sur Chrome et Firefox va scanner la page web sur laquelle on se trouve et donner un score d’accessibilité. Ce scan vérifiera par exemple que l’on a bien des labels sur chaque élément qui doivent être lus (exemple: les boutons) ou encore que les contrastes entre un texte et le fond soient bien adaptés.
Plus d’informations sur Equal Access Accessibility Checker ici
Les ARIA (Accessible Rich Internet Applications) sont un ensemble d’attributs qui définissent comment rendre le contenu et les applications web accessibles. Ces attributs sont placés sur les balises HTMLHTML (HyperText Markup Language) est un langage permettant de décrire le découpage d'une page web. et permettent aux lecteurs d’écrans de savoir comment interagir avec les balises en question quand les fonctionnalités standards ne le permettent pas. Parmi ces indications, on retrouve le texte qui doit être lu, quand est-ce qu’il doit être lu ou encore le rôle de l’élément HTML. Voici des exemples des attributs aria les plus utiles :
C’est celui que l’on utilisera le plus. Il permet d’indiquer au lecteur d’écran quel texte doit être lu au passage sur l’élément HTML auquel il est rattaché.
<button type="button" aria-label="Ce texte sera lu par les lecteurs d’écran">Bouton avec aria-label</button>
Cet attribut prévient le lecteur d’écran d’un changement afin que l’on puisse indiquer à l’utilisateur des éléments qui apparaîtraient à l’écran, comme une popup par exemple. Il prend comme valeur le niveau de priorité du texte qui sera lu lors du changement sur cet élément. Il y en a 3 possibles :
Voici un petit exemple avec Angular, le bouton permet d’afficher/cacher les éléments avec aria-live à l’écran :
<button type="button" (click)="show()">Bouton de délenchement des aria-live</button>
<div *ngIf="test" aria-live="off">Ce texte ne sera pas lu</div>
<div *ngIf="test" aria-live="assertive">Ce texte sera lu en priorité</div>
<div *ngIf="test" aria-live="polite">Ce texte sera lu après les textes en cours de lecture</div>
test = false
show(): void {
this.test = !this.test
}
Aria-atomic Indique que le contenu de l’élément doit être lu comme une seule entité. Sans cela, seule la partie du contenu qui change sera lue.
Par exemple, si on passe de 2 à 3 utilisateurs, avec ce bloc html :
<div id="nb-user-info" aria-live="polite">
{{nbUser}} utilisateurs correspondants
</div>
Sans le aria-atomic, le texte qui sera lu au changement du nombre d’utilisateurs sera "3", si on modifie ce bloc pour y ajouter un aria-atomic="true" comme ceci :
<div id="nb-user-info" aria-live="polite" aria-atomic="true">
{{nbUser}} utilisateurs correspondants
</div>
Le texte lu sera alors "3 utilisateurs correspondant".
Ndlr: A noter que ce comportement dépend du lecteur d’écran que l’on utilise. Nous avons testé Voice Over et NVDA. Dans le cas de Voice Over, le texte entier sera lu même sans l’attribut aria-atomic.
Par défaut, tous les éléments avec lesquels un utilisateur peut interagir (et uniquement ceux-là) sont accessibles via la touche de tabulation. Ces éléments sont les boutons, les inputs et les liens. Il peut arriver que l’on ait besoin de rendre un élément atteignable avec la tabulation, ou simplement focalisable. Pour cela, on peut utiliser l’attribut tabindex
. Cet attribut permet d’indiquer aux navigateurs que l’élément auquel il est rattaché est focalisable. Sa valeur est un nombre et indique l’ordre dans lequel il doit être atteint. Voici un exemple :
<div tabindex="1">Texte 1</div>
<div tabindex="3">Texte 3</div>
<div tabindex="2">Texte 2</div>
Sans les tabindex, aucun de ces éléments ne pourrait être atteint avec la tabulation, car la balise <div>
n’est pas focalisable par défaut. Avec les tabindex, lors d’un déplacement avec la tabulation, l’utilisateur se déplacera dans l’ordre indiqué par la valeur de chacun d’eux. On aura donc Texte 1, puis Texte 2 et enfin Texte 3. Cependant, si l’on vient ajouter un bouton (qui est nativement focalisable), le navigateur ira d’abord sur la bouton, puis sur Texte 1, Texte 2 et Texte 3, ce qui n’est pas forcément le comportement souhaité :
<div tabindex="1">Texte 1</div>
<div tabindex="3">Texte 3</div>
<div tabindex="2">Texte 2</div>
<button type="button">Mon bouton</button>
Pour ne pas impacter l’ordre, il est possible d’utiliser la valeur 0 pour le tabindex. De cette façon, le navigateur lira les éléments dans leur ordre d’apparition dans le DOM.
<div tabindex="0">Texte 1</div>
<div tabindex="0">Texte 2</div>
<div tabindex="0">Texte 3</div>
<button type="button">Mon bouton</button>
A noter qu’il est également possible d’utiliser la valeur -1 pour le tabindex. Cette valeur a 2 utilités :
<button id="unaccessible-btn" type="button" tabindex="-1">Mon bouton inaccessible</button>
<button id="accessible-btn" type="button">Mon bouton accessible</button>
Dans cet exemple, seul le 2ème bouton pourra être atteint via la tabulation, mais il est toujours possible d’atteindre le premier de cette façon par exemple :
document.document.getElementById("unaccessible-btn").focus()
Dans le cas d’une <div>
qui ne serait pas accessible par défaut, le fait d’ajouter tabindex="-1" la rendra accessible via le .focus() mais pas via la tabulation.
Bien que les tabindex puissent être pratiques dans certains cas, il est recommandé de ne les utiliser que lorsque c’est réellement nécessaire. Dans le cas contraire, il faut privilégier les éléments qui sont naturellement focalisables comme les liens ou les boutons
Il est possible d’ajouter un attribut role
sur les balises html. Ces rôles permettent de donner des indications aux lecteurs d’écrans sur le but de l’élément. L’attribut role
prend en paramètres le nom du rôle. Il en existe plusieurs, voici quelques exemples :
Vous pouvez retrouver la liste des complète des rôles disponibles ici
Pour faciliter la mise en place de l’accessibilité sur votre application web ou votre site internet, il est aussi possible d’utiliser des kits de développement qui intègrent déjà certains éléments dans leurs composants ! Parmi les plus connus, nous pouvons citer Boostrap ou encore Material Design qui proposent tout un tas de classes CSSFeuilles de style qui permettent de mettre en forme des pages web. et de composants permettant d’améliorer l’accessibilité web en 2021.
L’accessibilité est également un sujet important sur vos applications mobiles ! Pour cela, nous avons rédigé un article dédié que vous pouvez retrouver à cette adresse.
Et vous, vous avez déjà réalisé des applications web accessibles ?
Accessibilité: Liste des points de vigilance sur l’accessibilité des applications web et la prise en compte des différents handicaps.
Découvrez la planche #39 !
Comment rendre une application web accessible ? Quels tests faut-il faire ? Zoom sur les outils dans cet article !