Captures d'écran annotées : règles et exemples

Une capture d’écran annotée montre un état réel de l’interface et identifie les zones exactes qu’un lecteur doit remarquer. L’image porte des marqueurs numérotés ; la page porte la légende textuelle correspondante. Cette séparation constitue l’élément : ni une image produit non annotée, ni des étiquettes intégrées dans les pixels ne satisfont le contrat.

Audit de fraîcheur du contenu, filtré sur une URL suivie.

1. URL suivie : Confirme que la revue s’applique à la page visée plutôt qu’à l’ensemble du domaine.
2. Filtre de statut : Réduit le tableau aux pages nécessitant une décision éditoriale.
3. Date du résultat : Indique quand l’enregistrement d’audit sous-jacent a été actualisé pour la dernière fois.

La capture est en attente, donc le commentaire est une spécification de capture de production plutôt qu’une référence d’image cassée. Une fois l’actif existant, l’image, la légende et la liste numérotée s’affichent comme une figure sémantique unique.

Pourquoi cet élément est important

Les lecteurs utilisent une image produit pour répondre à une question spatiale : « Quel contrôle, valeur ou état cette instruction désigne-t-elle ? » Les interfaces denses contiennent de la navigation, des filtres, des étiquettes, des données, des badges et des actions qui peuvent tous sembler également importants. Une capture d’écran non annotée demande au lecteur de rétroconcevoir l’attention de l’auteur. Les marqueurs numérotés réduisent cette recherche à une correspondance directe entre un emplacement visible et une courte explication.

L’élément remplace également le langage fragile de coordonnées. « Utilisez le contrôle à droite » devient faux lorsqu’une barre d’outils se réorganise ; « choisissez le filtre de statut marqué 2 » reste utilisable tant que la capture est à jour.

L’extractibilité automatique signifie que le logiciel peut isoler et réutiliser le sens utile d’une unité de contenu. La vision par ordinateur peut reconnaître le texte d’une interface, mais elle ne peut pas déduire de manière fiable pourquoi l’un des vingt contrôles est important pour cette procédure. Une légende visible et ordonnée crée des paires explicites marqueur-explication que les systèmes de recherche, les outils de traduction, les logiciels d’accessibilité et les audits de contenu peuvent traiter comme du texte. L’image fournit la preuve spatiale ; la légende fournit le sens interrogeable. Cela suit les règles de rédaction des éléments générales : le contenu reste typé et portable même lorsque son moteur de rendu change.

N’intégrez jamais la légende dans les pixels. Le texte pixelisé ne peut pas être traduit, recherché, sélectionné ou corrigé sans modifier l’illustration. Il est également invisible pour un lecteur d’écran, un logiciel qui annonce le contenu numérique aux personnes qui ne peuvent pas voir l’écran. Seuls les numéros de marqueurs appartiennent à l’image.

Quand l’utiliser

Utilisez une capture d’écran annotée lorsque le lecteur doit identifier une zone spécifique dans une interface réelle et que les mots seuls laissent plus d’une cible plausible. Elle est requise lorsque deux contrôles ont des noms similaires, qu’un état important est subtil, qu’un résultat doit être interprété dans son contexte environnant, ou qu’une configuration visuelle ne peut pas être représentée fidèlement en prose. Elle est également utile lorsqu’une page produit formule une affirmation concrète sur l’interface que l’image peut prouver.

Une capture d’écran est facultative lorsque l’instruction nomme déjà un contrôle unique et visible et que l’interaction est conventionnelle. « Sélectionnez Enregistrer les modifications » n’a normalement besoin d’aucune image lorsque la page contient un seul bouton de ce type. Elle devient requise si le même écran propose Enregistrer le brouillon, Enregistrer la vue et Enregistrer les modifications, et que choisir le mauvais bouton change le résultat.

Une capture d’écran est nuisible lorsqu’elle ajoute du poids sans résoudre l’incertitude. N’en ajoutez pas une pour la décoration ou pour répéter un texte qui est plus clair dans un tableau. Quatorze captures d’écran dans un guide de quatorze étapes créent quatorze interruptions, des problèmes de zoom mobile et des actifs obsolètes. Capturez les étapes ambiguës ; laissez les verbes précis porter les étapes courantes.

Les quasi-échecs incluent :

