Annoterte skjermbilder: regler og eksempler

Et annotert skjermbilde viser en reell grensesnitttilstand og identifiserer de nøyaktige områdene en leser må legge merke til. Bildet har nummererte markører; siden har den tilhørende tekstlige tegnforklaringen. Det skillet er elementet: verken et umerket produktbilde eller etiketter bakt inn i piksler oppfyller kontrakten.

Innholdsfriskhetsrevisjon, filtrert til én sporet URL.

1. Sporet URL: Bekrefter at gjennomgangen gjelder den tiltenkte siden fremfor hele domenet.
2. Statusfilter: Begrenser tabellen til sider som krever en redaksjonell beslutning.
3. Resultatdato: Viser når det underliggende revisjonsregisteret sist ble oppdatert.

Opptaket er under arbeid, så kommentaren er en spesifikasjon for produksjonsopptak snarere enn en ødelagt bildereferanse. Når aktivaet eksisterer, gjengis bildet, bildeteksten og den nummererte tegnforklaringen som én semantisk figur.

Hvorfor dette elementet er viktig

Lesere bruker et produktbilde for å besvare et romlig spørsmål: «Hvilken kontroll, verdi eller tilstand mener denne instruksjonen?» Tette grensesnitt inneholder navigasjon, filtre, etiketter, data, merker og handlinger som alle kan se like viktige ut. Et uannotert skjermbilde ber leseren om å reversere forfatterens oppmerksomhet. Nummererte markører reduserer dette søket til en direkte kobling mellom et synlig sted og en kort forklaring.

Elementet erstatter også skjør koordinatspråk. «Bruk kontrollen til høyre» blir feil når en verktøylinje brytes; «velg statusfilteret merket 2» forblir brukbart så lenge opptaket er aktuelt.

Maskinuttrekkbarhet betyr at programvare kan isolere og gjenbruke den nyttige meningen av en innholdsenhet. Datasyn kan gjenkjenne grensesnitttekst, men kan ikke pålitelig utlede hvorfor én av tjue kontroller er viktig for denne prosedyren. En synlig, ordnet tegnforklaring skaper eksplisitte markør-til-forklaring-par som søkesystemer, oversettelsesverktøy, tilgjengelighetsprogramvare og innholdsrevisjoner kan behandle som tekst. Bildet gir romlig bevis; tegnforklaringen gir søkbar mening. Dette følger de bredere element-skrivereglene : innhold forblir typet og bærbart selv når gjengivelsesverktøyet endres.

Bak aldri tegnforklaringen inn i piksler. Pikseltekst kan ikke oversettes, søkes i, velges eller korrigeres uten å redigere kunstverket. Det er også usynlig for en skjermleser, programvare som kunngjør digitalt innhold til personer som ikke kan se skjermen. Bare markørnumre hører hjemme i bildet.

Når det skal brukes

Bruk et annotert skjermbilde når leseren må identifisere et spesifikt område i et reelt grensesnitt og ord alene etterlater mer enn ett plausibelt mål. Det er påkrevd når to kontroller har lignende navn, en viktig tilstand er subtil, et resultat må tolkes i sin sammenheng, eller en visuell konfigurasjon ikke kan gjengis pålitelig i prosa. Det er også nyttig når en produktside kommer med et konkret grensesnittkrav som bildet kan bevise.

Et skjermbilde er valgfritt når instruksjonen allerede navngir en unik, synlig kontroll og interaksjonen er konvensjonell. «Velg Lagre endringer» trenger normalt ikke bilde når siden inneholder én slik knapp. Det blir påkrevd hvis samme skjerm har Lagre kladd, Lagre visning og Lagre endringer, og det å velge feil endrer resultatet.

Et skjermbilde er skadelig når det tilfører vekt uten å løse usikkerhet. Ikke legg til ett for dekorasjon eller for å gjenta tekst som er tydeligere i en tabell. Fjorten skjermbilder i en fjorten-trinns guide skaper fjorten avbrudd, mobilzoomproblemer og utdaterte aktiva. Ta opp de tvetydige trinnene; la presise verb bære de rutinemessige.

Nære bommer inkluderer:

