Accessibilité web
Comment construire un site que tout le monde peut utiliser – y compris avec un lecteur d’écran, un texte agrandi ou uniquement au clavier. La série présente les exigences des WCAG 2.2, le droit européen et français, la structure de la page, les textes alternatifs, les formulaires, l’utilisation au clavier, ARIA et les tests. Les exemples ont passé le validateur et l’outil axe-core, et leur fonctionnement a été vérifié dans Chrome, Firefox et Safari (moteur WebKit).
Un site accessible peut aussi être utilisé par quelqu’un qui ne voit pas, voit mal, n’entend pas ou n’utilise pas de souris. Ce que cela signifie en pratique, comment sont construites les WCAG 2.2 et qui est concerné par le droit de l’UE et le droit français – organismes publics et boutiques en ligne.
Un lecteur d’écran sait sauter d’un titre à l’autre et d’une zone de la page à l’autre – à condition que la page en ait. Comment bâtir le squelette d’une page avec la langue, les titres et les repères, ajouter un lien d’évitement et quand masquer un texte pour ne le réserver qu’aux lecteurs d’écran.
Pour une personne aveugle, une image sans description est un vide et un bouton avec une icône sans nom n’est qu’un « bouton ». Comment rédiger un bon texte alternatif, quand le laisser vide, comment nommer les icônes et les SVG, et ce qu’il ne faut pas oublier pour les vidéos et les animations.
C’est par les formulaires qu’un site rapporte – commande, inscription, demande. Et c’est justement là que bloquent le plus souvent les personnes avec un lecteur d’écran ou au clavier. Comment décrire les champs, signaler les champs obligatoires, annoncer une erreur et faciliter la saisie.
Tout ce qui fonctionne à la souris doit aussi fonctionner au clavier. Comment le focus parcourt la page, pourquoi éviter un tabindex positif, comment rendre le focus visible sans qu’il disparaisse sous un en-tête fixe, et comment ouvrir et fermer correctement une boîte de dialogue.
ARIA dit aux lecteurs d’écran ce que le HTML seul ne dit pas – si un menu est déroulé, quel onglet est sélectionné ou qu’un message est apparu. Quand l’utiliser, comment construire un menu déroulant et des onglets, et pourquoi un mauvais ARIA est pire que pas d’ARIA du tout.
Un outil automatique trouve en quelques secondes les étiquettes manquantes ou un contraste insuffisant – mais seulement une partie des problèmes. Comment calculer le contraste, vérifier un site avec axe-core et Lighthouse, intégrer le contrôle aux tests automatiques, et ce qu’il faut parcourir à la main et avec un lecteur d’écran.