Annoterade skärmbilder: Regler och exempel

En annoterad skärmbild visar ett verkligt gränssnittstillstånd och identifierar de exakta områden som en läsare behöver lägga märke till. Bilden bär numrerade markörer; sidan bär den matchande textförklaringen. Den separationen är elementet: varken en omärkt produktbild eller etiketter inbakade i pixlar uppfyller avtalet.

Granskning av innehållsaktualitet, filtrerad till en spårad webbadress.

1. Spårad webbadress: Bekräftar att granskningen avser den avsedda sidan snarare än hela domänen.
2. Statusfilter: Begränsar tabellen till sidor som kräver ett redaktionellt beslut.
3. Resultatdatum: Visar när den underliggande granskningsposten senast uppdaterades.

Inspelningen väntar, så kommentaren är en produktionsspecifikation snarare än en bruten bildreferens. När tillgången finns renderas bilden, bildtexten och den numrerade förklaringen som en sammanhängande figur.

Varför detta element är viktigt

Läsare använder en produktbild för att besvara en rumslig fråga: “Vilken kontroll, vilket värde eller vilket tillstånd menar den här instruktionen?” Densitetsrika gränssnitt innehåller navigation, filter, etiketter, data, märken och åtgärder som alla kan se lika viktiga ut. En oannoterad skärmbild ber läsaren att baklängeskonstruera författarens uppmärksamhet. Numrerade markörer reducerar den sökningen till en direkt matchning mellan en synlig plats och en kort förklaring.

Elementet ersätter också spröda koordinatspråk. “Använd kontrollen till höger” blir fel när ett verktygsfält radbryts; “välj statusfiltret markerat med 2” förblir användbart så länge inspelningen är aktuell.

Maskinell extraherbarhet innebär att programvara kan isolera och återanvända den användbara betydelsen av en innehållsenhet. Datorseende kan känna igen gränssnittstext, men kan inte tillförlitligt avgöra varför en av tjugo kontroller är viktig för just denna procedur. En synlig, ordnad förklaring skapar explicita markör-till-förklaring-par som söksystem, översättningsverktyg, tillgänglighetsprogramvara och innehållsgranskningar kan bearbeta som text. Bilden tillhandahåller rumsligt bevis; förklaringen tillhandahåller sökbar mening. Detta följer de bredare skrivreglerna för element : innehåll förblir typat och portabelt även när dess renderare ändras.

Baka aldrig in förklaringen i pixlar. Pixeltext kan inte översättas, sökas, markeras eller korrigeras utan att redigera bilden. Den är också osynlig för en skärmläsare, programvara som annonserar digitalt innehåll för personer som inte kan se skärmen. Endast markörnummer hör hemma i bilden.

När det ska användas

Använd en annoterad skärmbild när läsaren måste identifiera ett specifikt område i ett verkligt gränssnitt och ord ensamma lämnar mer än ett troligt mål. Det krävs när två kontroller har liknande namn, ett viktigt tillstånd är subtilt, ett resultat måste tolkas i sitt sammanhang, eller en visuell konfiguration inte kan återges korrekt i prosa. Det är också användbart när en produktsida gör ett konkret gränssnittspåstående som bilden kan bevisa.

En skärmbild är valfri när instruktionen redan namnger en unik, synlig kontroll och interaktionen är konventionell. “Välj Spara ändringar” behöver normalt ingen bild när sidan innehåller en sådan knapp. Det blir obligatoriskt om samma skärm har Spara utkast, Spara vy och Spara ändringar, och om att välja fel ändrar resultatet.

En skärmbild är skadlig när den tillför tyngd utan att lösa osäkerhet. Lägg inte till en för dekoration eller för att upprepa text som är tydligare i en tabell. Fjorton skärmbilder i en guide med fjorton steg skapar fjorton avbrott, mobila zoomproblem och inaktuella tillgångar. Fånga de tvetydiga stegen; låt precisa verb bära rutinmässiga.

