Geannoteerde Screenshots: Regels en Voorbeelden

Een geannoteerde screenshot toont een echte interfacestatus en identificeert de exacte regio’s die een lezer moet opmerken. De afbeelding draagt genummerde markers; de pagina draagt de bijpassende tekstlegenda. Die scheiding is het element: noch een ongemarkeerde productafbeelding, noch labels die in pixels zijn gebakken, voldoet aan de overeenkomst.

Content freshness audit, gefilterd op één gevolgde URL.

1. Gevolgde URL: Bevestigt dat de beoordeling van toepassing is op de beoogde pagina in plaats van het hele domein.
2. Statusfilter: Verkleint de tabel tot pagina’s die een redactionele beslissing vereisen.
3. Resultaatdatum: Toont wanneer het onderliggende auditrecord voor het laatst is ververst.

De opname is in behandeling, dus de opmerking is een productie-opnamespecificatie in plaats van een verwijzing naar een gebroken afbeelding. Zodra het bestand bestaat, worden de afbeelding, het bijschrift en de genummerde legenda weergegeven als één semantische figuur.

Waarom dit element ertoe doet

Lezers gebruiken een productafbeelding om een ruimtelijke vraag te beantwoorden: “Welk besturingselement, waarde of status wordt met deze instructie bedoeld?” Dichte interfaces bevatten navigatie, filters, labels, gegevens, badges en acties die er allemaal even belangrijk uit kunnen zien. Een niet-geannoteerde screenshot vraagt de lezer om de aandacht van de auteur te achterhalen. Genummerde markers verminderen die zoektocht tot een directe match tussen een zichtbare locatie en een korte uitleg.

Het element vervangt ook kwetsbare coördinatentaal. “Gebruik het besturingselement aan de rechterkant” wordt fout wanneer een werkbalk terugloopt; “kies het statusfilter gemarkeerd met 2” blijft bruikbaar zolang de opname actueel is.

Machine-extracteerbaarheid betekent dat software de bruikbare betekenis van een inhoudseenheid kan isoleren en hergebruiken. Computervisie kan interfacetekst herkennen, maar kan niet betrouwbaar afleiden waarom een van de twintig bedieningselementen belangrijk is voor deze procedure. Een zichtbare, geordende legenda creëert expliciete marker-naar-uitleg-paren die zoeksystemen, vertaaltools, toegankelijkheidssoftware en inhoudsaudits als tekst kunnen verwerken. De afbeelding levert ruimtelijk bewijs; de legenda levert doorzoekbare betekenis. Dit volgt de bredere element-schrijfregels : inhoud blijft getypeerd en draagbaar, zelfs wanneer de renderer verandert.

Bak de legenda nooit in pixels. Pixeltekst kan niet worden vertaald, doorzocht, geselecteerd of gecorrigeerd zonder de afbeelding te bewerken. Het is ook onzichtbaar voor een schermlezer, software die digitale inhoud aankondigt aan mensen die het scherm niet kunnen zien. Alleen markernummers horen in de afbeelding.

Wanneer gebruiken

Gebruik een geannoteerde screenshot wanneer de lezer een specifiek gebied in een echte interface moet identificeren en woorden alleen meer dan één plausibel doelwit overlaten. Het is vereist wanneer twee bedieningselementen vergelijkbare namen hebben, een belangrijke status subtiel is, een resultaat moet worden geïnterpreteerd in zijn omringende context, of een visuele configuratie niet getrouw in proza kan worden weergegeven. Het is ook nuttig wanneer een productpagina een concrete interfaceclaim doet die de afbeelding kan bewijzen.

Een screenshot is optioneel wanneer de instructie al een uniek, zichtbaar besturingselement noemt en de interactie conventioneel is. “Selecteer Wijzigingen opslaan” heeft normaal gesproken geen afbeelding nodig wanneer de pagina één zo’n knop bevat. Het wordt vereist als hetzelfde scherm Concept opslaan, Weergave opslaan en Wijzigingen opslaan bevat, en het kiezen van de verkeerde de uitkomst verandert.

