What is this?
Cet outil fournit un modèle structuré pour enregistrer les sessions de test d'accessibilité avec les utilisateurs, en testant avec de vrais utilisateurs handicapés. Le test utilisateur est la forme de preuve d'accessibilité la plus précieuse.
When do I need this?
Utilisez cet outil lors de sessions de recherche utilisateur avec des participants handicapés, ou lors de l'examen de tests d'utilisabilité incluant des tâches d'accessibilité.
- 1Configurez l'enregistrement de la session, Entrez la date, le handicap du participant et les technologies d'assistance utilisées, le navigateur et le système d'exploitation.
- 2Enregistrez les tâches et les résultats, Pour chaque tâche testée, enregistrez si le participant l'a complétée, les problèmes rencontrés et les citations directes.
- 3Notez la gravité, Pour chaque problème détecté, enregistrez sa gravité : critique (échec de la tâche), grave (difficulté significative), modérée (contournement nécessaire) ou mineure.
- 4Capturez les citations des participants, Les citations directes des participants constituent une preuve puissante dans un dossier technique et pour les équipes de développement.
- 5Exportez votre journal de session, Téléchargez le journal complété pour votre dossier de conformité. Plusieurs journaux constituent une base de preuves solide.
Liste de contrôle vierge, formulaire imprimable
Tests utilisateurs avec des participants en situation de handicap, Checklist
Testing Methodology & Documentation Checklist
Liste de contrôle vierge à compléter hors ligne.
Cochez une case par ligne. Ajoutez vos commentaires et références de preuves dans la colonne Notes si nécessaire.
Recrutement et représentation des participants
Assurez-vous que les panels de participants sont représentatifs des utilisateurs finaux en situation de handicap et que les pratiques de recrutement sont éthiques et documentées.
| Réf | Gravité | Exigence | Statut | Notes / Preuves |
|---|---|---|---|---|
| EN 301 549 Annex C | Critique | Au moins 2 participants par profil de handicap sont recrutés pour chaque cycle de tests.Tester avec un seul participant par profil ne produit pas de résultats fiables. Deux participants par profil est le minimum pour identifier des tendances plutôt que des préférences individuelles. Des panels plus larges sont préférables pour les services critiques. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EN 301 549 Annex C | Critique | Les profils de handicap incluent les déficiences visuelles, auditives, motrices et cognitives.Les tests doivent couvrir les quatre grandes catégories de handicap. Au sein de chaque catégorie, envisagez des sous-profils (par ex. Malvoyance vs cécité, sourd/sourde vs malentendant). Les profils retenus doivent refléter les utilisateurs finaux probables du produit. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EN 301 549 §5.1 | Majeur | Les participants utilisent leur propre technologie d'assistance pendant les sessions de test.Demander aux participants d'utiliser une technologie d'assistance non familière introduit des variables parasites. Les utilisateurs doivent apporter leurs propres appareils et technologies d'assistance (lecteurs d'écran, contacteurs, loupes) configurés selon leurs préférences. En test à distance, confirmez que les participants utilisent leur configuration habituelle. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EAA Article 15 | Majeur | Les participants reçoivent une rémunération équitable pour leur temps.Les tests non rémunérés exploitent les participants en situation de handicap et peuvent biaiser le recrutement vers ceux ayant moins d'options. La rémunération doit au moins être équivalente aux taux du marché pour les tests d'utilisabilité. Le paiement doit être accessible (par ex. Virement bancaire, et non uniquement des cartes-cadeaux vers des plateformes inaccessibles). | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EAA Article 15 | Critique | Le consentement éclairé est documenté pour chaque participant, couvrant l'utilisation des données, l'enregistrement et l'anonymisation.Les formulaires de consentement doivent être accessibles (pas uniquement des PDF d'images). Ils doivent expliquer quelles données sont collectées, comment les sessions sont enregistrées, comment les constats sont anonymisés et comment les participants peuvent se retirer. Fournissez les formulaires de consentement à l'avance pour que les participants puissent les examiner avec leur technologie d'assistance. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A |
Méthodologie de test
Vérifiez que l'approche de test est structurée, reproductible et appropriée à l'évaluation d'accessibilité avec des participants en situation de handicap.
| Réf | Gravité | Exigence | Statut | Notes / Preuves |
|---|---|---|---|---|
| EN 301 549 Annex C | Critique | Des scénarios de tâches définis couvrent tous les parcours utilisateurs critiques.Les scénarios de tâches doivent couvrir les parcours de bout en bout les plus importants: inscription, connexion, fonctionnalités principales, paiements, support. Les tâches doivent être rédigées en langage clair et réalisables dans le temps de la session. Évitez d'orienter les participants vers des éléments d'interface spécifiques. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EN 301 549 Annex C | Majeur | Les tâches correspondent au périmètre de l'évaluation d'accessibilité (mêmes pages, composants et flux).Les tests utilisateurs doivent valider le même périmètre que l'évaluation de conformité. Si l'audit WCAG couvre 20 pages, les tâches de test utilisateur doivent solliciter ces mêmes pages. Un périmètre désaligné signifie que les résultats des tests ne peuvent pas être corrélés aux constats d'audit. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EN 301 549 Annex C | Majeur | La méthode du protocole « think-aloud » ou d'observation structurée est documentée et suivie.La méthode d'animation doit être définie avant le début des tests. Le protocole think-aloud demande aux participants de verbaliser leurs pensées pendant l'exécution des tâches. Alternativement, les entretiens rétrospectifs ou l'observation structurée avec une grille prédéfinie sont acceptables. La méthode doit être cohérente sur l'ensemble des sessions. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EAA Article 15 | Majeur | Les sessions sont enregistrées (avec le consentement du participant) à des fins de preuve et d'analyse ultérieure.Les enregistrements fournissent des preuves pour les organismes de contrôle et permettent à l'équipe d'examiner les constats en détail. L'écran et l'audio doivent être capturés. Si les participants refusent l'enregistrement, des notes contemporaines détaillées doivent s'y substituer. Les enregistrements doivent être stockés en sécurité avec un accès restreint. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EN 301 549 Annex C | Majeur | Les tests sont animés par une personne indépendante, pas le développeur ou le concepteur du produit.Les développeurs et concepteurs ont un biais inhérent et une connaissance du produit qui peuvent les amener à guider inconsciemment les participants. L'animateur doit être quelqu'un qui n'a pas construit la fonctionnalité testée. Les consultants externes en accessibilité ou les chercheurs UX formés sont préférables. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A |
Documentation des constats
Assurez-vous que les obstacles identifiés lors des tests utilisateurs sont documentés avec suffisamment de détail pour la remédiation et les preuves réglementaires.
| Réf | Gravité | Exigence | Statut | Notes / Preuves |
|---|---|---|---|---|
| EN 301 549 Annex C | Critique | Chaque obstacle est documenté avec: profil de handicap, technologie d'assistance utilisée, tâche tentée, description de l'obstacle et gravité.Un constat sans contexte n'est pas exploitable. Chaque obstacle documenté doit indiquer quel profil participant l'a rencontré, quelle technologie d'assistance était utilisée, quelle tâche était tentée, une description claire de l'obstacle et un niveau de gravité (critique / majeure / mineure). Cette structure permet une remédiation priorisée. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| WCAG 2.2 | Majeur | Chaque constat est lié au critère de succès WCAG pertinent.Lier les constats des tests utilisateurs aux critères de succès WCAG relie les preuves d'utilisateurs réels aux exigences normatives. Cela renforce les déclarations de conformité et aide les développeurs à comprendre quelle exigence est concernée. Si un obstacle ne correspond pas à un critère de succès spécifique, documentez-le comme un problème d'utilisabilité hors périmètre WCAG. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EAA Article 15 | Mineur | Des citations de participants sont incluses dans les constats (anonymisées).Les citations directes des participants fournissent des preuves qualitatives puissantes. Elles illustrent l'impact humain des obstacles et sont convaincantes dans les soumissions réglementaires et les présentations aux parties prenantes. Toutes les citations doivent être anonymisées (par ex. « Participant B3, aveugle, utilisateur JAWS »). | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EN 301 549 Annex C | Majeur | Le taux de réussite par tâche et par profil de handicap est enregistré.Les taux de réussite quantitatifs complètent les constats qualitatifs. Pour chaque tâche, enregistrez combien de participants de chaque profil de handicap l'ont accomplie avec succès, partiellement ou pas du tout. Ces données révèlent quels parcours sont les plus problématiques et pour quels groupes d'utilisateurs. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A |
Suivi et vérification de la remédiation
Confirmez que les constats des tests utilisateurs alimentent la remédiation et que les corrections sont validées par de nouveaux tests.
| Réf | Gravité | Exigence | Statut | Notes / Preuves |
|---|---|---|---|---|
| EAA Article 15 | Critique | De nouveaux tests sont planifiés après la remédiation des obstacles identifiés.Des tests utilisateurs sans nouveaux tests de suivi sont incomplets. Un cycle de retest doit être planifié après que les développeurs ont traité les constats critiques et majeurs. Le plan de retest doit préciser les calendriers, le périmètre (quelles corrections valider) et les exigences relatives aux participants. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EN 301 549 Annex C | Majeur | Les mêmes participants (ou les mêmes profils de handicap) sont invités au retest.Le retest doit impliquer des participants ayant les mêmes profils de handicap que le cycle initial pour s'assurer que les corrections sont validées par les groupes d'utilisateurs concernés. Idéalement, les mêmes individus participent pour assurer la continuité. Si les participants initiaux ne sont pas disponibles, recrutez des remplaçants avec des profils correspondants. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EAA Article 15 | Critique | Les constats sont partagés avec l'équipe de développement dans les 5 jours ouvrés suivant la fin des tests.Un rapport tardif réduit la probabilité de remédiation. Les obstacles critiques doivent être communiqués immédiatement; le rapport complet doit suivre dans les 5 jours ouvrés. Utilisez des formats accessibles et incluez suffisamment de détails techniques pour que les développeurs puissent reproduire et corriger chaque obstacle. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EN 301 549 Annex C | Majeur | Les constats des tests utilisateurs sont intégrés à l'auto-évaluation ou aux résultats d'évaluation de conformité.Les tests utilisateurs doivent alimenter l'évaluation formelle d'accessibilité. Les déclarations de conformité WCAG doivent être éclairées par des preuves d'utilisateurs réels, pas uniquement par des tests automatisés et d'experts. Lorsque les tests utilisateurs révèlent des obstacles que les tests d'experts ont manqués, l'évaluation doit être mise à jour. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EAA Article 15 | Majeur | Les tests utilisateurs sont répétés annuellement ou après toute publication majeure du produit.Un seul cycle de tests utilisateurs ne fournit pas d'assurance continue. Les tests doivent être réalisés au moins annuellement et déclenchés par les versions majeures qui affectent les fonctionnalités pertinentes pour l'accessibilité. Documentez la cadence de test dans la politique d'accessibilité. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EAA Article 15 | Mineur | Le rapport de tests est disponible pour les autorités de surveillance du marché sur demande.Les organismes de contrôle peuvent demander des preuves de tests utilisateurs dans le cadre de la surveillance du marché. Le rapport doit être stocké en sécurité, être récupérable dans un délai raisonnable et contenir suffisamment de détails pour démontrer la conformité aux exigences de documentation technique de l'article 15 de l'AEA. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A |