• Et fullt dashbord brukt til å forklare ett ikon: beskjær til det minste området som bevarer orientering. En markør som går tapt i et bredt grensesnitt reduserer ikke søkeinnsatsen.
• Et skjermbilde brukt som numerisk bevis: gjenta den avgjørende verdien i tekst eller en tabell. Piksler kan ikke være den eneste tilgjengelige kopien av en påstand.
• Et skjermbilde av en meny før den åpnes: ta opp tilstanden leseren trenger å inspisere. Den lukkede tilstanden beviser at produktet eksisterer, men ikke hvilket valg som skal tas.
• Et skjermbilde som inneholder kunderegistre: erstatt dem med stabile demodata før opptak. Uskarphet er lett å overse.
• Et diagram forkledd som et skjermbilde: bruk et diagram for abstrakte sammenhenger. Grensesnittrealisme hjelper bare når grensesnittet er relevant.

Hvor det skal plasseres

Plasser figuren etter avsnittet eller trinnet som først ber leseren om å inspisere grensesnittet. I en prosedyre, plasser den etter handlingen og før suksesstilstanden eller feilsøkingen, slik at leseren finner kontrollen før han eller hun verifiserer resultatet.

Hold bildet, bildeteksten og tegnforklaringen samlet. En overskrift kan introdusere gruppen, men et annet avsnitt, en utheving, en annonse eller et sideskift må ikke skille opptaket fra de nummererte forklaringene. En bildetekst identifiserer hele skjermen og konteksten; den bærer ikke en instruksjon som hører hjemme i prosaen, og erstatter ikke tegnforklaringen.

Ikke plasser to fullbredde skjermbilder sammen. Sett inn forklaringen som skiller dem, eller lag én merket sammenligning når begge tilstandene må vurderes sammen. Hold skjermbilder unna ikke-relaterte handlingsknapper, tette tabeller og gallerier.

Gjenta elementet bare når hver forekomst svarer på et annet romlig spørsmål. Foretrekk én fokusert figur; gi ellers separate beskjæringer distinkte filnavn og formål.

Anatomi

Anatomiopptaket viser de synlige og tekstlige delene av ett komplett element. Forklarende etiketter forblir i den gjengitte tegnforklaringen snarere enn å bli en del av kildebildet.

Gjengitt tegnforklaring

1. Kontekstgrense: Inkluderer nok omkringliggende grensesnitt til å identifisere siden og plasseringen, men ekskluderer ikke-relatert navigasjon og tomrom.
2. Nummerert markør: Bruker en sirkel med høy kontrast og et heltall, ikke farge alene, for å koble et område til sin tegnforklaringsoppføring.
3. Målområde: Markerer den minste komplette kontrollen, verdien eller tilstanden som trengs for forklaringen; den dekker aldri målområdets etikett.
4. Orienteringlandemerke: Bevarer én stabil overskrift, fane eller paneletikett slik at leseren kan finne samme område i det levende produktet.
5. Bildetekst: Navngir skjermen, tilstanden og scenarioet i synlig tekst under bildet.
6. Tegnforklaring: Bruker en ordnet liste hvis numre nøyaktig samsvarer med markørene, og hvis oppføringer forklarer betydning, ikke bare utseende.

Markørnumre starter på 1 og følger tegnforklaringsrekkefølgen. Bruk to til seks per bilde; ett passer for et vanskelig mål, mens mer enn seks vanligvis signaliserer et for bredt opptak.

Designeksempler

De støttede variantene endrer beskjæring og visningsport, ikke annotasjonspolitikken. Hver variant bruker demodata, nummererte bildemarkører, en ekstern tekstlig tegnforklaring og en synlig bildetekst.

Fokusert kontroll: Foretrukket for en enkelt tvetydig handling. Bevar én orienteringsetikett slik at beskjæringen ikke blir et anonymt rektangel.

Arbeidsflyttilstand: Bruk når forholdet mellom en inndata, et filter og et resultat er viktig. Hold ikke-relatert global navigasjon utenfor bildet.

URL i kontekst: Den eneste standardvarianten som inkluderer nettleserens chrome, det vil si nettleserens egne faner, adresselinje og kontroller. Inkluder kun adresselinjen og nødvendig tillatelses- eller sikkerhetsindikator.

Mobil tilstand: Ta opp den faktiske smale layouten når interaksjonen endres ved mobil bredde. Ikke krymp en bred dataskjerm og kall det et mobileksempel.

Parametere

Parameterne utgjør den bærbare innholdskontrakten. Visuelle verdier som markørfarge, kanttykkelse og bildeteksttypografi tilhører gjengivelsesverktøyet og er ikke forfatterfelt.

