Faneblade / Personaskifter: Format, regler og eksempler

En faneblads-/personaskifter giver flere læsere forskellige stier gennem ét afgrænset emne uden at sende dem til separate sider. Etiketterne identificerer stien; valg af én afslører dens panel samme sted. Elementet er kun nyttigt, når panelerne er ægte sideløbende, og hvert panel forbliver til stede i sidens oprindelige HTML.

Den gengivne tilstand viser ét aktivt panel, men de to andre paneler er også i dokumentobjektmodellen (DOM) — browserens strukturerede repræsentation af siden. De er skjult med det native hidden-attribut, ikke anmodet efter et klik. En produktionsgengiver tilføjer tastatur- og pegeradfærden beskrevet nedenfor; den forfattede indholdskontrakt forbliver den samme på tværs af platforme.

Hvorfor dette element er vigtigt

Læsere filtrerer en side gennem deres rolle, mål og ansvarsniveau. En indholdsspecialist ønsker måske udkastinstruktioner, en SEO-specialist ønsker måske valideringsregler, og en teamleder ønsker måske styring. En velfungerende personaskifter reducerer indsatsen ved at oversætte generiske råd til “hvad betyder dette for mig?” Den holder også den fælles præmis på ét sted, hvilket undgår tre næsten identiske sider, der konkurrerer om den samme hensigt.

Den psykologiske fordel er genkendelse frem for fortolkning. En læser kan genkende en etiket som “SEO-teams” hurtigere, end de kan scanne tre afsnit for at udlede, hvilket der gælder. Faneblade bevarer også rumlig kontekst: panelet skifter på stedet, så læseren kan sammenligne sideløbende stier uden gentagne gange at scrolle forbi den fælles introduktion.

Denne bekvemmelighed skaber et kompromis med maskinudtrækkelighed. Maskinudtrækkelighed er evnen hos en crawler, søgeindeks, hjælpeteknologi eller genfindingssystem til at isolere indhold, mens dets emne og relationer bevares. Synlige overskrifter og afsnit fremstår i en tydelig læsesekvens. Fanebladspaneler introducerer en interaktionstilstand: ét er synligt, flere er ikke, og software skal forbinde hver fanebladsetiket til det korrekte panel. En svag implementering efterlader kun det aktive panel i HTML’en, indlæser andre paneler efter et klik eller gentager generiske overskrifter som “Fordele” uden personanavnet. I hvert tilfælde modtager en maskine mindre kontekst, end læseren ser.

Selv en korrekt implementering kan reducere udtrækkelighed sammenlignet med almindelige sektioner. Nogle systemer prioriterer initially synlig tekst, flader interaktive relationer ud eller udelader skjult indhold fra uddrag. Faneblade er derfor et informationsdirigeringsværktøj, ikke en måde at skjule væsentlige svar på. Placer det fælles svar, definition, advarsel, berettigelsesbetingelse og konklusion uden for fanebladssættet. Brug paneler til målgruppespecifik anvendelse, eksempler, arbejdsgange eller dokumentation, der forbliver nyttig, efter det fælles svar er kendt.

Anvend element-skrivereglerne : udkast den fulde forklaring først, klassificér derefter et ægte sæt af sideløbende læserstier som dette typedeelement. Reglerne på denne side har forrang for panelkortlægning, interaktion og indholdsbegrænsninger.

Hvornår skal det bruges

Brug en faneblads-/personaskifter, når alle disse betingelser er opfyldt:

1. To til fem genkendelige målgrupper, kontekster eller tilstande har brug for forskellige anvendelser af det samme emne.
2. Hvert panel besvarer det samme spørgsmål med sammenlignelig dybde.
3. De fleste læsere har brug for ét panel ad gangen, mens et mindretal måske sammenligner to eller flere.
4. Det fælles svar kan angives uden for elementet uden at tvinge en læser til at åbne hvert faneblad.
5. At holde stierne på én side er tydeligere end at vedligeholde separate sider med stort set duplikerede introduktioner.

Stærke anvendelser inkluderer implementeringsvejledning til “Udviklere / Redaktører / Anmeldere”, onboarding-stier til “Solo / Team / Agentur” og én kapacitet forklaret gennem “Planlæg / Producer / Mål.” Personaetiketter bør afspejle meningsfulde forskelle i arbejdsgang, dokumentation, tilladelser eller ønsket resultat — ikke demografiske gæt.