Nära missar inkluderar:

• En full dashboard som används för att förklara en ikon: beskära till minsta område som bevarar orientering. En markör som försvinner i ett brett gränssnitt minskar inte sökinsatsen.
• En skärmbild som används som numeriskt bevis: upprepa det avgörande värdet i text eller en tabell. Pixlar kan inte vara den enda tillgängliga kopian av ett påstående.
• En skärmbild av en meny innan den öppnas: fånga tillståndet läsaren behöver inspektera. Det stängda tillståndet bevisar att produkten finns men inte vilket val som ska göras.
• En skärmbild som innehåller kundregister: ersätt dem med stabil demodata före inspelning. Oskärpa är lätt att missa.
• Ett diagram förklätt som skärmbild: använd ett diagram för abstrakta relationer. Gränssnittsrealism hjälper bara när gränssnittet är relevant.

Var det ska placeras

Placera figuren efter stycket eller steget som först ber läsaren att inspektera gränssnittet. I en procedur, placera den efter åtgärden och före framgångstillståndet eller felsökningen, så att läsaren lokaliserar kontrollen innan resultatet verifieras.

Håll bilden, bildtexten och förklaringen tillsammans. En rubrik kan introducera gruppen, men ett annat stycke, en utfyllnad, en annons eller en sidbrytning får inte separera inspelningen från dess numrerade förklaringar. En bildtext identifierar hela skärmen och sammanhanget; den bär inte en instruktion som hör hemma i prosan eller ersätter förklaringen.

Placera inte två fullbredds-skärmbilder tillsammans. Infoga förklaringen som skiljer dem åt, eller skapa en märkt jämförelse när båda tillstånden måste utvärderas tillsammans. Håll skärmbilder borta från orelaterade uppmaningar till handling, täta tabeller och gallerier.

Upprepa elementet endast när varje förekomst besvarar en annan rumslig fråga. Föredra en fokuserad figur; ge annars separata beskärningar distinkta filnamn och syften.

Anatomi

Anatomiinspelningen visar de synliga och textuella delarna av ett komplett element. Förklarande etiketter förblir i den renderade förklaringen snarare än att bli en del av källbilden.

Renderad förklaring

1. Kontextgräns: Inkluderar tillräckligt med omgivande gränssnitt för att identifiera sidan och platsen, men utesluter orelaterad navigation och tomt utrymme.
2. Numrerad markör: Använder en högkontrastcirkel och ett heltal, inte enbart färg, för att koppla en region till dess förklaringspost.
3. Målregion: Markerar den minsta kompletta kontrollen, värdet eller tillståndet som behövs för förklaringen; den täcker aldrig målets etikett.
4. Orientieringslandmärke: Bevarar en stabil rubrik, flik eller panelmarkering så att läsaren kan hitta samma område i den levande produkten.
5. Bildtext: Namnger skärmen, tillståndet och scenariot i synlig text under bilden.
6. Förklaring: Använder en ordnad lista vars nummer exakt matchar markörerna och vars poster förklarar betydelse, inte enbart utseende.

Markörnummer börjar på 1 och följer förklaringsordningen. Använd två till sex per bild; ett passar för ett svårt mål, medan fler än sex vanligtvis signalerar en alltför bred inspelning.

Designexempel

De varianter som stöds ändrar beskärning och viewport, inte annoteringspolicyn. Varje variant använder demodata, numrerade bildmarkörer, en extern textförklaring och en synlig bildtext.

Fokuserad kontroll: Föredras för en enskild tvetydig åtgärd. Bevara en orienteringsmarkering så att beskärningen inte blir en anonym rektangel.

Arbetsflödestillstånd: Använd när förhållandet mellan indata, status och ett resultat är viktigt. Håll orelaterad global navigation utanför bilden.

Webbadress i kontext: Den enda standardvarianten som inkluderar webläsarchrome, det vill säga webläsarens egna flikar, adressfält och kontroller. Inkludera endast adressfältet och nödvändig behörighets- eller säkerhetsindikator.

