Rechercher
Saisissez au moins deux caractères, sans donnée personnelle.

    BibliothèqueArticles et FAQ Votre projetDemander un devis
    LangueFR
    Guides pratiques

    Tester l’accessibilité d’un site web avec méthode

    Un contrôle utile suit les tâches que les visiteurs doivent accomplir. Il combine plusieurs modes de navigation et consigne les obstacles observés, page par page et étape par étape.

    Voir la méthode

    Illustration de la préparation d’un projet web : Tester l’accessibilité d’un site web avec méthode

    Choisir des pages et des tâches représentatives

    Commencez par l’accueil, une page de contenu longue, une liste filtrable, un formulaire et une page d’erreur. Ajoutez les variantes mobiles et les langues publiées. Notez pour chaque parcours le point de départ, l’action attendue et ce qui confirme sa réussite.

    Conservez l’URL, la largeur d’écran, le navigateur et la date de chaque constat. Une capture seule ne décrit pas un blocage de clavier ou un message annoncé au mauvais moment.

    • Accéder à une information depuis le menu.
    • Trouver un résultat avec un filtre.
    • Envoyer puis corriger un formulaire.

    Parcourir sans souris

    Rechargez la page et utilisez Tab, Maj+Tab, Entrée, Espace et les flèches selon le contrôle. Le focus doit rester visible et suivre un ordre compréhensible. Ouvrez le menu, changez les filtres, atteignez les liens après une carte et fermez les éventuelles fenêtres sans piège au clavier.

    Vérifiez aussi les liens d’évitement et les ancres. Après un saut dans la page, la position de lecture doit permettre de reprendre au bon endroit. Les contrôles rapides du W3C donnent une première méthode, sans remplacer un audit complet.

    Lire la page autrement

    Agrandissez le texte et le zoom jusqu’à 200 %, puis testez une largeur proche d’un téléphone. Le contenu essentiel et les boutons doivent rester disponibles sans défilement horizontal imposé. Contrôlez le contraste des textes, du focus et des messages importants avec un outil de mesure adapté.

    Parcourez la liste des titres et des liens avec un lecteur d’écran. Les titres doivent décrire les sections, les liens être compréhensibles hors du paragraphe et les images porteuses d’information avoir une alternative utile. Une image décorative peut avoir un alt vide.

    Comparer deux couleurs

    Saisissez deux couleurs opaques au format hexadécimal, par exemple #285B86. Le calcul reste dans cette page.

    Trois paires, trois décisions différentes

    Ces couleurs de démonstration sont opaques, sur fond blanc. Comparez les valeurs et leur usage, puis chargez une paire dans le calculateur.

    #647D66 / #FFFFFF

    Un arrondi qui induit en erreur

    #647D66 sur blanc donne environ 4,499512:1. Un affichage à deux décimales montrerait 4,50:1, mais le seuil AA du texte courant reste non atteint. Décidez avec la valeur non arrondie.

    Rapport approximatif
    4,499512:1
    Texte courant · AA ≥ 4,5:1
    Seuil non atteint

    #767676 / #FFFFFF

    Une correction à vérifier en contexte

    #767676 sur blanc dépasse 4,5:1 et atteint ici le seuil AA du texte courant, mais pas AAA. La marge est faible : contrôlez les couleurs réellement appliquées, les états et la finesse des caractères.

    Rapport approximatif
    4,542225:1
    Texte courant · AA ≥ 4,5:1
    Seuil atteint

    #949494 / #FFFFFF

    3:1 ne suffit pas pour tout

    #949494 sur blanc dépasse 3:1, mais reste sous 4,5:1. Ce contraste peut convenir à certaines informations graphiques selon WCAG 1.4.11 ; il ne valide pas le texte courant de leur légende. Contrôlez aussi les autres couleurs adjacentes.

    Rapport approximatif
    3,033470:1
    Texte courant · AA ≥ 4,5:1
    Seuil non atteint

    Inverser deux couleurs opaques conserve leur rapport. Vérifiez néanmoins leur rôle réel et chaque état du composant.

    Le grand texte correspond au moins à 18 points (24 pixels CSS), ou 14 points en gras (environ 18,7 pixels CSS). Le résultat compare seulement ces deux couleurs opaques : vérifiez séparément les images de fond, transparences, états de focus et composants. Il ne constitue pas une évaluation complète de l’accessibilité.

    W3C · WCAG 2.2 · 1.4.3 · WCAG 2.2 · 1.4.11 · WCAG 2.2 · sRGB ·

    Tester les erreurs et les changements dynamiques

    Soumettez le formulaire vide, puis avec une adresse incorrecte. Le message doit expliquer quel champ corriger, rester associé à ce champ et ne pas effacer les réponses valides. Après envoi, confirmez que l’état de succès ou d’échec est perceptible sans dépendre de la couleur.

    Dans les recherches et filtres, vérifiez le nombre de résultats, l’état vide et l’annonce des changements au lecteur d’écran. Une interface qui fonctionne à la souris peut rester incompréhensible lorsque son contenu change sans indication.

    • Étape exacte qui échoue.
    • Effet sur la tâche de l’utilisateur.
    • Correction attendue et nouvelle vérification.

    Prioriser puis faire évaluer

    Corrigez d’abord les obstacles qui empêchent de lire, naviguer, comparer ou contacter. Rejouez le parcours après correction sur les mêmes pages et notez le résultat. Les outils automatiques accélèrent la détection de certains problèmes, mais ne vérifient ni la pertinence d’un texte alternatif ni la logique d’un parcours.

    Ce contrôle préalable ne permet pas de déclarer une conformité. Si une obligation ou une déclaration d’accessibilité s’applique, faites conduire l’évaluation appropriée selon le référentiel concerné, par exemple le RGAA en France. Le contrôle avant mise en ligne aide à intégrer ces essais à la recette du projet.

    Vérifier les changements d’état, pas seulement la page initiale

    Préparez un parcours avec ouverture du menu, passage dans une fenêtre et confirmation d’une action. Relevez où arrive le focus, ce qui est annoncé et comment revenir sans perdre les données. Une capture du premier écran ne révèle pas les liens invisibles d’un panneau fermé ni un message qui disparaît avant d’être lu.

    Refaites le parcours avec des libellés longs et une fenêtre étroite. Vérifiez également les messages d’attente et d’échec : un composant correct dans le cas idéal peut empêcher de reprendre une tâche lorsque le service distant ne répond plus.

    Concevoir et tester une fenêtre de dialogue modale · Concevoir une navigation mobile et ses sous-menus · Rédiger et annoncer les messages d’état d’une interface

    Tester un parcours au clavier

    Main utilisant un clavier externe à côté d’un ordinateur portable
    Tester le parcours au clavier sur les états réellement publiés.

    Cas proposé : un lien reçoit le focus mais une couche fixe le masque. Le contrôle est présent dans le code, pourtant la personne ne sait plus où elle agit.

    Déroulez une tâche complète au clavier, y compris ouverture et fermeture des panneaux. Notez ordre, visibilité et retour du focus ; un passage sur la page d’accueil ne couvre pas tous les états.

    • Choisir une tâche complète
    • Observer le focus à chaque étape
    • Documenter l’état qui bloque

    Contrôler l’effort cognitif dans le processus complet

    Ne testez pas seulement le premier formulaire : connexion, récupération, récapitulatif et correction peuvent chacun introduire un obstacle. Distinguez les saisies répétées dans une même activité des informations demandées lors d’une session ultérieure ; WCAG 3.3.7 n’impose pas un stockage entre sessions.

    Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

    Contrôler l’effort cognitif dans le processus complet
    SituationRésultat attenduLimite à vérifier
    Donnée répétéeChercher un préremplissage ou une possibilité de sélection.L’autocomplétion du navigateur seule ne démontre pas la conformité.
    Mot de passe ou codeEssayer le remplissage par un gestionnaire et le collage du code complet.Ne pas imposer une transcription manuelle dans des cases séparées.
    CorrectionModifier une réponse et refaire le récapitulatif.Consigner le résultat observé et l’obstacle restant.
    • W3C WAI · WCAG 3.3.7

      Lire la portée et les exceptions du critère ; ce scénario est une application pratique, pas un certificat de conformité.

    Transformer une alerte en vérification du parcours

    1. Ouvrir l’état utile
    2. Lire le constat
    3. Reproduire la tâche
    4. Vérifier la correction

    Une liste d’erreurs automatisées est un point de départ. Pour chaque constat, ajoutez la tâche empêchée, l’état de l’interface et la manière de reproduire le problème. WAVE peut repérer un attribut manquant ; le sens d’un texte alternatif ou la facilité d’une tâche exige une appréciation humaine.

    Exemple de contrôle : une image informative possède un texte alternatif, mais celui-ci décrit un autre produit. La présence de l’attribut ne suffit pas. Comparez le sens transmis, corrigez le texte, puis relisez la page sans les images ; complétez par les contrôles manuels applicables.

    Documents de référence

    Contenu mis à jour le

    Repères documentaires pour ce sujet

    Repères documentaires pour ce sujet
    RéférenceValeur ou syntaxePortée du repère
    WCAG 2.2 · 1.4.3
    4.5:1 / 3:1Texte courant / grand texte (18 pt ou 14 pt gras) ; exceptions prévues par le critère.
    WCAG 2.2 · 2.5.8
    24 × 24 CSS pxUne cible plus petite peut satisfaire le critère grâce à l’espacement ; d’autres exceptions existent.
    WCAG 2.2 · 1.4.10
    320 CSS pxContenu vertical sans défilement dans deux dimensions ; exceptions pour les contenus intrinsèquement bidimensionnels.
    WCAG 2.2 · 1.4.4
    200 %Le texte agrandi conserve contenu et fonctions ; exceptions pour sous-titres et images de texte.
    WCAG 2.2 · 3.3.7
    A · same processDans un même processus, une information déjà fournie doit être préremplie ou disponible à la sélection, sauf exceptions du critère. L’autocomplétion du navigateur seule ne suffit pas ; le site doit proposer la donnée déjà reçue ou éviter de la redemander.
    WCAG 2.2 · 3.3.8
    AA · authenticationUne étape d’authentification qui exige de mémoriser ou transcrire doit offrir une aide ou une autre voie, selon les exceptions du critère. Tester le gestionnaire de mots de passe et le collage des codes ; une alternative audio à transcrire ne supprime pas à elle seule l’effort cognitif.

    Les dates indiquent la consultation des références. Ces repères ne constituent ni un audit du site ni une déclaration globale de conformité.

    Matrice de recette à adapter au projet

    Ces contrôles proposés utilisent des cas fictifs. Décidez du comportement attendu avec l’équipe, notez le résultat et attribuez les écarts non résolus avant publication.

    Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

    Cas de test, résultats attendus et preuves utiles
    CasRésultat attenduPreuve à conserver
    Le menu mobile est testé uniquement à la souris.Ouvrir, parcourir et fermer au clavier, avec un focus visible et un ordre compréhensible.Séquence de touches, élément actif à chaque étape et destination du focus après fermeture.
    Un menu fermé conserve des liens invisibles dans la tabulation.Les liens masqués cessent de prendre le focus ; les destinations restent accessibles après ouverture.Ordre de focus menu fermé puis ouvert, sans utilisation de la souris.

    Questions fréquentes

    Un score automatique peut-il certifier l’accessibilité ?

    Non. Il révèle certains défauts mais ne juge pas seul le sens d’un lien, la pertinence d’une alternative ou la réussite d’un parcours au clavier. Associez outils, vérification humaine et périmètre documenté. Une conclusion doit expliquer ce qui a été testé et les limites de l’échantillon.

    Comment tester une fenêtre modale au clavier ?

    Ouvrez-la sans souris, vérifiez où arrive le focus et parcourez ses commandes. Dans une modale active, la navigation reste dans le dialogue. Testez sa fermeture et le retour du focus vers une commande logique pour poursuivre la tâche.

    Quelles pages inclure dans un contrôle d’accessibilité ?

    Retenez des types de pages, composants et états différents, puis des parcours complets. Incluez formulaire en erreur, recherche vide, navigation mobile et documents utiles. Décrivez les exclusions : un échantillon favorable ne démontre pas la conformité de toutes les pages.