• Un tableau de bord complet utilisé pour expliquer une seule icône : recadrez à la plus petite région qui préserve l’orientation. Un marqueur perdu dans une interface large ne réduit pas l’effort de recherche.
• Une capture d’écran utilisée comme preuve numérique : répétez la valeur décisive en texte ou dans un tableau. Les pixels ne peuvent pas être la seule copie accessible d’une affirmation.
• Une capture d’écran d’un menu avant son ouverture : capturez l’état que le lecteur doit inspecter. L’état fermé prouve que le produit existe mais pas quel choix faire.
• Une capture d’écran contenant des enregistrements clients : remplacez-les par des données de démonstration stables avant la capture. Le floutage est facile à oublier.
• Un diagramme déguisé en capture d’écran : utilisez un diagramme pour les relations abstraites. Le réalisme de l’interface n’aide que lorsque l’interface compte.

Où la placer

Placez la figure après le paragraphe ou l’étape qui demande au lecteur d’inspecter l’interface pour la première fois. Dans une procédure, placez-la après l’action et avant l’état de succès ou le dépannage, afin que le lecteur localise le contrôle avant de vérifier le résultat.

Gardez l’image, la légende et la liste numérotée ensemble. Un titre peut introduire le groupe, mais un autre paragraphe, un encadré, une publicité ou un saut de page ne doit pas séparer la capture de ses explications numérotées. Une légende identifie l’écran entier et son contexte ; elle ne porte pas d’instruction qui appartient à la prose ni ne remplace la liste numérotée.

Ne placez pas deux captures d’écran en pleine largeur côte à côte. Insérez l’explication qui les distingue, ou créez une comparaison étiquetée lorsque les deux états doivent être évalués ensemble. Éloignez les captures d’écran des appels à l’action non liés, des tableaux denses et des galeries.

Répétez l’élément uniquement lorsque chaque occurrence répond à une question spatiale différente. Préférez une figure ciblée ; sinon, donnez aux différents recadrages des noms de fichiers et des objectifs distincts.

Anatomie

La capture d’anatomie montre les parties visibles et textuelles d’un élément complet. Les étiquettes explicatives restent dans la légende rendue plutôt que de faire partie de l’image source.

Légende rendue

1. Limite de contexte : Inclut suffisamment d’interface environnante pour identifier la page et l’emplacement, mais exclut la navigation non liée et les espaces vides.
2. Marqueur numéroté : Utilise un cercle à fort contraste et un entier, pas seulement la couleur, pour relier une région à son entrée de légende.
3. Zone cible : Marque le plus petit contrôle, valeur ou état complet nécessaire à l’explication ; il ne recouvre jamais l’étiquette de la cible.
4. Repère d’orientation : Préserve un en-tête, un onglet ou une étiquette de panneau stable afin que le lecteur puisse trouver la même zone dans le produit en direct.
5. Légende : Nomme l’écran, l’état et le scénario en texte visible sous l’image.
6. Liste numérotée : Utilise une liste ordonnée dont les numéros correspondent exactement aux marqueurs et dont les entrées expliquent la signification, pas seulement l’apparence.

Les numéros de marqueurs commencent à 1 et suivent l’ordre de la légende. Utilisez deux à six par image ; un seul convient pour une cible difficile, tandis que plus de six signale généralement une capture trop large.

Exemples de conception

Les variantes prises en charge changent le recadrage et la fenêtre d’affichage, pas la politique d’annotation. Chaque variante utilise des données de démonstration, des marqueurs d’image numérotés, une légende textuelle externe et une légende visible.

Contrôle ciblé : Préféré pour une seule action ambiguë. Préservez une étiquette d’orientation pour que le recadrage ne devienne pas un rectangle anonyme.

État du flux de travail : À utiliser lorsque la relation entre une entrée, un statut et un résultat est importante. Gardez la navigation globale non liée hors du cadre.

URL en contexte : La seule variante standard qui inclut le chrome du navigateur, c’est-à-dire les onglets, la barre d’adresse et les contrôles du navigateur. Incluez uniquement la barre d’adresse et l’indicateur d’autorisation ou de sécurité nécessaire.

État mobile : Capturez la disposition réellement étroite lorsque l’interaction change à la largeur mobile. Ne réduisez pas un écran large d’ordinateur en l’appelant un exemple mobile.

Paramètres

Les paramètres constituent le contrat de contenu portable. Les valeurs visuelles telles que la couleur des marqueurs, l’épaisseur des bordures et la typographie des légendes appartiennent au moteur de rendu et ne sont pas des champs d’auteur.

Le screenId identifie la surface du produit indépendamment de son nom de fichier, afin qu’une version puisse trouver différents recadrages de content-freshness-audit. Le fichier alt.yaml reste simple : un nom de fichier suivi d’une chaîne de texte alternatif pliée.