Een screenshot is schadelijk wanneer het gewicht toevoegt zonder onzekerheid weg te nemen. Voeg er geen toe ter decoratie of om tekst te herhalen die duidelijker is in een tabel. Veertien screenshots in een gids van veertien stappen creëren veertien onderbrekingen, mobiele zoomproblemen en verouderde bestanden. Leg de dubbelzinnige stappen vast; laat gebruikelijke werkwoorden de routinestappen dragen.

Bijna-missers zijn onder andere:

• Een volledig dashboard gebruikt om één pictogram uit te leggen: knip bij tot het kleinste gebied dat de oriëntatie behoudt. Een marker verloren in een brede interface vermindert de zoekinspanning niet.
• Een screenshot gebruikt als numeriek bewijs: herhaal de beslissende waarde in tekst of een tabel. Pixels kunnen niet de enige toegankelijke kopie van een bewering zijn.
• Een screenshot van een menu voordat het opent: leg de status vast die de lezer moet inspecteren. De gesloten status bewijst dat het product bestaat, maar niet welke keuze te maken.
• Een screenshot met klantgegevens: vervang deze door stabiele demogegevens vóór de opname. Vervagen wordt gemakkelijk over het hoofd gezien.
• Een diagram vermomd als screenshot: gebruik een diagram voor abstracte relaties. Interfacerealisme helpt alleen wanneer de interface er toe doet.

Waar plaatsen

Plaats de figuur na de alinea of stap die de lezer voor het eerst vraagt de interface te inspecteren. Zet het in een procedure na de actie en vóór de successtatus of probleemoplossing, zodat de lezer het besturingselement lokaliseert voordat hij het resultaat verifieert.

Houd de afbeelding, het bijschrift en de legenda bij elkaar. Een kop kan de groep introduceren, maar een andere alinea, uitgelicht blok, advertentie of paginascheiding mag de opname niet scheiden van de genummerde uitleg. Een bijschrift identificeert het volledige scherm en de context; het bevat geen instructie die in het proza thuishoort of vervangt de legenda niet.

Plaats geen twee schermvullende screenshots naast elkaar. Voeg de uitleg in die ze onderscheidt, of maak één gelabelde vergelijking wanneer beide statussen samen moeten worden geëvalueerd. Houd screenshots weg van niet-gerelateerde call-to-actions, dichte tabellen en galerijen.

Herhaal het element alleen wanneer elk voorkomen een andere ruimtelijke vraag beantwoordt. Geef de voorkeur aan één gerichte figuur; geef anders aparte uitsneden verschillende bestandsnamen en doeleinden.

Anatomie

De anatomie-opname toont de zichtbare en tekstuele delen van één compleet element. Verklarende labels blijven in de weergegeven legenda in plaats van deel uit te maken van de bronafbeelding.

Weergegeven legenda

1. Contextgrens: Bevat voldoende omringende interface om de pagina en locatie te identificeren, maar sluit niet-gerelateerde navigatie en lege ruimte uit.
2. Genummerde marker: Gebruikt een contrastrijke cirkel en een geheel getal, niet alleen kleur, om een regio te verbinden met zijn legendaitem.
3. Doelgebied: Markeert het kleinste volledige besturingselement, waarde of status dat nodig is voor de uitleg; het bedekt nooit het label van het doel.
4. Oriëntatiemarkering: Behoudt één stabiele kop, tabblad- of paneellabel zodat de lezer hetzelfde gebied in het live-product kan vinden.
5. Bijschrift: Noemt het scherm, de status en het scenario in zichtbare tekst onder de afbeelding.
6. Legenda: Gebruikt een geordende lijst waarvan de nummers exact overeenkomen met de markers en waarvan de items het belang uitleggen, niet alleen het uiterlijk.

