Après avoir vu les erreurs courantes en accessibilité web dans la première partie, cette suite se concentre sur des éléments clés pour rendre une interface utilisable par tous.
Nous commencerons par la navigation au clavier, utile pour ceux qui ne peuvent pas utiliser de souris. Puis, nous expliquerons les attributs ARIA et les rôles, qui enrichissent la sémantique et facilitent la lecture par les technologies d’assistance.
Enfin, nous présenterons des outils qui aident les développeurs à créer des applications accessibles, en détectant et corrigeant les erreurs au fil du développement.
6. La navigation au clavier
Lors du développement d’une interface, une règle essentielle guide les développeurs : l’usage d’une souris n’est pas obligatoire. Pour garantir l’accessibilité web, toutes les fonctionnalités doivent rester utilisables par ceux qui ne peuvent pas ou ne veulent pas utiliser de souris.
L’utilisateur se déplace entre les éléments avec la touche Tab, puis interagit avec eux via d’autres touches comme les flèches, Entrée, Espace ou Échap.
Les technologies d’assistance lisent l’élément actif. Cependant, pour ceux qui n’en utilisent pas, il faut ajouter un indicateur visuel sur l’élément actif pour que l’utilisateur puisse repérer sa position de navigation. Il faut alors utiliser l’état CSS `:focus-visible` qui s’active lorsqu’un élément reçoit le focus depuis une navigation au clavier.
Note : On utilise généralement la même représentation visuelle que l’état `:hover` pour représenter le `:focus-visible`
7. Les informations supplémentaires : ARIA et role
Les ARIA (Accessible Rich Internet Application) représentent l’ensemble des attributs HTML permettant de renseigner des informations supplémentaires sur les balises permettant de préciser son contenu, usage ou encore un état. Ces attributs permettent aux technologies d’assistance de mieux restituer les informations et les interactions disponibles pour l’utilisateur.
Ils s’associent généralement à l’attribut ‘role’, que nous avons déjà vu avec `role=bouton`. De nombreux rôles existent, chacun lié à des attributs ARIA bien définis.
Ces attributs ne remplacent pas la balise sémantique appropriée. Ils complètent la balise quand c’est nécessaire ou lorsqu’aucune balise ne correspond au besoin.
Il existe de nombreux rôles et ARIA pouvant être utilisés, mais voici une liste d’exemples :
- `role=”tooltip”` : Représente un texte de complément d’informations apparaissant dynamiquement lorsque qu’un élément reçoit l’état focus ou hover. Ils sont liés via les attributs `id` et `aria-describedby`
- `role=”switch”` : Transformation sémantique de la checkbox vers un état activé/désactivé
- `aria-hidden` : Permet de masquer le contenu du tag html pour les technologies d’assistance
- `aria-expanded` : Décrit l’état visible ou non d’un autre élément. Ils sont liés via les attributs `id` `aria-controls`
- `aria-current` : Déclare un élément comme étant celui “actif” dans une liste. Par exemple `aria-current=”page”` définit le lien de la page actuelle dans une liste de liens (pagination, breadcrumb, …)
En fonction de leurs natures, les ARIA doivent être mis à jour dynamiquement en utilisant du javascript. Il est possible d’utiliser l’attribute binding d’Angular, avec par exemple `[attr.aria-expanded]=”isExpanded”`.
Le aria-label
Nous allons parler plus en détail du `aria-label` qui est la propriété ARIA la plus utilisée (voire importante). En effet, elle permet de donner une signification au bloc entier sur lequel elle est affecté.
Prenons une liste d’articles composée d’une image, d’un titre et d’une description. Chaque article est un lien vers une page de détail. Les technologies d’assistance lisent tout le contenu de la carte, souvent sous forme de texte désordonné, pour indiquer ce que le lien contient. Pour faciliter la navigation, nous pouvons utiliser la propriété `aria-label avec le titre de l’article. Cela permet à l’utilisateur d’avoir un résumé clair du lien, tout en pouvant accéder aux détails s’il le souhaite.
<ul>
@for (article of articles; track article.id) {
<li>
<a
[routerLink]="[article.id]"
[attr.aria-label]="article.title"
>
<article>
<img [src]="article.src" [alt]="article.accs" />
<h3>{{article.title}}</h3>
<p>{{article.description}}</p>
</article>
</a>
</li>
}
</ul>
De la même façon, nous pourrions utiliser `aria-labelledby`, qui a la même utilité mais utilise la référence à un autre élément de la page via son id :
<ul>
@for (article of articles; track article.id) {
<li>
<a
[routerLink]="[article.id]"
[attr.aria-labelledby]="article.uniqueKey"
>
<article>
<img [src]="article.src" [alt]="article.accs" />
<h3 [attr.id]="article.uniqueKey">{{article.title}}</h3>
<p>{{article.description}}</p>
</article>
</a>
</li>
}
</ul>
8. Utiliser les bons outils
De nombreuses autres règles relatives à l’accessibilité web existent. Aujourd’hui, il existe de nombreux outils mis à notre disposition pour nous aider à développer de manière accessible tout en évitant d’éventuels oublis et erreurs.
Tout d’abord au travers des IDE, les logiciels permettant aux programmeurs de développer des applications. Ils sont fortement configurables et intègrent de plus en plus d’extensions facilitant l’expérience développeur. La console développeur intégrée dans les navigateurs inclut également une section permettant une meilleure représentation de l’accessibilité (via un onglet dédié) de la transcription faite de notre code html.
Ensuite via l’utilisation de linters d’accessibilité. Un linter et un outil intégré à un projet de développement permettant de définir des règles de développement. Ils aident ainsi à améliorer la qualité et la cohérence du code entre les différents membres d’une équipe. Il existe aujourd’hui une large variété de linter d’accessibilité, soit directement intégrés dans des linters plus globaux (c’est le cas d’angular eslint par exemple), soit plus spécialisés (a11y, html-validate, …). A vous de choisir le(s) plus adapté(s).
La mise en place de différents critères d’accessibilité dans les différents tests automatisés (unitaires ou e2e) ou fonctionnels via des normes définies est aussi un bon moyen de garantir la validité du code et des différentes fonctionnalités d’une application.
Fin de cette deuxième partie, la suite, consacrée à un cas pratique sur l’accessibilité web d’un menu déroulant, sera disponible très prochainement.
Alexandre PICARD
Practice Leader Product Development à Toulouse
& Tech Lead Angular