Syntaxe et exemples de code

Chaque notation préserve les mêmes métadonnées, légende, marqueurs et ordre de lecture image–légende–liste numérotée.

Directive Markdown portable

:::annotated-screenshot{src="/images/seo-playbook/elements/annotated-screenshot/workflow-state.webp" viewport=1440 density="2x" screenId="content-freshness-audit" captureDate="2026-08-27"}
Audit de fraîcheur du contenu filtré sur une URL suivie.

1. **URL suivie :** Confirme quelle page l'audit évalue.
2. **Filtre de statut :** Limite les résultats aux pages en attente de révision.
3. **Date du résultat :** Indique quand les données d'audit ont été actualisées.
:::

L’adaptateur résout alt à partir du fichier alt.yaml du dossier. Une clé de nom de fichier manquante est un échec de publication, pas une autorisation à copier la légende.

Mappage de shortcode Hugo

{{< annotated-screenshot src="/images/seo-playbook/elements/annotated-screenshot/workflow-state.webp" viewport="1440" density="2x" screenId="content-freshness-audit" captureDate="2026-08-27" >}}
Audit de fraîcheur du contenu filtré sur une URL suivie.

1. **URL suivie :** Confirme quelle page l'audit évalue.
2. **Filtre de statut :** Limite les résultats aux pages en attente de révision.
3. **Date du résultat :** Indique quand les données d'audit ont été actualisées.
{{< /annotated-screenshot >}}

Il s’agit d’un contrat d’adaptateur, pas d’un shortcode enregistré. Tant qu’un moteur de rendu approuvé et un actif n’existent pas, utilisez le pipeline de figure sémantique établi ou laissez le commentaire de capture prescrit. Ne substituez pas un moteur de rendu qui supprime la légende ou les champs de fraîcheur.

Bloc ou shortcode WordPress

[annotated_screenshot src="workflow-state.webp" viewport="1440" density="2x" screen_id="content-freshness-audit" capture_date="2026-08-27"]
[caption]Audit de fraîcheur du contenu filtré sur une URL suivie.[/caption]
[marker number="1" label="URL suivie"]Confirme quelle page l'audit évalue.[/marker]
[marker number="2" label="Filtre de statut"]Limite les résultats aux pages en attente de révision.[/marker]
[marker number="3" label="Date du résultat"]Indique quand les données d'audit ont été actualisées.[/marker]
[/annotated_screenshot]

Un bloc WordPress peut exposer les champs comme des contrôles, mais il doit stocker les descriptions des marqueurs sous forme de texte.

Exemples

Bon : un état ambigu, trois marqueurs utiles

Revue de fraîcheur du contenu pour demo.example/pricing/.

1. URL suivie : Vérifie que le résultat appartient à la page de tarification sélectionnée dans l’instruction.
2. À revoir : Identifie le filtre exact qui supprime les pages à jour de la file de travail.
3. Dernière actualisation : Empêche l’éditeur de traiter un ancien résultat d’audit comme un diagnostic actuel.

Cela fonctionne car chaque marqueur répond à une décision, le recadrage préserve l’orientation et la légende explique les conséquences non visibles dans les pixels. Le domaine de démonstration n’est clairement pas une donnée client.

Mauvais : une affiche produit étiquetée

La version mauvaise explique un tableau de bord entier en une seule fois. Huit flèches se croisent, les étiquettes masquent les contrôles et la promotion intégrée ne donne aucune action. Les marque-pages du navigateur créent un risque de confidentialité, les noms de clients rendent l’approbation incertaine, aucun identifiant d’écran ne prend en charge les mises à jour et le redimensionnement mobile rend les cibles illisibles.

Réparez-la en sélectionnant une tâche, en utilisant des données de démonstration approuvées, en recadrant son panneau et en ne conservant que les marqueurs nécessaires. Déplacez les explications dans une légende textuelle, ajoutez un texte alternatif contextuel et enregistrez l’identifiant d’écran et la date.

Balisage schema et accessibilité

Une capture d’écran annotée n’a pas de type Schema.org spécial. Elle peut alimenter la propriété image d’un Article ou un ImageObject avec contentUrl, légende, largeur et hauteur précises. N’inventez pas de propriétés de marqueur ; gardez la légende visible.

Utilisez la sémantique native de figure : un <figure> contenant l’<img>, un <figcaption> et la liste ordonnée. La légende nomme l’écran et l’état entiers. L’attribut alt de l’image décrit ce que l’écran montre dans ce contexte ; il ne doit pas commencer par « capture d’écran de », car l’élément image s’annonce déjà comme tel. La légende fournit les explications numérotées détaillées, donc répéter les six entrées dans le texte alternatif crée une annonce longue et redondante.

