Liste de contrôle d'accessibilité logicielle (WCAG 2.2)

Qu'est-ce qu'une liste de contrôle d'accessibilité logicielle ?

Une liste de contrôle d'accessibilité logicielle est un ensemble de vérifications concrètes, à réponse oui ou non, qu'une équipe applique à un site web ou une application pour repérer les obstacles rencontrés par les personnes en situation de handicap. Les bonnes listes s'appuient sur les critères de succès WCAG, se regroupent selon le besoin de l'utilisateur (perceptible, utilisable, compréhensible, robuste) et servent pendant la conception, le développement et la mise en production. Une liste repère tôt les problèmes courants. Elle ne prouve pas la conformité à elle seule.

Ce qu'il faut vérifier

• Clavier. Chaque commande est-elle atteignable et utilisable au clavier seul, dans un ordre de navigation logique et sans piège ?
• Focus visible. L'élément qui a le focus est-il clairement visible (WCAG 2.4.7, niveau AA) ?
• Alternatives textuelles. Les images porteuses de sens ont-elles une description, et les images décoratives aucune ? Voir les images accessibles.
• Contraste. Le texte atteint-il 4,5:1, ou 3:1 pour du grand texte (au moins 18 points ou 14 points en gras ; WCAG 1.4.3, niveau AA) ? Voir les palettes de couleurs accessibles.
• Taille des cibles. Les cibles de pointeur font-elles au moins 24 sur 24 pixels CSS, ou sont-elles espacées de façon à respecter les exceptions (WCAG 2.5.8, nouveauté de la 2.2, niveau AA) ?
• Formulaires. Chaque champ a-t-il une étiquette, et les erreurs sont-elles décrites en texte et annoncées aux technologies d'assistance ?
• Structure et noms. Les titres, repères et noms des commandes sont-ils pertinents, et ARIA n'est-il utilisé que lorsque le HTML natif ne suffit pas ?
• Médias. La vidéo et l'audio ont-ils des sous-titres ou une transcription ? Voir les médias accessibles.
• Mise en page et zoom. L'interface fonctionne-t-elle encore une fois agrandie ou sur petit écran ? Voir la mise en page accessible.

Comment l'utiliser

• Choisissez d'abord la norme et le niveau, en général les WCAG 2.2 AA.
• Relisez les maquettes avec elle avant le développement et appliquez-la par fonctionnalité en revue de code.
• Lancez des analyses automatiques pour ce que le code permet de détecter, puis vérifiez le reste à la main avec un lecteur d'écran et le clavier. Voir les tests manuels et les tests automatisés.
• Consignez chaque échec avec la page, le critère et la correction, puis retestez.

Exemple de points

Un point concret se lit comme un test : « Sur la page de paiement, appuyez sur Tab depuis le haut. Chaque champ et chaque bouton reçoit un indicateur de focus visible dans l'ordre d'affichage, et Entrée envoie le formulaire. » Réussi ou échoué, avec la page nommée.

Erreurs fréquentes

• Voir dans une liste cochée ou une analyse Lighthouse sans alerte la preuve de la conformité aux WCAG. Les outils automatiques n'en vérifient qu'une partie.
• L'appliquer une fois avant le lancement plutôt qu'à chaque version.
• Ignorer les technologies d'assistance comme les lecteurs d'écran et les contacteurs.
• Ajouter de l'ARIA pour corriger ce qu'un HTML correct réglerait.

La place de LoadFocus

LoadFocus ne réalise pas d'audit d'accessibilité complet et ne délivre pas de rapports de conformité. La surveillance de la vitesse des pages lance des audits Lighthouse planifiés avec un score d'accessibilité, qui peut signaler des régressions sur ce que le code permet de détecter entre deux revues manuelles. Pour une vue d'ensemble, lisez tests de performance et accessibilité.

Questions fréquentes

Une checklist suffit-elle pour affirmer la conformité aux WCAG ?

Non. Une checklist repère les problèmes courants, mais la conformité s'apprécie par critère de succès sur un échantillon représentatif, et une partie exige une évaluation manuelle. La liste est un bon outil de travail, pas un certificat.

Quel niveau WCAG viser avec la checklist ?

Le niveau AA des WCAG 2.2 est la cible habituelle. Vérifiez si votre client, la loi ou le contrat citent une norme ou une version précise.

Quels sont les gains les plus rapides d'une checklist d'accessibilité logicielle ?

Une utilisation complète au clavier avec focus visible, une étiquette sur chaque champ de formulaire, un texte alternatif sur les images porteuses de sens et un contraste de texte suffisant corrigent une grande part des échecs courants.

Peut-on automatiser toute la checklist ?

Non. Des outils comme Lighthouse et axe détectent ce que le code révèle, mais des points comme l'ordre logique de tabulation, un texte alternatif pertinent et le comportement avec un lecteur d'écran demandent une personne.