Markernummers beginnen bij 1 en volgen de legendavolgorde. Gebruik twee tot zes per afbeelding; één is geschikt voor een moeilijk doel, terwijl meer dan zes meestal wijst op een te brede opname.

Ontwerpvoorbeelden

De ondersteunde varianten wijzigen de uitsnede en viewport, niet het annotatiebeleid. Elke variant gebruikt demogegevens, genummerde afbeeldingsmarkers, een externe tekstlegenda en een zichtbaar bijschrift.

Gericht besturingselement: De voorkeur voor een enkele dubbelzinnige actie. Behoud één oriëntatielabel zodat de uitsnede geen anonieme rechthoek wordt.

Werkstroomstatus: Gebruik wanneer de relatie tussen een invoer, een status en een resultaat ertoe doet. Houd niet-gerelateerde globale navigatie buiten beeld.

URL in context: De enige standaardvariant die browserchrome omvat, dat wil zeggen de eigen tabbladen, adresbalk en besturingselementen van de browser. Neem alleen de adresbalk en de benodigde machtigings- of veiligheidsindicator op.

Mobiele status: Leg de daadwerkelijke smalle lay-out vast wanneer de interactie verandert bij mobiele breedte. Verklein geen breed desktopscherm en noem het een mobiel voorbeeld.

Parameters

De parameters vormen het draagbare inhoudscontract. Visuele waarden zoals markerkleur, randdikte en bijschrifttypografie behoren tot de renderer en zijn geen auteurvelden.

De screenId identificeert het productoppervlak onafhankelijk van de bestandsnaam, zodat een release verschillende uitsneden van content-freshness-audit kan vinden. Het alt.yaml-bestand blijft eenvoudig: één bestandsnaam gevolgd door één gevouwen alt-teksttekenreeks.

Syntax en codevoorbeelden

Elke notatie behoudt dezelfde metadata, bijschrift, markers en leesvolgorde afbeelding–bijschrift–legenda.

Draagbare Markdown-directive

:::annotated-screenshot{src="/images/seo-playbook/elements/annotated-screenshot/workflow-state.webp" viewport=1440 density="2x" screenId="content-freshness-audit" captureDate="2026-08-27"}
Content freshness audit gefilterd op één gevolgde URL.

1. **Gevolgde URL:** Bevestigt welke pagina de audit evalueert.
2. **Statusfilter:** Beperkt de resultaten tot pagina's die wachten op beoordeling.
3. **Resultaatdatum:** Toont wanneer de auditgegevens zijn ververst.
:::

De adapter lost alt op uit de alt.yaml van de map. Een ontbrekende bestandsnaamsleutel is een publicatiefout, geen toestemming om het bijschrift te kopiëren.

Hugo shortcode-mapping

{{< annotated-screenshot src="/images/seo-playbook/elements/annotated-screenshot/workflow-state.webp" viewport="1440" density="2x" screenId="content-freshness-audit" captureDate="2026-08-27" >}}
Content freshness audit gefilterd op één gevolgde URL.

1. **Gevolgde URL:** Bevestigt welke pagina de audit evalueert.
2. **Statusfilter:** Beperkt de resultaten tot pagina's die wachten op beoordeling.
3. **Resultaatdatum:** Toont wanneer de auditgegevens zijn ververst.
{{< /annotated-screenshot >}}

Dit is een adaptercontract, geen geregistreerde shortcode. Totdat een goedgekeurde renderer en asset bestaan, gebruikt u de gevestigde semantic-figure-pijplijn of laat u de voorgeschreven opnameopmerking staan. Vervang geen renderer die de legenda- of versheidsvelden laat vallen.

WordPress-blok of shortcode

