Choisir les parcours
Incluez entrée depuis une page, navigation, formulaire, confirmation et état d’erreur. Testez aussi une page sur mobile et à fort zoom.
GUIDE / PROTOCOLE
Auditer l’accessibilité d’un parcours web
L’accessibilité se juge dans une tâche complète : trouver, comprendre, agir et récupérer après une erreur.
Réponse directe
Comment mener un audit d’accessibilité utile ?
Choisissez des parcours représentatifs et leurs états critiques. Combinez inspection du code, navigation au clavier et essais avec technologies d’assistance. Rattachez chaque défaut à une tâche bloquée, une exigence WCAG, une preuve et un nouvel essai.
01 / Méthode de contrôle
Méthode de contrôle
Parcourir au clavier
Vérifiez ordre de focus, visibilité du focus, accès à chaque commande, menus, modales et sortie des composants. Aucun piège clavier ne doit rester.
Vérifier sens et restitution
Contrôlez titres, noms accessibles, étiquettes, alternatives d’images, structure, contraste et annonces d’erreur avec un lecteur d’écran.
Prioriser puis rejouer
Classez les blocages par tâche et gravité, corrigez le composant partagé, puis rejouez le parcours et les pages qui le réutilisent.
EN PRATIQUE
Vérifier un parcours, pas seulement une capture
Un écran lisible peut encore bloquer une action. Testez un objectif complet : trouver la bonne section, utiliser le contrôle, comprendre le résultat et revenir en arrière. Consignez le premier obstacle et son effet concret.
Quel contrôle effectuer en premier ?
Choisissez la situation observée. Chaque piste précise une première vérification, la preuve utile et la limite de ce contrôle.
Le parcours fonctionne à la souris, pas au clavier
- Premier contrôle
- Reprenez une tâche avec Tab, Maj+Tab, Entrée et les touches attendues du composant. Suivez le focus : où entre-t-il, quel contrôle reçoit-il et peut-on sortir d’un menu ou d’un dialogue ?
- Preuve à conserver
- Étape, touche, contrôle actif, état ouvert ou fermé et point exact où le parcours se bloque ou devient incompréhensible.
- Limite à garder en tête
- Un ordre de focus cohérent ne certifie pas toute l’accessibilité. Le nom des contrôles, les états annoncés et la lecture du contenu doivent aussi être examinés.
Un formulaire refuse la saisie sans expliquer pourquoi
- Premier contrôle
- Provoquez une erreur sur un champ puis relisez son intitulé, son format attendu et le message associé. Vérifiez qu’une correction est possible sans perdre les autres valeurs utiles.
- Preuve à conserver
- Champ concerné, valeur d’essai non sensible, message, lien entre erreur et champ, comportement du focus et résultat après correction.
- Limite à garder en tête
- Un message visible ne garantit pas qu’il soit relié au champ ou annoncé au bon moment. Vérifiez également l’envoi, l’accusé de réception et le cas d’indisponibilité.
Le texte déborde ou devient difficile à lire
- Premier contrôle
- Réduisez la largeur, agrandissez le texte et reprenez la tâche. Repérez le composant qui force toute la page à défiler horizontalement ; distinguez-le d’un tableau qui exige ses deux dimensions.
- Preuve à conserver
- Largeur de fenêtre, niveau de zoom, langue, composant, texte masqué et besoin réel de défilement dans deux directions.
- Limite à garder en tête
- Une capture mobile isolée ne couvre pas tous les zooms, langues et états. Une exception de tableau ne justifie pas le débordement de toute la page.
Pour approfondir
| Situation | À éviter | Correction utile |
|---|---|---|
| Navigation | Tester uniquement à la souris. | Parcourir au clavier et conserver un focus visible. |
| Formulaire | S’appuyer sur un texte provisoire dans le champ. | Garder un libellé visible et relier l’erreur au champ concerné. |
| Résultat dynamique | Changer un chiffre sans expliquer son contexte. | Présenter le résultat, son unité et ce qui vient de changer. |
Repérer
Le titre décrit-il la bonne tâche ?
Agir
Le contrôle est-il accessible et compréhensible ?
Comprendre
Le résultat et la prochaine action sont-ils explicites ?
Contrôle final
Rejouez le parcours avec Tab, Maj+Tab et Entrée, puis à 200 % de zoom. Lors du défilement, vérifiez que l’en-tête fixe ne masque pas entièrement le contrôle qui reçoit le focus. Ouvrez et fermez le menu au clavier, provoquez une erreur de formulaire et vérifiez que vous pouvez la corriger. Notez la page, l’action et l’obstacle observé ; ces essais ciblés ne constituent pas une certification WCAG.
Références documentaires
Consulté le .
Atelier de lecture
Tester le cycle entier d’une boîte modale
Le cas fictif DEMO-A23 observe ouverture, état désactivé, arrière-plan et fermeture d’un dialogue de révision.
Données et traces fictives pour apprendre : aucun résultat présenté ici ne provient d’un service interrogé en direct.
Confirmer un choix après lecture
Le dialogue contient un titre, une case « lecture terminée », un bouton Confirmer initialement désactivé et Annuler. Le déclencheur reste présent après fermeture.
Ouvrir au clavier
- Observation du cas
- Le focus arrive sur le titre à lire
- Ce que cela établit
- La tâche commence dans le dialogue, pas derrière lui.
- Suite à donner
- Vérifier le nom annoncé et la lecture de la consigne.
Parcourir l’état initial
- Observation du cas
- Tab atteint la case puis Annuler ; Confirmer est désactivé
- Ce que cela établit
- L’action indisponible ne doit pas s’exécuter.
- Suite à donner
- Cocher au clavier, vérifier l’activation de Confirmer puis refaire le parcours.
Essayer l’arrière-plan
- Observation du cas
- La page derrière reste visible mais inactive
- Ce que cela établit
- Le fond ne doit recevoir ni action ni focus pendant la modalité.
- Suite à donner
- Tester Tab/Shift+Tab et une cible derrière ; l’assombrissement seul ne suffit pas.
Fermer sans confirmer
- Observation du cas
- Échap ferme ; focus rendu au déclencheur
- Ce que cela établit
- La personne peut reprendre sa tâche initiale.
- Suite à donner
- Rejouer aussi Annuler et une nouvelle ouverture.
Essayer le cycle de focus dans une boîte modale
Ouvrir place le focus sur le titre. Tab permet ensuite de lire et de cocher ; Confirmer reste désactivé avant la coche. Pendant l’ouverture, la commande d’arrière-plan doit rester inactive. Échap ou Annuler ramènent au bouton Ouvrir.
La démonstration interactive est indisponible dans cette configuration ; le cas détaillé reste lisible.
Démonstration prête : aucune donnée transmise.
Cet exemple utilise une boîte modale native. Il illustre un parcours et ne teste pas l’accessibilité de votre propre site. La case n’est ni une autorisation ni une protection côté serveur.
Peut-on accepter le composant sur le seul attribut aria-modal ?
Ouvrir chaque proposition pour comparer son diagnostic. Plusieurs contrôles peuvent rester nécessaires.
Oui, cet attribut fournit tout le comportement.
Non : il faut vérifier les actions et le cycle de focus.
Oui, si le fond est sombre.
Non : l’apparence ne prouve pas l’inactivité du fond.
Non ; contrôler le cycle avec la case cochée puis non cochée.
Adapté. Conserver les défauts et les conditions d’essai ; un composant réussi ne certifie pas tout le site.
Trace de la tâche au clavier
Cas : DEMO-A23 Ouverture : focus sur titre du dialogue État initial : case non cochée ; Confirmer désactivé Parcours : case puis Annuler ; retour interne Après coche : Confirmer disponible Fond : aucune action ni sortie de focus attendue Échap : fermeture et retour au déclencheur
Conserver les touches, l’état des commandes, le nom restitué et le focus avant/après fermeture. Rejouer avec les technologies d’assistance réellement incluses au périmètre.
Documentation des règles, distincte des exemples fictifs
02 / Preuves à conserver
Preuves à conserver
Scénario et environnement
URL, appareil, navigateur, technologie d’assistance, zoom et action tentée.
Reproduction
Étapes exactes, capture ou extrait DOM, résultat observé et résultat attendu.
Référence et impact
Critère WCAG concerné, personnes ou tâches affectées et sévérité motivée.
Contre-épreuve
Correctif, version, date et résultat du nouveau test clavier et lecteur d’écran.
Comparer avec les autres situations et exercices
POINT DE CONTRÔLE
Avant de conclure
Une erreur de lecture fréquente et la vérification qui permet de l’éviter.
Conclusion trop rapide
Un score automatique élevé ne garantit pas que le parcours soit utilisable ; des obstacles de compréhension, de focus ou d’annonce d’erreur exigent une vérification humaine.
Contrôle décisif
Parcourir les tâches clés au clavier et avec une technologie d’assistance, noter l’étape bloquante et rattacher chaque correction à un critère vérifiable.
APRÈS LE CONTRÔLE
Décider selon le constat
Le menu est visible mais inaccessible au clavier
Bloquez la validation du parcours, corrigez le composant partagé puis vérifiez ouverture, navigation et fermeture sur toutes ses pages.
Le contrôle automatique est vert mais la consigne reste incompréhensible
Conservez le résultat de l’outil, documentez l’échec de tâche et reformulez la consigne avant un essai avec les modes d’accès concernés.
Arbitrage et trace de décision
Arbitrage et trace de décision
Ce que le contrôle doit permettre de décider, et la preuve à conserver pour réexaminer ce choix.
Preuve suffisante
Parcourir au clavier les actions essentielles, les erreurs et les états dynamiques ; noter URL, élément, technologie d’assistance et résultat attendu. Un score automatique ne suffit pas.
Décision suivante
Classer d’abord les blocages de parcours. Corriger le composant commun, puis retester la tâche complète et les variantes mobile et linguistiques touchées.
Cas de contrôle approfondis
Situations types pour préparer un contrôle. Elles ne décrivent pas des missions ou observations réalisées.
Un tableau lisible à l’écran perd ses en-têtes
Ce qu’il faut examiner
Vérifier les associations entre cellules et en-têtes, la lecture linéaire et le déplacement au clavier. Une présentation visuelle correcte ne démontre pas que chaque valeur reste compréhensible avec une autre modalité de lecture.
Décision et action
Corriger la structure et les intitulés, puis reprendre une tâche précise de consultation. Distinguer le résultat d’un analyseur automatique de celui du parcours réellement effectué.
Preuve à conserver
Conserver le tableau testé, les cellules concernées, la modalité de lecture et la séquence qui permet de retrouver une valeur.
Le focus disparaît sous un bandeau fixe
Ce qu’il faut examiner
Parcourir les liens, ouvrir puis fermer les menus et changer de taille de fenêtre. Observer où se trouve le focus, si sa cible reste visible et si la fermeture rend la main au déclencheur.
Décision et action
Ajuster le positionnement, le défilement ou la restitution du focus. Rejouer le parcours complet, y compris après une erreur de formulaire, sans limiter le contrôle à la première tabulation.
Preuve à conserver
Noter la taille de fenêtre, les touches utilisées, le composant et les positions du focus avant et après la correction.
Le focus se perd après une interaction
Ce qu’il faut examiner
Parcourir filtre, menu et formulaire au clavier puis observer le focus après changement d’état.
Décision et action
Rendre la suite de la tâche atteignable et son résultat compréhensible.
Preuve à conserver
Séquence clavier, état, position du focus et correction.
Relecture avant décision
Ces questions complètent la méthode. Elles aident à vérifier ce qui est réellement établi, sans effacer les réserves du relevé.
Tâche au clavier
La tâche peut-elle être terminée au clavier, sans piège, avec focus visible et sans contrôle masqué par une zone fixe ? Conserver le chemin testé et le navigateur.
Voir une décision commentée
Exemple fictif : l’état concerne uniquement le critère et le périmètre décrits.
- Observation fictive
- Au clavier, le bouton reçoit le focus mais reste entièrement caché derrière l’en-tête fixe.
- État déclaré
- Écart observé
- Décision et prochain contrôle
- Corriger le positionnement ou le défilement et reprendre le chemin clavier complet. Un focus présent dans le DOM n’est pas suffisant.
Erreurs compréhensibles
Les champs possèdent-ils des noms explicites et les erreurs indiquent-elles comment reprendre ? Compléter les tests automatiques par zoom et lecteur d’écran sur les parcours retenus.
Voir une décision commentée
Exemple fictif : l’état concerne uniquement le critère et le périmètre décrits.
- Observation fictive
- Un champ invalide devient rouge ; son message ne nomme pas le champ et n’explique pas la correction.
- État déclaré
- Écart observé
- Décision et prochain contrôle
- Ajouter une erreur textuelle reliée au champ et tester la reprise au clavier et avec lecteur d’écran.
Lecture au zoom
Au zoom, les intitulés, tableaux et actions restent-ils utilisables ? Examiner les relations entre en-têtes et cellules, pas seulement l’absence de débordement.
Documentation consultée : W3C · WCAG 2.2 ·
Voir une décision commentée
Exemple fictif : l’état concerne uniquement le critère et le périmètre décrits.
- Observation fictive
- Dans le tableau testé au zoom, chaque valeur reste reliée à ses en-têtes de ligne et colonne ; la zone se parcourt au clavier.
- État déclaré
- Vérifié dans ce périmètre
- Décision et prochain contrôle
- Conserver navigateur, zoom et tableau testés. Cette réussite ne vaut pas évaluation des autres tableaux ou de tout le site.
OUTILS / REGISTRES
Informations à relever
Reproduire la tâche au clavier et avec une technologie d’assistance. Noter l’élément précis, le critère concerné et l’obstacle ; un outil automatisé seul ne conclut pas à la conformité.
- Date de consultation et fuseau
- URL exacte
- Tâche / étape du parcours
- Appareil / navigateur
- Critère de validation
- Résultat observé
- Décision / prochaine action
- Responsable du contrôle
- Prochain contrôle
03 / FAQ
Questions fréquentes
Un outil automatique suffit-il ?
Non. Il détecte certaines erreurs de code, mais ne juge pas toujours l’ordre logique, la compréhension ou la réussite d’une tâche.
Que tester en premier ?
Les composants partagés et les parcours essentiels : navigation, recherche, demande, paiement ou contact selon le site.
Faut-il tester chaque langue ?
Oui pour les écrans clés : langue déclarée, libellés, messages d’erreur et ordre de lecture peuvent changer.
Quand fermer une anomalie ?
Quand le scénario initial réussit avec les modes d’accès concernés et que la correction ne casse pas les autres états.
Une interface sans erreur automatique peut-elle rester bloquante ?
Oui. Les contrôles automatiques détectent certains défauts, mais l’exécution des interactions reste nécessaire pour observer les obstacles de navigation, de compréhension ou de validation.
04 / Références officielles
Références officielles
05 / Poursuivre la lecture
Poursuivre la lecture
Présenter un contexte
Passer du besoin à une prestation cadrée
Quelques interventions adaptées à ce sujet. Chaque montant correspond au périmètre de référence indiqué ; le devis confirme les priorités et les éventuels recouvrements.
Diagnostic d’accessibilité
Clavier, formulaires, contrastes et lisibilité ; plan de correction.
Gabarits : 3 · 6 h
À partir de 480 € HT / 576 € TTC
Préparation et critères de livraison
- À préparer
- Pages et composants représentatifs, tâches utilisateurs et référentiel de contrôle retenu.
- Déroulement proposé
- Définir des tâches, observer leurs obstacles puis refaire les mêmes contrôles après modification.
- Livraison à convenir
- Constats reproductibles, critères examinés et limites du diagnostic ; aucune certification implicite.
- Contrôle de cette prestation
- Rejouer les contrôles convenus au clavier et documenter les éléments, critères et limites examinés.
- Limites du périmètre
- Un échantillon de pages ou de tâches ne permet pas de conclure sur tous les usages du site.
Base de travail indicative, à confirmer dans le devis.
Corrections mobile & responsive
Débordements, composants et interactions tactiles.
Gabarits : 3 · 4 h
À partir de 320 € HT / 384 € TTC
Préparation et critères de livraison
- À préparer
- Composants concernés, largeurs cibles, textes longs et langues utilisées.
- Déroulement proposé
- Définir des tâches, observer leurs obstacles puis refaire les mêmes contrôles après modification.
- Livraison à convenir
- Corrections de mise en page, zoom et interactions sur les dimensions convenues.
- Contrôle de cette prestation
- Contrôler les largeurs retenues, les textes longs et l’absence de débordement sur les pages convenues.
- Limites du périmètre
- Un échantillon de pages ou de tâches ne permet pas de conclure sur tous les usages du site.
Base de travail indicative, à confirmer dans le devis.
CTA & conversion des formulaires
Promesse, libellés, erreurs et confirmation.
Parcours : 1 · 4 h
À partir de 320 € HT / 384 € TTC
Préparation et critères de livraison
- À préparer
- Action attendue, champs actuels, erreurs fréquentes et règle de qualification des demandes.
- Déroulement proposé
- Définir des tâches, observer leurs obstacles puis refaire les mêmes contrôles après modification.
- Livraison à convenir
- Libellés, messages d’erreur et confirmation révisés, avec parcours de contrôle.
- Contrôle de cette prestation
- Tester une demande valide et une erreur, puis vérifier les consignes et la confirmation affichées.
- Limites du périmètre
- Un échantillon de pages ou de tâches ne permet pas de conclure sur tous les usages du site.
Base de travail indicative, à confirmer dans le devis.
Préparer et valider une prestation
Ces repères servent à cadrer la demande et à relire la livraison. Le devis fixe les éléments retenus, les volumes et le calendrier.
SXO, UX, accessibilité & performance
Réduire les obstacles rencontrés sur un parcours utile, notamment sur mobile et au clavier.
- À préparer
- Fournir les parcours prioritaires, les appareils visés et les erreurs réellement rencontrées.
- Déroulement proposé
- Définir des tâches, observer leurs obstacles puis refaire les mêmes contrôles après modification.
- Livraison à convenir
- Convenir d’un relevé des obstacles, de leur contexte et des corrections effectivement vérifiées.
- Limites du périmètre
- Un échantillon de pages ou de tâches ne permet pas de conclure sur tous les usages du site.
Critère de recette à préparer
Inclure les erreurs, confirmations, menus ouverts et bandeaux fixes dans le parcours clavier. Noter les composants dont le focus est masqué et justifier chaque exception de taille de cible ; mesurer l’icône seule est insuffisant.
Voir le périmètre et les tarifsREPÈRES DOCUMENTÉS
WCAG 2.2 : distinguer cible cliquable, focus et niveau visé
Un audit de parcours doit annoncer la version des WCAG et le niveau recherché. Les valeurs 24 et 44 concernent des pixels CSS, pas les pixels physiques d’un écran. Elles ne constituent pas, seules, un test de conformité globale.
| Repère | Valeur ou forme | Ce que cela désigne |
|---|---|---|
| 2.5.8 | AA · 24 × 24 CSS px | Taille minimale des cibles au niveau AA. Des exceptions existent : espacement suffisant, commande équivalente, cible dans un texte, contrôle natif et présentation essentielle. |
| 2.5.5 | AAA · 44 × 44 CSS px | Critère renforcé de taille au niveau AAA, avec ses propres exceptions. Ne pas présenter 44 × 44 comme l’exigence générale du niveau AA. |
| 2.4.11 | AA | Au focus clavier, le composant ne doit pas être entièrement caché par un contenu créé par l’auteur, par exemple un bandeau fixe. |
| 2.4.12 | AAA | Le critère renforcé demande qu’aucune partie du composant au focus ne soit cachée par un contenu créé par l’auteur. |
| 2.5.7 | AA | Une fonction utilisant un glisser-déposer doit aussi être réalisable avec un pointeur sans glissement, sauf cas essentiel ou contrôle natif non modifié. |
| 3.3.7 | A | Dans un même processus, une information déjà saisie doit pouvoir être reprise ou sélectionnée, sauf exception de sécurité, d’obsolescence ou de nécessité. |
À retenir pour le dossier
Tester la zone réellement interactive, pas seulement le dessin de l’icône. Documenter les exceptions individuellement et parcourir les états ouverts, erreurs et confirmations au clavier. Un outil automatique ne suffit pas à évaluer le masquage du focus ou tous les processus.
Documentation primaire
- W3C · WCAG 2.2 Recommendation, 12 December 2024
- W3C WAI · Target Size (Minimum)
- W3C WAI · Focus Not Obscured (Minimum)
Documentation consultée le .
REPÈRES DOCUMENTÉS
Champ de formulaire : séparer le nom, l’aide, la contrainte et l’erreur
Pour un code postal, 00123 peut être une chaîne à préserver plutôt qu’une quantité à additionner. Le choix du contrôle part du sens attendu. Ce tableau donne des contrôles distincts pour une revue de formulaire ; aucun attribut isolé ne prouve la validité d’un dossier ou la conformité de tout le parcours.
| Repère | Valeur ou forme | Ce que cela désigne |
|---|---|---|
| label[for] / id | association | Associer le libellé visible au contrôle : for doit viser son id, unique dans le document. name sert à nommer les données envoyées, pas à créer cette association. |
| placeholder / aria-describedby | instructions | Le placeholder disparaît quand une valeur est saisie. Garder les consignes nécessaires dans un texte persistant ; aria-describedby peut relier ce texte au contrôle. |
| type / inputmode | semantics / keyboard | inputmode propose un mode de saisie, sans imposer à lui seul une syntaxe. type=number convient à une quantité numérique, pas à tout identifiant composé de chiffres. |
| pattern | whole value | Sur un champ texte approprié, pattern exprime une contrainte de format sur l’ensemble de la valeur. Un champ facultatif vide ne devient pas obligatoire à cause du seul pattern. |
| required / aria-required | constraint / state | required impose une valeur dans les contrôles auxquels il s’applique. aria-required annonce un état ; il ne crée pas à lui seul le blocage natif de soumission. |
| aria-invalid / error text | state / explanation | Après détection d’un problème, aria-invalid peut exposer l’état. Ajouter un texte qui nomme le champ et explique le problème : une bordure rouge seule ne suffit pas. |
| WCAG 3.3.1 / 3.3.3 | identification / suggestion | Une suggestion de correction est distincte de l’identification de l’erreur. La fournir lorsqu’elle est connue et ne compromet pas la sécurité ou l’objectif du contenu. |
| client / server | two checks | La validation du navigateur facilite la saisie mais peut être contournée. Le serveur doit contrôler les données et traiter ses propres règles métier. |
À retenir pour le dossier
Le code postal 00123 est un exemple de chaîne, pas une adresse vérifiée. Ne généralisez pas un format national à tous les pays. Une vérification automatique des attributs doit être complétée par des essais au clavier, avec technologies d’assistance et sur les états d’échec et de reprise.
Documentation primaire
- W3C WAI · Labelling controls
- W3C WAI · User notifications
- WHATWG · input types and attributes
- WHATWG · inputmode
- WHATWG · Client-side validation security
- W3C · WCAG 3.3.3
Documentation consultée le .
REPÈRES DOCUMENTÉS
Contraste du texte : comparer le ratio avant de l’arrondir
Deux couleurs différentes peuvent rester difficiles à distinguer. WCAG 2.2 compare leurs luminances relatives, après linéarisation des composantes sRGB. L’outil ci-dessous calcule ce ratio pour deux couleurs opaques ; il ne prélève pas les pixels d’une photographie.
| Repère | Valeur ou forme | Ce que cela désigne |
|---|---|---|
| ratio | (Lmax + 0.05) / (Lmin + 0.05) | Le rapport utilise la luminance la plus claire au numérateur. Inverser texte et fond ne change donc pas le résultat. |
| WCAG 1.4.3 · AA | 4.5:1 | Le seuil AA du texte courant est de 4,5:1 dans les situations auxquelles le critère 1.4.3 s’applique. |
| WCAG 1.4.3 · AA · large | 3:1 | Le seuil AA du grand texte est de 3:1. La définition vise notamment 18 points, ou 14 points en gras, avec ses précisions sur les polices. |
| WCAG 1.4.6 · AAA | 7:1 / 4.5:1 | Le critère renforcé 1.4.6 fixe 7:1 pour le texte courant et 4,5:1 pour le grand texte, dans son périmètre d’application. |
| 4.499:1 | < 4.5:1 | Une valeur calculée inférieure à 4,5 ne franchit pas ce seuil parce que son affichage arrondi indique 4,50. Le verdict doit précéder l’arrondi. |
Calculer un contraste sRGB
Deux codes #RRGGBB opaques. Le ratio affiché est arrondi à quatre décimales ; les seuils utilisent la valeur non arrondie.
Deux couleurs valides : comparaison des seuils effectuée.
- Ratio
- 21.0000:1
- AA · texte courant · 4,5:1
- Seuil atteint
- AA · grand texte · 3:1
- Seuil atteint
- AAA · texte courant · 7:1
- Seuil atteint
- AAA · grand texte · 4,5:1
- Seuil atteint
s = component / 255 linear = s ≤ 0.04045 ? s / 12.92 : ((s + 0.055) / 1.055)^2.4 L = 0.2126 × R + 0.7152 × G + 0.0722 × B ratio = (max(L1, L2) + 0.05) / (min(L1, L2) + 0.05)
À retenir pour le dossier
Le calcul est limité à #RRGGBB en sRGB, sans transparence, dégradé, image de fond ou autre espace colorimétrique. Il ne teste ni les exceptions des critères, ni toutes les paires de couleurs du site, ni la conformité WCAG complète. Pour un texte sur une photographie, examiner les zones réellement placées derrière les lettres et les différents cadrages.
Documentation primaire
Documentation consultée le .
APPROFONDISSEMENT / PRATIQUE
Examiner les obstacles rencontrés dans un parcours
Un utilisateur peut lire une page mais ne pas atteindre son action principale. L’examen doit porter sur navigation, compréhension et interaction, dans plusieurs conditions d’usage.
Mis à jour le .
Vérifications prioritaires
Parcourir les éléments au clavier, vérifier les intitulés et observer les messages de validation. Contrôler la visibilité du focus, l’ordre de lecture et l’accès aux informations indispensables.
Pièges d’interprétation
Un contrôle automatique ne couvre pas toute l’expérience. Une interface visuellement claire peut rester difficile à utiliser avec un clavier ou une technologie d’assistance.
Document de travail à conserver
Un relevé d’obstacles associe parcours, condition d’usage, étape bloquée et preuve. La correction doit être retestée dans la condition qui a permis d’identifier le problème.
Évaluer un parcours complet au clavier
Choisir une tâche réelle : trouver une information, ouvrir le menu, remplir un formulaire et comprendre sa confirmation. Parcourir toutes les étapes au clavier, vérifier la visibilité du focus et identifier les endroits où l’utilisateur ne peut plus avancer.
Les WCAG 2.2 proposent des critères vérifiables. Un contrôle automatique aide à repérer certains défauts, mais doit être complété par une vérification humaine du sens des intitulés, de l’ordre de lecture et des messages d’erreur.