Næsten-ramte tilfælde kommer ofte fra at forsøge at forkorte en side. Læg ikke sekventielle trin i faneblade; at skjule trin to, indtil en læser vælger det, ødelægger procedurens rækkefølge. Sæt ikke en kort liste af definitioner i faneblade, fordi almindelige overskrifter udstiller den samme information med mindre interaktion. Brug ikke faneblade til en detaljeret funktionssammenligning: en sammenligningstabel holder kriterier samtidigt synlige. Brug ikke faneblade som navigation mellem ubeslægtede emner, og opdel ikke information blot fordi siden føles lang.

En accordion passer bedre, når sektionerne er uafhængige spørgsmål i et vertikalt læseflow, eller når flere svar bør forblive åbne. Separate sider er bedre, når hver målgruppe har brug for en særskilt søgehensigt, titel, dokumentationssæt, konverteringssti eller mere end cirka 300 ord unikt indhold. Hvis en læser har brug for alle paneler for at handle sikkert eller korrekt, er faneblade den forkerte komponent.

Hvor skal det placeres

Placer skifteren efter det fælles svar og afsnittet, der forklarer, hvorfor stierne adskiller sig. Læseren bør forstå det fælles emne, før de vælger en etiket. På en produkt- eller løsningsside betyder det normalt efter kernepropositionen og den fælles kapacitetsforklaring, men før detaljeret dokumentation og den primære afsluttende handling. I dokumentation placeres den umiddelbart før de rollespecifikke instruktioner, den styrer.

Placer ikke et fanebladssæt før sidens direkte svar, definition eller obligatoriske advarsel. Placer det ikke mellem et krav og dets kilde, mellem en forudsætning og den procedure, den styrer, eller mellem en pris og dens kvalifikationer. Disse relationer skal overleve, selv når intet panel er valgt. Et fanebladssæt må ikke sidde ved siden af et andet fanebladssæt, en accordion, et stort sammenligningsgrid eller et karussel; tilstødende interaktionsmodeller skaber konkurrerende kontroller og uklar læserækkefølge.

Undgå indlejrede faneblade. Det ydre valg skjuler det indre valg, skaber vanskelig tastaturadfærd og gør dyb delinkning tvetydig. Undgå også at placere en personaskifter umiddelbart over en anden målgruppevælger i en formular eller CTA. Hvis begge kontroller bruger lignende etiketter, ved læsere måske ikke, om de ændrer synligt indhold eller indsender en præference.

Anatomi

Anatomi består af én mærket container, én ordnet fanebladliste og ét panel for hvert faneblad. Skærmbilledet skal vise inaktive paneler i DOM-inpektøren såvel som den synlige tilstand, fordi tilstedeværelse i kilden er en del af elementet, ikke en implementeringsdetalje.

1. Fælles titel: Angiver det fælles spørgsmål eller den fælles opgave, som hvert panel adresserer.
2. Fanebladliste: Grupperer to til fem sideløbende etiketter i en stabil forfattet rækkefølge.
3. Fanebladsetiket: Navngiver en målgruppe, kontekst eller tilstand i et sprog, læsere genkender.
4. Valgt tilstand: Kommunikerer det aktive faneblad gennem tekstsemantik og en synlig behandling, ikke kun farve.
5. Panel: Indeholder en selvstændig overskrift og indholdet for én etiket.
6. Programmatisk relation: aria-controls på fanebladet og aria-labelledby på panelet forbinder hvert par.
7. Fallback-rækkefølge: Holder den fælles titel, etiketter og alt panelindhold meningsfuldt, når scripts eller styling ikke kører.

Afstand, kant, indikatorform, animation og breakpoint tilhører gengiveren. Forfattere styrer etiketter, kildeordning, panelindhold og en valgfri stabil fragmentidentifikator.

Designeksempler

Komponenten understøtter fire varianter. Hver variant bruger den samme indholdsmodel og DOM-krav.

Personafaneblade: Brug rolleetiketter, når arbejdsgange, dokumentation eller næste handlinger ægte adskiller sig efter læser. Foretræk etableret kundesprog såsom “Interne teams” frem for opfundne personaer som “Vækstguruer.”

Kontekstfaneblade: Brug ikke-persona-tilstande såsom teamstørrelse, driftsmodel eller implementeringstilstand. Den fælles titel skal navngive den skiftende dimension, så etiketterne ikke forveksles med sidenavigation.

Vertikale faneblade: Brug kun, når etiketter har brug for mere horisontal plads, og der ikke er mere end fem. DOM- og tastaturrækkefølge forbliver faneblad ét til faneblad fem, efterfulgt af deres tilknyttede paneler i henhold til den valgte tilgængelige implementering.

Small-viewport og fallback-tilstand: Etiketter kan scrolle horisontalt, når en synlig indikation gør overløb tydeligt, eller gengiveren kan udstille paneler som stablede markerede sektioner. Den må ikke afkorte etiketter til tvetydige fragmenter eller fjerne inaktivt indhold fra HTML’en.

