UX, accessibilité, SEO et qualité web
Chapitres, TP et corrigés consultables ; les TP sont principalement à réaliser hors de la page. Trois questions d’entraînement interactif facultatif sont proposées dans ce module, sans note ni validation automatique. Le manuel de formation est également consultable depuis le lien en haut de page. Les durées sont des repères pour organiser le parcours ; les lectures, activités, travaux pratiques et évaluations ne doivent pas être additionnés deux fois.
Dans ce module — Accès rapide
MODULE 10 — UX, ACCESSIBILITÉ, SEO ET QUALITÉ WEB
Durée : 10 heures | Bloc C — Concevoir une expérience autonome | Public : débutants complets
Finalité : transformer le site fil rouge en une expérience compréhensible, utilisable, accessible, découvrable et vérifiable. Les tests humains complètent les outils automatiques.
Voir un exemple, essayer et vérifier
Je vois — exemple concret : Un lien « Cliquez ici » est peu explicite hors contexte ; « Lire le programme de l’atelier » annonce la destination. Un bouton utilisable au clavier doit aussi avoir un indicateur de focus visible.
J’essaie — petit geste : Parcourez les liens avec la touche Tab sur ordinateur ; vérifiez l’ordre, le focus et la compréhension des intitulés.
Je vérifie — si cela ne fonctionne pas : Sur téléphone, vérifiez la lisibilité et l’absence de défilement horizontal ; cela ne remplace pas le test clavier.
Comprendre et essayer — exemple guidé
Je vois : Une liste de contrôle qualité sert de synthèse du module : elle rassemble les vérifications de navigation, accessibilité, adaptation mobile et référencement à effectuer avant publication.
J’essaie : Écrivez une courte liste de contrôle qualité à réutiliser lors d’une prochaine publication.
Je vérifie : La liste de contrôle comporte des vérifications exécutables et un résultat à consigner.
Autre façon de faire : Rédigez une checklist courte avec une action et un résultat observable par point.
Pour reprendre plus tard : Conservez la version ou le scénario utilisé, la preuve disponible et l’étape distante qui reste à tester réellement.
Compétences attendues
Décrire un parcours utilisateur et repérer une difficulté de navigation.
Contrôler la navigation au clavier, les libellés, les contrastes et les alternatives textuelles.
Tester la présentation sur plusieurs largeurs d’écran sans perte de contenu.
Expliquer le rôle des titres, métadonnées, liens, sitemap.xml et URL canonique.
Contrôler les liens et les QR codes sur la destination réelle.
Utiliser une grille de recette et documenter les anomalies et corrections.
Déroulé des 10 heures
Séquence 1 — UX et parcours utilisateur : 1 h 30
Séquence 2 — Accessibilité et clavier : 2 h
Séquence 3 — Responsive et lisibilité : 1 h
Séquence 4 — SEO et indexation : 2 h
Séquence 5 — Performance, liens et QR codes : 1 h 30
Séquence 6 — Recette et autonomie : 2 h
1. UX : partir du visiteur
L’expérience utilisateur (UX) désigne la manière dont une personne comprend et utilise un service. Avant de modifier le site, écrire trois tâches : découvrir le projet, trouver les informations pratiques, revenir à l’accueil. Pour chacune, compter les étapes et noter les hésitations. Un lien intitulé « En savoir plus » est moins explicite que « Découvrir la carte intérieure ». Un test simple consiste à demander à une personne de réaliser la tâche sans lui expliquer l’interface.
Comprendre et essayer — exemple guidé
Je vois : Une difficulté de parcours se révèle quand le visiteur hésite sur l'action suivante.
J’essaie : Suivez le parcours d’un visiteur fictif et repérez une hésitation.
Je vérifie : Le parcours comporte un objectif et au moins un point de friction observable.
Autre façon de faire : Demandez à une autre personne de lire le parcours proposé et de signaler à quel moment elle ne sait plus où aller.
Pour reprendre plus tard : Conservez votre production de l’activité 1, le point précis du critère non encore satisfait et la prochaine vérification à effectuer.
2. HTML sémantique et repères
Une page doit présenter un titre principal h1 pertinent, des sous-titres hiérarchisés et des zones structurées avec header, nav, main et footer. Le contenu reste lisible sans CSS. Les boutons déclenchent une action ; les liens conduisent à une ressource. Ne pas utiliser un div cliquable lorsque button ou a convient.
Comprendre et essayer — exemple guidé
Je vois : Les titres structurent la lecture et les liens doivent annoncer leur destination.
J’essaie : Vérifiez la présence de titres hiérarchisés et d’un lien de navigation compréhensible.
Je vérifie : Un titre principal et des sous-titres cohérents rendent le plan compréhensible.
Autre façon de faire : Sur une copie HTML locale, contrôlez l’ordre des titres et le libellé des liens.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
3. Accessibilité : test au clavier
Depuis le début de la page, utiliser Tab et Maj+Tab : chaque élément interactif doit être atteignable dans un ordre logique, avec un indicateur de focus visible. Entrée active un lien ou un bouton ; Espace active un bouton. Vérifier qu’aucun piège au clavier n’empêche de sortir d’un composant. Un test clavier n’est pas un audit complet : vérifier aussi les lecteurs d’écran et les usages mobiles lorsque c’est possible.
Comprendre et essayer — exemple guidé
Je vois : Le focus visible permet de suivre le déplacement au clavier.
J’essaie : Parcourez les liens au clavier et repérez l’indicateur de focus.
Je vérifie : Le focus est visible sur les liens et suit un ordre de navigation logique.
Autre façon de faire : Sans compte, ouvrez une page HTML locale et parcourez ses liens avec Tab puis Maj+Tab ; notez l’ordre et la visibilité du focus. Une annotation sur papier prépare le contrôle mais ne remplace pas l’essai au clavier.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
4. Images, formulaires et contraste
Rédiger un texte alternatif décrivant la fonction ou l’information de l’image ; une image purement décorative peut avoir alt="". Associer chaque champ à un label. Ne pas transmettre une information uniquement par la couleur. Vérifier les contrastes : pour le texte courant, viser au moins 4,5:1 et pour le grand texte au moins 3:1 (WCAG AA), sous réserve des exceptions prévues par les critères.
Comprendre et essayer — exemple guidé
Je vois : Un texte alternatif décrit l'information utile portée par une image, pas sa décoration.
J’essaie : Examinez une image sans texte alternatif et proposez une description utile.
Je vérifie : Pour une image informative, le texte de l’attribut alt restitue son information essentielle. Pour une image purement décorative, utilisez alt="" afin qu’elle soit ignorée par les lecteurs d’écran.
Autre façon de faire : Sur papier, rédigez un texte alternatif utile pour une image informative ; pour une image uniquement décorative, indiquez alt="". Comparez les deux cas.
Pour reprendre plus tard : Conservez votre production de l’activité 4, le point précis du critère non encore satisfait et la prochaine vérification à effectuer.
5. Responsive : une seule page, plusieurs contextes
Tester environ 320, 375, 768 et 1280 pixels de largeur ; ces valeurs sont des points de contrôle, pas des catégories absolues d’appareils. Aucun défilement horizontal ne doit être nécessaire pour lire les contenus ordinaires. Vérifier les textes agrandis à 200 %, les menus, les images et les zones tactiles. Ne pas supprimer des informations importantes sur mobile.
Comprendre et essayer — exemple guidé
Je vois : Une page adaptable ne doit pas imposer de défilement horizontal pour lire le contenu courant.
J’essaie : Réduisez la largeur d’affichage et repérez un élément qui dépasse.
Je vérifie : Le contenu reste accessible à faible largeur sans chevauchement ni défilement horizontal non prévu.
Autre façon de faire : Réduisez la fenêtre du navigateur pour constater les débordements réels.
Pour reprendre plus tard : Conservez votre production de l’activité 5, le point précis du critère non encore satisfait et la prochaine vérification à effectuer.
6. SEO : rendre une page interprétable
Le référencement naturel commence par un contenu utile, un title spécifique, une meta description pertinente, des titres cohérents et des liens descriptifs. Une meta description n’impose pas le texte affiché dans les résultats. Un sitemap aide à découvrir des URL mais ne garantit pas leur indexation. robots.txt et la balise noindex ne remplissent pas la même fonction.
Comprendre et essayer — exemple guidé
Je vois : Le titre et la description d'une page doivent refléter son contenu réel.
J’essaie : Repérez le titre de page et une description qui résume son contenu réel.
Je vérifie : Le titre et la description correspondent au sujet réel de la page.
Autre façon de faire : Comparez le titre et la description d’une page locale à son contenu visible.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
7. Canonical et indexation
La balise <link rel="canonical" href="https://exemple.fr/page/"> indique une URL préférée parmi des variantes ; c’est un signal, non une obligation pour Google. Vérifier que la destination est absolue, correcte, accessible et cohérente avec les liens internes et le sitemap. Après publication, utiliser l’inspection d’URL de Search Console pour examiner l’URL déclarée et l’URL choisie par Google. Une demande d’indexation n’est pas une garantie.
Comprendre et essayer — exemple guidé
Je vois : La balise canonique désigne l'URL de référence d'un contenu.
J’essaie : Comparez deux URL canoniques et choisissez celle correspondant à la page de référence.
Je vérifie : La canonical désigne l’URL de référence prévue et non une page sans rapport.
Autre façon de faire : Sur deux URL fictives, choisissez la référence canonique et expliquez pourquoi.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
8. QR codes et liens
Un QR code encode une donnée, souvent une URL. Avant impression, le scanner avec au moins deux appareils ou applications ; vérifier l’URL affichée, la page d’arrivée, HTTPS, la lecture sur mobile et la pérennité du lien. Ne jamais conclure qu’un QR fonctionne seulement parce que le motif paraît correct. Prévoir une URL lisible imprimée comme solution de secours.
Comprendre et essayer — exemple guidé
Je vois : Un QR code doit conduire à l'adresse exacte attendue par son support imprimé.
J’essaie : Lisez la destination d’un QR code et comparez-la à la page attendue.
Je vérifie : Le QR code se décode vers l’URL attendue ; ouvrez ensuite cette URL pour confirmer que la page est réellement accessible et correspond au contenu annoncé.
Autre façon de faire : Scannez le QR code avec un lecteur gratuit ; sans lecteur, notez « destination non vérifiée ».
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
9. Performance et qualité
Observer la taille des images, la stabilité visuelle, les temps de chargement et les erreurs réseau. Utiliser les outils de développement du navigateur et Lighthouse comme aides au diagnostic ; leurs scores ne remplacent pas un test réel. Définir une priorité : défaut bloquant, défaut important, amélioration souhaitable. Corriger une anomalie à la fois, puis refaire les tests de non-régression.
Comprendre et essayer — exemple guidé
Je vois : Le poids des images influe sur le chargement, notamment avec une connexion lente.
J’essaie : Repérez une image trop lourde et proposez une vérification de son poids.
Je vérifie : La ressource volumineuse est identifiée et son poids est mesuré avant et après optimisation.
Autre façon de faire : Sans compte, ouvrez les outils de développement du navigateur pour relever la taille réelle de l’image transférée ; sur papier, listez les éléments à contrôler mais ne prétendez pas avoir mesuré le poids.
Pour reprendre plus tard : Notez le résultat attendu, l’observation obtenue et l’éventuel écart à reproduire à la prochaine séance.
10. Confidentialité et données locales
Ne pas envoyer d’informations sensibles à des services tiers sans nécessité. Les données enregistrées dans localStorage restent liées à une origine et peuvent être supprimées par l’utilisateur ; elles ne sont ni chiffrées par défaut ni une sauvegarde durable. Expliquer les mécanismes de mémorisation dans l’interface.
Comprendre et essayer — exemple guidé
Je vois : Une préférence enregistrée localement n'est pas automatiquement une donnée envoyée à un tiers.
J’essaie : Distinguez une préférence locale d’une donnée transmise à un service externe.
Je vérifie : Le stockage local est distingué d’un transfert réseau ; aucune confidentialité absolue n’est promise.
Autre façon de faire : Classez sur papier stockage local et transmission réseau, sans présumer de la confidentialité.
Pour reprendre plus tard : Gardez le tableau de classement avec les éléments qui vous ont fait hésiter et la distinction à revoir.
Exemple de code : repères et référencement (page autonome de démonstration, à ne pas substituer au projet fil rouge). Pour intégrer cet exercice dans le projet des modules 3 à 5, conserver les sections et les interactions existantes, ajouter uniquement le bouton id="astuce" dans la section Présentation, réutiliser l’unique paragraphe id="message" déjà présent et ajouter le gestionnaire JavaScript indiqué ci-dessous. Ne pas créer de second id="message".
<!doctype html>
<html lang="fr">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">Faire défiler horizontalement pour voir les lignes longues.
<title>Mon premier projet — Présentation</title>
<meta name="description" content="Découvrez un premier projet web interactif.">
<!-- À remplacer par la vraie URL publique après déploiement -->
<link rel="canonical" href="https://exemple.fr/">
<link rel="stylesheet" href="style.css">
<script src="script.js" defer></script>
</head>
<body>
<a class="skip-link" href="#contenu">Aller au contenu</a>
<header><nav aria-label="Navigation principale"><a href="index.html">Accueil</a></nav></header>
<main id="contenu"><h1>Mon premier projet</h1><p>Une création numérique accessible.</p>
<button type="button" id="astuce">Afficher une astuce</button>
<p id="message" aria-live="polite"></p>
</main>
<footer><p>Projet pédagogique.</p></footer>
</body>
</html>Faire défiler horizontalement pour voir les lignes longues.
Vérification pratique : ajouter dans script.js, sans effacer les fonctions précédentes, ce gestionnaire autonome :
document.querySelector("#astuce")?.addEventListener("click", () => {
const zone = document.querySelector("#message");Faire défiler horizontalement pour voir les lignes longues.
if (zone) zone.textContent = "Une idée peut naître d’une simple observation.";
});Faire défiler horizontalement pour voir les lignes longues.
Recharger la page, activer le bouton au clavier et vérifier que le message apparaît. Le bouton ne fonctionne pas si ce gestionnaire n’est pas chargé.
Explication : lang="fr" indique la langue ; viewport permet la mise en page mobile ; title nomme la page ; canonical doit être adapté à l’URL effectivement publiée ; le lien d’évitement facilite l’accès au contenu ; aria-live annonce les mises à jour du message. Ne pas copier l’URL exemple.fr sur un site réel.
Travaux pratiques guidés
TP1 — Parcours utilisateur (30 min)
Faire réaliser à un pair trois tâches ; noter les clics, incompréhensions et pistes de correction. Si aucun pair n'est disponible, réaliser une inspection guidée des trois tâches et indiquer qu'il ne s'agit pas d'un test utilisateur. Livrable : tableau tâche / observation / amélioration.
Corrigé commenté et approfondissement — à consulter après votre essai
Critère de réussite : Trois tâches formulées comme actions, un tableau tâche / observation / correction et un statut « testé avec un pair » ou « inspection personnelle ».
Comprendre et essayer — exemple guidé
Je vois : Un test utilisateur révèle des hésitations invisibles pour la personne qui a conçu la page.
J’essaie : Faites tester à une autre personne l’accès à une page précise.
Je vérifie : La personne testée atteint la page sans indication supplémentaire ; les hésitations sont notées.
Autre façon de faire : Demandez à une personne d’ouvrir la page et notez ses hésitations ; une simulation ne remplace pas ce test.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
TP2 — Clavier et sémantique (45 min)
Naviguer sans souris ; corriger les titres, les liens et l’indicateur de focus. Livrable : captures ou compte rendu des tests avant/après.
Corrigé commenté et approfondissement — à consulter après votre essai
Critère de réussite : Journal avant/après : élément, action au clavier, résultat constaté, correction, nouveau résultat.
Afficher le corrigé commenté — Diagnostic clavier avant/après
Exemple : Tab atteint tous les liens, mais aucun focus visible. Correction CSS : a:focus-visible { outline: 3px solid currentColor; outline-offset: 3px; }. Vérifier ensuite Tab et Maj+Tab, Entrée sur les liens, ordre logique des titres h1 puis h2 et texte de lien compréhensible hors contexte. Ne pas confondre focus et survol de souris.
Comprendre et essayer — exemple guidé
Je vois : Tab et Entrée permettent de tester une partie essentielle de l'usage sans souris.
J’essaie : Vérifiez qu’un bouton reste utilisable avec Tab et Entrée.
Je vérifie : Tab et Entrée permettent d’actionner le bouton et le focus reste visible.
Autre façon de faire : Sans abonnement, ouvrez une copie locale de la page et testez le bouton avec Tab puis Entrée. Notez l’état du focus et le résultat obtenu ; un parcours décrit sur papier n’atteste pas de l’interaction.
Pour reprendre plus tard : Notez le résultat attendu, l’observation obtenue et l’éventuel écart à reproduire à la prochaine séance.
TP3 — Responsive (45 min)
Tester quatre largeurs et le zoom à 200 %. Corriger un débordement sans masquer le contenu. Livrable : grille de résultats.
Corrigé commenté et approfondissement — à consulter après votre essai
Critère de réussite : Grille cinq tests avec état avant/après, capture facultative, et mention explicite des contrôles non effectués.
Afficher le corrigé commenté — Quatre largeurs et zoom 200 %
Exemple : à 320 px, une carte déborde. Remplacer une largeur fixe de 600px par max-width:100%; et ajouter min-width:0; à l’élément de grille si nécessaire. Retester 320, 375, 768 et 1280 px puis zoom 200 %. Noter les éventuelles exceptions (contenu nécessitant défilement bidimensionnel).
Comprendre et essayer — exemple guidé
Je vois : Deux largeurs d'écran peuvent révéler des débordements différents.
J’essaie : Contrôlez la page à deux largeurs et notez le premier débordement.
Je vérifie : Deux largeurs au minimum sont consignées avec une anomalie précise ou l’absence de débordement.
Autre façon de faire : Sans compte, testez une page locale dans un navigateur à deux largeurs distinctes et notez les débordements observés. Un dessin peut anticiper les risques, mais pas valider l’affichage réel.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
TP4 — SEO et canonical (60 min)
Rédiger title et description. Si le site est publié, vérifier l’URL canonique réelle et la cohérence d’un éventuel sitemap ; inspecter l’URL avec Search Console uniquement si l’accès est disponible. Si le site n’est pas publié, préparer une proposition de canonical sans insérer d’URL fictive dans le projet et noter « URL publique non disponible — contrôle différé ». Le sitemap n’est pas obligatoire pour ce site à page unique. Livrable : fiche SEO distinguant vérifications réalisées et contrôles différés.
Corrigé commenté et approfondissement — à consulter après votre essai
Critère de réussite : Fiche : title, description, URL publique vérifiée ou absente, canonical vérifiée ou différée, éventuel sitemap et preuve du contrôle.
Afficher le corrigé commenté — Métadonnées vérifiables et URL réelle
Exemple de title : « Découvrir trois récits — Atelier ». Description : « Explorez trois récits et choisissez votre parcours de lecture. » Pour un site effectivement publié, canonical absolue identique à l’URL publique de référence, cohérente avec redirections et sitemap s’il existe. Sans URL publique, ne pas écrire de canonical fictive : « contrôle différé ». Search Console ne prouve pas à elle seule l’indexation immédiate.
Comprendre et essayer — exemple guidé
Je vois : Titre, description et URL canonique doivent décrire la même ressource.
J’essaie : Vérifiez que le titre, la description et la canonical désignent la même page.
Je vérifie : Titre, description et canonical désignent le même contenu publié.
Autre façon de faire : Lisez title, description et canonical dans le code source et confrontez-les au contenu.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
TP5 — QR et liens (30 min)
Tester trois liens existants du projet et, si un QR code est fourni ou généré pour une URL de test, le scanner et noter l’URL encodée et l’URL finale. Sans QR code disponible, préparer une fiche de contrôle décrivant la procédure et indiquer « scan non exécuté » ; ne pas inventer de résultat. Livrable : tableau de validation des liens et statut explicite du test QR.
Corrigé commenté et approfondissement — à consulter après votre essai
Critère de réussite : Tableau trois liens avec résultats réels et statut distinct du scan QR.
Afficher le corrigé commenté — Séparer lien, code QR et destination finale
Exemple : lien A : ouverture OK, destination correcte ; lien B : 404, correction du chemin relatif puis retest ; lien C : redirection vers une autre page, vérifier qu’elle est attendue. Si un QR code est disponible, scanner avec un téléphone et comparer URL décodée / URL finale / page affichée. Sans scan, écrire « non exécuté », jamais « validé ».
Comprendre et essayer — exemple guidé
Je vois : Une adresse imprimée et celle d'un QR code doivent mener au même contenu attendu.
J’essaie : Comparez le lien imprimé et la destination réelle du QR code.
Je vérifie : L’URL encodée correspond à la page voulue et reste accessible depuis le support prévu.
Autre façon de faire : Scannez le QR code et comparez sa destination à l’URL imprimée ; sinon marquez le test non effectué.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
TP6 — Recette finale (60 min)
Identifier trois anomalies de catégories différentes, les classer, corriger et retester. Livrable : rapport de recette daté.
Corrigé commenté et approfondissement — à consulter après votre essai
Critère de réussite : Rapport daté avec contexte, trois contrôles, anomalies réelles ou simulées clairement identifiées, corrections et retests.
Afficher le corrigé commenté — Rapport de recette traçable
Exemple : anomalie 1 « focus invisible » (accessibilité, importante) ; anomalie 2 « image déborde à 320 px » (responsive, importante) ; anomalie 3 « lien vers page inexistante » (fonctionnel, bloquante). Pour chacune : reproduction, correction, retest et statut. Si moins de trois défauts réels existent, consigner les tests négatifs et employer des défauts d’exercice explicitement simulés, sans les présenter comme réels.
Comprendre et essayer — exemple guidé
Je vois : Une anomalie reproductible précise les étapes, le résultat attendu et le résultat observé.
J’essaie : Remplissez une grille d’anomalies avec étapes, attendu et constaté.
Je vérifie : La grille comporte pour chaque anomalie étapes, attendu, constaté et gravité.
Autre façon de faire : À partir d’un défaut fictif, écrivez les étapes pour le reproduire et distinguez le résultat attendu du résultat observé.
Pour reprendre plus tard : Conservez votre production de l’activité 16, le point précis du critère non encore satisfait et la prochaine vérification à effectuer.
Étude de cas : les pages de découverte des Récits Vivants
Situation : une page de découverte liée à une carte imprimée doit rester lisible sur mobile, accessible depuis un QR code et indexable. Le contrôle ne porte pas uniquement sur l’apparence : vérifier la destination exacte du QR, les liens, la balise canonique, la cohérence du sitemap et l’absence de contenu masqué. Ne pas attribuer automatiquement une absence d’indexation à la balise canonique : examiner le rapport d’inspection et les autres causes possibles.
Comprendre et essayer — exemple guidé
Je vois : La découverte d'une page doit rester compréhensible pour une personne qui ne connaît pas le projet.
J’essaie : Parcourez une page de découverte Récits Vivants comme un visiteur débutant.
Je vérifie : Le parcours d’un novice aboutit à une action identifiable sans explication extérieure.
Autre façon de faire : Faites parcourir une page réelle à un novice et notez ce qu’il comprend sans aide.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
Entraînement interactif facultatif — V0.6.0
Ces questions complémentaires ne constituent ni une note ni une validation de compétence. Aucune réponse n’est enregistrée.
Autoévaluation : 10 questions avec corrigés
Afficher le corrigé
1. Quelle différence entre UX et interface graphique ?
Corrigé : L’UX couvre l’expérience d’utilisation ; l’interface graphique en est une composante.
Pourquoi cette réponse ? L’UX concerne l’ensemble du parcours et des difficultés vécues ; l’apparence graphique n’en est qu’une composante.
Exemple ou vérification autonome Observez si un utilisateur retrouve une information, indépendamment de l’esthétique de la page.
Afficher le corrigé
2. Comment tester sans souris ?
Corrigé : Tab, Maj+Tab, Entrée et Espace ; contrôler ordre, focus et absence de piège.
Pourquoi cette réponse ? Les commandes doivent être atteignables et activables au clavier, avec un ordre logique et un focus perceptible.
Exemple ou vérification autonome Parcourez la page avec Tab, Maj+Tab, Entrée et Espace sans utiliser la souris.
Afficher le corrigé
3. À quoi sert alt ?
Corrigé : À transmettre l’information ou la fonction d’une image aux personnes qui ne la voient pas.
Pourquoi cette réponse ? L’attribut alt fournit une alternative pertinente à l’image lorsqu’elle n’est pas perçue visuellement ; sa rédaction dépend du rôle de l’image.
Exemple ou vérification autonome Pour une image informative, rédigez un alt utile ; pour une décoration, envisagez alt vide.
Afficher le corrigé
4. Que signifie responsive ?
Corrigé : Une interface qui s’adapte aux contextes et tailles d’affichage.
Pourquoi cette réponse ? Le responsive adapte la présentation à la largeur et au contexte, sans imposer de défilement horizontal inutile.
Exemple ou vérification autonome Comparez le même contenu à 375, 768 et 1280 px.
Afficher le corrigé
5. Un sitemap garantit-il l’indexation ?
Corrigé : Non, il facilite la découverte des URL.
Pourquoi cette réponse ? Un sitemap aide les moteurs à découvrir les URL mais n’impose ni leur indexation ni leur classement.
Exemple ou vérification autonome Comparez une URL du sitemap avec son état réel dans un outil d’inspection.
Afficher le corrigé
6. La balise canonical force-t-elle Google ?
Corrigé : Non, elle indique une préférence.
Pourquoi cette réponse ? La balise canonical signale l’URL préférée ; le moteur peut retenir une autre version selon ses propres signaux.
Exemple ou vérification autonome Sur deux URL proches, repérez la canonical déclarée et distinguez-la de l’URL retenue.
Afficher le corrigé
7. Comment vérifier un QR code ?
Corrigé : Le scanner et contrôler l’URL réelle et la page de destination.
Pourquoi cette réponse ? Un QR code n’est fiable qu’après vérification de sa destination réelle et de son fonctionnement sur appareil.
Exemple ou vérification autonome Scannez le code, lisez l’URL avant ouverture et contrôlez la page cible.
Afficher le corrigé
8. Que mesure un audit automatique ?
Corrigé : Une partie des critères techniques ; il ne remplace pas les tests humains.
Pourquoi cette réponse ? Un outil automatique détecte certaines anomalies techniques, mais pas tous les problèmes d’usage ou de compréhension.
Exemple ou vérification autonome Complétez un audit automatique par un parcours clavier et une lecture humaine.
Afficher le corrigé
9. Pourquoi conserver une grille de recette ?
Corrigé : Pour rendre les contrôles reproductibles et suivre les corrections.
Pourquoi cette réponse ? La grille conserve les conditions et résultats des essais, afin de pouvoir reproduire un contrôle et suivre une correction.
Exemple ou vérification autonome Remplissez une ligne : environnement, action, attendu, observé, statut.
Afficher le corrigé
10. Que faire après une correction CSS ?
Corrigé : Retester le problème initial et les fonctions susceptibles d’être affectées.
Pourquoi cette réponse ? Une correction CSS peut affecter d’autres tailles ou composants ; il faut vérifier le défaut initial et les risques de régression.
Exemple ou vérification autonome Après correction, retestez l’écran concerné puis le mobile et le zoom à 200 %.
Épreuve d’autonomie — 60 minutes
Sans IA : partir du projet du module 9. Produire une grille de 12 contrôles couvrant UX, clavier, responsive, SEO, liens et QR. Détecter au moins deux défauts réels ou démontrer leur absence par des tests. Corriger un défaut simple, documenter les modifications et expliquer oralement pourquoi la correction est adaptée. Barème : diagnostic 8 pts, correction 5 pts, non-régression 4 pts, explication 3 pts. Réussite proposée : 12/20 avec aucun défaut bloquant laissé sans signalement.
Comprendre et essayer — exemple guidé
Je vois : Une décision de recette s'appuie sur des observations, non sur une impression générale.
J’essaie : Sans IA, justifiez un GO/NO GO à partir de trois observations vérifiables.
Je vérifie : Le verdict s’appuie sur trois constats datés et distingue blocage et amélioration.
Autre façon de faire : Examinez trois constats fictifs, dont un défaut bloquant, et expliquez la décision de publication sans demander l’avis d’une IA.
Pour reprendre plus tard : Conservez uniquement l’exemple anonymisé, la correction retenue et l’affirmation ou la donnée qu’il faudra contrôler.
Références pour approfondir
W3C WAI — Web Content Accessibility Guidelines (WCAG) : https://www.w3.org/WAI/standards-guidelines/wcag/
MDN Web Docs — HTML, CSS et accessibilité : https://developer.mozilla.org/fr/
Google Search Central — Documentation SEO : https://developers.google.com/search/docs?hl=fr
Google Search Console : https://search.google.com/search-console/about
web.dev — Performance et Core Web Vitals : https://web.dev/
Note pédagogique : les interfaces des plateformes et leurs procédures évoluent. Les captures d’écran et étapes de navigation devront être vérifiées lors de chaque édition du manuel.
Comprendre et essayer — exemple guidé
Je vois : Une référence d'accessibilité permet de confronter un constat à un critère explicite.
J’essaie : Repérez une règle d’accessibilité à approfondir dans une référence officielle.
Je vérifie : La référence choisie concerne bien la règle testée et une méthode de contrôle est notée.
Autre façon de faire : Consultez une référence officielle d’accessibilité et notez comment tester la règle choisie.
Pour reprendre plus tard : Conservez votre production de l’activité 19, le point précis du critère non encore satisfait et la prochaine vérification à effectuer.
Atelier d’approfondissement — parcours guidé
Ce parcours complète les travaux pratiques du module. Il peut être réalisé sans abonnement payant et ne constitue pas une évaluation certifiante.
Ce que vous allez apprendre — Décrire un contrôle de qualité reproductible et distinguer test réalisé et test prévu.
Matériel nécessaire — Ordinateur avec navigateur pour clavier et zoom ; téléphone utile pour un second affichage.
Organisation sur deux écrans — Vous pouvez lire ce cours sur téléphone et effectuer les manipulations sur ordinateur. Gardez les deux appareils à portée de vue ; aucun transfert de données entre eux n’est obligatoire.
Rédiger une fiche de recette qualité
Comment procéder concrètement
- Ouvrez une page de votre projet et notez le navigateur utilisé.
- Parcourez les liens et boutons avec Tab puis Maj+Tab ; observez le focus.
- Réglez le zoom à 200 % puis 400 % et cherchez les éléments masqués.
- Testez les liens internes et consignez chaque observation dans la fiche de recette.
- Pour chaque anomalie, écrivez comment la reproduire, puis refaites le test après correction.
Si vous n’avez qu’un téléphone — Sur téléphone, contrôlez la lecture et les boutons tactiles ; cela ne remplace pas les essais clavier et zoom sur ordinateur.
Repères pratiques — Distinguer exemple et observation
À réaliser concrètement : La fiche du corrigé contient une anomalie fictive, utilisée seulement pour apprendre à la documenter. Pour votre propre recette, partez d’une fiche vierge : URL ou fichier, navigateur, largeur, action, résultat attendu, résultat observé, statut et correction éventuelle. Ne recopiez pas « réussi » sans test.
Si vous êtes bloqué : Si vous n’avez pas pu tester le zoom ou le clavier, inscrivez « non testé » et expliquez pourquoi.
Essai autonome, sans recopier le modèle : Réalisez une inspection d’une autre page et remplissez une nouvelle fiche sans consulter le modèle.
Étape 1 — Tester au clavier
À faire : Parcourez menu, liens et boutons avec Tab et Maj+Tab.
Exemple ou résultat modèle : Constat : ordre logique ; le focus est visible.
Vérification : Chaque commande est atteignable et activable.
Étape 2 — Tester le zoom
À faire : Passez à 200 % et 400 % et relevez les débordements.
Exemple ou résultat modèle : Anomalie possible : un tableau impose un défilement horizontal local.
Vérification : Aucun texte indispensable n’est masqué.
Étape 3 — Consigner et retester
À faire : Écrivez observation, reproduction, correction et résultat du second test.
Exemple ou résultat modèle : « À 400 %, bouton masqué ; correction CSS ; retest : bouton visible. »
Vérification : La conclusion distingue les contrôles réalisés des points non testés.
Si cela ne fonctionne pas : pistes de dépannage
Une case « réussi » est cochée sans essai : remettez-la à « non testé ». Le focus est invisible : documentez l’élément et vérifiez les styles focus-visible.
Afficher le corrigé commenté
Corrigé modèle : une fiche qualité ne dit pas seulement « conforme ». Elle précise l’environnement, les étapes de reproduction, les observations et les limites de la vérification.
Exemple complet à reproduire
Fichier ou livrable modèle : fiche-recette.txt. Copiez ou adaptez ce contenu dans votre propre dossier de travail.
PAGE TESTÉE : atelier/index.html
ENVIRONNEMENT : navigateur et largeur d'écran à renseigner.
TEST 01 — Clavier : Tab atteint tous les liens ; focus visible.
TEST 02 — Zoom 200 % : aucun contenu essentiel masqué.
TEST 03 — Zoom 400 % : vérifier la lecture et les débordements.
TEST 04 — Lien interne : Entrée rejoint la section Programme.
ANOMALIE (exemple fictif) :
À 400 %, un bouton déborde du conteneur.
REPRODUCTION : ouvrir la page, zoomer à 400 %, atteindre le bouton.
CORRECTION ENVISAGÉE : retirer la largeur fixe.
RETEST : à effectuer et consigner ; ne pas marquer « réussi » sans essai.Pourquoi ce corrigé est valable
Une fiche de recette distingue résultats observés et exemples fictifs. Le test est reproductible grâce à son environnement et ses étapes. Le statut « à effectuer » évite d'affirmer une conformité non vérifiée.
Preuve de vérification attendue
Après réalisation, conservez le fichier produit et une note indiquant la manipulation testée, le résultat réellement observé et les éventuelles limites. Ne cochez pas un test non effectué.
Bilan personnel : notez ce qui fonctionne, ce qui reste à vérifier et une amélioration possible. Aucun résultat de cet atelier n’est envoyé au site.
Complément de corrigé TP — exemple de vérification et diagnostic
Audit UX et accessibilité — Noter le problème observé, la preuve, le public affecté et un changement précis. Vérifier au clavier et sur écran étroit sans confondre préférence esthétique et obstacle d’usage.
Variante autonome : changer un seul élément de votre réalisation, prévoir le résultat, effectuer le test et consigner ce qui a réellement été observé. Plusieurs solutions sont acceptables si elles satisfont les critères du TP.
Laboratoire ludique facultatif — L’enquête d’accessibilité
Explore une page fictive, repère les obstacles au clavier, au contraste, au zoom et aux alternatives textuelles, puis compare les corrections. Aucun score et aucun audit réel.
Ouvrir le laboratoire M10 — enquête d’accessibilité
Afficher le corrigé commenté — Observation / hypothèse / amélioration
Exemple : tâche « trouver les trois créations ». Observation : le lien « Découvrir » est ambigu hors contexte ; amélioration : « Découvrir les trois créations ». Un test avec un pair est une observation utilisateur ; sans pair, noter « inspection personnelle », et ne pas attribuer à un utilisateur des réactions imaginées.