screenId identifiserer produktflaten uavhengig av filnavnet, slik at en utgivelse kan finne ulike beskjæringer av content-freshness-audit. alt.yaml-filen forblir enkel: ett filnavn etterfulgt av én foldet alt-tekststreng.

Syntaks og kodeeksempler

Hver notasjon bevarer de samme metadataene, bildeteksten, markørene og leserekkefølgen bilde–bildetekst–tegnforklaring.

Bærbar Markdown-direktiv

:::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 filtered to one tracked URL.

1. **Tracked URL:** Confirms which page the audit evaluates.
2. **Status filter:** Limits the results to pages awaiting review.
3. **Result date:** Shows when the audit data was refreshed.
:::

Adapteren løser alt fra mappens alt.yaml. En manglende filnøkkel er en publiseringsfeil, ikke tillatelse til å kopiere bildeteksten.

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 filtered to one tracked URL.

1. **Tracked URL:** Confirms which page the audit evaluates.
2. **Status filter:** Limits the results to pages awaiting review.
3. **Result date:** Shows when the audit data was refreshed.
{{< /annotated-screenshot >}}

Dette er en adapterkontrakt, ikke en registrert shortcode. Inntil en godkjent gjengivelseskomponent og aktiva eksisterer, bruk den etablerte semantiske figur-pipelinen eller la den foreskrevne opptakskommentaren stå. Ikke erstatt med en gjengivelseskomponent som utelater tegnforklaringen eller friskhetsfeltene.

WordPress-blokk eller -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 filtered to one tracked URL.[/caption]
[marker number="1" label="Tracked URL"]Confirms which page the audit evaluates.[/marker]
[marker number="2" label="Status filter"]Limits the results to pages awaiting review.[/marker]
[marker number="3" label="Result date"]Shows when the audit data was refreshed.[/marker]
[/annotated_screenshot]

En WordPress-blokk kan eksponere feltene som kontroller, men den må lagre markørbeskrivelser som tekst.

Eksempler

Bra: én tvetydig tilstand, tre nyttige markører

Innholdsfriskhetsgjennomgang for demo.example/pricing/.

1. Sporet URL: Verifiserer at resultatet tilhører prissiden som ble valgt i instruksjonen.
2. Trenger gjennomgang: Identifiserer det nøyaktige filteret som fjerner aktuelle sider fra arbeidskøen.
3. Sist oppdatert: Forhindrer at redaktøren behandler et gammelt revisjonsresultat som en aktuell diagnose.

Dette fungerer fordi hver markør svarer på en beslutning, beskjæringen bevarer orientering, og tegnforklaringen forklarer konsekvenser som ikke er synlige i piksler. Demodomenet er tydeligvis ikke kundedata.

Dårlig: en merket produktplakat

Den dårlige versjonen forklarer et helt dashbord på én gang. Åtte piler krysser, etiketter skjuler kontroller, og innebygd reklame gir ingen handling. Nettleserbokmerker skaper personvernrisiko, kundenavn gjør godkjenning usikker, ingen skjermidentifikator støtter oppdateringer, og mobilskalering gjør målområder uleselige.

Reparer det ved å velge én oppgave, bruke godkjente demodata, beskjære til panelet, og beholde bare nødvendige markører. Flytt forklaringer til en tekstlig tegnforklaring, legg til kontekstuell alt-tekst , og registrer skjermidentifikatoren og datoen.

Skjemamarkering og tilgjengelighet

Et annotert skjermbilde har ingen spesiell Schema.org-type. Det kan fylle en Articles image-egenskap eller et ImageObject med nøyaktig contentUrl, bildetekst, bredde og høyde. Ikke oppfinn markøregenskaper; hold tegnforklaringen synlig.

Bruk opprinnelig figur-semantikk: ett <figure>-element som inneholder <img>, en <figcaption> og den ordnede tegnforklaringen. Bildeteksten navngir hele skjermen og tilstanden. Bildets alt-attributt beskriver hva skjermen viser i denne konteksten; det bør ikke starte med «skjermbilde av» fordi bildeelementet allerede annonserer seg selv. Tegnforklaringen gir de detaljerte nummererte forklaringene, så det å gjenta alle seks oppføringene i alt-tekst skaper en lang, duplisert kunngjøring.