Parametre

Indholdskontrakten holder relationen eksplicit, mens visuel og responsiv adfærd overlades til gengiveren.

Etiketter er attributter, fordi de betjener kontrollen; paneltitler kommer fra den første overskrift, fordi de tilhører indholdet. De to kan være ens, men en kortfattet fanebladsetiket kan mappe til en fyldigere, udtrækkelig paneloverskrift. Panelbrødtekster tillader afsnit, en kort liste, inline-kode, ét billede og én kontekstuel handling. De tillader ikke endnu et fanebladssæt, accordion, datatabel, formular, videoafspiller eller flertrinsprocedure.

Syntaks og kodeeksempler

Alle tre notationer bevarer én titel, ordnede etiketter, paneloverskrifter, panelbrødtekster, stabile ID’er og den oprindelige standard. Det bærbare Markdown-direktiv er den kanoniske forfattede form.

Bærbart Markdown-direktiv

:::tabs-persona-switcher{default=content-teams variant=horizontal}
## Vælg dit team

::item{label="Content teams" id=content-teams}
### Gør briefen til et gentageligt udkast

Start med det krævede svar, dokumentation og elementsæt. Udkast ræsonnementet fuldt ud, før du anvender komponenter.
::

::item{label="SEO teams" id=seo-teams}
### Verificer opdagelse og udtrækning

Inspicer den gengivne HTML, interne links, overskrifter og strukturerede felter. Bekræft, at hvert panel ankommer i det oprindelige svar.
::

::item{label="Team leaders" id=team-leaders}
### Gennemgå systemet, ikke kun siden

Godkend det fælles løfte én gang, og gennemgå derefter, hvor hver målgruppe ægte har brug for en anden arbejdsgang, dokumentation eller næste handling.
::
:::

Den overordnede brødteksts første overskrift mappes til title. Hvert indlejret emne tager label og id fra attributter, mapper sin første overskrift til item.title og resten til item.content.

Hugo shortcode

{{< tabs-persona-switcher title="Choose your team" default="content-teams" variant="horizontal" >}}
  {{< tab-item label="Content teams" id="content-teams" title="Turn the brief into a repeatable draft" >}}
  Start with the required answer, evidence, and element set. Draft the reasoning in full before applying components.
  {{< /tab-item >}}
  {{< tab-item label="SEO teams" id="seo-teams" title="Verify discovery and extraction" >}}
  Inspect the rendered HTML, internal links, headings, and structured fields. Confirm that every panel arrives in the initial response.
  {{< /tab-item >}}
  {{< tab-item label="Team leaders" id="team-leaders" title="Review the system, not just the page" >}}
  Approve the shared promise once, then review where each audience genuinely needs a different workflow, proof point, or next action.
  {{< /tab-item >}}
{{< /tabs-persona-switcher >}}

Adapteren bruger kun navngivne parametre. Den skal gengive alle emnebrødtekster under serverresponsen, afvise duplikerede ID’er og initialisere interaktion uden at omskrive indholdsmodellen.

WordPress-blok

<!-- wp:amicited/tabs-persona-switcher {"title":"Choose your team","default":"content-teams","variant":"horizontal"} -->
  <!-- wp:amicited/tab-item {"label":"Content teams","id":"content-teams","title":"Turn the brief into a repeatable draft"} -->
  <p>Start with the required answer, evidence, and element set. Draft the reasoning in full before applying components.</p>
  <!-- /wp:amicited/tab-item -->
  <!-- wp:amicited/tab-item {"label":"SEO teams","id":"seo-teams","title":"Verify discovery and extraction"} -->
  <p>Inspect the rendered HTML, internal links, headings, and structured fields. Confirm that every panel arrives in the initial response.</p>
  <!-- /wp:amicited/tab-item -->
  <!-- wp:amicited/tab-item {"label":"Team leaders","id":"team-leaders","title":"Review the system, not just the page"} -->
  <p>Approve the shared promise once, then review where each audience genuinely needs a different workflow, proof point, or next action.</p>
  <!-- /wp:amicited/tab-item -->
<!-- /wp:amicited/tabs-persona-switcher -->

WordPress bør begrænse indre blokke til registrerede fanebladsemner. Forhåndsvisning, gemt markup og frontend-gengivelse skal bevare hvert panel; redaktørens bekvemmelighed må ikke gøre inaktive emner til klient-fetchet indhold.

Eksempler

Godt eksempel

Vælg en implementeringssti

Hostet platform — Lancér uden at vedligeholde infrastruktur