Mobilt tillstånd: Fånga den faktiska smala layouten när interaktionen ändras vid mobil bredd. Krymp inte en bred datorskärm och kalla det ett mobilt exempel.

Parametrar

Parametrarna utgör det portabla innehållskontraktet. Visuella värden som markörfärg, kanttjocklek och bildtexttypografi tillhör renderaren och är inte författarfält.

screenId identifierar produktens yta oberoende av dess filnamn, så att en utgåva kan hitta olika beskärningar av content-freshness-audit. alt.yaml-filen förblir enkel: ett filnamn följt av en hopfälld alt-text-sträng.

Syntax och kodexempel

Varje notation bevarar samma metadata, bildtext, markörer och läsordning bild–bildtext–förklaring.

Portabel 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.
:::

Adaptern löser alt från mappens alt.yaml. En saknad filnamnsnyckel är ett publiceringsfel, inte tillstånd att kopiera bildtexten.

Hugo shortcode-mappning

{{< 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 >}}

Detta är ett adapterkontrakt, inte en registrerad shortcode. Tills en godkänd renderare och tillgång finns, använd den etablerade pipeline för semantisk figur eller lämna den föreskrivna inspelningskommentaren. Ersätt inte med en renderare som utelämnar förklaringen eller aktualitetsfälten.

WordPress-block 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]

Ett WordPress-block kan exponera fälten som kontroller, men måste lagra markörbeskrivningar som text.

Exempel

Bra: ett tvetydigt tillstånd, tre användbara markörer

Innehållsaktualitetsgranskning för demo.example/pricing/.

1. Spårad webbadress: Verifierar att resultatet tillhör prissättningssidan som valts i instruktionen.
2. Behöver granskning: Identifierar det exakta filtret som tar bort aktuella sidor från arbetskön.
3. Senast uppdaterad: Förhindrar att redaktören behandlar ett gammalt granskningsresultat som en aktuell diagnos.

Detta fungerar eftersom varje markör besvarar ett beslut, beskärningen bevarar orienteringen och förklaringen förklarar konsekvenser som inte syns i pixlar. Demodomänen är tydligt icke-kunddata.

Dåligt: en märkt produktaffisch

Den dåliga versionen förklarar en hel dashboard på en gång. Åtta pilar korsar varandra, etiketter skymmer kontroller och inbakad marknadsföring ger ingen åtgärd. Webläsarbokmärken skapar integritetsrisk, kundnamn gör godkännande osäkert, ingen skärmidentifierare stöder uppdateringar och mobil skalning gör målen oläsliga.

Åtgärda det genom att välja en uppgift, använda godkänd demodata, beskära till dess panel och endast behålla nödvändiga markörer. Flytta förklaringar till en textförklaring, lägg till kontextuell alt-text och registrera skärmidentifieraren och datumet.

Schemamarkering och tillgänglighet

En annoterad skärmbild har ingen särskild Schema.org-typ. Den kan fylla en Article:s image-egenskap eller ett ImageObject med korrekt contentUrl, bildtext, bredd och höjd. Hitta inte på marköregenskaper; håll förklaringen synlig.

Använd ursprunglig figursemantik: ett <figure> som innehåller <img>, en <figcaption> och den ordnade förklaringen. Bildtexten namnger hela skärmen och tillståndet. Bildens alt-attribut beskriver vad skärmen visar i detta sammanhang; det bör inte börja med “skärmbild av”, eftersom bildelementet redan annonserar sig självt. Förklaringen tillhandahåller de detaljerade numrerade förklaringarna, så att upprepa alla sex poster i alt-text skapar en lång, dubblerad uppläsning.

Sikta på 80–180 tecken, med 250 som tak. Namnge produktområdet, tillståndet och markerat syfte: “Granskning av innehållsaktualitet filtrerad till en spårad webbadress, med markörer på statusfiltret och datum för senaste uppdatering.” Transkribera inte gränssnittet, stoppa inte in nyckelord och använd inte filnamnet. Denna informativa bild behöver normalt icke-tom alt-text.