[annotated_screenshot src="workflow-state.webp" viewport="1440" density="2x" screen_id="content-freshness-audit" capture_date="2026-08-27"]
[caption]Content freshness audit gefilterd op één gevolgde URL.[/caption]
[marker number="1" label="Tracked URL"]Bevestigt welke pagina de audit evalueert.[/marker]
[marker number="2" label="Status filter"]Beperkt de resultaten tot pagina's die wachten op beoordeling.[/marker]
[marker number="3" label="Result date"]Toont wanneer de auditgegevens zijn ververst.[/marker]
[/annotated_screenshot]

Een WordPress-blok kan de velden als besturingselementen tonen, maar moet markerbeschrijvingen opslaan als tekst.

Voorbeelden

Goed: één dubbelzinnige status, drie nuttige markers

Content freshness-beoordeling voor demo.example/pricing/.

1. Gevolgde URL: Verifieert dat het resultaat hoort bij de prijspagina geselecteerd in de instructie.
2. Moet worden beoordeeld: Identificeert het exacte filter dat huidige pagina’s uit de werkrij verwijdert.
3. Laatst ververst: Voorkomt dat de redacteur een oud auditresultaat behandelt als een actuele diagnose.

Dit werkt omdat elke marker een beslissing beantwoordt, de uitsnede de oriëntatie behoudt en de legenda gevolgen uitlegt die niet zichtbaar zijn in pixels. Het demo-domein is duidelijk geen klantgegevens.

Slecht: een gelabelde productposter

De slechte versie legt een volledig dashboard in één keer uit. Acht pijlen kruisen elkaar, labels verbergen bedieningselementen en ingebakken promotie geeft geen actie. Browserbladwijzers creëren privacyrisico’s, klantnamen maken goedkeuring onzeker, geen scherm-id ondersteunt updates en mobiele schaling maakt doelen onleesbaar.

Herstel het door één taak te selecteren, goedgekeurde demogegevens te gebruiken, uit te snijden tot het paneel en alleen noodzakelijke markers te behouden. Verplaats uitleg naar een tekstlegenda, voeg contextuele alt-tekst toe en noteer de scherm-ID en datum.

Schema-markup en toegankelijkheid

Een geannoteerde screenshot heeft geen speciaal Schema.org-type. Het kan de image-eigenschap van een Article of een ImageObject vullen met accurate contentUrl, bijschrift, breedte en hoogte. Verzin geen markereigenschappen; houd de legenda zichtbaar.

Gebruik native figuursemantiek: één <figure> met de <img>, een <figcaption> en de geordende legenda. Het bijschrift benoemt het hele scherm en de status. Het alt-attribuut van de afbeelding beschrijft wat het scherm in deze context toont; het moet niet beginnen met “screenshot van”, omdat het afbeeldingselement zichzelf al aankondigt. De legenda levert de gedetailleerde genummerde uitleg, dus het herhalen van alle zes items in alt-tekst creëert een lange, dubbele aankondiging.

Streef naar 80–180 tekens, met 250 als maximum. Noem het productgebied, de status en het gemarkeerde doel: “Content freshness audit gefilterd op één gevolgde URL, met markers op het statusfilter en de laatst ververste datum.” Transcribeer niet de interface, prop geen trefwoorden of gebruik de bestandsnaam. Deze informatieve afbeelding heeft normaal gesproken niet-lege alt-tekst nodig.

Markernummers moeten leesbaar zijn zonder kleur. Gebruik hoog contrast tegen zowel lichte als donkere interfacegebieden, houd hun visuele grootte consistent en bedek geen labels of waarden. De legenda gebruikt een geordende lijst in normale documentvolgorde; vermijd ARIA, of Accessible Rich Internet Applications, rollen die statische inhoud veranderen in een melding of interactieve widget. Een aria-describedby-relatie is alleen optioneel wanneer tests aantonen dat het de navigatie verbetert zonder dat de zichtbare legenda twee keer wordt aangekondigd.