Tilslut den godkendte datakilde, konfigurér roller, og validér output i et staging-miljø. Leverandøren vedligeholder runtime-opdateringer og overvågning; dit team ejer indholdsgodkendelse og adgangsgennemgang.

Selv-hostet — Kontrollér implementering og datagrænser

Implementér den understøttede pakke i dit miljø, tilslut den samme godkendte datakilde, og tildel en ansvarlig for opgraderinger, overvågning, backups og adgangsgennemgang.

Dette virker, fordi begge paneler besvarer det samme implementeringsspørgsmål, navngiver den operationelle forskel og indeholder sammenlignelige ansvarsområder. “Hostet platform” og “Selv-hostet” er genkendelige etiketter. Den fælles beslutning forbliver klar, hvis begge paneler flades ud i kildeordning.

Dårligt eksempel

Udforsk alt

Oversigt: Vores platform gør moderne teams mere effektive.

Pris: Kontakt salg for et personligt tilbud og vigtige kontraktbetingelser.

Sikkerhed: Læs vores sikkerhedsdokumentation.

Karriere: Bliv en del af vores voksende team.

Dette er sidenavigation forklædt som faneblade. Panelerne besvarer ikke ét fælles spørgsmål, etiketterne blander køberinformation med virksomhedsindhold, og vigtige prisbetingelser er skjult bag en interaktion. Erstat sættet med almindelige sidesektioner og rigtig navigation. Hvis prismuligheder har brug for samtidig evaluering, brug en pris- eller sammenligningsstruktur frem for faneblade.

Skemamarkup og tilgængelighed

Faneblade og personaskiftere opretter ikke en dedikeret Schema.org-type. Deres indhold forbliver en del af den omsluttende Article, TechArticle, Product eller WebPage, når den pågældende side uafhængigt kvalificerer sig. Marker ikke faneblade som ItemList blot fordi de gentages, og generér ikke flere Person-entiteter fra personaetiketter. En etiket som “Agentur” beskriver en læsersti, ikke en faktuel entitetspåstand.

Brug WAI-ARIA fanebladsmønsteret kun, når grænsefladen faktisk opfører sig som faneblade. Containeren har role="tablist"; hver kontrol har role="tab", et unikt ID, aria-controls og en præcis aria-selected-værdi; hvert panel har role="tabpanel" og aria-labelledby. Brug knapper til kontroller, ikke links med falske destinationer. Det valgte faneblad tilhører sidens fanebladsrækkefølge; inaktive faneblade bruger roving tabindex="-1" og forbliver tilgængelige med piletasterne. Home og End flytter til første og sidste faneblad. Aktivering må kun følge fokus, når panelskift er øjeblikkeligt; ellers aktiverer Enter eller Mellemrum det fokuserede faneblad.

Fokus skal forblive forudsigeligt. Valg af et faneblad skubber ikke automatisk fokus ind i dets panel. Et panel kan bruge tabindex="0", når dets første indhold ikke ellers er fokuserbart, så tastaturbrugere kan flytte ind i det. En synlig fokusindikator og valgtindikator skal adskille sig, og ingen må udelukkende stole på farve.

Alle paneler skal gengives i den oprindelige HTML-respons. Skjulning af inaktive paneler med hidden, CSS eller en progressivt forbedret ækvivalent er acceptabelt; at oprette dem først efter et klik er ikke. Uden JavaScript skal fallbacken udstille hvert mærket panel i kildeordning eller levere rigtige links til servergengivne destinationer. Stabile fragmenter kan aktivere et panel, men den kanoniske side forbliver én URL. Test zoom, smalle skærme, lange oversatte etiketter, skærmlæserrelationer, tastaturordning og scriptfejl.

Skriveregler

Begynd med det fælles spørgsmål. Hvis hvert foreslået panel besvarer et andet spørgsmål, brug ikke faneblade. Skriv to til fem emner, med tre eller fire foretrukket. Hold etiketter på ét til fire ord og 28 tegn hvor muligt. Brug parallel grammatik: alle roller (“Redaktører / Anmeldere”), alle tilstande (“Hostet / Selv-hostet”) eller alle stadier (“Planlæg / Producer / Mål”). Bland ikke en rolle, et verbum og en marketingfrase.

Giv hvert panel en overskrift på 3–10 ord, der navngiver både den relevante sti og dens resultat, når fanebladsetiketten alene er utilstrækkelig. Skriv 40–180 ord per panel, med 300 som et absolut maksimum. Paneler bør have sammenlignelig dybde, men de behøver ikke identiske ordantal. Brug direkte sprog og konkrete forskelle i opgaver, dokumentation, tilladelser, begrænsninger eller handlinger. At ændre kun pronominerne fra “du” til “dit team” retfærdiggør ikke et andet panel.