Markörnummer måste vara läsbara utan färg. Använd hög kontrast mot både ljusa och mörka gränssnittsområden, håll deras visuella storlek konsekvent och täck inte etiketter eller värden. Förklaringen använder en ordnad lista i normal dokumentordning; undvik ARIA-roller (Accessible Rich Internet Applications) som gör statiskt innehåll till en varning eller interaktiv widget. En aria-describedby-relation är endast valfri när testning visar att den förbättrar navigationen utan att den synliga förklaringen tillkännages två gånger.

Vid smala bredder måste responsiv design bevara mening. Skala en bred bild endast medan markörer och mål förblir läsbara; tillhandahåll annars en fokuserad beskärning eller äkta mobil inspelning. Orsaka aldrig horisontell rullning på sidnivå eller kräv zoom. Bildtext och förklaring radbryts nedanför.

Innehålls- och inspelningsregler

Konsekvens gör skärmbilder jämförbara och utbytbara. Fånga produktsskärmar på datorn vid en fast 1440 CSS-pixel viewport och 2x pixeldensitet, ofta kallad Retina-densitet, som registrerar två enhetspixlar för varje CSS-pixel. Fånga äkta mobila tillstånd vid 390 CSS-pixlar och 2x densitet. Använd det godkända produkttemat konsekvent inom en guide; växla inte mellan ljust och mörkt läge om inte temaskillnaden är ämnet.

Använd endast demodata: inga riktiga namn, e-postadresser, domäner, faktureringsuppgifter, tokens, uppmaningar eller resultat. Inspektera sidofält, senaste objekt, autofyll, notiser och avatarer före inspelning.

Uteslut webläsarchrome om inte en webbadress, behörighet eller webläsarkontroll är poängen. Dölj flikar, bokmärken, tillägg, nedladdningar, profiler och notiser. Fånga efter inläsning; stäng irrelevanta verktygstips och visa en markör endast när det är nödvändigt.

Förvara källinspelningar under cdn-assets/seo-playbook/elements/annotated-screenshot/. Använd gemen kebab-case-namn baserade på skärm och tillstånd, såsom freshness-audit-needs-review.webp; använd aldrig final, new, v2, en persons namn eller ett datum som filnamn. Det stabila namnet gör att tillgången kan bytas ut utan att varje sida skrivs om. Använd WebP för normal leverans, företrädesvis en förlustfri inställning när liten gränssnittstext måste förbli skarp. Använd PNG endast när produktionspipen visar att WebP skadar text eller genomskinlighet. Använd inte JPEG för UI-inspelningar med fin text och skarpa kanter.

Rendera till högst 1600 CSS-pixlar bred; en 1440-pixel 2x-källa kan vara 2880 fysiska pixlar. Bevara bildförhållande och inneboende dimensioner. Optimering stöder bild-SEO , men komprimering får inte sudda ut text eller markörer.

Varje tillgångsmapp innehåller alt.yaml med en post per filnamn:

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.

Nyckeln matchar filnamnet exakt; värdet är alt-text, inte en bildtext eller förklaring. Platshållare, standard-dashboards och icke-existerande bildreferenser är förbjudna. Väntande inspelningar använder endast en SCREENSHOT-kommentar och screenshotsPending = true.

Policy för aktualitet och omtagning

Skärmbilder åldras tyst när en avbildad kontroll flyttas eller byter namn. Behandla varje inspelning som en vy av en registrerad skärm: screenId kopplar produktförändringar till tillgångar, medan inspelningsdatum identifierar det inspelade tillståndet.