Sikt på 80–180 tegn, med 250 som tak. Navngi produktområdet, tilstanden og det markerte formålet: «Innholdsfriskhetsrevisjon filtrert til én sporet URL, med markører på statusfilteret og siste oppdateringsdato.» Ikke transkriber grensesnittet, stapp inn nøkkelord, eller bruk filnavnet. Dette informative bildet trenger normalt ikke-tom alt-tekst.

Markørnumre må være lesbare uten farge. Bruk høy kontrast mot både lyse og mørke grensesnittområder, hold den visuelle størrelsen konsistent, og dekk ikke etiketter eller verdier. Tegnforklaringen bruker en ordnet liste i vanlig dokumentrekkefølge; unngå ARIA, eller Accessible Rich Internet Applications, roller som gjør statisk innhold til et varsel eller en interaktiv widget. En aria-describedby-relasjon er valgfri kun når testing viser at den forbedrer navigasjon uten å føre til at den synlige tegnforklaringen kunngjøres to ganger.

Ved smale bredder må responsivt design bevare mening. Skaler et bredt bilde kun mens markører og målområder forblir leselige; gi ellers en fokusert beskjæring eller ekte mobilopptak. Forårsak aldri horisontal rulling på sidenivå eller krev zoom. Bildetekst og tegnforklaring brytes til neste linje under.

Innholds- og opptaksregler

Konsistens gjør skjermbilder sammenlignbare og utskiftbare. Ta opp produktbilder for datamaskin ved en fast 1440 CSS-pikslers visningsport og 2x pikseltetthet, ofte kalt Retina-tetthet, som registrerer to enhetspiksler for hver CSS-piksel. Ta opp ekte mobile tilstander ved 390 CSS-piksler og 2x tetthet. Bruk godkjent produkt-tema konsekvent innenfor én guide; veksle ikke mellom lys og mørk modus med mindre temaforskjellen er temaet.

Bruk kun demodata: ingen ekte navn, e-postadresser, domener, faktureringsdetaljer, tokens, spørsmål, spørringer eller resultater. Inspiser sidepaneler, nylige elementer, autofyll, varsler og avatarer før opptak.

Ekskluder nettleserens chrome med mindre en URL, tillatelse eller nettleserkontroll er poenget. Skjul faner, bokmerker, utvidelser, nedlastinger, profiler og varsler. Ta opp etter lasting; lukk irrelevante verktøytips og vis markøren kun når det er nødvendig.

Lagre kildeopptak under cdn-assets/seo-playbook/elements/annotated-screenshot/. Bruk små bokstaver, kebab-case-navn basert på skjerm og tilstand, for eksempel freshness-audit-needs-review.webp; bruk aldri final, new, v2, en persons navn eller en dato som filnavn. Det stabile navnet lar aktivaet erstattes uten å omskrive hver side. Bruk WebP for normal levering, fortrinnsvis en tapsfri innstilling når liten grensesnitttekst må forbli skarp. Bruk PNG kun når produksjonspipelinen viser at WebP skader tekst eller gjennomsiktighet. Ikke bruk JPEG for UI-opptak med fin tekst og skarpe kanter.

Gjengi i maksimalt 1600 CSS-piksler bredde; en 1440-pikslers 2x-kilde kan være 2880 fysiske piksler. Bevar sideforhold og iboende dimensjoner. Optimalisering støtter bildesøkemotoroptimalisering , men komprimering må ikke gjøre tekst eller markører uklare.

Hver aktivamappe inneholder alt.yaml med én oppføring per filnavn:

freshness-audit-needs-review.webp: >-
  AmICited content freshness audit filtered to one tracked URL, with numbered markers on the review status and last-refreshed date.

Nøkkelen matcher filnavnet nøyaktig; verdien er alt-tekst, ikke en bildetekst eller tegnforklaring. Plassholdere, standard-dashbord og ikke-eksisterende bildereferanser er forbudt. Ventende opptak bruker kun en SCREENSHOT-kommentar og screenshotsPending = true.

Friskhet og politikk for nytt opptak

Skjermbilder eldes i stillhet når en avbildet kontroll flytter seg eller endrer navn. Behandle hvert opptak som et bilde av en registrert skjerm: screenId forbinder produktendringer med aktiva, mens opptaksdatoen identifiserer den registrerte tilstanden.

