La réponse en bref
Commencez le travail d’accessibilité par la tâche essentielle : une personne peut-elle comprendre l’offre, atteindre le formulaire, corriger ses erreurs et recevoir une confirmation, quelle que soit sa manière d’interagir ? Combinez un parcours au clavier, une revue des contenus et des formulaires, des contrôles du zoom et de la redistribution, des diagnostics automatisés et des critères de validation avec un responsable désigné. Il s’agit d’un premier diagnostic, pas d’une garantie de conformité aux WCAG ni d’un avis juridique.
- Testez une tâche client complète plutôt que des pages isolées.
- Un focus visible et non masqué ainsi que des erreurs de formulaire faciles à corriger sont essentiels à l’activité commerciale.
- Les analyses automatisées détectent certains problèmes, mais ne peuvent pas établir une conformité complète.
- Consignez l’impact, le responsable, les preuves et le statut du nouveau test pour chaque constat.
Sur cette page
Définir le parcours avant de contrôler les composants
Une revue de l’accessibilité débouche plus facilement sur des mesures concrètes lorsqu’elle suit un véritable objectif client. Choisissez un parcours critique, par exemple comprendre un service, ouvrir la navigation, atteindre un formulaire de devis, corriger une erreur et l’envoyer. Incluez les fenêtres de consentement et les autres éléments superposés, car ils peuvent interrompre le parcours.
Le W3C présente ses contrôles simples comme une première revue uniquement. Une page peut sembler les réussir tout en comportant des obstacles importants. Utilisez cette liste pour dégager les priorités et produire des preuves d’acceptation, pas pour certifier un site ou tirer une conclusion juridique.
Avant le test, notez le point de départ, l’issue attendue et les obstacles possibles. Une société suisse de conseil fictive pourrait définir la réussite ainsi : sélectionner des services de conseil, lire l’étendue de la mission, envoyer une demande de rappel et recevoir une confirmation claire.
- Choisissez une tâche à forte valeur et une tâche purement informative.
- Incluez la navigation, les éléments superposés, les formulaires, les erreurs et la confirmation.
- Testez des modèles représentatifs sur mobile et sur ordinateur.
- Distinguez les obstacles observés des suppositions.
| Étape du parcours | Besoin du client | Défaillance qui bloque la progression | Preuve |
|---|---|---|---|
| Comprendre le service | Titre clair et explication lisible | Structure ambiguë ou contenu manquant | Revue de la page |
| Accéder à la demande | Navigation prévisible et fonction des liens compréhensible | Menu inaccessible au clavier | Enregistrement du parcours au clavier |
| Envoyer les informations | Libellés, consignes et erreurs corrigibles | Champ sans libellé ou saisie perdue | Test du formulaire |
| Confirmer le résultat | Statut et prochaine étape clairs | Échec silencieux ou focus laissé en arrière | Contrôle du reçu et du focus |
Effectuer un parcours de 15 minutes au clavier
Mettez la souris de côté. Utilisez Tab et Maj+Tab pour vous déplacer, Entrée ou Espace pour activer les commandes, et Échap lorsqu’une boîte de dialogue ou un menu doit se fermer. À chaque étape, vérifiez où se trouve le focus, si son ordre est logique et si la commande ciblée est visible.
Un piège au clavier constitue un obstacle majeur : le focus entre dans un composant, mais les touches habituelles ne permettent plus d’en sortir. Repérez également les commandes entièrement ignorées, les arrêts en double, le focus qui passe dans un contenu masqué et les composants personnalisés qui ne réagissent pas comme leurs équivalents natifs.
Recommencez le parcours après avoir ouvert la navigation, déclenché des erreurs de validation et utilisé les commandes de consentement. Les états dynamiques se comportent souvent différemment de l’état initial de la page.
- Partez de la barre d’adresse du navigateur et atteignez le contenu principal.
- Ouvrez et fermez chaque commande du parcours.
- Remplissez le formulaire et provoquez volontairement des erreurs.
- Après l’envoi, vérifiez que le focus se déplace vers un retour utile.
| Étape | Focus visible | Ordre logique | Commande fonctionnelle | Résultat |
|---|---|---|---|---|
| Fermer la fenêtre de consentement | Oui ou non | Première action pertinente | Entrée et Échap | Valider, corriger ou examiner |
| Ouvrir la navigation | Oui ou non | Déclencheur puis menu | Entrée, flèches si prévu, Échap | Valider, corriger ou examiner |
| Corriger l’erreur d’adresse e-mail | Oui ou non | Erreur puis champ | Tab et saisie | Valider, corriger ou examiner |
| Envoyer la demande | Oui ou non | Bouton puis statut | Entrée | Valider, corriger ou examiner |
Vérifier que les contenus fixes et superposés ne masquent pas le focus
Les WCAG 2.2 comprennent un critère de niveau AA qui exige qu’un composant recevant le focus au clavier ne soit pas entièrement masqué par un contenu créé par l’auteur. Les en-têtes fixes, bandeaux de cookies, boutons de lancement d’un chat et barres d’action placées en bas de l’écran sont des sources fréquentes d’obstruction.
Faites défiler la page au clavier et examinez le focus à proximité de chaque élément fixe. Testez avec une fenêtre étroite et un zoom accru, car un bandeau de taille modeste peut alors occuper une grande partie de la zone visible. La fermeture d’un élément superposé doit rendre le focus à la commande qui l’a ouvert, sauf si l’interaction prévoit une autre destination dûment documentée.
Ne remédiez pas à une obstruction en supprimant le focus visible. Ajustez les décalages, la mise en page, l’ordre de superposition et le comportement de défilement afin que l’utilisateur puisse à la fois repérer et actionner la commande.
- Testez les en-têtes fixes et les barres inférieures avec plusieurs tailles de fenêtre.
- Ouvrez des éléments superposés dans des combinaisons réalistes.
- Vérifiez que le focus reste dans la boîte de dialogue ouverte et revient au bon endroit à sa fermeture.
- Vérifiez que les cibles d’ancrage ne sont pas masquées sous les en-têtes.
Examiner les titres, les liens et les textes alternatifs des images
Un titre de page pertinent et une hiérarchie de titres cohérente aident les personnes à comprendre où elles se trouvent et comment le contenu est structuré. Examinez le plan sans vous fier à la taille visuelle. Les titres doivent décrire le contenu qui suit, tandis qu’une simple mise en évidence doit rester du texte ordinaire.
Le texte d’un lien doit être compréhensible dans son contexte. Une série de liens intitulés En savoir plus crée une ambiguïté évitable lorsqu’ils mènent à des services différents. Nommez la destination ou l’action. Les images ont besoin de textes alternatifs qui transmettent leur fonction, tandis que les images décoratives ne doivent pas ajouter de bruit.
Les contrôles du contraste et des couleurs doivent couvrir les états réels, notamment le survol, le focus, les commandes désactivées, les erreurs et le texte placé sur une image. N’utilisez pas uniquement la couleur pour communiquer un statut.
- Vérifiez la présence d’un titre de page clair et d’un titre principal descriptif.
- Lisez les liens hors de leur texte environnant.
- Adaptez le texte alternatif à la fonction de l’image.
- Examinez les états normal, survolé, ciblé, erroné et désactivé.
Tester les formulaires, les erreurs et la reprise du parcours
Un formulaire doit identifier chaque champ, expliquer les formats inhabituels et conserver les saisies utiles en cas de problème. Un texte indicatif n’est pas un libellé durable. Le caractère obligatoire d’un champ et les messages d’erreur doivent rester compréhensibles sans dépendre uniquement de la couleur ou de la position.
Envoyez des valeurs vides, mal formées et réalistes. Vérifiez que le message indique le problème et la manière de le corriger, puis observez où se déplace le focus du clavier et du lecteur d’écran. Simulez aussi une panne du réseau ou de l’acheminement, en plus d’un échec de validation. La personne ne doit pas perdre un message soigneusement rédigé.
La réussite mérite la même attention. Indiquez ce qui a été accepté et ce qui va se passer ensuite, sans garantir la réception dans une boîte de messagerie ni annoncer un délai de réponse que l’entreprise ne peut pas tenir.
- Associez des libellés visibles aux champs.
- Laissez les consignes accessibles pendant la saisie.
- Décrivez précisément les erreurs et conservez les valeurs valides.
- Testez l’échec et la réussite dans le parcours d’acheminement en production.
| Test | Comportement attendu | Bloquer le lancement lorsque |
|---|---|---|
| Valeur obligatoire manquante | Champ identifié et consigne de correction fournie | L’utilisateur ne peut pas localiser ou comprendre l’erreur |
| Adresse e-mail invalide | Problème de format expliqué sans effacer les autres champs | Le formulaire tourne en boucle ou supprime le contenu |
| Échec de l’acheminement | Message honnête et saisie conservée | L’interface annonce à tort une réussite |
| Envoi accepté | Le statut reçoit le focus et la prochaine étape est claire | Aucune confirmation ou statut inaccessible |
Soumettre le zoom, la redistribution et les états visuels à une revue humaine
Augmentez le zoom du navigateur et testez des fenêtres étroites. Le contenu doit rester lisible et utilisable sans collision du texte, disparition des commandes ni défilement horizontal nécessaire pour un texte courant. Les tableaux de données peuvent nécessiter une zone de défilement dotée d’un libellé et accessible au clavier.
Ne désactivez pas l’agrandissement par l’utilisateur. Testez de longs libellés traduits, des messages d’erreur détaillés et les réglages de texte du navigateur, car le contenu réel fragilise souvent des mises en page qui semblaient stables avec les textes courts de la maquette.
Sur un véritable appareil mobile, contrôlez l’orientation et le comportement du clavier virtuel. Le champ ciblé doit rester visible et le clavier ne doit pas recouvrir l’action d’envoi.
- Testez l’agrandissement du texte et sa redistribution dans une fenêtre étroite.
- Recherchez les contenus coupés, les chevauchements et les actions masquées.
- Examinez séparément les tableaux et les autres contenus volontairement bidimensionnels.
- Recommencez avec des chaînes traduites réalistes.
Utiliser l’automatisation comme élément de preuve, pas comme verdict
Les outils automatisés sont utiles pour détecter de manière reproductible des problèmes tels que des libellés manquants, des attributs non valides et certains défauts de contraste. Ils ne peuvent pas juger si un texte alternatif est pertinent, si les titres sont utiles, si l’ordre du focus suit la tâche ou si une erreur est compréhensible.
Lancez une analyse automatisée sur des modèles et des états d’interaction représentatifs, puis combinez ses résultats avec des revues au clavier, avec zoom, des contenus et des technologies d’assistance. Lorsque cela est proportionné, associez des personnes en situation de handicap aux recherches et aux tests.
Un score automatisé élevé ne prouve pas la conformité. Consignez l’outil, sa version, l’URL, l’état et la date afin qu’une analyse ultérieure puisse reproduire le constat.
- Analysez des modèles représentatifs, pas seulement la page d’accueil.
- Ouvrez les menus, les boîtes de dialogue et les erreurs avant d’analyser ces états.
- Regroupez les constats identiques liés à un même composant.
- Après une correction, recommencez le test manuellement.
Transformer les constats en critères d’acceptation attribués
Une liste de problèmes devient utile lorsqu’elle identifie les utilisateurs concernés, la tâche bloquée, le responsable du composant et les preuves nécessaires à la clôture. Traitez en priorité les obstacles qui empêchent de naviguer, de comprendre, de saisir des informations ou d’obtenir une confirmation, avant les imperfections esthétiques.
Rédigez les critères d’acceptation sous une forme observable. Par exemple : avec un zoom de 200 pour cent, le parcours de contact peut être achevé sans chevauchement du contenu ; ou, après un envoi non valide, le focus atteint le récapitulatif des erreurs et chaque erreur renvoie à son champ. Évitez les exigences vagues telles que rendre le site accessible.
Testez de nouveau le parcours initial et les composants associés. Une modification de la navigation ou d’un formulaire partagé peut corriger plusieurs pages, mais aussi créer des régressions ailleurs.
- Consignez la gravité, l’impact sur la tâche, le composant et le responsable.
- Joignez les étapes de reproduction et le comportement attendu.
- Exigez une preuve du nouveau test avant la clôture.
- Gardez les obstacles non résolus visibles dans la validation du lancement.
VOS QUESTIONS, NOS RÉPONSES
Questions fréquentes
La réussite de cette liste de contrôle prouve-t-elle la conformité aux WCAG ?
Non. Il s’agit d’une première revue ciblée. Le W3C précise que des pages peuvent sembler réussir les contrôles simples tout en comportant des obstacles importants. Une évaluation complète exige des tests plus étendus.
Un score d’accessibilité automatisé peut-il remplacer les tests manuels ?
Non. L’automatisation peut repérer certains schémas techniques, mais elle ne peut pas évaluer de façon fiable le sens, le déroulement d’une tâche, l’ordre du focus ou la clarté du processus de correction.
Quel parcours une entreprise doit-elle tester en premier ?
Commencez par la tâche la plus importante pour les clients et le chiffre d’affaires, par exemple trouver un service et envoyer une demande. Incluez les erreurs et la confirmation.
Le niveau AA des WCAG 2.2 est-il obligatoire pour toutes les entreprises suisses ?
Ce guide ne tire aucune conclusion juridique. Les WCAG constituent une norme technique. Demandez conseil en fonction de l’entreprise, du service et des juridictions concernés.
Un module d’accessibilité superposé peut-il rendre le site conforme ?
Aucun outil ni module superposé ne peut établir à lui seul une conformité complète. Corrigez les obstacles dans les contenus, le design et le code, puis testez le parcours réel.
POUR ALLER PLUS LOIN