Hold fælles information uden for elementet. Gentagelse af den samme indledende sætning i hvert panel skaber vedligeholdelsesdrift og får udtrukne passager til at se duplikerede ud. Læg forskelle inden i paneler, og gør hver forskel eksplicit nok til at overleve udtrækning. Foretræk “Agenturteams kan tildele roller på klientniveau” frem for “Du får mere kontrol,” som mister sit emne, når det adskilles fra den valgte etiket.

Læg aldrig disse ind i et fanebladssæt:

• Sidens eneste definition, direkte svar, konklusion, sikkerhedsadvarsel, juridiske kvalifikation, berettigelsesregel eller kildeangivelse.
• Sekventielle trin, som hver læser skal fuldføre, eller forudsætninger, der styrer indhold uden for ét panel.
• Endnu et fanebladssæt, accordion, karussel, kompleks datatabel, multi-felt formular eller autoafspillende medie.
• Mere end én primær call-to-action per panel, eller handlinger, der fører til ubeslægtede tragtstadier.
• Indhold indlæst først efter interaktion, selv når indlæsningstilstanden er hurtig for et menneske.
• Etiketter som “Andet,” “Mere,” “Generelt” eller “Ressourcer,” der skjuler en udefineret relation.

Hvis hvert panel overstiger 300 ord, har brug for sit eget dokumentationssæt eller målretter en anden søgehensigt, udgiv dedikerede sektioner eller sider. Hvis læsere har brug for at sammenligne flere kriterier på én gang, brug en tabel. Hvis indholdet kun er valgfri detalje, brug prosa eller en accordion i henhold til relationen.

Indlægstyper, der bruger det

Feltet postTypes i frontmatter er kilden til denne tabel. Inklusion betyder, at formatet kan understøtte faneblade; det gør dem ikke obligatoriske.

QA-tjekliste

• Et fælles spørgsmål: Hvert panel besvarer det samme afgrænsede spørgsmål for en anden målgruppe, kontekst eller tilstand.
• Passende antal: Sættet indeholder to til fem faneblade, fortrinsvis tre eller fire, med kortfattede parallelle etiketter.
• Synligt fælles svar: Definitionen, kernesvaret, obligatorisk kvalifikation og konklusion forbliver uden for fanebladssættet.
• Oprindelig DOM-tilstedeværelse: Hvert panel og dets fulde forfattede indhold fremgår af den oprindelige servergengivne HTML.
• Eksplicit kontekst: Hver paneloverskrift og indledende sætning forbliver forståelig, når den udtrækkes uden den visuelle fanebladstilstand.
• Korrekte relationer: Faneblads- og panel-ID’er er unikke; aria-controls og aria-labelledby parrer dem korrekt.
• Tastaturadfærd: Pil, Home, End, Enter, Mellemrum, Tab og Shift+Tab opførsel matcher den valgte aktiveringsmodel.
• Fokusklarhed: Fokus og valg er visuelt adskilte, og valg flytter ikke fokus uventet.
• Stabil fallback: Scriptfejl udstiller mærket indhold eller brugbare servergengivne destinationer uden at miste information.
• Responsiv adfærd: Etiketter forbliver komplette og findbare ved smalle bredder, 200% zoom og med længere oversat tekst.
• Sikker placering: Komponenten adskiller ikke et krav fra dokumentation, en advarsel fra dens rækkevidde eller forudsætninger fra instruktioner.
• Ingen kompleks indlejring: Paneler indeholder afgrænset prosa og simpelt understøttende indhold, ikke et andet interaktionssystem.
• Skemarestriktion: Gengiveren opfinder ikke liste-, person- eller målgruppeskema fra præsentationsetiketter.
• Notationsparitet: Markdown, Hugo og WordPress bevarer samme rækkefølge, ID’er, standard, etiketter, overskrifter og panelbrødtekster.

En anmelder bør afvise komponenten, når inaktivt indhold kræver en klik-udløst netværksanmodning, når væsentlig information kun eksisterer inden for ét panel, eller når etiketterne ikke beskriver sideløbende stier. Det er indholds- og arkitekturfejl; visuel forfining kan ikke reparere dem.

FAQ

De strukturerede FAQ-indgange i frontmatter adresserer indeksering, fragment-URL’er, fanebladantal, call-to-action-knapper og skelnen mellem faneblade og accordions. De er bevidst placeret uden for det interaktive element, så hver læser og gengiver modtager den samme implementeringsvejledning.