En UI-endring utløser nytt opptak når den flytter eller omdøper et merket mål, endrer tilstanden tegnforklaringen forklarer, endrer navigasjonsstien som trengs for å nå det, fjerner et bevart orienteringslandemerke, eller gjør det gamle bildet sannsynlig til å sende leseren til feil kontroll. Ta opp hele figursettet for den skjermen på nytt, inkludert fokuserte og mobile varianter. En fargetoken-endring, justering av avstand eller en ikke-relatert sidepanel-tilføyelse krever ikke automatisk utskifting med mindre skjermbildet nå synlig er i konflikt med den levende opplevelsen eller tilgjengelighetsstandarden.

Når en skjerm endres, søk etter dens screenId, deretter mappen og filnavnet for å fange opp eldre bruksområder. Erstatt stabile filer, gjennomgå alt.yaml, og inspiser hver berørt tegnforklaring. Ikke gi nytt navn til erstatningsfiler og la eldre referanser bli hengende.

Eieren av produktskjermen signaliserer endringer; innholdseieren aksepterer erstatninger. Ta opp på nytt med samme demo-oppsett, visningsport, tetthet og tema. Gå gjennom skjermbilder ved hver vesentlig sideoppdatering.

Innleggstyper som bruker det

postTypes frontmatter er den registrerte koblingen. Hver type bruker samme elementkontrakt, men anvender en annen terskel for krav.

| Ultimativ guide | Sjelden, selektiv støtte | Ved den første virkelig visuelle prosedyren eller grensesnittkonseptet | Brede guider blir ubrukelige når hver seksjon får et stort produktbilde. |

Casestudier krever en ekstra grense: enten innhent eksplitt tillatelse til å vise ekte kundeinformasjon, eller bygg om grensesnittet med tydelig oppgitte demodata og behandl det som en arbeidsflytillustrasjon, ikke resultatbevis. Redigering er ikke en erstatning for samtykke eller et kontrollert oppsett.

QA-sjekkliste

En gjennomganger sjekker kommunikasjon og vedlikeholdsrisiko før visuell polering.

• Formål: Figuren løser én romlig tvetydighet eller beviser én synlig grensesnittpåstand.
• Nødvendighet: Rutinetrinn forblir tekst; siden tildeler ikke ett skjermbilde til hvert trinn som standard.
• Reell tilstand: Opptaket viser den nøyaktige åpne menyen, valgte filteret, resultatet eller feilen som diskuteres i teksten.
• Demodata: Ingen kunde-, ansatt-, konto-, nettleser-, token-, spørsmåls- eller faktureringsinformasjon er synlig.
• Opptakskonsistens: Visningsport, 2x tetthet, tema, grensesnitttilstand og nettleserchrome-regel samsvarer med standarden.
• Fokusert beskjæring: Nok kontekst er bevart for orientering, men ikke-relaterte grensesnittområder konkurrerer ikke med målet.
• Markører: Det er én til seks fortløpende numre, hver med høy kontrast, leselig og fri for etiketter og verdier.
• Ekstern tegnforklaring: Hver markør har én samsvarende oppføring i ordnet liste i sideteksten; ingen tegnforklaringstekst er bakt inn i piksler.
• Bildetekst: Figuren har en konsis synlig bildetekst som navngir skjermen, tilstanden og scenarioet.
• Alt-tekst: Mappens alt.yaml inneholder en nøyaktig filnøkkel og en kontekstuell beskrivelse innenfor måltegnlengdeintervallet.
• Mobilatferd: Målet og markørene forblir leselige uten horisontal rulling på sidenivå eller påkrevd zoom; ellers finnes en fokusert beskjæring.
• Filkontrakt: Sti, små bokstaver kebab-case-navn, format, dimensjoner og iboende størrelse følger leveringsstandarden.
• Friskhet: screenId og opptaksdato er registrert, det levende UI samsvarer fortsatt, og alle referanser kan finnes ved tekstsøk.
• Bærbar paritet: Markdown-, Hugo- og WordPress-representasjoner bevarer samme aktiva, bildetekst, markørrekkefølge og tegnforklaringsordlyd.
• Ingen ødelagt aktiva: En reell bildesti vises kun etter at filen eksisterer; ventende opptak forblir kommentarer og beholder screenshotsPending = true.

FAQ

Akademimalen gjengir de fem gjennomgåtte spørsmålene som er lagret i denne sidens [[faq]]-frontmatter. De dekker skjermbildefrekvens, eksterne tegnforklaringer, alt-tekstlengde, utløsere for nytt opptak og unntaket for nettleserchrome.