Comment arrêter de deviner lors de la création d'interfaces accessibles

Vous êtes-vous déjà demandé pourquoi un simple bouton sur le web se comporte parfois étrangement lorsque vous essayez de le cliquer au clavier ? Ou pourquoi un lecteur d'écran se met soudain à débiter des sottises lorsque vous ouvrez une modale ? Habituellement, le problème vient des attributs ARIA. Nous avons l'habitude de les ajouter « à l'œil », en espérant que aria-label ou role="button" vont magiquement corriger une sémantique défaillante. Mais l'accessibilité n'est pas de la magie — ce sont des modèles d'interaction stricts.

Dans le dépôt w3c/aria-practices se trouve ce que j'appelle la « bible du développeur frontend ». Ce n'est pas une simple spécification ennuyeuse, mais un Authoring Practices Guide (APG) vivant qui explique exactement comment les menus déroulants, les onglets, les curseurs et les accordéons doivent fonctionner pour que absolument tout le monde puisse les utiliser.

De quoi parle ce projet

Le projet est géré par un groupe de travail du W3C. Ce sont essentiellement les personnes qui inventent les standards du web. Dans le dépôt, ils collectent des exemples de référence des implémentations de modèles d'interface. Si vous ne savez pas si le focus doit revenir au bouton après la fermeture d'une modale, ou quelles touches fléchées doivent permuter les onglets — c'est ici qu'il faut regarder.

De nombreux développeurs considèrent encore l'accessibilité (a11y) comme quelque chose d'optionnel. Mais lorsqu'un projet grandit, le manque de navigation clavier appropriée devient une dette technique. Ce dépôt aide à éliminer cette dette dès la phase de conception des composants.

Ce que propose ce dépôt

À l'intérieur, vous trouverez non seulement des règles arides, mais aussi des exemples de code fonctionnels. Voici quelques éléments auxquels je me réfère constamment dans ce projet.

Modèles de conception prêts à l'emploi

Pour chaque élément complexe (par exemple, Combobox ou Tree View), il y a une section séparée. Elle décrit le comportement clavier attendu et les rôles requis. Cela élimine le besoin de réinventer la roue. Vous prenez simplement la liste des exigences et vérifiez votre composant par rapport à celles-ci.

Exemples de code de référence

Dans le dossier examples, il y a des implémentations en HTML, CSS et JavaScript purs. Il n'y a pas d'abstractions inutiles, ni React, ni Vue — juste la logique d'accessibilité brute. C'est pratique lorsque vous avez besoin de comprendre comment lier les éléments id via aria-controls ou aria-labelledby pour que le lecteur d'écran annonce correctement le contexte.

Tests et linting

Curieusement, les auteurs utilisent un linting strict. Ils valident le HTML via NU HTML Validator, et le JS et CSS via ESLint et Stylelint standards. Si vous décidez de contribuer au projet, vous devrez installer le JDK pour le validateur HTML. Cela montre le niveau de sérieux : même dans les exemples de code, pas une seule erreur de validation n'est autorisée.

Comment utiliser cela dans votre travail

J'utilise souvent ce dépôt comme liste de contrôle. Par exemple, j'écris un select personnalisé. Au lieu de googler « comment faire un select accessible », je vais sur APG et je regarde la section Select-Only Combobox.

Là, je trouve :

1. Quels attributs l'élément parent doit avoir.
2. Comment gérer l'état aria-expanded.
3. Ce qui doit se passer lors de l'appui sur les touches Home, End ou PageUp.

Au fait, le dépôt contient des scripts pour les tests automatisés des exemples. La commande npm test exécute des tests qui vérifient le comportement des éléments dans le navigateur. C'est un excellent exemple de la façon dont vous pouvez automatiser les tests d'accessibilité dans vos propres projets.

L'aspect technique

Le projet fonctionne avec Node.js. Pour travailler localement, vous aurez besoin de :

• Node.js et npm pour exécuter les linters et les tests.
• JDK (Java Development Kit) pour la validation HTML.

Point intéressant : le projet est configuré avec une correction automatique des erreurs sur commit. Si vous avez mal espacé dans le CSS ou oublié le camelCase en JavaScript, le linter essaiera de le corriger lui-même avant de laisser le code entrer dans le dépôt.

Qui devrait consulter aria-practices

En premier lieu — les développeurs de bibliothèques de composants. Si vous écrivez votre propre système de design, ignorer ces pratiques n'est tout simplement pas une option. Le projet est également utile pour les ingénieurs QA : vous pouvez y trouver exactement comment une interface doit se comporter lors des tests d'accessibilité.

Je ne dirai pas que lire ce dépôt est un divertissement léger du soir. Les textes sont arides et il y a beaucoup d'exigences. Mais c'est la seule façon de créer des interfaces qui fonctionnent vraiment pour tout le monde, pas seulement pour ceux qui utilisent une souris.

Si vous en avez assez que vos modales « s'envolent » à la fin de la page à la fermeture, ou que vous voulez enfin comprendre à quoi sert aria-live, clonez simplement ce dépôt et voyez comment les pros du W3C le font. Lien vers le projet : w3c/aria-practices.