Bij smalle breedtes moet responsief ontwerp de betekenis behouden. Schaalaanpassing van een brede afbeelding is alleen toegestaan zolang markers en doelen leesbaar blijven; geef anders een gerichte uitsnede of een echte mobiele opname. Zorg nooit voor horizontaal scrollen op paginaniveau of vereiste zoom. Bijschrift en legenda worden eronder teruggewikkeld.

Inhouds- en opnameregels

Consistentie maakt screenshots vergelijkbaar en vervangbaar. Leg desktop-productscreens vast op een vaste 1440 CSS-pixel viewport en 2x pixeldichtheid, vaak Retina-dichtheid genoemd, wat twee apparaatpixels per CSS-pixel registreert. Leg echte mobiele statussen vast op 390 CSS-pixels en 2x dichtheid. Gebruik het goedgekeurde productthema consistent binnen een gids; wissel niet tussen lichte en donkere modus tenzij het themaverschil het onderwerp is.

Gebruik alleen demogegevens: geen echte namen, e-mailadressen, domeinen, factuurgegevens, tokens, prompts of resultaten. Inspecteer zijbalken, recente items, automatisch aanvullen, meldingen en avatars vóór opname.

Sluit browserchrome uit tenzij een URL, machtiging of browserbesturing het punt is. Verberg tabbladen, bladwijzers, extensies, downloads, profielen en meldingen. Leg vast na het laden; sluit niet-gerelateerde tooltips en toon een cursor alleen wanneer essentieel.

Bewaar bronopnames onder cdn-assets/seo-playbook/elements/annotated-screenshot/. Gebruik lowercase kebab-case-namen op basis van scherm en status, zoals freshness-audit-needs-review.webp; gebruik nooit final, new, v2, een persoonsnaam of een datum als bestandsnaam. De stabiele naam laat toe het bestand te vervangen zonder elke pagina te herschrijven. Gebruik WebP voor normale levering, bij voorkeur een lossless instelling wanneer kleine interfacetekst scherp moet blijven. Gebruik PNG alleen wanneer de productiepijplijn aantoont dat WebP tekst of transparantie schaadt. Gebruik geen JPEG voor UI-opnames met fijne tekst en scherpe randen.

Render op maximaal 1600 CSS-pixels breed; een 1440-pixel 2x bron kan 2880 fysieke pixels zijn. Behoud de aspectratio en intrinsieke afmetingen. Optimalisatie ondersteunt afbeelding-SEO , maar compressie mag tekst of markers niet vervagen.

Elke assetmap bevat alt.yaml met één item per bestandsnaam:

freshness-audit-needs-review.webp: >-
  AmICited content freshness audit gefilterd op één gevolgde URL, met genummerde markers op de beoordelingsstatus en de laatst ververste datum.

De sleutel komt exact overeen met de bestandsnaam; de waarde is alt-tekst, geen bijschrift of legenda. Placeholders, standaard dashboards en niet-bestaande afbeeldingsverwijzingen zijn verboden. Opnames in behandeling gebruiken alleen een SCREENSHOT-opmerking en screenshotsPending = true.

Versheid en herhalingsbeleid

Screenshots verouderen stilletjes wanneer een afgebeeld besturingselement beweegt of van naam verandert. Behandel elke opname als een weergave van een geregistreerd scherm: screenId verbindt productwijzigingen met assets, terwijl de opnamedatum de vastgelegde status identificeert.

Een UI-wijziging leidt tot een nieuwe opname wanneer het een gemarkeerd doel verplaatst of hernoemt, de status verandert die de legenda uitlegt, het navigatiepad wijzigt dat nodig is om het te bereiken, een bewaarde oriëntatiemarkering verwijdert, of de oude afbeelding waarschijnlijk de lezer naar het verkeerde besturingselement stuurt. Maak een nieuwe opname van de volledige figurenset voor dat scherm, inclusief gerichte en mobiele varianten. Een kleurcodewijziging, aanpassing van de witruimte of niet-gerelateerde zijbalktoevoeging vereist geen automatische vervanging, tenzij de screenshot nu zichtbaar conflicteert met de live-ervaring of toegankelijkheidsstandaard.