Visez 80 à 180 caractères, avec un maximum de 250. Nommez la zone du produit, l’état et l’objectif marqué : « Audit de fraîcheur du contenu filtré sur une URL suivie, avec des marqueurs sur le filtre de statut et la date de dernière actualisation. » Ne transcrivez pas l’interface, ne bourrez pas de mots-clés et n’utilisez pas le nom de fichier. Cette image informative a normalement besoin d’un texte alternatif non vide.

Les numéros de marqueurs doivent être lisibles sans couleur. Utilisez un contraste élevé à la fois sur les zones d’interface claires et sombres, maintenez leur taille visuelle cohérente et ne couvrez pas les étiquettes ou les valeurs. La légende utilise une liste ordonnée dans l’ordre normal du document ; évitez les rôles ARIA (Accessible Rich Internet Applications) qui transforment un contenu statique en alerte ou widget interactif. Une relation aria-describedby est facultative uniquement lorsque les tests montrent qu’elle améliore la navigation sans que la légende visible soit annoncée deux fois.

Aux largeurs étroites, le design responsive doit préserver le sens. Redimensionnez une image large uniquement si les marqueurs et les cibles restent lisibles ; sinon, fournissez un recadrage ciblé ou une véritable capture mobile. Ne provoquez jamais de défilement horizontal au niveau de la page ni de zoom obligatoire. La légende et la liste numérotée se placent en dessous.

Règles de contenu et de capture

La cohérence rend les captures d’écran comparables et remplaçables. Capturez les écrans produit sur ordinateur à une fenêtre d’affichage fixe de 1440 pixels CSS et une densité de pixels de 2x, souvent appelée densité Retina, qui enregistre deux pixels d’appareil pour chaque pixel CSS. Capturez les états mobiles réels à 390 pixels CSS et densité 2x. Utilisez le thème produit approuvé de manière cohérente dans un guide ; n’alternez pas le mode clair et sombre sauf si la différence de thème est le sujet.

Utilisez uniquement des données de démonstration : pas de vrais noms, adresses e-mail, domaines, informations de facturation, jetons, invites ou résultats. Inspectez les barres latérales, les éléments récents, la saisie automatique, les notifications et les avatars avant la capture.

Excluez le chrome du navigateur sauf si une URL, une autorisation ou un contrôle du navigateur est le sujet. Masquez les onglets, les marque-pages, les extensions, les téléchargements, les profils et les notifications. Capturez après le chargement ; fermez les infobulles non pertinentes et n’affichez un curseur que si nécessaire.

Stockez les captures source sous cdn-assets/seo-playbook/elements/annotated-screenshot/. Utilisez des noms en casse kebab minuscule basés sur l’écran et l’état, comme freshness-audit-needs-review.webp ; n’utilisez jamais final, new, v2, un nom de personne ou une date comme nom de fichier. Le nom stable permet de remplacer l’actif sans réécrire chaque page. Utilisez WebP pour la livraison normale, de préférence un paramètre sans perte lorsque le petit texte d’interface doit rester net. Utilisez PNG uniquement lorsque le pipeline de production démontre que WebP nuit au texte ou à la transparence. N’utilisez pas JPEG pour les captures d’interface avec du texte fin et des bords nets.

Rendu à 1600 pixels CSS maximum de large ; une source 1440 pixels 2x peut faire 2880 pixels physiques. Préservez le rapport hauteur/largeur et les dimensions intrinsèques. L’optimisation soutient le SEO des images , mais la compression ne doit pas brouiller le texte ou les marqueurs.

Chaque dossier d’actifs contient alt.yaml avec une entrée par nom de fichier :

freshness-audit-needs-review.webp: >-
  Audit de fraîcheur du contenu AmICited filtré sur une URL suivie, avec des marqueurs numérotés sur le statut de révision et la date de dernière actualisation.

La clé correspond exactement au nom de fichier ; la valeur est le texte alternatif, pas une légende ou une liste numérotée. Les espaces réservés, les tableaux de bord génériques et les références d’images inexistantes sont interdits. Les captures en attente utilisent uniquement un commentaire SCREENSHOT et screenshotsPending = true.

Politique de fraîcheur et de nouvelle capture