En UI-ändring utlöser en omtagning när den flyttar eller byter namn på ett markerat mål, ändrar det tillstånd som förklaringen beskriver, ändrar navigeringsvägen som behövs för att nå det, tar bort ett bevarat orienteringslandmärke, eller gör att den gamla bilden sannolikt skickar läsaren till fel kontroll. Ta om hela figursetet för den skärmen, inklusive fokuserade och mobila varianter. En färgförändring, justering av avstånd eller orelaterad tillägg i sidofältet kräver inte automatiskt utbyte om inte skärmbilden nu synbart står i konflikt med den verkliga upplevelsen eller tillgänglighetsstandarden.

När en skärm ändras, sök efter dess screenId, sedan dess mapp och filnamn för att fånga äldre användningar. Ersätt stabila filer, granska alt.yaml och inspektera varje berörd förklaring. Byt inte namn på ersättningsfiler och lämna äldre referenser strandsatta.

Produktsskärmsägaren signalerar ändringar; innehållsägaren accepterar ersättningar. Spela in på nytt med samma demofixtur, viewport, densitet och tema. Granska skärmbilder vid varje substantiell siduppdatering.

Posttyper som använder det

postTypes-frontmatter är den registrerade kopplingen. Varje typ använder samma elementkontrakt men tillämpar en annan kravtröskel.

Fallstudier kräver en extra gräns: antingen inhämta uttryckligt tillstånd att visa verklig kundinformation eller bygg om gränssnittet med tydligt avslöjad demodata och behandla det som en arbetsflödesillustration, inte som resultatbevis. Redigering är inte en ersättning för samtycke eller en kontrollerad fixtur.

QA-checklista

En granskare kontrollerar kommunikation och underhållsrisk före visuell putsning.

• Syfte: Figuren löser en rumslig tvetydighet eller bevisar ett synligt gränssnittspåstående.
• Nödvändighet: Rutinmoment förblir text; sidan tilldelar inte en skärmbild till varje steg som standard.
• Verkligt tillstånd: Inspelningen visar den exakta öppna menyn, valda filtret, resultatet eller felet som diskuteras i texten.
• Demodata: Ingen kund-, anställd-, konto-, webläsar-, token-, uppmanings- eller faktureringsinformation är synlig.
• Inspelningskonsekvens: Viewport, 2x-densitet, tema, gränssnittstillstånd och regel för webläsarchrome matchar standarden.
• Fokuserad beskärning: Tillräckligt med sammanhang finns kvar för orientering, men orelaterade gränssnittsområden konkurrerar inte med målet.
• Markörer: Det finns en till sex kontinuerliga nummer, varje högkontrast, läsbart och fritt från etiketter och värden.
• Extern förklaring: Varje markör har en matchande post i ordnad lista i sidans text; ingen förklaringsord är inbakad i pixlar.
• Bildtext: Figuren har en koncis synlig bildtext som namnger dess skärm, tillstånd och scenario.
• Alt-text: Mappens alt.yaml innehåller en exakt filnamnsnyckel och en kontextuell beskrivning inom målängdsintervallet.
• Mobilt beteende: Målet och markörerna förblir läsbara utan horisontell rullning på sidnivå eller obligatorisk zoom; annars finns en fokuserad beskärning.
• Filavtal: Sökväg, gemen kebab-case-namn, format, dimensioner och inneboende storlek följer leveransstandarden.
• Aktualitet: screenId och inspelningsdatum är registrerade, det levande gränssnittet matchar fortfarande, och alla referenser kan hittas via textsökning.
• Portabel paritet: Markdown-, Hugo- och WordPress-representationer bevarar samma tillgång, bildtext, markörordning och förklaringsformulering.
• Ingen bruten tillgång: En verklig bildsökväg visas först efter att filen finns; väntande inspelningar förblir kommentarer och behåller screenshotsPending = true.

FAQ

Akademimallen renderar de fem granskade frågorna som lagras i denna sidas [[faq]]-frontmatter. De täcker skärmbildsfrekvens, externa förklaringar, alt-text-längd, omtagningsutlösare och undantaget för webläsarchrome.