Wanneer een scherm verandert, zoek dan op de screenId, daarna op de map en bestandsnaam om verouderd gebruik te vinden. Vervang stabiele bestanden, controleer alt.yaml en inspecteer elke getroffen legenda. Hernoem vervangingsbestanden niet en laat oudere referenties niet achter.

De product-screeneigenaar signaleert wijzigingen; de inhoudseigenaar accepteert vervangingen. Voer de nieuwe opname uit met dezelfde demo-fixture, viewport, dichtheid en thema. Controleer screenshots bij elke inhoudelijke paginarefresh.

Posttypes die het gebruiken

De postTypes frontmatter is de geregistreerde koppeling. Elk type gebruikt hetzelfde elementcontract, maar past een andere vereistendrempel toe.

Casestudies vereisen een extra grens: verkrijg ofwel expliciete toestemming om echte klantinformatie te tonen, of herbouw de interface met duidelijk vermelde demogegevens en behandel het als een werkstroomillustratie, niet als resultaatbewijs. Redactie is geen vervanging voor toestemming of een gecontroleerde fixture.

QA-checklist

Een beoordelaar controleert communicatie- en onderhoudsrisico vóór visuele afwerking.

• Doel: De figuur lost één ruimtelijke dubbelzinnigheid op of bewijst één zichtbare interfaceclaim.
• Noodzaak: Routinestappen blijven tekst; de pagina kent niet standaard één screenshot toe aan elke stap.
• Echte status: De opname toont het exacte geopende menu, geselecteerde filter, resultaat of fout die in de tekst wordt besproken.
• Demogegevens: Geen klant-, medewerker-, account-, browser-, token-, prompt- of factuurgegevens zijn zichtbaar.
• Opnameconsistentie: Viewport, 2x dichtheid, thema, interfacestatus en browserchrome-regel komen overeen met de standaard.
• Gerichte uitsnede: Voldoende context blijft voor oriëntatie, maar niet-gerelateerde interfacegebieden concurreren niet met het doel.
• Markers: Er zijn één tot zes doorlopende nummers, elk met hoog contrast, leesbaar en vrij van labels en waarden.
• Externe legenda: Elke marker heeft één overeenkomend item in een geordende lijst in paginatekst; geen legendatekst is in pixels gebakken.
• Bijschrift: De figuur heeft een beknopt zichtbaar bijschrift dat het scherm, de status en het scenario benoemt.
• Alt-tekst: De alt.yaml van de map bevat een exacte bestandsnaamsleutel en een contextuele beschrijving binnen de beoogde lengteband.
• Mobiel gedrag: Het doel en de markers blijven leesbaar zonder horizontaal scrollen op paginaniveau of vereiste zoom; anders bestaat er een gerichte uitsnede.
• Bestandscontract: Pad, lowercase kebab-case-naam, formaat, afmetingen en intrinsieke grootte volgen de leveringsstandaard.
• Versheid: screenId en opnamedatum zijn vastgelegd, de live-UI komt nog overeen en alle verwijzingen kunnen worden gevonden via tekstzoekopdracht.
• Draagbare gelijkheid: Markdown-, Hugo- en WordPress-representaties behouden dezelfde asset, hetzelfde bijschrift, dezelfde markervolgorde en dezelfde legendatekst.
• Geen gebroken asset: Een echt afbeeldingspad verschijnt pas nadat het bestand bestaat; opnames in behandeling blijven opmerkingen en behouden screenshotsPending = true.

FAQ

De academy-sjabloon geeft de vijf beoordeelde vragen weer die zijn opgeslagen in de [[faq]] frontmatter van deze pagina. Ze behandelen screenshotfrequentie, externe legenda’s, alt-tekstlengte, triggers voor nieuwe opnames en de uitzondering voor browserchrome.