Les captures d’écran vieillissent silencieusement lorsqu’un contrôle représenté se déplace ou change de nom. Traitez chaque capture comme une vue d’un écran enregistré : screenId relie les changements produit aux actifs, tandis que la date de capture identifie l’état enregistré.

Un changement d’interface utilisateur déclenche une nouvelle capture lorsqu’il déplace ou renomme une cible marquée, modifie l’état que la légende explique, altère le chemin de navigation nécessaire pour y accéder, supprime un repère d’orientation préservé, ou rend l’ancienne image susceptible d’envoyer le lecteur vers le mauvais contrôle. Refaites la capture de l’ensemble complet des figures pour cet écran, y compris les variantes ciblées et mobiles. Un changement de jeton de couleur, un ajustement d’espacement ou un ajout de barre latérale non lié ne nécessite pas de remplacement automatique, sauf si la capture d’écran entre désormais en conflit visible avec l’expérience en direct ou la norme d’accessibilité.

Lorsqu’un écran change, recherchez son screenId, puis son dossier et son nom de fichier pour retrouver les utilisations héritées. Remplacez les fichiers stables, révisez alt.yaml et inspectez chaque légende concernée. Ne renommez pas les fichiers de remplacement en laissant les références plus anciennes orphelines.

Le propriétaire de l’écran produit signale les changements ; le propriétaire du contenu accepte les remplacements. Recapturez avec le même environnement de démonstration, la même fenêtre d’affichage, la même densité et le même thème. Révisez les captures d’écran lors de chaque actualisation substantielle de la page.

Types d’articles qui l’utilisent

Le champ postTypes dans le frontmatter est la jonction enregistrée. Chaque type utilise le même contrat d’élément mais applique un seuil d’exigence différent.

Les études de cas nécessitent une frontière supplémentaire : soit obtenir l’autorisation explicite de montrer de vraies informations clients, soit reconstruire l’interface avec des données de démonstration clairement divulguées et la traiter comme une illustration de flux de travail, pas comme une preuve de résultat. La rédaction n’est pas un substitut au consentement ou à un environnement contrôlé.

Liste de contrôle QA

Un réviseur vérifie le risque de communication et de maintenance avant le polissage visuel.

• Objectif : La figure résout une ambiguïté spatiale ou prouve une affirmation d’interface visible.
• Nécessité : Les étapes courantes restent en texte ; la page n’attribue pas une capture d’écran à chaque étape par défaut.
• État réel : La capture montre le menu ouvert exact, le filtre sélectionné, le résultat ou l’erreur discuté dans le texte.
• Données de démonstration : Aucune information client, employé, compte, navigateur, jeton, invite ou facturation n’est visible.
• Cohérence de capture : La fenêtre d’affichage, la densité 2x, le thème, l’état de l’interface et la règle du chrome du navigateur correspondent à la norme.
• Recadrage ciblé : Suffisamment de contexte reste pour l’orientation, mais les zones d’interface non liées ne concurrencent pas la cible.
• Marqueurs : Il y a un à six numéros continus, chacun à fort contraste, lisible et dégagé des étiquettes et des valeurs.
• Légende externe : Chaque marqueur a une entrée de liste ordonnée correspondante dans le texte de la page ; aucun libellé de légende n’est intégré dans les pixels.
• Légende : La figure a une légende visible concise nommant son écran, son état et son scénario.
• Texte alternatif : Le fichier alt.yaml du dossier contient une clé de nom de fichier exacte et une description contextuelle dans la plage de longueur cible.
• Comportement mobile : La cible et les marqueurs restent lisibles sans défilement horizontal au niveau de la page ni zoom obligatoire ; sinon, un recadrage ciblé existe.
• Contrat de fichier : Le chemin, le nom en casse kebab minuscule, le format, les dimensions et la taille intrinsèque suivent la norme de livraison.
• Fraîcheur : screenId et la date de capture sont enregistrés, l’interface utilisateur en direct correspond toujours et toutes les références peuvent être trouvées par recherche textuelle.
• Parité portable : Les représentations Markdown, Hugo et WordPress préservent le même actif, la même légende, le même ordre des marqueurs et le même libellé de légende.
• Aucun actif cassé : Un chemin d’image réel n’apparaît qu’après la création du fichier ; les captures en attente restent des commentaires avec screenshotsPending = true.

FAQ

Le modèle d’academy affiche les cinq questions examinées stockées dans le champ [[faq]] du frontmatter de cette page. Elles couvrent la fréquence des captures d’écran, les légendes externes, la longueur du texte alternatif, les déclencheurs de nouvelle capture et l’exception du chrome du navigateur.